10.8 Implications for firewalls

As discussed in this chapter, executable or active content is potentially dangerous and should be avoided in the first place. Unfortunately, this is not always possible and an increasingly large number of Web sites are making use of executable or active content. If these sites are located on the Internet, the corresponding HTTP request messages must pass the (corporate) firewall. Consequently, one may think about strategies and technologies to block executable or active content at the firewall.

Against this background, it is important to note that executable or active content has changed the firewall s role and importance in the overall security landscape (security architecture). The role of a firewall has been to logically separate the insiders (i.e., the ˜ ˜good guys) from the outsiders (i.e., the ˜ ˜bad guys). With the use of executable or active content, this logical separation is difficult, because insiders running executable or active content may effectively become inside assistants for outsiders. In fact, insiders may not even know that they are being (mis)used by outsiders to attack computer systems from the inside.

In the past, several strategies and technologies to block executable or active content at the firewall have been developed, implemented, and partly deployed. For example, in the case of a proxy-based firewall, response content filtering may be used [7]. In response content filtering, the proxy server looks into the content of an HTTP response message. Typically, content filters are designed specifically for a certain type of executable content, and are invoked only if the MIME content type matches one of the content types for which the filter has been configured.

The following examples illustrate some possible response blocking and content filtering mechanisms:

Java applet blocking mechanisms prevent Java applets from being downloaded to computer systems located behind the firewall. A simple strategy takes advantage of the fact that all Java class files begin with the 4-byte hex signature CA, FE, BA, and BE (according to the JVM specification). The strategy is to prevent all inbound files beginning with this signature from being forwarded by the firewall. By proxying protocols, such as HTTP and FTP, such transfers can be detected and blocked. Another commonly suggested strategy is to reject all browser requests via HTTP and FTP for files with names ending in .class. This strategy once enjoyed most of the advantages of the previous strategy, even though there was never any requirement in the JVM specification that class files actually have the suffix .class. Unfortunately, both strategies cannot block other executable or active content, such as JavaScript code or ActiveX controls. Because of JavaScript s inline nature, blocking JavaScript code at the firewall turns out to be difficult.
HTML tag filtering mechanisms allow certain HTML tags to be removed from HTML documents ( applicable for documents of MIME type text/html). This is used in the same way as other filtering mechanisms to prevent the exploitation of known security holes and bugs . For example, it is possible to filter out embedded objects from HTML documents, such as Java applets, ActiveX controls, or JavaScript code. In the case of Java applets, for example, it is possible to scan the HTML documents for < APPLET > tags and rewrite them in a more benign form. The firewall toolkit originally developed by Trusted Information Systems, Inc. (TIS) has been extended accordingly [8]. Similarly, it is possible to scan the HTML documents for tags that are used to incorporate JavaScript code and ActiveX controls.
Virus scanning allows downloaded programs to be scanned for known computer viruses (applicable for documents of MIME type application/octet-stream). By restricting the application of this technology, HTML and ASCII text transfer performance remains unaffected by computer virus scanning.
Similar to virus scanning, various forms of code scanning allow specialized analysis of executable content, such as Java applets and ActiveX controls, inspecting which function calls are made and determining whether they are allowed or not. For example, a software called SurfinGate (developed by Finjan Software ^[22] ) performs this sophisticated type of filtering. Unfortunately, it is not easily decidable whether a specific code segment is malicious or not (we have already mentioned this fact at several places throughout the book).

All mechanisms require use of an application-level gateway or proxy server (i.e., they can not be implemented with a packet filter alone). For example, httpf is a widely deployed open source implementation of a filtering proxy server that is licensed under the GNU General Public License (GPL). ²³ Obviously, a filtering proxy server is not able to protect a client system against malicious code that is already located on the system.

@FN@Further information about httpf is available at http://httpf. sourceforge .net . #FN#

Last but not least, it is important to note that encrypted data streams cannot be parsed or scanned by an application-level gateway or proxy server. This poses some interesting problems with regard to the simultaneous use of cryptographic security protocols, such as IPsec or SSL/TLS, and scanning and filtering technologies. It is certainly a good practice to scan all data streams that are not encrypted. Consequently, we see complementary virus scanners running at firewalls, mail exchange servers, and end systems. This plurality has a positive effect on the overall protection against malicious code.

^[22] http://www.halcyon.com/mclain/ActiveX/welcome.html