You want to configure internal antivirus on your ScreenOS firewall.

Set the antivirus pattern type:

	set av scan-mgr pattern-type standard

Update the signature file the first time manually:

	exec av scan-mgr pattern-update

Link the default antivirus filter profile to a policy:

	set policy id 100 from "Trust" to "Untrust"  "Any" "Any" "Any" nat src permit
	set policy id 100
	   set av ns-profile
	exit

The branch office model of the SSG Series and the NS-5GT features optional integrated antivirus scanning by Kaspersky. It is a very powerful antivirus scanner, delivering high performance for smaller sites. In addition to in-the-wild and polymorphic virus protection, the Kaspersky engine also protects from spyware and phishing: you need a license key and valid subscription for this feature. Note that some models may need a memory upgrade.

The antivirus scanner scans the File Transfer Protocol (FTP), HyperText Transfer Protocol (HTTP; including web mail), Post Office Protocol version 3 (POP3), Internet Message Access Protocol (IMAP), and Simple Mail Transfer Protocol (SMTP), as well as the peer-to-peer applications AOL Messenger, ICU, MSN Messenger, and Yahoo! Messenger. The scanner is also able to look into multiple levels of compressed packages.

The first step in configuring antivirus is to choose the virus definition package. Due to memory limitations, some models may be able to load only the standard set. The standard method is the most common, and it is somewhere between itw basic scanning and extended scanning, which can also lead to false positives.

	FIREWALL-> set av scan-mgr pattern-type ?
	extended    All Virus and Spyware, plus adware/pornware/riskware/greyware
	itw         in-the-wild Virus and Spyware
	standard    All Virus and Spyware

The next step is to load the virus definition files onto the device. You may want to update the signatures the first time manually. The device needs Internet access for updates. The scan engine checks once per hour for new updates by default:

	exec av scan-mgr pattern-update
	set av scan-mgr pattern-update-url http://update.juniper-updates.net/AV/SSG5_SSG20/
	interval 60

If your firewall has no direct connection to the Internet, but it can reach a proxy, you need to configure the proxy settings. This is supported on ScreenOS 6.1 and later:

	set pattern-update proxy http proxy.juniper.net:8080

Enter the following command to check which virus definition is currently installed:

	FIREWALL-> get av | include signature
	    AV signature version: 08/08/2007 23:40 GMT, virus records: 157977

If you have problems downloading the virus definition, use the get lic command to see that you have a valid license, and the get dns name juniper.net command to see that you have Internet access and that your Domain Name System (DNS) server is working.

The last step is to link the antivirus profile to the policy. The default profile is ns-profile:

	set policy id 100 from "Trust" to "Untrust"  "Any" "Any" "HTTP" nat src permit
	set policy id 100
	   set av ns-profile
	exit

In most cases, you are done at this point. However, the antivirus engine is highly tunable. You will find tunable values under the following hierarchies:

	set av all
	set av scan-mgr
	set av profile <profile>
	set av extension-list <list>
	set av mime-list <mime>
	set av http webmail ...

You are able to tune how many CPU the antivirus engine can consume, how large the largest message can be, how many messages can be scanned concurrently, and how many messages can be queued:

	set av all resources 70
	set av scan-mgr max-content-size 10000
	set av scan-mgr max-msgs 16
	set av scan-mgr queue-size 16

You also can decide what should happen if the engine should fully fail or if a scan fails because of certain reasons. The default is that antivirus fails open should the whole engine fail, and fails close if a scan fails. Causes of failures include decompression layers (a ZIP file within a ZIP file within a ZIP file, etc.), password-protected archives, corrupted files, too many files in the queue or a file that is too large, an engine that is not ready, or a timeout being reached.

	set av all fail-mode traffic permit
	set av scan-mgr decompress-layer drop
	set av scan-mgr passwd-file drop
	set av scan-mgr corrupt-file drop
	set av scan-mgr out-of-resource drop
	set av scan-mgr engine-not-ready drop
	set av scan-mgr timeout drop

