Re: ACK scan - RESOLUTION

From: Todd Ransom (transom@extremelogic.com)
Date: 08/10/01 

Message-ID: <005001c121a8$a2ad4010$9b4699aa@loki>
From: "Todd Ransom" <transom@extremelogic.com>
To: <incidents@securityfocus.com>
Subject: Re: ACK scan - RESOLUTION
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

Quantcast