IDS Functionality on the PIX Firewall

One of important features of the PIX firewall is its intrusion detection capability. Cisco has a dedicated IDS product called Cisco Secure IDS (former NetRanger appliance), but a limited part of its functionality is implemented in both Cisco IOS and Cisco PIX. Because the PIX is basically an OSI Layers 3 and 4 filtering device, it supports detection of only simpler attacks that happen on these layers of network communication and can be detected by inspecting a single packet in the traffic. The IDS signatures (that is, descriptions of attacks) that the PIX supports are a subset of the Cisco Secure IDS signature set and are embedded in PIX software. In order to upgrade this set of signatures, you need to upgrade the entire PIX firmware using a general upgrade procedure. Doing so does not pose a big problem, though, because these signatures describe very general and simple attacks, which are not invented often. Intrusion detection can be configured on each interface in inbound and outbound directions. When the PIX detects each signature, the device produces an alert (the alert can be of two types, information or attack, depending on the severity of the attack) and sends it via syslog to the configured destination.

Supported Signatures

Unfortunately, Cisco's own documentation is not quite clear about signatures supported in each specific version. The best way to check what your PIX can do in the area of intrusion detection is to browse a list of syslog messages produced by the specific version (for example, see the Cisco PIX Firewall System Log Messages guide). For version 6.2, syslog messages numbered from 400 000 to 400 050 are reserved for IDS messages. Their format is shown here:

%PIX-4-4000<nn>: : <sig_num> <sig_msg> from <IP_addr> to <IP_addr> on interface  <int_name>

This syslog message means that PIX has detected an attack with number sig_num and name sig_msg. The two IP addresses show the origin and the destination of this attack. Finally, the interface on which the attack was detected is mentioned. For example:

%PIX-4-400013 IDS:2003 ICMP redirect from 1.2.3.4 to 10.2.3.1 on interface dmz

Table 31.5 lists all signatures detected by PIX, with short descriptions.

Table 31.5: PIX IDS Signatures

Message Number	Signature ID	Signature Title	Signature Type
400000	1000	IP options-Bad Option List	Informational
400001	1001	IP options-Record Packet Route	Informational
400002	1002	IP options-Timestamp	Informational
400003	1003	IP options-Security	Informational
400004	1004	IP options-Loose Source Route	Informational
400005	1005	IP options-SATNET ID	Informational
400006	1006	IP options-Strict Source Route	Informational
400007	1100	IP Fragment Attack	Attack
400008	1102	IP Impossible Packet	Attack
400009	1103	IP Fragments Overlap	Attack
400010	2000	ICMP Echo Reply	Informational
400011	2001	ICMP Host Unreachable	Informational
400012	2002	ICMP Source Quench	Informational
400013	2003	ICMP Redirect	Informational
400014	2004	ICMP Echo Request	Informational
400015	2005	ICMP Time Exceeded for a Datagram	Informational
400016	2006	ICMP Parameter Problem on Datagram	Informational
400017	2007	ICMP Timestamp Request	Informational
400018	2008	ICMP Timestamp Reply	Informational
400019	2009	ICMP Information Request	Informational
400020	2010	ICMP Information Reply	Informational
400021	2011	ICMP Address Mask Request	Informational
400022	2012	ICMP Address Mask Reply	Informational
400023	2150	Fragmented ICMP Traffic	Attack
400024	2151	Large ICMP Traffic	Attack
400025	2154	Ping of Death Attack	Attack
400026	3040	TCP NULL flags	Attack
400027	3041	TCP SYN+FIN flags	Attack
400028	3042	TCP FIN only flags	Attack
400029	3153	FTP Improper Address Specified	Informational
400030	3154	FTP Improper Port Specified	Informational
400031	4050	UDP Bomb attack	Attack
400032	4051	UDP Snork attack	Attack
400033	4052	UDP Chargen DoS attack	Attack
400034	6050	DNS HINFO Request	Attack
400035	6051	DNS Zone Transfer	Attack
400036	6052	DNS Zone Transfer from High Port	Attack
400037	6053	DNS Request for All Records	Attack
400038	6100	RPC Port Registration	Informational
400039	6101	RPC Port Unregistration	Informational
400040	6102	RPC Dump	Informational
400041	6103	Proxied RPC Request	Attack
400042	6150	ypserv (YP server daemon) Portmap Request	Informational
400043	6151	ypbind (YP bind daemon) Portmap Request	Informational
400044	6152	yppasswdd (YP password daemon) Portmap Request	Informational
400045	6153	ypupdated (YP update daemon) Portmap Request	Informational
400046	6154	ypxfrd (YP transfer daemon) Portmap Request	Informational
400047	6155	mountd (mount daemon) Portmap Request	Informational
400048	6175	rexd (remote execution daemon) Portmap Request	Informational
400049	6180	rexd (remote execution daemon) Attempt	Informational
400050	6190	statd Buffer Overflow	Attack

