Application Layer Gateways
Application layer firewalls, also called proxy firewalls or application gateways, provide a higher level of security than packet-filtering firewalls because they allow the greatest level of control. Application-level proxy servers operate on Layers 3, 4, 5, and 7 of the OSI model, as shown in Figure 3-5.
Most application layer firewalls include specialized application software and proxy servers. A proxy is an application that does work on behalf of something else. Proxy services are special-purpose programs that manage traffic through a firewall for a specific service, such as HTTP or FTP. Proxy services are specific to the protocol that they are designed to forward, and they can provide increased access control, careful detailed checks for valid data, and generate audit records about the traffic that they transfer.
Proxy firewalls act as intermediaries between networks to determine whether to allow the communication to proceed. No direct connection exists between an outside user and internal network resources, because the original connection stops in the proxy and a new connection is set between the proxy and the outside destination. For this reason, the only IP address of the network that is visible from the Internet is the IP address of the outside interface of the proxy. The client connects to the proxy server and submits an application layer request. The application layer request includes the true destination and the data request itself. The proxy server analyzes the request and can filter or change the packet contents. The server makes a copy of each incoming packet, changes the source address, and sends the packet to the destination address. The destination server replies to the proxy server, and the proxy server passes the response back to the client.
Sometimes, application layer firewalls support only a limited number of applications, or even just one application. Some of the more common applications that an application layer firewall might support include email, web services, DNS, Telnet, FTP, Usenet news, Lightweight Directory Access Protocol (LDAP), and Finger.
Application layer firewalls provide several advantages:
-
Application layer firewalls authenticate individuals, not devices: These firewalls typically allow you to authenticate connection requests before allowing traffic to an internal or external resource. This process enables you to authenticate the user requesting the connection instead of authenticating the device.
-
Application layer firewalls make it is harder for hackers to spoof and implement DoS attacks: An application layer firewall enables you to prevent most spoofing attacks, and DoS attacks are limited to the application firewall itself. The application firewall can detect DoS attacks, and thus reduce the burden on your internal resources.
-
Application layer firewalls can monitor and filter application data: You can monitor all data on a connection, so you can detect application attacks such as malformed URLs, buffer-overflow attempts, unauthorized access, and more. You can even control the commands or functions you allow an individual to perform based on the authentication and authorization information.
-
Application layer firewalls can provide detailed logging: Using application layer firewalls, you can generate detailed logs and monitor the actual data that the individual is sending across a connection. This logging can prove extremely useful if a hacker finds a new type of attack, because you can monitor what the hacker does and how the machine does it, and then address the attack. Besides using logging for security purposes, you can use it for management purposes by keeping track of who is accessing what resources, how much bandwidth is used, and how often a user accesses the resources.
The topology in Figure 3-6 represents a typical proxy server deployment. The example in Figure 3-6 shows a client inside the network requesting access to a website. The client browser uses a proxy server for all HTTP requests. Network security policies force all client connections to go through the proxy server. As shown, the browser connects to the proxy server to make requests. Client-side DNS queries and client-side routing to the Internet are not needed when using a proxy server. The client has to reach only the proxy server to make the request.
When the proxy server receives the request from a client, it performs user authentication according to the rules applied to it and uses its Internet connection to access the requested website. It forwards only Layer 3 and Layer 4 packets that match the firewall rules. On the return route, the proxy server forwards only Layer 5 and Layer 7 messages and content that the server allows (that is, traffic that is not seen as malicious) according to the firewall rules.
In spite of how application layer firewalls work, this firewall provides only a limited number of services; however it provides the highest level of filtering for those specific protocols.
The main limitation of application layer firewalls is that they are process intensive because the server evaluates a significant amount of information embedded in many packets. This type of technology requires many CPU cycles and a lot of memory to process every packet that needs inspection, which sometimes creates throughput problems. In addition, the detailed logging can create disk space problems. To address these issues, you can use one of two solutions:
-
A context transfer protocol: Using a context transfer protocol, where identity-specific information tracks users, enables you to perform only authentication and authorization; you cannot monitor data on the connection, only whether the user is authorized to go on the Internet. With this solution however, we cannot talk per se of real firewalling because packets are not checked for their content, but rather based on the validity of the source and destination. It would be similar to a packet filter that has the capability of learning dynamically source and destination and match return traffic on that information it learned dynamically.
-
Monitor only key applications: With this solution, you limit the application layer firewall to process only certain application types (such as email, Telnet, FTP, or web services), and then, perhaps, process only connections to specific internal resources. The problem with this approach is that you are not monitoring all applications and connections, and this creates a security weakness.
Application layer firewalls typically do not support all applications, such as multimedia or peer-to-peer file sharing (to name a few). Instead, they are generally limited to one or a few connection types, typically common applications, such as email, Telnet, FTP, and web services. Therefore, you cannot monitor data on all applications: It monitors data only on applications it intrinsically understands.
Finally, application layer firewalls sometimes require you to install vendor-specific software on the client, which the firewall uses to handle the authentication process and any possible connection redirection. This limitation can create scalability and management problems if you must support thousands of clients.
Dynamic or Stateful Packet-Filtering Firewalls
Stateful packet filters, or stateful firewalls, are the most versatile and therefore the most common firewall technologies in use. Stateful filtering provides dynamic packet-filtering capabilities to firewalls. Stateful inspection is a firewall architecture that is classified at the network layer, although for some applications it can analyze traffic at Layers 4 and Layer 5, too, as shown in Figure 3-7. Some stateful firewalls can analyze traffic up to Layer 7 under special circumstances and additional configuration.
Unlike static packet filtering, which examines a packet based on the information in its header, stateful inspection tracks each connection traversing all interfaces of the firewall and confirms that they are valid. Stateful packet filtering maintains a state table and allows modification of the security rules on-the-fly. The state table is part of the internal structure of the firewall and tracks all sessions and inspects all packets passing through the firewall. If packets have the expected properties that are predicted by the state table, the firewall allows them to pass. The state table changes dynamically according to traffic flow.
Stateful firewalls use a state table to keep track of the actual communication process. From a transport layer perspective, the firewall examines information in the headers of Layer 3 packets and Layer 4 segments. For example, the firewall looks at the TCP header for SYN, reset (RST), acknowledgment (ACK), FIN, and other control codes to determine the state of the connection. In this scenario, the session layer is responsible for establishing and tearing down the connection.
When an outside service is accessed, the stateful packet filter firewall “remembers” certain details of the request by saving the state of the request in the state table. Each time a TCP or User Datagram Protocol (UDP) connection is established for inbound or outbound connections, the firewall logs the information in a stateful session flow table. When the outside system responds to the request, the firewall server compares the received packets with the saved state to allow or deny network access.
The stateful session flow table contains the source and destination addresses, port numbers, UDP connection information and TCP sequencing information, and additional flags for each TCP connection associated with a particular session. This information creates a connection object against which the firewall compares all inbound and outbound packets. The firewall permits data only if an appropriate connection exists to validate the passage of that data.
More advanced stateful firewalls include the capability to parse FTP port commands and update the state table to allow FTP to work transparently through the firewall. Advanced stateful firewalls can also provide TCP sequence number randomization, and DNS query and response matching to ensure that the firewall allows packets to return only in response to queries that originate from inside the network. These features reduce the threat of TCP RST flood attacks and DNS cache poisoning. Some stateful firewalls can also check the validity of protocol commands to ensure that only more intrusive and dangerous commands are not admitted on our network.
There is a potential disadvantage of using stateful filtering that you must consider. Although stateful inspection provides speed and transparency, packets inside the network must make their way to the outside network. This can possibly expose internal IP addresses to potential hackers. Most firewalls incorporate stateful inspection, Network Address Translation (NAT), and proxy servers for added security.
To overcome this disadvantage, stateful firewalls keep track of the state of a connection and whether the connection is in an initiation, data transfer, or termination state. This information is useful when you want to deny the initiation of connections from external devices but allow your users to establish connections to these devices and permit the responses to come back through the stateful firewall.
Figure 3-8 shows a successfully established HTTP TCP session that leads to a dynamic ACL rule entry on the outside interface that permits response packets from the web server to the client.
Stateful packet-filtering firewalls are good to use for the following applications:
-
As a primary means of defense: In most situations, a stateful firewall is used as a primary means of defense by filtering unwanted, unnecessary, or undesirable traffic.
-
As an intelligent first line of defense: Networks use routing devices that support a stateful function as a first line of defense or as an additional security boost on perimeter routers.
-
As a means of strengthening packet filtering: Stateful filtering provides more stringent control over security than packet filtering does, without adding too much cost.
-
To improve routing performance: Stateful packet-filtering devices perform better than packet filters or proxy servers. Stateful firewalls do not require a large range of port numbers to allow returning traffic back into the network, providing that the firewall is familiar with the protocol and its behavior. The state table determines whether a packet is returning traffic. If it is not returning traffic, the filtering table filters the traffic.
-
As a defense against spoofing and DoS attacks: Stateful packet filtering works on packets and connections. In particular, stateful firewalls track the state of the connection in the state table listing every connection or connectionless transaction. By determining whether packets belong to an existing connection or are from an unauthorized source, stateful firewalls allow only traffic from connections that are listed in the table. As an example, during the three-way handshake of a TCP session, the firewall tracks the flag and therefore can predict what the following exchange between the client and the server will be. When the firewall removes a connection from the state table (for instance, because of the connection termination following the TCP four-way handshake as a goodbye), the firewall does not allow any more traffic from that device. In addition, the stateful firewall can log more information than a packet-filtering firewall can, including when a connection was set up, how long it was up, and when it was torn down. This logging makes connections harder to spoof.
Stateful firewalls have the following limitations:
-
Stateful firewalls cannot prevent application layer attacks: For example, your network might allow traffic to port 80 on a web server. Your stateful firewall examines the destination address in the Layer 3 packet and the destination port number in the segment. If there is a match, the stateful firewall allows the incoming and outgoing traffic. One problem with this approach is that the stateful firewall does not examine the actual contents of the HTTP connection.
-
Not all protocols are stateful: UDP and Internet Control Message Protocol (ICMP) are not stateful, so stateful firewalls can provide only limited support for these protocols. For example, UDP has no defined process for how to set up, maintain, and tear down a connection. Routers define UDP connections on an application-by-application basis.
-
Some applications open multiple connections: On earlier (more basic) stateful firewalls, if the client was inside the network and the server was outside the network, both stateful and packet-filtering firewalls had problems dealing with the data connection that the FTP server established to the client. You needed to open a whole range of ports to allow this second connection. Cisco IOS Firewall does not have this problem.
-
Stateful firewalls do not support user authentication: Stateful firewall technology itself does not support user authentication. Add-on functionality is required to provide a feature such as proxy authentication.
0 comments
Post a Comment