|
We had a user over the weekend send us some interesting traffic primarily destineto port 80. The TCP option used is in an option kind that appears to be in unassigned range, the sequence numbers are not changing, but the source IPs are. They also throw in a packet here and there to destination ports other than 80 such as ports 21, 22 and 1. If anyone is seeing something similar and has logs or preferrably packets, please send them to us. |
Lorna 165 Posts ISC Handler Mar 7th 2011 |
| Thread locked Subscribe |
Mar 7th 2011 1 decade ago |
|
Yep - been seeing that for a few weeks. I have a small sample pcap I can send you, and just started another one for longer-term collection. What's the preferred way to get it to you? Would prefer not posting an URL in public.
|
PhilHagen 5 Posts |
| Quote |
Mar 7th 2011 1 decade ago |
|
NM - just found the contact us page. sending now.
|
PhilHagen 5 Posts |
| Quote |
Mar 7th 2011 1 decade ago |
|
What's the simplest tcpdump filter or snort rule to watch for this?
It's been way too long since I had to create a filter using offsets and if someone else has it, it would save me time and headaches. |
Jasey 93 Posts |
| Quote |
Mar 7th 2011 1 decade ago |
|
Hey Jason,
tcpdump -w /storage/dump -s0 -nn -Z pcap 'not src host (yourhostip) and not (port with known traffic) and tcp[tcpflags]&(tcp-syn) !=0 and not tcp[tcpflags]& (tcp-ack) !=0', optionally piped by a `grep opt' should work out of the box.[0] Kind regards, srm [0] man 1 tcpdump |
Jasey 1 Posts |
| Quote |
Mar 9th 2011 1 decade ago |
|
Whatever is sending these packets may be based on the source code found here:
http://www.enye-sec.org/en/papers/playing.with.sockets.%28port.scanning%29.txt The documentation includes examples where the sequence number above appears on every packet. The reason for this is that the programmer forgot to seed the random number generator, resulting in the same "random" number being generated every time the program is launched. Also the line of code that sets the tcp offset does not make sense to me - it looks like a kludge that may work most of the time, or may cause garbage from adjacent memory to be appended to the packet. Also it does not look like the code initializes the ACK number, which could result in garbage data going into that field. |
Jasey 8 Posts |
| Quote |
Mar 15th 2011 1 decade ago |
|
Nice catch and bears further investigating. I wonder if someone has used this code in a new tool or as is...you just gotta love a good mystery:) Thanks for sending this in!! Lorna
|
Lorna 165 Posts ISC Handler |
| Quote |
Mar 15th 2011 1 decade ago |
|
Looks like this may be the culprit? Or at least a variant of this code?
http://www.koders.com/c/fidB8A4A098EE8F34F898C75AEC374E771CE56767B2.aspx?s=printf#L102 |
Lorna 1 Posts |
| Quote |
Mar 18th 2011 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!
https://www.sans.edu