The default profile is ns-profile; on older ScreenOS releases, it is scan-mgr. You can create your own profile and determine the exact behavior for each supported protocol. You also can enable or disable certain protocols.

	set av extension-list my-incl-list exe;com;bat
	set av mime-list my-mime-excl-list text/html;text/css

	set av profile my-profile

	   set ftp enable
	   set ftp decompress-layer 3
	   set ftp scan-mode scan-ext
	   set ftp extension-list include my-incl-list
	   set ftp timeout 180

	   set http enable
	   set http decompress-layer 2
	   set http scan-mode scan-intelligent
	   set http skipmime skipmime my-mime-excl-list
	   set http timeout 180

	   set smtp enable
	   set smtp decompress-layer 3
	   set smtp email-notify virus sender
	   set smtp email-notify virus recipient
	   set smtp timeout 180

	   set aim-icq enable
	   set aim-icq file enable
	   set aim-icq msg enable
	   set aim-icq unknown-version best-effort
	   unset imap enable
	   unset pop3 enable
	   unset ymsg enable
	   unset msnms enable
	exit

There are special parameters for each protocol. For most, the default ns-profile is probably fine.

HTTP is the only protocol that also has global settings. You can configure trickling and keepalives, as well as enable web mail support. Those are all default and there should be no need to change them.

	set av http keep-alive
	set av http trickling default
	set av http webmail enable

To tune and check the effectiveness of the scan engine, you can list scan statistics and reports:

	FIREWALL-> get av statistics
	<AV statistics>
	No Scan: Max Msg:            0
	No Scan: Max Content Size:   0
	Fwd to Scan Engine: Total:   377
	Scan Code: Clear             377
	Scan Code: Infect            0
	Scan Code: Psw Archive File  0
	Scan Code: Decompress Layer  0
	Scan Code: Corrupt File      0
	Scan Code: Out Of Resource   0
	Scan Code: Internal Error    0
	Scan Code: Error             0
	Scan Eng: Error:             0
	Fail Mode:                   0

	<App Session>
	Max. Sessions:           2000
	Init. Sessions:          400
	Total Alloc Sessions:    2236
	Total Free Sessions:     2236
	Tcp Sessions:            0
	Active Sessions:         0
	Run out of packet count: 0

In particular, you will want to look at the number of infected files and the error counters below it. You may have to increase decompression layers if you see a high count here. This can be because an email is attached to another email, which has a ZIP file attached to it, which contains another ZIP file, for instance.

You can also view which virus was found in the event log with get event type 547 or on your syslog server or NSM:

	FIREWALL-> get event type 547
	Total event entries = 28
	Date       Time     Module Level Type Description
	2007-10-24 00:17:33 system warn 00547 AV: VIRUS FOUND: 192.168.97.101:
	                                      4836->168.215.74.5:80, http url: http:/
	                                      /ssl-hints.netflame.cc/Fc/FcPred.class,
	                                      file ssl_hints.netflame.cc/Fc/
	                                      FcPred.class/ virus
	                                      Trojan-Downloader.Java.Agent.c.

Problems with the antivirus engine are also logged to the event log and can be viewed with get event type 554.

You want to use antivirus in combination with your own ICAP-capable antivirus server.

Configure the ICAP server:

	set icap server my-server host 192.168.1.100
	set icap server my-server probe-interval 20
	set icap server my-server probe-url /SYMCScan-Resp-AV
	set icap server my-server max-connections 128

Configure the antivirus profile:

	set av profile my-profile
	   set icap my-server /SYMCScanReq-AV /SYMCScanResp-AV
	exit

Link the antivirus filter profile to a policy:

	set policy id 100 from "Trust" to "Untrust" "Any" "Any" "HTTP" nat src permit
	set policy id 100
	   set av my-profile
	exit

ScreenOS supports RFC 3507 ICAP 1.0 antivirus servers, such as the Symantec Scan Engine 5.0 ICAP server. ICAP is not as popular as it once was, because of some performance limitations, but it is best suited for link speeds of T3 and lower. For higher-performing solutions, an antivirus inline solution is recommended, which you can integrate with the firewall via PBR (see Recipe 12.3). Also, ICAP is supported on only ISG Series models. ICAP supports the redirection of HTTP and SMTP traffic only.

Start by configuring the connection to the ICAP server:

	set icap server my-server host 192.168.1.100
	set icap server my-server probe-interval 20
	set icap server my-server probe-url /SYMCScan-Resp-AV
	set icap server my-server max-connections 128

Here, we configured the IP address of the server, the probe interval for a server health check, the probe URL, and the number of maximum concurrent connections.

