cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
311
Views
0
Helpful
4
Replies

IDS 4215 Interface Monitoring Problem

smartin
Level 1
Level 1

Interface int2 is connected to a 2950 switch (outside of PIX).

Interface int3 is connected to a 2950 switch (inside of network connected via a PIX).

On the IDS event viewer the IDS is finding & blocking signatures that I enabled but only on the int2 interface. I don't see anything coming from int3 interface.

The port is enabled on the IDS & is listed in the interface group.

1 Accepted Solution

Accepted Solutions

Things to try:

Check the output of "show interfaces" wait a few minutes and re-execute.

Verify that the rx packet count increase on the int3 interface is close to the rx packet count increase for the interface group statistics.

Looking in the interface group statistics you can see if these packets are being seen as IP packets and in some cases even the TCP/UDP/ICMP protocol.

So see if the packet counts for these protocols are increasing.

Additionally there are lines for packets not processed because the protocol is different. See what percentage of the packets are fitting into this category. Normal switch management protocols show up in this category. If this is the majority of the packet counts then then is can often indicate that the switch is not configured to properly copy (span) the packets to the sensor.

Additionally the statistics for the group will show how many alarms have been generated. You can look to see if the count is going up.

Check your switch and make sure your span session is setup properly. The span needs to be configured to copy traffic from the firewall as well traffic going to the firewall. If the sensor only sees the traffic in one direction then it will usually not be able to properly monitor and generate alarms.

Another thing to try is intentionally send a test attack through your firewall. Before sending the attack you can turn on iplogging for the ip address you are attacking from. Once the attack and IP Log are complete then you can download the IP Log and see if the packets were seen by the sensor.

View solution in original post

4 Replies 4

marcabal
Cisco Employee
Cisco Employee

Execute "show interfaces"

Look to see if the packet counts for both int2 and int3 are increasing.

If the packet counts are not increasing on int3 then it is possible that the switch may not be configured properly to send you the right packets.

The other thing to keep in mind is that if the attack is based on a TCP string it is possible that the sensor first detects the attack on int2. When it sees the packet again on int3 it may see it as a duplicate packet and as such will throw it away and not generate an alarm for it.

This is because the sensor does not track traffic on each port separately. It combines the packets from both interfaces and analyzes the packets as if they all came in on one interface.

Because of this the same packet on multiple interfaces will be seen as duplicate packets.

The Atomic signatures generally fire on each of the duplicate packets, floods and scans may count each of the duplicate packets, but the tcp conneciton based signatures (like the web sigs) will only fire once for the first packet seen and will throw away the second packet as a duplicate in the stream.

When I execute "sh interfaces" I do see packet counts increasing on both interfaces.

I then disabled int2, cleared the shun list and cleared the IDS event viewer. With int2 disabled nothing is being shun, nothing is being logged on the IDS event viewer.

Things to try:

Check the output of "show interfaces" wait a few minutes and re-execute.

Verify that the rx packet count increase on the int3 interface is close to the rx packet count increase for the interface group statistics.

Looking in the interface group statistics you can see if these packets are being seen as IP packets and in some cases even the TCP/UDP/ICMP protocol.

So see if the packet counts for these protocols are increasing.

Additionally there are lines for packets not processed because the protocol is different. See what percentage of the packets are fitting into this category. Normal switch management protocols show up in this category. If this is the majority of the packet counts then then is can often indicate that the switch is not configured to properly copy (span) the packets to the sensor.

Additionally the statistics for the group will show how many alarms have been generated. You can look to see if the count is going up.

Check your switch and make sure your span session is setup properly. The span needs to be configured to copy traffic from the firewall as well traffic going to the firewall. If the sensor only sees the traffic in one direction then it will usually not be able to properly monitor and generate alarms.

Another thing to try is intentionally send a test attack through your firewall. Before sending the attack you can turn on iplogging for the ip address you are attacking from. Once the attack and IP Log are complete then you can download the IP Log and see if the packets were seen by the sensor.

I setup span on the switch interfaces and started to see the IDS log on the int3 interface.

Thanks for the help Marcabal