The signature IDs listed in the table correspond to signature numbers on the Cisco Secure IDS appliance. See www.cisco.com/univercd/cc/ td/doc/product/iaabu/csids/csids1/csidsug/sigs.htm (Cisco Secure Intrusion Detection System Version 2.2.1 User Guide) for a complete reference. All signatures are divided into two classes: informational and attack. The division is rather deliberate and cannot be changed, but it makes sense most of the time. For example, all Denial of Service (DoS) attacks are listed as attacks, and all information requests only have informational status. You might feel that if somebody tries to obtain information on RPC services on one of your hosts, this constitutes an attack, but it is still listed as informational by Cisco. Generalizing a little, it is possible to suggest the following reasoning on attack classification (from top to bottom in the table):

• Packets with IP options will not do any harm because they are always dropped by the PIX, so if these packets are detected, send only an informational message.

• Fragmented packets can pass through the firewall and are generally difficult to inspect, so they constitute an attack attempt.

• Legitimate ICMP traffic, although unwanted and maybe revealing some information about your network (for example, ICMP Information Request), is not classified as an attack.

• Fragmented ICMP, Ping of Death, and so on are considered attacks.

• Impossible TCP flag combinations are considered attacks because they are sometimes used for stealth scanning of networks.

• All floods/DoS attempts (including the UDP Snork attack) are classified as attacks.

• DNS transfers are classified as attacks; they reveal too much about the network.

• General RPC requests and all information requests for various RPC services are not considered that harmful and are classified as informational.

• Some specific one-packet attacks on RPC services are recognized separately.

Configuring Auditing for the PIX with an IDS

Auditing is configured using the ip audit command. Auditing can be turned on or off, different auditing policies can be created, the policies can be applied to specific interfaces, and specific signatures can be turned on or off. The easiest configuration requires you to assign a name for the auditing policy, specify actions (one for informational signatures and one for attack signatures) to be taken, and apply the policy to an interface. The actions that can be taken are:

• Alarm When PIX detects a signature in the packet, it reports with the message described previously to all configured syslog servers.

• Drop When this action is configured, PIX drops the offending packet.

• Reset This action means that PIX should drop the packet and close the connection if this packet was a part of an open connection.

The default action is alarm. Policy configuration usually takes no more than two commands:

ip audit name <audit_name> info action [drop | alarm | reset ] ip audit name <audit_name> attack action [drop | alarm | reset ]

For example, the following commands create a policy with the name myaudit and specify that when an informational signature is matched, the PIX should send an alarm to syslog, and when an attack signature is matched, the PIX should drop the packet:

PIX1(config)# ip audit name myaudit info action alarm PIX1(config)# ip audit name myaudit attack action drop 

It is possible to omit the action in the configuration. In this case, the default action is applied. Default actions are configured via these commands:

ip audit info action [drop | alarm | reset ] ip audit attack action [drop | alarm | reset ]