Next, link the ICAP server to an antivirus profile. In the profile, you also have to configure the req-url and resp-url. Those are the two URLs to which the firewall will forward client- and server-side traffic to the antivirus server.

	set av profile my-profile
	   set icap my-server /SYMCScanReq-AV /SYMCScanResp-AV
	exit

The last step is to link the antivirus profile to the policy:

	set policy id 100 from "Trust" to "Untrust"  "Any" "Any" "SMTP" nat src permit
	set policy id 100
	   set av my-profile
	exit

You will find a log if a virus was found on your antivirus server. You can troubleshoot URL filtering with debug flow basic and debug icap all. Problems are also written to the event log and can be viewed with get event type 81.

You want to put an antivirus server inline.

Configure a PBR policy for the traffic, which should be redirected to the antivirus server:

	set vr trust

	  set access-list extended 1 dst-port 25-25 protocol tcp entry 10
	     set access-list extended 1 dst-port 80-80 protocol tcp entry 20

	  set match-group name match-av-trust
	     set match-group match-av-trust ext-acl 1 match-entry 10

	  set action-group name action-av
	     set action-group action-av next-hop 192.168.3.100 action-entry 10

	  set pbr policy name av-policy-trust
	  set pbr policy av-policy-trust match-group match-av-trust
	action-group action-av 10

	  set route 0.0.0.0/0 interface e0/2 gateway 192.168.2.254
	  set route 10.0.0.0/8 interface e0/0 gateway 192.168.1.254

	exit

Link the PBR policy to the Trust side interface:

	set interface e0/0 pbr av-policy-trust

There are multiple ways to put an antivirus server inline of the traffic stream. For email, this is quite easy, by making the antivirus server an MTA. Another method is to redirect certain traffic—for instance, just HTTP and SMTP—via PBR (see Chapter 19) to the antivirus server. This recipe is not an in-depth discussion about PBR, but it should show how you can use PBR to implement high-performance antivirus servers with the firewall, as illustrated in Figure 12-1.

Figure 12-1. External antivirus with PBR

In Figure 12-1, there is a border firewall with an access router to the north, and a core router to the south. e0/0 is Trust and e0/2 is Untrust. The firewall is connected to network 192.168.3.0/24 and to an external antivirus server via e0/1.

	set interface e0/0 zone Trust
	set interface e0/0 ip 192.168.1.1/24

	set interface e0/1 zone Trust
	set interface e0/1 ip 192.168.3.1/24

	set interface e0/2 zone Untrust
	set interface e0/2 ip 192.168.2.1/24

The idea is to redirect antivirus traffic coming from the south to the antivirus server, instead of directly to the north. The antivirus traffic should make a detour through the antivirus server, but all other traffic should go directly out the north interface. It’s easy to achieve this with PBR, supported in ScreenOS 5.4 and later.

The task is to match on 80/tcp and 25/tcp to redirect HTTP and SMTP traffic to server 192.168.3.100 to do antivirus scanning for outbound traffic as an example in this recipe. (For SMTP, you may also want to configure inbound rules.) The server processes the traffic and sends it back to the firewall. Then the firewall sends the traffic out with all the other Internet-bound traffic. To do this, you need to write an extended access control list (ACL) to match on those dst-ports, link the ACL to a match group, and then define an action group with the next hop to the antivirus server. Next, you’ll need to link both the match group and the action group to a PBR policy, and finally, link the PBR policy to the Trust interface. (You do not need a matching policy for the Untrust interface because a session in the firewall will be established when the clients behind Trust first connect, and a session always overrules routing.)

	set vr trust

	   set access-list extended 1 dst-port 25-25 protocol tcp entry 10
	      set access-list extended 1 dst-port 80-80 protocol tcp entry 20

	   set match-group name match-av-trust
	      set match-group match-av-trust ext-acl 1 match-entry 10

	   set action-group name action-av
	      set action-group action-av next-hop 192.168.3.100 action-entry 10

	   set pbr policy name av-policy-trust
	   set pbr policy av-policy-trust match-group match-av-trust
	action-group action-av 10

	   set route 0.0.0.0/0 interface e0/2 gateway 192.168.2.254
	   set route 10.0.0.0/8 interface e0/0 gateway 192.168.1.254

	exit

	set interface e0/0 pbr av-policy-trust

