I finally tracked the ACK scans all the way down. It turns out to be a RTT calculation performed by a network device made by RadWare. Once I started capturing all traffic from these machines I could see a pattern: them -> me 37852 udp them -> me icmp echo req them -> me tcp ack * this is what snort picked up them -> me tcp syn * radware waits for syn/ack then RSTs the connection I found this explanation at SANS: http://www.sans.org/y2k/031401.htm hopefully this will keep someone else from spending several days tracking this down like I did. TR ========================= "Information is not knowledge." --Caleb Carr ----- Original Message ----- From: "Todd Ransom" <transomat_private> To: <incidentsat_private> Sent: Friday, August 03, 2001 10:35 AM Subject: ACK scan > I got several nmap tcp ping events from one of my snort sensors the other > day. As I started digging into it the traffic starts to look more and more > strange. I wanted to bounce it off the list and see if anyone else had seen > anything similar or could (in)validate my thoughts on this. Here goes. > > I got 20 of these (abbreviated ACID output) from 5 different addresses: > ====== > [2001-08-02 11:43:58]IDS28/scan_probe-nmap_tcp_ping > IPv4: attacker.com -> fw.my.org > hlen=5 TOS=0 dlen=40 ID=59958 flags=0 offset=0 TTL=55 chksum=45800 > TCP: port=80 -> dport: 51723 flags=***A**** seq=193 > ack=0 off=5 res=0 win=1024 urp=0 chksum=64006 > Payload: none > ====== > I concluded that these are not normal traffic because: > 1.. The ack bit is set but the ack number is 0, which makes no sense. > 2.. the sequence number of all the packets is less than 1000. For a 32 > bit field this is just too coincidental. > 3.. The windows size of 1024 also looks suspicious to me. > So they look like crafted packets. I pull out nmap 2.54 Beta 6 and run an > ACK scan. The sequence numbers and ACK are reasonable numbers. So either > this is an old version of nmap or it's not nmap or it's generated using some > other option from nmap. > > According to the nmap man page ACK scans can be used for a few different > things. > 1.. Determine if a host exists. I don't think this is the purpose because > so many of them are going to the same machine. He only needs one or maybe 2 > packets to determine this. > 2.. Determine whether or not a host is behind a stateful firewall. A > stateful firewall will drop the packet, a non-stateful will pass it b/c of > the presence of the ACK bit and you should get a RST from the remote host. > Some things that are funny: > > 1.. The TTLs are all between 53 - 56 for all packets. I would expect them > to differ more than that, being from different subnets. From this I > conclude all the source addresses except 1 are spoofed. > 2.. I did a traceroute to try and find out which of the networks would > come up with a TTL close to 53. Every single source address is around 10-15 > hops away from me and they are all behind firewalls that rewrite the TTL > just before the destination. HUNH?!? This throws a kink in everything else > I've concluded. Either someone REALLY did their homework before scanning me > or there's something here I'm not seeing. > 3.. Mixed in with the rest was this one packet: > ====== > [2001-08-02 16:04:29]IDS28/scan_probe-nmap_tcp_ping > IPv4: attacker.com -> fw.my.org > hlen=5 TOS=0 dlen=40 ID=7842 flags=0 offset=0 TTL=52 chksum=41042 > TCP: port=80 -> dport: 53 flags=***A**** seq=55 > ack=0 off=5 res=0 win=1024 urp=0 chksum=58172 > Payload: none > ====== > > Aha! A scan to port 53. There is one packet to 51723 from this address and > one to 53 from this address. Now I REALLY think the rest are spoofed and > this one address is my attacker. > > TR > > > -------------------------------------------------------------------------- -- > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com > > ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Fri Aug 10 2001 - 12:51:49 PDT