|
|
|
|
Application-Level Firewalls: Smaller Net, Tighter Filter
|
 |
|
March 21, 2003
By Mike Fratto
|
|
Just when you thought a properly configured firewall would guard your perimeter, along comes the next zero-day vulnerability knocking over your public servers and letting attackers in the front door. Didn't you buy a firewall to stop such attacks? Well, we're going to let you in on a secret: You probably bought a stateful packet-filtering firewall that's effective at blocking network-level attacks but leaves any server available to the world still extremely vulnerable to application-layer attacks.
Application-layer firewalls differ from stateful packet-filtering and circuit-level gateways in several ways. First, application-layer firewalls support multiple application proxies on a single firewall. The proxies sit between the client and server passing data between the two endpoints. Suspicious data is dropped and the client and server never communicate directly with each other. Because application-level proxies are application-aware, the proxies can more easily handle complex protocols like H.323, which is used for videoconferencing and VoIP (voice over IP), and Oracle SQL*Net. Application proxies can be transparent to the client and server--no configuration is required on the client or the server--or nontranparent, letting the client and server address the proxy server directly. Transparency versus nontransparency is a matter of implementation and address hiding rather than security.
|
|
Second, because application-level proxies act as both client and servers for a protocol, they can enforce protocol conformance. For example, attacks over HTTP that violate the protocol, such as those that send non-ASCII data in the header fields, should be dropped because of nonconformance. An example is the IIS printer ISAPI buffer overflow, Bugtraq ID 2674, which inserts an overly long string along with non-ASCII characters in the host field. Exploits that do not violate HTTP, however, will pass through the application proxy. Application proxies handle complex protocols, such as H.323 and SQL*Net, which open dynamic ports.
Finally, application proxies look deeper into sessions and can make pass/drop decisions based on information in the application-protocol headers or in the application payload. SMTP application proxies, for example, can be configured to allow only necessary SMTP commands, such as helo, mail from: and rcpt to:, to pass through the firewall while blocking other commands, such as expn and vrfy, which try to expand a list and verify that an account exists, respectively, and are used by attackers and spammers to enumerate e-mail accounts. Other protocol-specific items like MIME type and message size can be used to filter traffic as well. Application proxies used in firewalls rarely delve into the protocol payload to make pass/fail decisions. However, there are HTTP-specific proxies that do examine HTTP data and form/fields (see "Proxies Add a Protective Shield").
|
|
|
|
|
|
|
|
RSS