You configure two normal routes: a default route out the Untrust interface e0/2, and the internal networks to the Trust interface e0/0. The antivirus server itself just needs a default route toward the firewall.

Because in this design the interface to the antivirus server was put into the same zone as the south interface is in (Trust in this case), you do not need any special policies. There will be two sessions: one session from Trust to Trust to the antivirus server, and one from Trust to Untrust from the antivirus server. If you have zone blocking enabled, or a final global deny rule, you will need an intra-zone rule from Trust to Trust as well.

	set policy id 100 from "Untust" to "Trust" "Any" "Any" "SMTP" nat src permit
	set policy id 100
	   set service http
	exit

	set policy id 200 from Trust to Trust "Any" "Any" "Any" permit

You will find a log if a virus was found on your antivirus server.

The best way to troubleshoot PBR is to use debug flow basic and look at the session table with get sessions dst-port <port>.

You want to configure antispam on your ScreenOS device.

Activate antispam on the policy:

	set policy from "Untust" to "Trust" "Any" "MIP(1.1.1.1)" "SMTP"
	permit anti-spam ns-profile

You need a valid license key for antispam and a valid subscription before you can use antispam. There is not much to configure besides enabling antispam on the policy.

	set policy from "Untust" to "Trust"  "Any" "MIP(1.1.1.1)" "SMTP"
	permit anti-spam ns-profile

Optionally, you can switch the default action from dropping the connection from the offending MTA to tagging it. (The default is drop.)

	set anti-spam profile ns-profile
	   set action tag
	exit

You can troubleshoot antispam with debug flow basic or debug anti-spam sbl. The first thing to check, however, is whether DNS resolution works.

Here’s an easy way to find out whether a certain MTA is listed in the SBL:

	FIREWALL-> exec anti-spam testscan juniper.net.s7a1.psmtp.com
	AS: anti spam result: action Pass, reason: No match

Blocked spam messages are logged to the event log (or syslog or NSM) and can be viewed with get event type 563.

Instead of using Juniper’s SBL, you want to use the SBL of a third party, such as Spamhaus.

Configure the third-party SBL:

	set anti-spam profile ns-profile
	   set sbl sbl-xbl.spamhaus.org input-type ip spam-list include any
	   unset sbl default-server enable
	exit

Then, activate antispam on the policy:

	set policy from "Untust" to "Trust"  "Any" "MIP(1.1.1.1)" "SMTP"
	permit anti-spam ns-profile

Instead of using Juniper’s subscription service, you can use a third-party SBL, but the quality of third-party SBLs may or may not be the same. In any case, you need a license key for antispam.

Configure the new SBL within the ns-profile profile. You’ll need to configure it if the input type is ip or hostname. The one for Spamhaus, for instance, is hostname. You may also want to disable Juniper’s SBL:

	set anti-spam profile ns-profile
	   set sbl sbl-xbl.spamhaus.org input-type ip spam-list include any
	   unset sbl default-server enable
	exit

Then, activate antispam on the policy:

	set policy from "Untust" to "Trust"  "Any" "MIP(1.1.1.1)" "SMTP"
	permit anti-spam ns-profile

You can troubleshoot antispam with debug flow basic or debug anti-spam sbl. The first thing to check, however, is whether DNS resolution works.

Here’s an easy way to find out whether a certain MTA is listed in the SBL:

	FIREWALL-> exec anti-spam testscan juniper.net.s7a1.psmtp.com
	AS: anti spam result: action Pass, reason: No match

Blocked spam messages are logged to the event log (or syslog or NSM) and can be viewed with get event type 563.

You want to whitelist an MTA, which is on the list of an SBL.

First, configure the whitelist:

	set anti-spam profile ns-profile
	   set whitelist juniper.net.s7a1.psmtp.com
	exit

Then, activate antispam on the policy:

	set policy from "Untust" to "Trust"  "Any" "MIP(1.1.1.1)" "SMTP"
	permit anti-spam ns-profile

Whitelisting is usually used in combination with Juniper’s or a third-party’s SBL. You can use blacklisting instead of an SBL. You need an antispam license key to configure white- or blacklists.

	set anti-spam profile ns-profile
	   set whitelist juniper.net.s7a1.psmtp.com
	   set blacklist evilspammer.com
	exit