If not changed, the default action is alarm. Note that if you issue only the following command but not the corresponding attack command, no attack signatures will be matched:

PIX1(config)# ip audit name myaudit info action alarm 

On the other hand, if you configure the policy in the following manner, omitting the action for informational signatures, both informational and attack signatures will be matched, and the default action (alarm) will be applied when a packet is matched with an informational signature:

PIX1(config)# ip audit name myaudit info PIX1(config)# ip audit name myaudit attack action drop 

After creating a policy, you need to apply it to an interface in order to activate IDS on the interface. For example:

PIX1(config)# ip audit interface outside myaudit 

This means that all signatures and actions configured should be matched on the outside interface. The general form of this command is:

ip audit interface <if_name> <audit_name>

• if_name is the name of an interface where the IDS has to check for packets.

• audit_name is a name of the policy that describes which actions to take.

As an example, let's configure a simple IDS on the outside interface, which will send an alarm when an informational signature is matched and drop the connection when an attack is noticed:

PIX1(config)# ip audit name myaudit info alarm PIX1(config)# ip audit name myaudit attack action drop PIX1(config)# ip audit interface outside myaudit 

Each command has its no equivalent, which removes the command from the configuration. For example:

PIX1(config)# no ip audit interface outside myaudit PIX1(config)# no ip audit name myaudit info 

Another command allows easy clearing of all IDS configuration related to an interface, policy, or default action:

clear ip audit [name | signature| interface | audit | info | attack ]

The following set of commands displays the corresponding configuration of IDS related to the interface, audit, or default action. This code simply shows the commands you entered when configuring these parameters:

show ip audit interface <if_name> show ip audit info show ip audit attack show ip audit name <audit_name>

Disabling Signatures

Imagine the following situation: You are interested in being alarmed on the informational signature 6102, "RPC Dump." This means that you have to include all informational signatures in your policy with a command such as:

PIX1(config)# ip audit name myaudit info action alarm 

Here comes the problem: Many other signatures are listed as informational, and some of them are very "noisy"—generating lots of alarms—for example, number 2000, "ICMP echo reply," which is simply a response to a ping. Chances are, you will be flooded with alarms on this latter signature and will not notice the former one, which is the one in which you are actually interested. One way to get around this issue is to disable the noisy signatures with the following command, which disables the detection of the signature with number sig_number:

ip audit signature <sig_number> disable 

In our case, to disable the "ICMP echo reply" signature, use the following command:

PIX1(config)# ip audit signature 2000 disable 

After this command is entered, signature number 2000 ("ICMP echo reply") will not be detected by the PIX at all. Note that disabling a signature means disabling it globally, not for a specific interface or audit.

It is possible to see the list of all disabled signatures with the command:

PIX1(config)# show ip audit signature 

You can enable a disabled signature with a no command in configuration mode:

no ip audit signature <sig_number> disable

Configuring Shunning

Shunning is a term used in the IDS context to describe blocking traffic from an attacking host. Shunning it is configured on the PIX using the following command:

shun <src_ip> [<dst_ip> <sport> <dport> [<protocol>]]

This technique temporarily blocks all traffic from the specified source IP address. To block all traffic, the source IP address of 10.0.1.1, use the following command:

PIX1(config)# shun 10.0.1.1 

You can also deny specific traffic from the source IP by specifying a source port, destination IP address, and destination port number. After the shun command is entered, the PIX deletes all matching connections from its internal connection table and drops all further packets that match the command's parameters. The action of this command takes priority over access list entries and even security levels on interfaces; all specified traffic is blocked, whether the offending host is on the inside or outside of the interface. In order to remove this blocking action, use the corresponding no command. For example:

PIX1(config)# no shun 10.0.1.1 

This command is dynamic and is not displayed or stored in the configuration. If you want to view active shuns, use the show shun command. The clear shun command deletes all shun entries.