×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Action 1202, 1204 and 1208 from 83.0.0.0

Answered Question
Nov 27th, 2003
User Badges:

Hi,


I have an IDS 4210 4.1. In the event viewer alarms 1202, 1204 and 1208 fires with 83.0.0.0 as source ip adress and 0.0.0.57 as destination


I don't understand why my IDS see this IP ?

Can someone could help me please ?


Thanks

Correct Answer by marcabal about 13 years 8 months ago

The 1202 alarm is for fragments where the datagram is too long

The 1204 alarm is for fragments where the first fragment of the datagram is missing.

The 1208 alarm is for fragments where the datagram is incomplete (one or more fragments are missing).


If you are seeing the 83.0.0.0 and 0.0.0.57 addresses for these alarms, then first determine if the sensor may actually be seeing these addresses on your network (somebody may be replaying packet traces with these addresses).


You can use the "iplog 0 83.0.0.0" and "iplog 0 0.0.0.57" to have the sensor iplog any packets to and from these addresses around the time that you are seeing these alarms.

Then use the "iplog-status" command to see if any packets are being logged for those ip logs.

If there are packets being logged for those addresses then there are packets with those addresses on your network.


Another thing to try would be to set Capture Packet to True for these signatures. On normal signatures the packet that triggered the alarm will be attached to the alarm.

In the case of these special signatures, I am not sure whether or not any packet will be attached, and if so which packet will be attached.

If a packet is attached then you can analyze the packet and determine what address was in the packet header.



If it turns out that these addresses are not on your network then you may be running into a sensor bug.


In version 3.1 sensors there was a bug for the following situation:

When the sensor generates the 1204 alarm, this means that the sensor did not see the first fragment for the datagram.

The first fragment is the one the sensor uses to fill in the Source IP Address, Destination IP Address, and ports in the alarm.

This information is in the other fragments as well, but the sensor still only pulls in the addresses from the first fragment (<-THIS IS REALLY WHAT THE BUG IS)

If in the case of the 1204 alarm, the first fragment is not seen, then the sensor will just fill in the field with random data.


This was fixed in later version of 3.1, but may have snuck back into version 4.0 or 4.1.

In which case 83.0.0.0 and 0.0.0.57 may just be the random data in those fields at the time that alert fired instead of the real IPs.

The 1204 signature woudl be the problem, and since the 1202 and 1208 are firing for the same datagram they will exhibit the same behaviour.

If you have verified that those addresses are not not on your network and believe that you may be running into a similar problem then please contact the TAC. They will work with development to verify what the problem is, and if necessary create a bug to track the problem.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
marcabal Mon, 12/01/2003 - 14:18
User Badges:
  • Cisco Employee,

The 1202 alarm is for fragments where the datagram is too long

The 1204 alarm is for fragments where the first fragment of the datagram is missing.

The 1208 alarm is for fragments where the datagram is incomplete (one or more fragments are missing).


If you are seeing the 83.0.0.0 and 0.0.0.57 addresses for these alarms, then first determine if the sensor may actually be seeing these addresses on your network (somebody may be replaying packet traces with these addresses).


You can use the "iplog 0 83.0.0.0" and "iplog 0 0.0.0.57" to have the sensor iplog any packets to and from these addresses around the time that you are seeing these alarms.

Then use the "iplog-status" command to see if any packets are being logged for those ip logs.

If there are packets being logged for those addresses then there are packets with those addresses on your network.


Another thing to try would be to set Capture Packet to True for these signatures. On normal signatures the packet that triggered the alarm will be attached to the alarm.

In the case of these special signatures, I am not sure whether or not any packet will be attached, and if so which packet will be attached.

If a packet is attached then you can analyze the packet and determine what address was in the packet header.



If it turns out that these addresses are not on your network then you may be running into a sensor bug.


In version 3.1 sensors there was a bug for the following situation:

When the sensor generates the 1204 alarm, this means that the sensor did not see the first fragment for the datagram.

The first fragment is the one the sensor uses to fill in the Source IP Address, Destination IP Address, and ports in the alarm.

This information is in the other fragments as well, but the sensor still only pulls in the addresses from the first fragment (<-THIS IS REALLY WHAT THE BUG IS)

If in the case of the 1204 alarm, the first fragment is not seen, then the sensor will just fill in the field with random data.


This was fixed in later version of 3.1, but may have snuck back into version 4.0 or 4.1.

In which case 83.0.0.0 and 0.0.0.57 may just be the random data in those fields at the time that alert fired instead of the real IPs.

The 1204 signature woudl be the problem, and since the 1202 and 1208 are firing for the same datagram they will exhibit the same behaviour.

If you have verified that those addresses are not not on your network and believe that you may be running into a similar problem then please contact the TAC. They will work with development to verify what the problem is, and if necessary create a bug to track the problem.


meether Tue, 12/02/2003 - 09:49
User Badges:

I use "iplog 0 83.0.0.0" and "iplog 0 0.0.0.57" .

Alarms were fired by a windows XP computer with NWLink client installed on. It did a "local master annoucement".


Thanks


Eric

Actions

This Discussion