If you want to use blacklists instead of an SBL, deactivate Juniper’s SBL:

	set anti-spam profile ns-profile
	   unset sbl default-server enable
	exit

Then, activate antispam on the policy:

	set policy from "Untust" to "Trust"  "Any" "MIP(1.1.1.1)" "SMTP"
	permit anti-spam ns-profile

Blocked spam messages are logged to the event log (or syslog or NSM) and can be viewed with get event type 563.

You want to configure built-in URL filtering.

Configure the categories you want to block:

	set url protocol type sc-cpa
	set url protocol sc-cpa
	   set enable
	   set profile "my-profile" "Advertisements" block
	   set profile "my-profile" "Games" block
	   set profile "my-profile" other permit
	exit

Link the URL filter profile to a policy:

	set policy id 100 from "Trust" to "Untrust"  "Any" "Any" "HTTP" nat src permit
	set policy id 100
	   set url protocol sc-cpa profile my-profile
	exit

Internal URL filtering works in conjunction with an external SurfControl server. No additional server is required. However, you need to configure a URL license key and have a valid subscription service for the built-in SurfControl URL filtering before you can configure it.

First, configure the URL filtering type to internal URL filtering:

	set url protocol type sc-cpa

Then, create a profile and attach categories to it, configuring whether you want to block or permit them. The category other defines what you want to do (which is usually permit) with traffic when it does not match any configured categories.

	set url protocol sc-cpa
	   set enable
	   set profile "my-profile" "Advertisements" block
	   set profile "my-profile" "Games" block
	   set profile "my-profile" other permit
	exit

You can also configure the default profile ns-profile with default categories. You show the predefined categories as follows:

	FIREWALL-> set url protocol sc-cpa
	FIREWALL(url:sc-cpa)-> get category pre
	        Type         code     Category name
	------------------------------------------------
	        PreDefine      90     Adult/Sexually Explicit
	        PreDefine      76     Advertisements
	        PreDefine      50     Arts & Entertainment
	        PreDefine    3001     Chat
	        PreDefine      75     Computing & Internet
	[...]

Custom categories are used for manual black- and whitelists.

The next step is to decide what happens if the firewall should lose connectivity to the SurfControl server. The default is permit:

	set url protocol sc-cpa
	   set fail-mode block
	exit

You link the custom or default profile to a policy. You can have different profiles for different policies. You can even have no URL filtering for some policies. Keep in mind that when you want to use different profiles, each policy needs to be different and that the first matched policy from top to bottom is matched. You need to define different src-addresses in the policies to use different URL filtering profiles because the dst-address will always be Any and the service will always be HTTP.

	set policy id 100 from "Trust" to "Untrust"  "Any" "Any" "HTTP" nat src permit
	set policy id 100
	   set url protocol sc-cpa profile my-profile
	exit

The internal URL scan engine caches URLs, already checked for their category. The cache is enabled by default. You can enlarge the cache; the number is in KB.

	set url protocol sc-cpa
	   set cache size 1000
	exit

You can troubleshoot URL filtering with debug flow basic and debug url-blk all. Of course, first check that you have access to the Internet and that your DNS resolution is configured correctly on the firewall. URL filtering-related logs are written to the event log and can viewed with get event log type 556.

You want to configure URL filtering with your own Websense or SurfControl filtering server.

First, configure how the firewall should contact the URL filtering server:

	set url type websense
	set url protocol websense
	   set config enable
	   set server 192.168.1.200 15868 10
	   set deny-message use-server
	   set fail-mode permit
	exit

Then, enable URL filtering on the policy:

	set policy from "Trust" to "Untrust" "Any" "Any" "HTTP" nat src permit url-filter

To use external URL filtering, you need your own Websense or SurfControl URL filtering server. No extra license key is required.

The configuration is quite simple: configure how the firewall should contact the URL server, whether you want to use the server’s deny message or a locally configured one, and whether you want to fail open or close:

	set url type websense
	set url protocol websense
	   set config enable
	   set server 192.168.1.200 15868 10
	   set deny-message use-server
	   set fail-mode permit
	exit

Instead of configuring websense for using a Websense server, you can configure scfp for using a SurfControl server.

The following code activates URL filtering on the policy:

	set policy from "Trust" to "Untrust" "Any" "Any" "HTTP" nat src permit url-filter

