RE: New DNS connection with SYN ACK

["Dan Hawrylkiw" <dh () ahpra org>]

These packets are usually from global load balancers (check out
bigip.com, akamai.com, etc).
They are just using them to get a round trip time to your site, so your
next web request (to whatever stite uses global load balancing) will be
handled from the server/cache with the fastest round trip time.. Many
high volume sites (CNN, MSNBC, etc) use them.

I see ~85 TCP SYN-ACKs to port 53 at a time.  Of those, most sources are
logged 5 times per "set".
The IP's from your list also appear in my IDS logs..

HTH,

/Dan Hawrylkiw, CISSP, RHCE

-----Original Message-----
From: Jerry Perser [mailto:jerry.perser () spirentcom com] 
Sent: Friday, January 11, 2002 9:51 AM
To: incidents () securityfocus com
Subject: New DNS connection with SYN ACK




Iptables on my firewall just dropped 2204 packets that 

were new TCP connections but had both the SYN 

and ACK flags set.  What is interesting about this is 

what these packets have in common AND what they 

don't have in common.



All the packets came from 19 different hosts targeting 

my firewall.  The TCP source port was high random 

number, the destination port was always 53 

(domain).  Having both the SYN and ACK flags set is 

a response to a TCP connection request (SYN only).  

But the TCP port numbers are reversed.  My DNS 

only runs over UDP.  Here is are same of a few 

packets:



Jan 10 13:30:12 bender kernel: FireWall 

INPUT_New_not_syn IN=eth0 OUT= 

MAC=00:e0:29:68:64:e7:00:02:17:e5:08:38:08:00 

SRC=203.194.166.182 DST=bender LEN=44 

TOS=0x00 PREC=0x00 TTL=236 ID=0 

PROTO=TCP SPT=15700 DPT=53 WINDOW=4128 

RES=0x00 ACK SYN URGP=0 



Jan 10 13:30:12 bender kernel: FireWall 

INPUT_New_not_syn IN=eth0 OUT= 

MAC=00:e0:29:68:64:e7:00:02:17:e5:08:38:08:00 

SRC=216.220.39.42 DST= bender LEN=44 

TOS=0x00 PREC=0x00 TTL=235 ID=0 

PROTO=TCP SPT=52475 DPT=53 WINDOW=4128 

RES=0x00 ACK SYN URGP=0 



Jan 10 13:30:12 bender kernel: FireWall 

INPUT_New_not_syn IN=eth0 OUT= 

MAC=00:e0:29:68:64:e7:00:02:17:e5:08:38:08:00 

SRC=194.205.125.26 DST= bender LEN=44 

TOS=0x00 PREC=0x00 TTL=240 ID=0 

PROTO=TCP SPT=57687 DPT=53 WINDOW=4128 

RES=0x00 ACK SYN URGP=0



There are 19 unique source IP addresses.  I went to 

ARIN to see who own the IP addresses.  The 

addresses have been assign around the world (US, 

Hong Kong, Germany, Australia).  NSLOOKUP could 

not find any entries for these addresses.  I can ping 

each of the addresses (so I know there is a machine 

there).  I did a quick port scan, and none of the 

machine had any open sockets.  Here are the 19 ip 

addresses:



128.121.10.146  128.242.105.34

        129.250.244.10  193.148.15.128

194.205.125.26  194.213.64.150

        202.139.133.129 203.194.166.182

203.81.45.254   216.220.39.42   216.33.35.214

        216.34.68.2

216.35.167.58   62.23.80.2      62.26.119.34

        64.14.200.154

64.37.200.46    64.56.174.186   64.78.235.14



What is really weird is the timing of the packets.  

Over a 4 day period, the packets only arrived at 6 

unique times lasting a duration of 11 to 12 seconds.  

It looks like a DDOS attack for 11 seconds.  The time 

between attacks is not constant, so that would rule 

out a cron job.  Here are the 6 event times (in Pacific 

Standard Time):



Jan 8 19:10:35  Jan 8 19:40:15  Jan  8 

20:38:45

Jan 8 21:16:15  Jan 9 20:20:29  Jan 10 

13:30:00



I can't find any connection between the 19 ip 

addresses, or the time, or even what the packets 

were trying to do.  Any ideas?


------------------------------------------------------------------------
----
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