This section discusses some commonly asked questions and answers on IPS Sensor.
I lost my password? How may I recover it?
You can use service account to reset other account passwords. Log in as the service account, su to root, then enter passwd (user) to reset a user's password.
Alternatively, if you have lost the service account password, then log in using an administrative account (cisco for example), and then delete and re-create the service account.
However, if you have lost all the administrative account passwords and the service account password, the only recourse is to re-image the sensor.
On a 4215, 4210, 4220, 4230, 4235 and 4250, you can connect to the serial console, reboot the sensor, and then when the Grub menu appears, select Cisco IPS Recovery (choice 1 on the Grub menu). When this process completes, all of your sensor data will be lost, and sensor will be restored back to default, except network settings (for example IP address, default gateway, and so on). All user accounts will be deleted, and you can log in to sensor with default username and password (cisco/cisco).
Does IPS 5.0 support AAA (TACACS+ or RADIUS)?
AAA is not supported on Sensor version 5.0, which is the latest version of Sensor as of writing this book.
Why do I want to recover my sensor from Recovering Partition instead of using a CD?
There are benefits to recovering from Recovery Partition instead of using CD:
With Recovery Partition, the network settings such as IP address, default gateway, and allowed hosts information is retained on the sensor. As IP address and allowed host info are retained, you can perform this recovery process remotely.
Another benefit is that the actual recovery (recover application partition) takes much less time than a CD recovery. This is because the CD recovery has to create both the Application Partition and the Recovery Partition.
Will I lose my configuration in particular signature tunings when a new signature update is applied to the sensor?
When a signature update is applied on a sensor, the new signatures are automatically merged into the existing settings on the sensor. The default settings for the existing signatures are updated in the same manner.
How can I know which signature belongs to which signature update level?
You can go to the following site, which groups the signature name based on the signature update file: http://www.cisco.com/cgi-bin/front.x/csec/idsHome.pl
Is ftp timeout configurable on the sensor?
Yes, it is configurable, but only from IPS version 5.0.
Can the sensor read and detect an encrypted attack?
It depends on whether the attack is in the data or in the protocol set up. If it is in the data (hence encrypted), the sensor will not see it, and so it will not be able to analyze it. However, if the violation occurs in the protocol setup, the sensor detects it and will take the action as configured. For example, IPS is able to detect SPAM on SMTP but unable to detect a word in the e-mail attachment.
Does Blocking have a time limit?
Yes, all blocking can be specified with a time limit, except for permanent blocks, which are in effect as long as they are configured.
Is it possible to block hosts for different lengths of time depending on the alarm?
This is not possible with automatic blocks that are performed by the sensor, but, with manual blocks it is possible. So, a possible solution is to configure the automatic blocks for a certain time, and then perform a manual block based on an alarm for which you specify the time. You can set a manual block for a much longer time period.
Is it possible to block a single connection on the PIX Firewall?
No, you cannot block a single connection on the PIX Firewall. Although, for automatic block, the sensor sends source/destination IP addresses, and source/ destination ports to the PIX firewall, it is not a connection block, rather a source IP address block. The PIX blocks all packets originating from that IP address. The additional information is used by the PIX firewall to connection maintenance, for example, to remove the initial connection entry that was built up before the blocking is applied to the PIX. If this connection is not removed from the connection table and does not time out before block is removed or times out, then it is theoretically possible that the attacker can continue the attack on the original connection. Removing this connection from the connection table ensures that the original connection cannot be used to continue the attack after the block is removed.
For manual blocks, by default, the sensor sends only the source IP only to the PIX. Although additional information can be specified, the PIX still treats this as a host shun. This is because PIX itself does not support (using the shun command) the blocking of a single connection. The PIX shun command always blocks the source address regardless of whether or not the additional connection information is provided.
Does Blocking work on PIX with the Fail Over set up?
Yes it does, if Telnet is used as the communication protocol between the sensor and the PIX firewall. This is limited to the inside interface, as Telnetting to an outside interface is not possible because of the design of the PIX. If ssh is used as the communication protocol, then blocking will not work when the PIX failover. This is because the SSH key generated on the Primary/Active unit is different than on the Secondary unit.
I am sniffing the network segment that is on the outside of the PIX firewall, which is configured for NAT or PAT. Blocking is configured on the sensor to apply the shun command on the PIX with the attack detection. Is there any issue?
Yes, there is. To understand this issue, think about the following example. Assume that the PIX is configured with NAT or PAT for the outbound connection from the inside network, and an inside host is unintentionally attacking the outside network. The sensor will see the translated IP address of the inside host as an attacker (as the sensor is sniffing the outside interface network). If blocking is activated, it will send the shun command for the translated IP address, and this is inaccurate. If PAT is configured, the whole network on the inside of the PIX firewall will be blocked with the shun command, as the PAT address is the same for the whole inside network. The work-around is to sniff the inside network.
For how long will the shun command be on the PIX Firewall? Can I re-adjust the timer for blocking (shunning) on the PIX?
If blocking is configured manually on the PIX, the shun command will be on the PIX until it is removed. However, if it is dynamically applied by the sensor, then it will be on the PIX until it is removed or reboots or the timer expires.
With dynamic blocking done by Sensor, you can re-adjust the timeout value on the Sensor itself.
Is blocking performed in global or interface mode on the PIX firewall?
Blocking is an interface-based mechanism on the PIX or FWSM firewall. Though blocking is configured or applied in global mode on the PIX, it works on the interface where the attacker is attacking the network. For instance, if the attacker is coming from the outside interface network of the PIX, blocking will be applied to the outside interface as an input filter. Remember that this does not stop someone on the inside network from going to this host, but does prevent it from getting back in.
Is Blocking possible on the Firewall Services Module (FWSM)?
Blocking is fully supported on FWSM by the IPS version 5.0 and above.
How do I configure blocking with Hot Standby Router Protocol (HSRP) setup between two routers, or MSFCs on a switch?
When you configure HSRP between two active routers or MSFCs, Routers/ MSFCs have their own IP addresses assigned to their physical interfaces, and the only address that is shared between the routers/MSFCs is the virtual HSRP IP address. Remember that the Virtual HSRP IP address is not an IP address of a complete physical interface; instead, it is part of the physical interface configuration. Because it is part of the physical interface configuration, you cannot apply an ACL using the HSRP interface IP address. Rather, you have to apply the ACL to the physical interface on which the HSRP is configured. So for blocking to work, the sensor has to manage both routers/MSFCs using their independent physical addresses, not the HSRP address, and it must apply the ACL to each router's physical interface on which the HSRP is configured.
In Promiscuous mode, why does the IPS sensor send 100 resets to both client and server?
The sensor will intentionally send 100 resets to the client and 100 resets to the server. This is because there might be a situation in which the client and server can respond to each other faster than the sensor can analyze and respond with the TCP reset packets in Promiscuous mode.
Because the server responds to the attack packet, the TCP sequence number will increase to some unknown value. Hence, if Sensor only sends one reset with the original sequence numbers, the reset would be ignored because the session would already have moved past those sequence numbers. So instead of sending one reset packet, Sensor takes 100 guesses in each direction (1 guess uses the original sequence numbers) to try to reset the connection. In most cases this works, and the sensor can reset the connection. In some cases when the client and server are near each other on the network, the session might proceed quickly enough that none of the 100 guesses would match appropriately, and the connection would continue without being reset. Hence, TCP resets are not guaranteed to work. However, in most real-world scenarios, in which the client and server are separate networks (usually the Internet), the TCP resets works well.
In Inline mode of IPS, Sensor can control when packets flow between the client and server. So the sensor needs to send only one TCP reset packet and it is known to be the correct sequence number. There is a chance that the TCP resets might get lost in transit, hence the deny-connection-inline action option is available that is new for Inline mode. You can configure the sensor to not only send the TCP reset packets, but also to deny any future packets on that connection. This way, if the resets are dropped, or the client/ server intentionally ignores the resets, the sensor would still drop any additional packets and force the client/server to eventually time out and drop the connection.
In Inline mode, is it possible or recommended to tune the signature for TCP reset or blocking?
You can configure the signature for TCP reset or for Blocking just as you do in Promiscuous mode, although TCP reset implementation is different, and you should check the previous answer for details). However, the real advantage with inline is that you can also configure it for denyPacket or denyConnection actions. If all actions are configured, then all actions will take place. The trigger packet will be denied along with the rest of the packets in the connection and the TCP Reset will be sent. The deny keeps the attack from completing, while the TCP Reset lets the client and server know that the connection should be torn down. Without the TCP Reset the client and server will continue trying to send the packets, "thinking" they were merely lost in transit, but with the reset, the client and server tear down the connection. It is up to you whether or not to use TCP Reset in conjunction with denyPacket/ denyConnection. DenyPacket/denyConnection works fine without TCP Reset, but it is not recommended to use only TCP Reset without denyPacket/denyConnection on an inline sensor because the deny actions do a better job of stopping the attack.
It is also possible to configure blocking in Inline mode. There is no general recommendation on whether you should configure blocking in Inline mode or not. It depends completely on specific scenarios. Assume that there are 3 different Internet connections to your network, and you have a sensor on each connection. If one sensor detects an attack and denyAttacker action is used, then that attacker IP can not enter the network through that one Internet connection in which that one sensor sits, but can still access the network from the other two Internet connections.
If the sensor were to do Blocking in addition to the denyAttacker, then the sensor could perform shunning on three firewalls of all three connections to block the attacker address. That way, the attacker would be blocked on all three Internet connections instead of just the one the sensor is on. Or you might have the sensor deployed in just one segment, but you want to block the ip from other segments as well. In that case, blocking must be used on the router between the segments, or better yet, on the switch where the actual machines are connected. If there is only one Internet connection and only one Internet address would be blocked, then denying just on the sensor might be enough without blocking on other devices. This would reduce the amount configuration on both the blocking device on the sensor and managed devices. Additionally, this would not place extra stress on the possibly low-end router being used for the Internet connection. So, deciding whether to configure Blocking or not depends completely on how your network topology is set up, and where the sensor is deployed.