You can check the state of your connection to the URL filtering server as follows:

	FIREWALL(M)-> get url all

	Legend: * - Vsys uses URL Server shared by the Root

	System    State       Server     Port  Timeout  Fail-Mode Connection
	=====================================================================
	Root     Enabled 192.168.1.200   15868      10  Block        Up

Use debug flow basic and debug url-blk all to troubleshoot. URL filtering-related logs are written to the event log and can viewed with get event log type 556.

You want to manually block access to certain web sites.

First, configure a blacklist of blocked URLs:

	set url protocol type sc-cpa
	set url protocol sc-cpa
	   set category "my-category" url "juniper.net/"
	   set category "my-category" url "netscreen.com/"
	   set profile "my-profile" "my-category" black-list
	   set profile "my-profile" other permit
	exit

Then, link the URL filter profile to a policy:

	set policy id 100 from "Trust" to "Untrust" "Any" "Any" "HTTP" nat src permit
	set policy id 100
	   set url protocol sc-cpa profile my-profile
	exit

To configure manual black-or whitelists, you’ll need to configure a URL license key and have a valid subscription service for the built-in SurfControl URL filtering.

First, configure the URL filtering type to internal URL filtering:

	set url protocol type sc-cpa

Then, configure a custom category for the web sites you want to block. Create a URL filtering profile and link the category to it. You can link multiple categories to the same profile or even create multiple profiles. You can choose for each profile or category pair whether you want to white-or blacklist it. A whitelist means that only the configured URLs will be allowed. A blacklist means that the configured URLs will not be allowed but any other will be allowed, depending on your global settings of category other.

	set url protocol sc-cpa
	   set category "my-category" url "juniper.net/"
	   set category "my-category" url "netscreen.com/"
	   set profile "my-profile" "my-category" black-list
	   set profile "my-profile" other permit
	exit

Link the profile (with the attached white-and blacklisted categories) to a policy. You can have different profiles for different policies, and even no URL filtering for some policies. Keep in mind that when you use different profiles, each policy needs to be different, and that the first matched policy from top to bottom is matched. You also need to define different src-addresses in the policies to use different URL filtering profiles because the dst-address will always be Any and the service will always be HTTP.

	set policy id 100 from "Trust" to "Untrust"  "Any" "Any" "HTTP" nat src permit
	set policy id 100
	   set url protocol sc-cpa profile my-profile
	exit

URL filtering-related logs are written to the event log and can viewed with get event log type 556.

You want to configure deep inspection signature or anomaly protection on your ScreenOS device.

Link a signature group to a policy and configure the logging level:

	set policy id 100 from "Untrust" to "Trust" "Any" "MIP(1.1.1.1)" "HTTP" permit
	set policy id 100
	   set attack "CRITICAL:HTTP:SIGS" action drop
	   set attack "CRITICAL:HTTP:ANOM" action drop
	   set attack "HIGH:HTTP:ANOM action none
	   set di-severity low
	exit

Deep inspection in ScreenOS is a subset of Juniper’s IDP functionality. Around a thousand signatures exist for deep inspection, which are updated by a subscription service. You need a license key and a signature subscription before you can use deep inspection. Note that some models may need a memory upgrade as well.

The first step in configuring deep inspection is to choose the signature packet:

	FIREWALL-> set attack db sigpack ?
	base            Baseline Deep Inspection Pack
	client          Client Deep Inspection Pack
	server          Server Deep Inspection Pack
	worm            Worm Mitigation Deep Inspection Pack

The next step is to load the signature onto the device. You may want to update the signatures the first time manually. The device needs Internet access for automatic updates.

	exec attack update
	set attack db mode update
	set attack db schedule daily 5:00

If your firewall has no direct connection to the Internet, but it can reach a proxy, you need to configure the proxy settings. This is supported on ScreenOS 6.1 and later:

	set pattern-update proxy http proxy.juniper.net:8080

If you have problems downloading the signatures, use the get lic command to ensure that you have a valid license, use the get clock command to ensure that your system clock shows the correct time, which is important for certificate validation, and use the get dns name juniper.net command to ensure that you have Internet access and that your DNS server is working. You can also download the signature pack manually (see Recipe 12.11).

