Performing Application Filtering
| Application filtering is one of the most difficult types of filtering that firewalls perform, because it requires the firewall to process the data at the application layer (Layer 7) of the OSI model. Application filtering is one of the two primary components of an application proxy firewall, the other being the proxy functionality provided by the firewall. Chapter 2, "Firewall Basics," and Chapter 8, "Application Proxy Firewalls," discuss application proxy firewalls in more detail. The purpose of application filtering is to enforce a specific security policy on various services provided through the firewall. Whereas network firewalls enforce policy-based on information between Layers 3 and 4, an application firewall goes further. Consider that an attacker can compromise a web server behind a firewall by attacking through the web service. Attacks such as Structured Query Language (SQL) injection, cross-site scripting, and viruses and worms represent significant problems because they attack the end host through the specific port that is required to be open in the network firewall. To solve this problem, many vendors and some open source efforts have developed firewalls that can inspect the data payload of the packets passing through the firewall and determine whether they violate the security policy of the end host. If they do violate the policy, these devices can prevent the attacks from affecting the target system. Applications That Are Hard to FirewallThe difficulty with application firewalls stems from the fact that the transaction between the client and the server is complex and can be made more so if the protocol or the data in the communication expands or increases the complexity of the transaction. Protocols such as eXtensible Markup Language (XML) and Simple Object Access Protocol (SOAP) make web application firewalls especially tricky. To provide proper web application security, the application firewall must have a detailed understanding of legitimate transactions, including the use of URLs; different HTTP methods such as GET (retrieving data from a web server), POST (transmitting data to a web server), and other HTTP methods; session IDs and session cookies; XML and SOAP schemas; SQL queries; and much more. Many vendors have focused on developing web application firewalls because of the wide array of difficulties faced in providing security to such a ubiquitous protocol as HTTP. Other applications that use protocols such as Simple Mail Transport Protocol (SMTP) and Secure Shell (SSH) also require significant filtering to prevent an attacker from compromising a service that is open in a network firewall. Web Applications (XML, SOAP, WSDL, CGI)Consider web applications. These applications may use a wide variety of protocols from simple HTML to XML to Web Service Definition Language (WSDL) and a whole range of Common Gateway Interface (CGI) programs. Many end users believe that the simple solution to web security is Secure Sockets Layer (SSL). When they want to "secure" their web application, they simply use an SSL-capable web server and restrict the traffic to TCP port 443. However, this belief is certainly a misconception. An attacker need have access only to the web server port to attack the application running on the server, not the web server itself. In the case of SSL, it just means that the attack happens to be encrypted, because the application (the web server software) is what is being attacked. How can this be? An example illustrates this point. An attacker finds a web server running on the Internet with a particular application. The server is only accessible through TCP port 443 (HTTPS). Example 14-1 shows using Telnet to access a server on TCP port 443 (HTTPS). Example 14-1. Using Telnet to Access a Server on TCP Port 443 (HTTPS)
A simple connection is clearly not understood by the server. To get around this, the attacker uses OpenSSL, as shown in Example 14-2. Example 14-2. OpenSSL
As you can see, the attacker can get more information from the server this time using OpenSSL. To run a web scanner against an SSL-enabled server, the attacker need only set up an SSL tunnel to the server and then scan through that tunnel. The attacker can easily do so by using the open source utility Stunnel. This scenario is where web application firewalls work. The precise methods of blocking applications differ from firewall to firewall and application to application. However, by inspecting the traffic more deeply than a network firewall and by applying specific, defined (typically by the firewall or security administrator or by the vendor that provides the application filtering capabilities) security policies to that traffic, the application firewall can identify attacks and prevent them before they ever reach the server. This inspection requires intimate knowledge of the protocol being used (XML, SOAP, WSDL, and so on) as well as the capability to identify attack strings. If, as in the web server example, the server requires authentication using a username and password combination, but the programmer did not bother to check to make sure the length of the username or password did not exceed a specific value, an attacker can try to overflow a value in the application by sending a large string of characters to the CGI: perl-e 'print "GET /cgi-bin/login?user=ido&password=","A"x2050,"HTTP/1.0\n\n"'This attempt may have no effect or it may cause the CGI to return a value that the attacker can then use to further try to refine the attack. For complex protocols such as XML, SOAP, and WSDL, the problem becomes more onerous because the attack may be embedded within the XML schema or in the SOAP transaction. The application firewall must be able to understand these protocols and compare them against a specific security policy developed by the administrators and the application developers to ensure that any part of the protocol that is outside the policy is blocked from reaching the protected application/server. Simple Mail Transport ProtocolSMTP is another protocol that presents problems for firewalls. SMTP uses a small command set to transmit e-mail from one server to another. But the data in the e-mail, the payload, can provide a significant problem. One of the most troublesome byproducts of SMTP is spam, or unsolicited e-mail that most folks do not want. Examples of spam include simple unsolicited commercial e-mail (UCE); e-mail with malicious content, such as viruses, Trojans, and worms; and e-mails that attempt to scam or otherwise rip off an unsuspecting reader, such as the Nigerian lottery scam e-mails. Today, spam accounts for approximately 40 percent of all e-mail on the Internet.[1] By the end of 2006, it is estimated that 80 percent of the e-mail on the Internet could be spam.[2] Antispam and e-mail-filtering capabilities in firewalls are adding to the overall defense against spam. Many vendors have dedicated e-mail or spam "firewalls" that are designed to stop the inflow of unwanted bulk e-mail. Unlike traditional network firewalls, these devices only filter SMTP traffic. In addition, these vendors frequently provide antivirus capabilities in such devices to provide customers with an all-in-one solution to the problems of e-mail spam and viruses. However, network firewall vendors are also adding capabilities to their offerings to identify spam and viruses that pass through their network firewall devices, providing for a single device that performs all network traffic and e-mail filtering. The difficulty remains that e-mail scanning for spam and viruses requires intensive operations that are best left to dedicated application firewalls whereas traffic filtering at Layer 2 and Layer 3 is handled by the network firewall, typically in a complementary fashion to each other. In addition to commercial offerings, there are many antispam and antivirus open source projectssuch as SpamAssassin, MailScanner, MIMEDefang, ClamAV, and many othersfor those individuals or organizations who choose to go that route. |
EAN: 2147483647
Pages: 147