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
Nội dung trích xuất từ tài liệu:
Performing Application FilteringPerforming Application FilteringApplication 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 theOSI model. Application filtering is one of the two primary components of an applicationproxy firewall, the other being the proxy functionality provided by the firewall. Chapter2, Firewall Basics, and Chapter 8, Application Proxy Firewalls, discuss applicationproxy firewalls in more detail.The purpose of application filtering is to enforce a specific security policy on variousservices provided through the firewall. Whereas network firewalls enforce policy-basedon information between Layers 3 and 4, an application firewall goes further. Considerthat an attacker can compromise a web server behind a firewall by attacking through theweb service. Attacks such as Structured Query Language (SQL) injection, cross-sitescripting, and viruses and worms represent significant problems because they attack theend host through the specific port that is required to be open in the network firewall. Tosolve this problem, many vendors and some open source efforts have developed firewallsthat can inspect the data payload of the packets passing through the firewall anddetermine whether they violate the security policy of the end host. If they do violate thepolicy, 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 betweenthe client and the server is complex and can be made more so if the protocol or the data inthe communication expands or increases the complexity of the transaction. Protocols suchas eXtensible Markup Language (XML) and Simple Object Access Protocol (SOAP)make web application firewalls especially tricky. To provide proper web applicationsecurity, the application firewall must have a detailed understanding of legitimatetransactions, 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 otherHTTP methods; session IDs and session cookies; XML and SOAP schemas; SQLqueries; and much more.Many vendors have focused on developing web application firewalls because of the widearray 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 fromcompromising 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 fromsimple HTML to XML to Web Service Definition Language (WSDL) and a whole rangeof Common Gateway Interface (CGI) programs. Many end users believe that the simplesolution to web security is Secure Sockets Layer (SSL). When they want to secure theirweb application, they simply use an SSL-capable web server and restrict the traffic toTCP port 443. However, this belief is certainly a misconception. An attacker need haveaccess only to the web server port to attack the application running on the server, not theweb server itself. In the case of SSL, it just means that the attack happens to beencrypted, 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. Theserver is only accessible through TCP port 443 (HTTPS). Example 14-1 shows usingTelnet to access a server on TCP port 443 (HTTPS).Example 14-1. Using Telnet to Access a Server on TCP Port 443 (HTTPS)4 $ telnet 10.16.17.223 443Trying 10.16.17.223...Connected to 10.16.17.223.Escape character is ^].GET / HTTP/1.0400 Bad RequestBad RequestYour browser sent a request that this server could not understand.Reason: Youre speaking plain HTTP to an SSL-enabled server port.Instead use the HTTPS scheme to access this URL, please.Hint: https:// www.innocentvictimcompany.com/Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7d DAV/2PHP/4.3.9 Server at www.innocentvictimcompany.com Port 443Connection to 10.16.17.223 closed by foreign host.A simple connection is clearly not understood by the server. To get around this, theattacker uses OpenSSL, as shown in Example 14-2.Example 14-2. OpenSSL3 $ openssl s_client -connect 10.16.17.223:443CONNECTED(00000003)depth=0 /C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=IdoDubrawsky/emailAddress=idubraws@dubrawsky.orgverify error:num=18:self signed certificateverify return:1depth=0 /C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=IdoDubrawsky/emailAddress=idubraws@dubrawsky.orgverify error:num=10:certificate has expirednotAfter=Oct 6 01:35:00 2005 GMTverify return:1depth=0 /C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=IdoDubrawsky/emailAddress=idubraws@dubrawsky.orgnotAfter=Oct 6 01:35:00 2005 GMTverify return:1---Certificate chain 0 s:/C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=IdoDubrawsky/emailAddress=idubraws@dubrawsky.org i:/C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=IdoDubrawsky/emailAddress=idubraws@dubrawsky.org---Server certificate-----BEGIN CERTIFICATE-----MIICqTCCAhICAQAwDQYJKoZIhvcNAQEEBQAwgZwxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNYXJ5bGFuZDEWMBQGA1UEBxMNU2lsdmVyIFNwcmluZzEWMBQGA1UEChMNZHVicmF3c2t5Lm9yZzELMAkGA1UECxMCSVQxFjAUBgNVBAMTDUlkbyBEdWJyYXdza3kxJTAjBgkqhkiG9w0BCQEWFmlkdWJyYXdzQGR1YnJhd3NreS5vcmcwHhcNMDQxMDA2MDEzNTAwWhcNMDUxMDA2MDEzNTAwWjCBnDELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1hcnlsYW5kMRYwFAYDVQQHEw1TaWx2ZXIgU3ByaW5nMRYwFAYDVQQKEw1kdWJyYXdza3kub3JnMQswCQYDVQQLEwJJVDE ...