Security Incidents mailing list archives
Re: ACK scan - RESOLUTION
From: "Todd Ransom" <transom () extremelogic com>
Date: Fri, 10 Aug 2001 10:27:50 -0400
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" <transom () extremelogic com> To: <incidents () securityfocus com> 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
Current thread:
- ACK scan Todd Ransom (Aug 03)
- Re: ACK scan - RESOLUTION Todd Ransom (Aug 10)