Only those signatures with a certain severity will be installed if your firewall has limited memory. By the way, the term signature actually refers to context and stream signatures as well as protocol anomaly. Protocol anomaly is great for preemptive protection from possible future exploits, by enforcing protocol definition, and the context and stream signatures protect from known exploits. The difference between context and stream matches is that context matches decode the application layer and apply the match only to a functional part of the application, such as a filename or a URL, instead of to the full data stream. You may want to block access to a certain filename of a virus but not block access to web sites reporting that virus. Context signatures can virtually eliminate false positives in a well-tuned system.

You can list signatures and anomalies with get attack signature and get attack anomaly.

You can organize and apply signatures to policies in groups using the get attack group command, and they are organized by their severity level: info, low, medium, high, and critical.

You can link an attack group to a policy with the permit action. Only if the policy permits will the traffic be sent to the deep inspection module. Otherwise, it will be immediately dropped.

	set policy id 100 from "Untrust" to "Trust" "Any" "MIP(1.1.1.1)" "HTTP" permit
	set policy id 100
	   set attack "CRITICAL:HTTP:SIGS" action drop
	   set attack "CRITICAL:HTTP:ANOM" action drop
	   set attack "HIGH:HTTP:ANOM action none
	   set di-severity low
	exit

You can configure multiple attack groups with different actions on the same policy:

	none           permit flow without processing
	ignore         ignore this flow if attack is found and continue
	drop-packet    drop this packet
	drop           drop all packets in this flow till connection timeout
	close-client   reset client to server connection and drop packet
	close-server   reset server to client connection and drop packet
	close          reset connections on both sides and drop packet

Be careful when blocking traffic that is triggered by low-severity signatures, as it can also block legitimate traffic. You can control the logging level with di-severity.

Deep inspection attacks are logged to the event log. You can view them with get event type 767 or on your syslog or NSM server.

You can fine-tune the different protocol decodes with the set di service <protocol> command. In ScreenOS 6.0, 29 protocol decodes are defined, and you can fine-tune things such as maximum cookie length and number of failed logins. Altogether, you can adjust more than 150 parameters.

To troubleshoot deep inspection problems, use debug flow basic and debug idp all.

You want to use deep inspection on a firewall, but you do not have direct Internet access.

Use your browser and download the signature packet to your PC:

Install the signature via the Trivial File Transfer Protocol (TFTP) on the device:

	FIREWALL-> save attack-db from tftp 192.168.1.100 attacks.bin to flash
	Load attack database from TFTP 192.168.1.100 (file: attacks.bin).
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

To install the signature pack automatically on the firewall, the firewall needs to have direct access to the Internet, have DNS configured, and have the correct time set up. If the device does not have direct access to the Internet, you can install the signature pack manually.

Download the attacks.bin file to your PC:

Enter the correct ScreenOS release (6.0), model (ssg5), and serial number (016810200600000). Then, download the file from your PC to the firewall via TFTP:

	FIREWALL-> save attack-db from tftp <ip> attacks.bin to flash

You can download the signature packet to your PC, but you will not be able to install it on a device without having a valid license key and a valid subscription.

You want to create your own deep inspection signature.

Choose the right deep inspection context. In this case, we block the search term Juniper Networks in a Google search. Develop a regular expression (regex):

	set attack "CS:google-juniper" http-request "/search?hl=..&q=[Juniper]+
	[Networks].*" severity critical

Create an attack group and attach the signature to the group:

	set attack group "CS:my_sigs"
	set attack group "CS:my_sigs" add "CS:google-juniper"

Link the attack group to a policy:

	set policy id 100 from "Trust" to "Untrust"  "Any" "Any" "HTTP" nat src permit
	set policy id 100 attack "CS:my_sigs" action close

Developing custom signatures is a very powerful way to control traffic on the application layer of the firewall. It is also a fine art. The first thing you have to be clear about is what you want to block.

In this example, let’s block users from Googling Juniper Networks. The first thing to do is to execute what you want to block while capturing the packet stream with a packet capture such as Wireshark. In this case, do a Google search on the search term Juniper Networks:

	GET /search?hl=en&q=juniper+networks

This is the string from the packet capture, which you have to match. The next step is to search for the right context. Alternatively, if no context exists, you can create a stream signature, but stream signatures are prone to false positives because the signatures match on any part of the traffic stream. In this example, the context is http-request. You can list other contexts with the following:

	FIREWALL-> set attack cs:TEST ?

