Configuring ActiveX and Java

ActiveX controls and Java applets are similar in functionality, but the ActiveX control has additional capabilities because it can run with the same privileges as the user running the application. With either of these applications, a potential risk for malicious use always exists. Because the FWSM has the capability of removing ActiveX objects and/or Java applets contained within HTTP traffic, you have options.

Filtering ActiveX replaces the object and applet tags with comments. The filter activex command also comments out Java files, images, and objects that are embedded within object tags.

NOTE

Packets that are fragmented cannot be blocked.

If you plan to use ActiveX or Java filtering, HTTP inspection must be enabled, or you will wonder why the filtering is not working. If the default global policy is used, the following commands need to be added:

policy-map global_policy class inspection_default inspect http

ActiveX and Java are configured using the following command set:

filter {activex I java} {port[-port] I except} local_ip local_mask foreign_ip foreign_mask

In this example, ActiveX is being filtered from 192.168.1.23 to any destination:

filter activex 80 192.168.1.23 255.255.255.255 0.0.0.0 0.0.0.0

A log message will be generated by the FWSM indicating that ActiveX content was filtered.

%FWSM-5-500001: ActiveX content modified src 192.168.1.23 dest 10.29.201.21 on interface Outside

ActiveX control and Java have the potential to be used for malicious intent. Fortunately, the FWSM has the capability to filter both types of content. Filtering will obviously break applications that need ActiveX or Java to operate properly. Use the except option as in URL filtering to allow this behavior from specific address(es).

Was this article helpful?

0 0

Post a comment