[Snort-users] Possible Memory Overlap/Bug? Help!
Lawrence.Reed at ...1444...
Thu Dec 12 06:40:04 EST 2002
-----BEGIN PGP SIGNED MESSAGE-----
I believe this to be a known bug in the stream4 reassembler. I have had
some discussions with the snort developers about a similiar problem.
~ The discussion was taken offline after a while,, but never resolved.
~ In my case the problem involved packet loss. I verified in the code
that the stream reassembly buffer is not cleared after each use ( for
performance reasons ) so when a stream misses a packet that space in the
buffer contains the previous streams contents. When this buffer is
passed to the rules engine an alert is generated relating to the old
data. I am currently trying to resolve this issue. I will post a patch
to snort-devel when it is ready.
Kevin Peuhkurinen wrote:
| I hope somebody can help me with this as I am nearing my wits end.
| I'm having a problem with anomalous "P2P GNUTELLA GET" alerts which
| appear to be caused by some kind of packet overlap or something.
| I had been having these problems with Snort 1.8.7, so upgraded to
| 1.9.0 and am still encountering them. The sensor reporting them is
| running Mandrake 8.1 with the latest stable release of libpcap.
| According to this sensor, the packets in question are originating from
| my SMTP server, with the destination being other SMTP servers on port
| 25. When I look at the packet in ACID, sure enough there is what
| appears to be HTTP GET requests. This was enough to make me
| curious. What I eventually decided to do was use a different machine
| to capture all of the traffic on port 25 to try to figure out what was
| going on.
| The thing is, the packets that are being logged by the sensor do not
| match the packets that are being captured by the other machine.
| Here is an example:
| From the sensor:
| Src: My SMTP Server Dest: Remote SMTP Server
| Src Port: 4479, Dest Port: 25
| IP Header Checksum: 0 (Incorrect, should be 0xc88f)
| TCP Header Checksum : 0 (Incorrect, should be 0x5b62)
| TCP Flags: ACK/PSH
| TCP Seq: 509426611
| TCP Ack: 2900267714
| The data contains an HTTP GET request followed by a bunch of garbage.
| When I look at the captured packets from the other machine, there is
| no such packet. The stream itself is an outgoing email with a fairly
| long attachment. There is one packet with matching Seq & Ack #'s,
| but it is actually just an ACK from the remote SMTP server back to my
| server. Certainly nowhere in any of the packets is anything that
| looks remotely like the HTTP GET which Snort is reporting on.
| However, I do know that at the same time, a user was making that HTTP
| connection since I can see traffic to the host in my firewall logs.
| Therefore, I have to conclude that somehow snort is getting its
| traffic mixed up. This is the only alert I have seen that looks
| like it is happening to. All other alerts appear to be genuine.
| Any thoughts?
| This sf.net email is sponsored by:
| With Great Power, Comes Great Responsibility Learn to use your power
| at OSDN's High Performance Computing Channel
| Snort-users mailing list
| Snort-users at lists.sourceforge.net
| Go to this URL to change user options or unsubscribe:
| Snort-users list archive:
Larry Reed Lawrence.Reed at ...1444...
NOAA IT Security Office
PGP Public Key:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Snort-users