In ScreenOS 6.0, 57 contexts are defined for the applications DNS, FTP, HTTP, SMTP, POP3, IMAP, SMB (Microsoft NetBIOS), and the peer-to-peer applications AOL Messenger, MSN Messenger, Yahoo! Messenger, and Gnutella. If you do not find a context, you need to use the stream match stream256 instead.

Once you identify the context, you need to create the signature. Note that deep inspection regexes are somewhat similar, but also different from Perl and POSIXstyle expressions. Here is a list of deep inspection expressions:

The most common problems with regexes are that a regex matches one character at a time instead of a typical string match in an editor. If any of the metacharacters in the preceding list are used within the pattern, they must be escaped. If the metacharacter already includes an escape, a second needs to be added. A signature within a context needs to match the entire string. Therefore, signatures often start and end with .*.

Compare the string from the packet capture with the regex. You can see that ? and + needed to be escaped, that we used any-match for the language en, and that we made the search term case-insensitive. We match on anything after the string in case the search term is something such as Juniper Networks, for instance:

	/search ?hl=en&q= Juniper   + Networks
	/search?hl=..&q=[juniper]+[networks].*

We add the regex to the custom signature CS:google-juniper. All custom signatures have to start with CS:.

	set attack "CS:google-juniper" http-request ".*/search?hl=..&q=[Juniper]+
	[Networks].*" severity critical

You have to link the signature to a group before you can apply it to a policy. Custom groups have to start with CS:.

	set attack group "CS:my_sigs"
	set attack group "CS:my_sigs" add "CS:google-juniper"

Link the attack group to a policy:

	set policy id 100 from "Trust" to "Untrust"  "Any" "Any" "HTTP" nat src permit
	set policy id 100 attack "CS:my_sigs" action close

You can use the debug idp all command to check whether your signature matched:

	_sc_http_verify_flow: (c2s) 192.168.98.128:2824 -> 216.239.51.104:80 [6]
	_sc_http_verify_flow: (45 c2s)GET /search?hl=en&q=juniper+networks HTTP/1.1
	_sc_http_verify_flow: c2s request
	SC_KQMSG_ADD_CONTEXT: service HTTP, type HTTP_REQUEST, length 45, skip false
	sc_ids_check_attack_match: 'CS:google-juniper' [] matched
	subs 0>vc 0 192.168.98.128:2824 216.239.51.104:80 6CLOSE ALARM IDP_ATTACK_MATCH CS:
	google-juniper

Deep inspection-related logs are written to the event log (or syslog or NSM) and can be viewed with get event type 767.

You want to redirect traffic to the integrated Security Module on an ISG Series firewall.

You enable IDP redirect for each permit policy individually if traffic should be sent to the Security Module.

	set policy id 100 from "Untrust" to "Trust" "Any" "MIP(1.1.1.1)" "HTTP" permit
	set policy id 100
	   set idp mode tap
	exit

Integrated IDP is Juniper’s full-blown IDP solution, running on optional Security Modules on the ISG Series firewalls. When the IDP module is installed, the firewall is managed via the NetScreen Security Manager (NSM). However, it may be necessary to enable IDP screening on policies on the CLI—for instance, during first-time deployment and before importing the device into NSM.

The IDP on the Security Module works independently of ScreenOS. Within a policy, you can configure whether a copy of the traffic is sent to the IDP blade. This setting is used to monitor traffic with the IDP module but not to block it:

	set policy id 100 from "Untrust" to "Trust"  "Any" "MIP(1.1.1.1)" "HTTP" permit
	set policy id 100
	   set idp mode tap
	exit

Or, you can configure that all traffic matching this policy is screened inline through the IDP blade. In this mode, the IDP can actually block traffic and protect the network, and in this case, the IDP processing capacity becomes the limiting factor even if the flow is installed in ASIC on the firewall side.

	set policy id 100 from "Untrust" to "Trust"  "Any" "MIP(1.1.1.1)"
	"HTTP" permit
	set policy id 100
	   set idp
	exit

You can install up to three Security Modules on an ISG-2000. It makes sense to run traffic inline through the Security Module if signatures for that protocol exist. Predefined signatures exist for all common protocols, but you may have to develop custom signatures to protect proprietary applications.

Note that you can only configure IDP policies via NSM, but IDP configuration is out of the scope of this book.