Performing Application Filtering
Application filtering is one of the most difficult types of filtering that firewalls perform,
b
ecause 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 Firewall
The 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)
4 $ telnet 10.16.17.223 443
Trying 10.16.17.223...
Connected to 10.16.17.223.
Escape character is '^]'.
GET / HTTP/1.0
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a
href="https://www.innocentvictimcompany.com/"><b>https://
www.innocentvictimcompany.com/</b></a></blockquote></p>
<hr>
<address>Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7d DAV/2
PHP/4.3.9 Server at
www.innocentvictimcompany.com Port 443</address>
</body></html>
Connection to 10.16.17.223 closed by foreign host.
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
3 $ openssl s_client -connect 10.16.17.223:443
CONNECTED(00000003)
depth=0 /C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=Ido
Dubrawsky/
emailAddress=idubraws@dubrawsky.org
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=Ido
Dubrawsky/
emailAddress=idubraws@dubrawsky.org
verify error:num=10:certificate has expired
notAfter=Oct 6 01:35:00 2005 GMT
verify return:1
depth=0 /C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=Ido
Dubrawsky/
emailAddress=idubraws@dubrawsky.org
notAfter=Oct 6 01:35:00 2005 GMT
verify return:1
---
Certificate chain
0 s:/C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=Ido
Dubrawsky/
emailAddress=idubraws@dubrawsky.org
i:/C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=Ido
Dubrawsky/
emailAddress=idubraws@dubrawsky.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICqTCCAhICAQAwDQYJKoZIhvcNAQEEBQAwgZwxCzAJBgNVBAYTAlVT
MREwDwYDVQQIEwhNYXJ5bGFuZDEWMBQG
A1UEBxMNU2lsdmVyIFNwcmluZzEWMBQGA1UEChMNZHVicmF3c2t5Lm9yZz
ELMAkGA1UECxMCSVQxFjAUBgNVBAM
TDUlkbyBEdWJyYXdza3kxJTAjBgkqhkiG9w0BCQEWFmlkdWJyYXdzQGR1YnJh
d3NreS5vcmcwHhcNMDQxMDA2MD
EzNTAwWhcNMDUxMDA2MDEzNTAwWjCBnDELMAkGA1UEBhMCVVMxET
APBgNVBAgTCE1hcnlsYW5kMRYwFAYDVQQHE
w1TaWx2ZXIgU3ByaW5nMRYwFAYDVQQKEw1kdWJyYXdza3kub3JnMQswCQ
YDVQQLEwJJVDEWMBQGA1UEAxMNSWRv
IER1YnJhd3NreTElMCMGCSqGSIb3DQEJARYWaWR1YnJhd3NAZHVicmF3c2t5
Lm9yZzCBnzANBgkqhkiG9w0BAQE
FAAOBjQAwgYkCgYEAwpCwIAhfnPvq9Q+2Y+CuPZoaKMROeUbEV8GcPlFfJO
CrR0CwcQIsGfZVQvgUPVNoBiRavu
9amk4tV6l1bJHZlgRD5bk0tmYRTdvjFUyXPJrcGk493vpqUqYKYX4Nhz7UIm9JIbJ
1SlSo5XhW47rS5QRDrfKVL
PHK4viuX7C56JsCAwEAATANBgkqhkiG9w0BAQQFAAOBgQC4huUgw9ahmLY
LPiuBqrGfSbov1OfeIVB83SJQiUlY
vzVaL/ANaAzcGcPQTobJJ9mgbnCU0C5y1khsX+Y060Ji/
afJPOKSJu45WKXUw87Dty93Baj4+pTzS0Cyh+0dB6t89dpUnq3AABSCclsmCb2J//5
OEdA2ESnOedpHULQKWQ==
-----END CERTIFICATE-----
subject=/C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=Ido
Dubrawsky/
emailAddress=idubraws@dubrawsky.org
issuer=/C=US/ST=Maryland/L=Silver Spring/O=dubrawsky.org/OU=IT/CN=Ido
Dubrawsky/
emailAddress=idubraws@dubrawsky.org
---
No client certificate CA names sent
---
SSL handshake has read 1249 bytes and written 346 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID:
E6F3E3D7B5CCBBFF64C00930A0EE9D056F82ED55F483E0682215EF37342D37E
E
Session-ID-ctx:
Master-Key:
DCE5F0E40DAB7ADF26EEA55A17DAA0E722213B64F229A81ED0CD2E2207CD
9D34A9650D4737AAF33855FD946
2E7E3B5A7
Key-Arg : None
Start Time: 1133540279
Timeout : 300 (sec)
Verify return code: 10 (certificate has expired)
---
HEAD / HTTP/1.0
HTTP/1.1 401 Authorization Required
Date: Fri, 02 Dec 2005 16:23:50 GMT
Server: Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7d DAV/2 PHP/4.3.9
WWW-Authenticate: Basic realm="SnortIDS ACID"
Connection: close
Content-Type: text/html; charset=iso-8859-1
Closed
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"'