Java Applets

Java applets are scripts that allow a web designer to implement many useful web server features. Java is very popular because of its platform independence: Java applets can be made and run on any machine that supports Java. Given its widespread use and usefulness, however, it has been the target of hackers. With older implementations of Java, hackers successfully downloaded rogue Java code to a user's desktop, allowing the hacker to take control. Sometimes the hacker planted a Trojan horse or worm to control the user's desktop remotely. In other instances, the hacker maliciously deleted user files or erased the entire disk drive.

Java Inspection

Some form of control is necessary to prevent hackers from attacking desktops using Java. Java blocking, or filtering, is the capability to selectively filter Java applets downloaded through HTTP connections. A few solutions are available to you:

CBAC inspection
URL filtering
HTTP proxies

The first solution, CBAC inspection, is the simplest to implement. When configured for Java filtering, CBAC inspection monitors HTTP connections for embedded Java applets. CBAC allows applets from only a list of allowed sites; for all other websites, CBAC blocks the download of the applets. Configuration of friendly and unfriendly Java sites is done with a simple standard ACL. Java inspection gives you more control over the sites that your users access, as well as the content that they can see from Java-enabled sites.

CAUTION

CBAC can inspect Java applets in only open HTTP connections. It cannot inspect Java applets if they have been compressed into a different format, such as .zip or .tar files; if they have been encrypted; or if they have been downloaded through FTP, gopher, or a nonstandard HTTP port that has not been mapped by PAM.

Java Blocking

Chapter 9 briefly covered how CBAC can inspect HTTP traffic and how to configure it. This section expands on how to set up Java filtering with CBAC. Filtering of Java applets is done with HTTP inspection. Use the following command to enable Java applet inspection:


Router(config)# ip inspect name inspection_name http

  [java-list standard_ACL_#] [alert {on | off}] [audit-trail {on | off}]

  [timeout seconds]

For Java inspection, use a protocol of http, and then create a standard IP ACL and reference this ACL in the ip inspect name command. The java-list parameter specifies the standard IP ACL to use for filtering of applets.

CAUTION

CBAC inspection of Java applets is CPU intensive for the router. Therefore, you should use this feature only if absolutely necessary. My recommendation is to filter all traffic from the website or network that has known malicious Java applets. This can be done with a simple extended ACL statement or statements, which is much less taxing on your router. However, if you need to download web content from a site but you do not trust its Java applets, be forewarned about the burden that you will be placing on your router when CBAC inspects for Java applets.

Java Blocking Example

Take a look at a simple example of setting up CBAC for Java inspection (see Figure 10-1). The administrator at this site found that a new virus was floating around the internal network. After some investigation, the administrator learned that the virus was infiltrating his users' PCs through Java applets from one commonly used web service provider(200.1.1.0/24). Unfortunately, the administrator could not block all HTTP traffic from this site because his internal users needed legitimate access to these web servers. After contacting this web service company about the problem and not getting much help, the administrator decided to use CBAC Java inspection to prevent applets from being downloaded from this site and spreading the virus to his users' computers.

Figure 10-1. Java Blocking

graphics/10fig01.gif

This example focuses only on the Java-blocking component of CBAC. Note that you still need to complete the rest of the configuration based on this company's specific policies. Example 10-1 shows the stripped-down configuration for Java applet filtering.

Example 10-1. Using CBAC to Filter Java Applets


Router(config)# ip access-list extended EXTERNAL-ACL

Router(config-ext-nacl)# ! <--add other ACL policy statements-->

Router(config-ext-nacl)# deny ip any any

Router(config-ext-nacl)# exit

Router(config)# ip access-list standard JAVA-ACL

Router(config-std-nacl)# deny 200.1.1.0 0.0.0.255

Router(config-std-nacl)# permit any

Router(config-std-nacl)# exit

Router(config)# ip inspect name CBAC-EXAMPLE http java-list JAVA-ACL

Router(config)# ! <--add other CBAC inspection statements-->

Router(config)# interface ethernet0

Router(config-if)# ip access-group EXTERNAL-ACL in

Router(config-if)# ip inspect CBAC-EXAMPLE out

In this example, the external ACL filters traffic entering the internal network. Note that I put a place marker where this company will add its ACL statements to implement its specific policies. Below this is a standard named ACL that denies traffic from 200.1.1.0/24 but permits everything else. I have included only one statement in the inspection rules for CBAC, but I added a placeholder for the other CBAC inspection statements needed for implementing a stateful firewall based on this company's policies. Notice that the inspection rule filters Java applets based on the standard ACL, JAVA-ACL, which will deny applets from 200.1.1.0/24 only.

After you have enabled this feature, test it by trying to access web pages from the offending site that uses Java applets. When you do this, CBAC filters the applet and you should see the following alert message (assuming that you have not disabled alerts) on your router's console:


%FW-4-HTTP_JAVA_BLOCK: JAVA applet is blocked from

  (200.1.1.5:80) to (192.1.1.22:45323).

As you can see from this output, CBAC is blocking applets from the 200.1.1.0/24 network.

NOTE

Java blocking with CBAC is not a scalable solution because it requires you to list which sites are "friendly" or "unfriendly." Typically, you should use this feature to block Java applets from known malicious sites or networks; otherwise, you should use another solution, such as an HTTP proxy or URL filtering with an external policy server. I discuss the latter option in the next section.