Re: ACK scan - RESOLUTION

["Todd Ransom" <transom () extremelogic com>]

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