Performing Application Filtering

Chia sẻ: Tuan Bui Nghia | Ngày: | Loại File: PDF | Số trang:6

Thêm vào BST

Báo xấu

86
lượt xem 7
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Performing Application Filtering

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 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 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Reason: You're 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/2 PHP/4.3.9 Server at www.innocentvictimcompany.com Port 443 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"'
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 Protocol SMTP 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.