|
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.
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.
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.
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>
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
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.
|