Table of Contents

NetRanger Required Filter Settings

first.fil
shun.fil

Security Policy Filter Settings

Security Policy Violation Signatures

Setting Filters in BorderGuard Bridge Mode
NetRanger Support for Passport Bridging
Data Privacy Facility

NetSentry Information

This appendix includes the following sections:

• NetRanger Required Filter Settings

• Security Policy Filter Settings

• Setting Filters in BorderGuard Bridge Mode

• NetRanger Support for Passport Bridging

• Data Privacy Facility

NetRanger Required Filter Settings

This section lists and explains the settings for the standard filter (.fil) files required to deploy a BorderGuard or Passport as part of a NetRanger security system.

The standard files that must be configured and installed on a BorderGuard device are:

• first.fil

• shun.fil

Both of these filter files reside in the Sensor's /usr/nr/etc/nsc/templates directory. These files must be edited on the Sensor and transferred to the BorderGuard using TFTP.

first.fil

The first.fil file identifies which network traffic should be copied to the Sensor. First, change the IP address of the Sensor that follows the copy_to commands if it has not already been changed. Then change any string-matching requirements defined in sensord.conf.

For string matching to be effective, all packets for a given service (e.g., Telnet at port 23) must be copied to port 35398. By default, the following ports are all copied to the tcp_dp and tcp_sp lines in first.fil:

• ftp (21)

• Telnet (23)

• SMTP (25)

• DNS (53)

• POP-3 (110)

• RPC (111)

• HTTP (80)

• Auth (113)

• NetBIOS (139)

• Rexec (512)

• Rlogin (513)

• Rsh (514)

To set up string matching on additional services, such as ftp Data (TCP port 20), add the additional ports to first.fil:

# Copy certain TCP traffic
ip_protocol in (6)
....
tcp_dp in (21,23,25,53,80,110,111,113,139,512,513,514,20)
copy_to IP_ADDRESS_SENSOR 35398 break;
 
tcp_sp in (21,23,25,53,80,110,111,113,139,512,513,514,20)
copy_to IP_ADDRESS_SENSOR 35398 break;
 

where IP_ADDRESS_SENSOR is the IP address of the Sensor associated with the BorderGuard.

shun.fil

The Sensor uses the shun.fil file to dynamically block outgoing as well as incoming IP addresses. It is not applied to a BorderGuard/Passport until the Sensor generates an alarm for an attack signature that is configured to shun.

Caution The name of this file should not be changed. The only edit required in this file is the IP address of the Sensor that follows the copy_to command.

Security Policy Filter Settings

In addition to the NetRanger required filter settings, your BorderGuard works with standard filters that deny and allow ICMP and TCP traffic. Your network device's security policy defines what type of activities and services you want to allow and disallow at key access points on your network. This includes the following types of services:

• Services to allow in from untrusted sites

• Services to allow out from trusted sites (for example, internal users)

• Services you want to track (Web traffic or FTP usage)

Implementation of your security policy is based largely on the filters installed on your BorderGuard or Passport network device.

Examples of filter files can be found in the Sensor's /usr/nr/etc/nsc/templates/old directory. These files must be edited on the Sensor and transferred to the BorderGuard using TFTP.

For more information on setting these filters, contact your STK representative.

Security Policy Violation Signatures

Security Policy Violation signatures are generated by reporting packet failures and/or successes from Security Policy Violation filters. When the NSG BorderGuard is used to enforce a specific security policy, an option exists to copy a subset of failed packets from the BorderGuard to the Sensor. Each copied packet includes the name of the Security Policy Violation filter that failed the packet. NetRanger matches this name with a pre-defined list of filter names and generates a security violation event record upon a match.

filter incom1_ip_spoof_fail
ip_sa mask 0xFF000000 in (10.*.*.*)
copy_to 10.1.5.3 35399
fail;
end
 

The filter in Example B-1 was designed to analyze all packets entering a network. If the source address is from the network, it is an impossible packet and may be part of an IP spoofing attack. The filter will send a copy to the NetRanger/Sensor at address 10.1.5.3, and then fail the packet. NetRanger will match the string "incom1_ip_spoof_fail" and generate a security violation event record. The event record will include the source and destination IP addresses and applicable ports.

Using this NetRanger capability, any filter on the BorderGuard is capable of generating event signatures. Because the BorderGuard allows a large number of highly configurable filters using the NetSentry filter language, the number of potential Security Policy Violation signatures generated by NetRanger could be considered unlimited. NetSentry filternames for versions 2.0 through 3.1 of the BorderGuard OS is case sensitive. Version 4 of the BorderGuard OS and the ERS report filternames in uppercase. If the original filtername is "finger_fail", then NetRanger must be configured to look for the filtername "FILTER_FAIL".

