IP Fragments and "port 16191"

[fields.james]

This issue has been raised previously; it's gained some visibility recently out at SANS although so far no one has an answer. I and a number of other folks occaisionaly see two or three alerts in a row regarding IP fragments, with the source and destination field set to 16191 (according to the IDS anyway).

Packet captures from the IDSMv2 show that what is really happening is a bunch of data is either being overwritten or inserted composed of the repeated hex byte 0x3f. It always seems to start at the offset where the source port would appear, and any double-byte field after that will translate as 16191 (0x3f3f = 16191).

These always seem to be packets to and from Windows machines (in my environment). This seems to match what others have reported. They also seem to only be "seen" by Cisco IDS sensors (don't know if it's all version 4 sensors or not, and don't know if this is ever seen by other products - only Cisco users have spoken up about it so far). It also seems to frequently involve active directory servers or SQL clusters. I've so far neither seen in my area nor heard from others that this happens with any *nix servers.

I am leaning towards thinking there is a bug in fragment reassembly (or something like that) causing this, that is only triggered with certain kinds of packets. I have quite a few examples I've captured on the IDS sensors, but I am trying to get a "real" sniffer trace that would include what was happening before and after with a given machine.

--James

[bobgerman]

I would like to see some clearer guidelines on resolution of this problem, if they exist. "Increase this, and maybe tweak that" just isn't that helpful. I increased the first param from 10000 to 30000, and I'm still seeing 1204's and 1208's coming in. I know they're suspect, just because of the source and destination (a bunch of addresses on a single Class C in Russia have no business connecting to random IPs on our network). I just need to know what kind of traffic they're pumping that's being misinterpreted by Cisco IDS as port 16191 UDP frags.

Also, messing with frag reassembly settings may lead to crashes, at least that was the prime suspect when we had near daily crashes on our sensor last year. The Cisco engineer assigned to our case tweaked some reassembly settings after verifying that the crashes seemed to be related to that. Eventually a version was released that supposedly resolved that problem but it has reappeared recently, perhaps in conjunction with a recent update. We are finding ourselves rebooting the sensor daily. Memory leak? Who knows, but I do know that it's acting like a Microsoft machine in terms of needing reboots.

P.S., we're running an IDS 4230 sensor, current version IDS-sig-4.1-4-S119.

[shawn.posthumus]

Well, I do not know how to fix the frag problem on the sensors, but here is the traffic you are seeing coming from Russia:

http://isc.sans.org//diary.php?date=2004-10-30

We too have been seing this for awhile.