All Security Policy Violation event records have a SigID of 10000. Each defined filtername in NetRanger must have a unique SubID assigned to it. Numbering SubIDs is left to the individual installing and maintaining NetRanger. For more information, refer to "The NSDB and Signatures."

Table B-1 lists Security Policy Violation filters and their implementations.

Setting Filters in BorderGuard Bridge Mode

In BorderGuard bridge mode, perform the following changes to the filter files:

Step 1 Replace copy_to with log_to.

Step 2 Replace UDP port 35398 with 35400.

Step 3 Replace UDP port 35399 with 35401.

Example B-1 illustrates a sample of a part of the filter NETRANGER.

filter NETRANGER
 
ip_protocol in (1)
log_to 10.1.100.1 35400 break;

ip_protocol in (6)
tl_byte 13 mask 0x07 in (1,2,4)
log_to 10.1.100.1 35400 break;
 
tcp_dp in (21,23,25,53,80,111,512,513,514)
log_to 10.1.100.1 35400 break;

tcp_sp in (21,23,25,53,80,111,512,513,514)
log_to 10.1.100.1 35400 break;
...
...
...
 

Example B-2 illustrates a sample security policy filter.

filter INCOM1_IP_SOURCE_ROUTE_FAIL
ip_option_present 0x83
log_to 10.1.100.1 35401
icmp_unreachable fail;
ip_option_present 0x89
log_to 10.1.100.1 35401
icmp_unreachable fail;

end

NetRanger Support for Passport Bridging

In bridge mode on the Nortel Passport, perform the following changes to the filter files:

Step 1 In each filter file, replace:

• copy_to with log_to.

• UDP port 35398 with 35402.

• UDP port 35399 with 35403.

Step 2 In first.fil, replace:

• FIRST_FILTER with FIRST_BR_FILTER

• NETRANGER with NETRANGER_BR

Step 3 In first.fil, create three new filters under NETRANGER_BR:

• NETRANGER_BR_ETHER (Ethernet)

• NETRANGER_BR_TOKENRING (Token Ring)

• NETRANGER_BR_FDDI (FDDI)

Step 4 In first.fil, copy the contents of filter NETRANGER into each of the NETRANGER_BR filters created in the previous step.

Example B-3 provides a partial listing of the new filters in first.fil to be used on the Passport in bridge mode.

   filter FIRST_BR_FILTER #<-- Applied at the first filter point
      filter NETRANGER_BR;
      filter SHUN;
   end
   filter NETRANGER_BR
      filter NETRANGER_BR_ETHER;
      filter NETRANGER_BR_TOKENRING;
      filter NETRANGER_BR_FDDI;
   end
   filter NETRANGER_BR_ETHER
      not mac_media_type in (1) #<-- Return if not Ethernet
         break;
      ip_protocol in (1)           #<-- Traditional filter
         log_to 10.1.100.1 35402 break;
      ...
      ...
      ...
   end
 

Caution The not mac_media_type in (1) line must be different for each NETRANGER_BR filter. Refer to your STK documentation for a listing of MAC media types and their associated values.

Step 5 For all Security Policy Violation filters, the ETHER, TOKENRING, or FDDI strings must be prepended to the name of the filter, depending on the type of network traffic being filtered.

In Example B-4, the filter is applied on the incoming filter point of an Ethernet interface. This ensures that all log_to packets from this filter include Ethernet MAC headers. If this filter were at another filter point (first, last, apply_table, etc.), then it would have to be broken up in triplicate like the first filter shown on the previous page.

   filter ETHER_INCOM1_FINGER_FAIL
      tcp_connect_request
      tcp_dp in (79)
          log_to 10.1.1.1 35403
          fail;
   end

Caution Filter names should not exceed 31 characters in length. In some cases, prepending one of the MAC formats listed above to certain default NetRanger policy filters will result in a filter name that exceeds the 31-character limit. In those cases, truncation will be necessary.

Data Privacy Facility

The BorderGuard 1000 and 2000 routers are equipped with a powerful encryption capability that can establish a Virtual Private Network (VPN) between geographically remote sites over public networks.

Examples of the files necessary for setting up a Data Privacy Facility can be found in the Sensor's /usr/nr/etc/nsc/templates/old directory. For more information, refer to your STK documentation or contact your STK representative.

Posted: Fri Jul 28 08:37:46 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.