[Courses] [Security] Syn flooding (was: knock knock?)

[Raven, corporate courtesan]

Heya --

Quoth Dave North (Wed, May 01, 2002 at 06:16:30PM -0700):
> How about if I drop one in real quick?
> 	I have what appears to be maybe a SYN flood addict leeching on to
> my server. The netstat goodies look like this:
> 
> tcp    0    0 moon.timochari:www-http 62.13.43.60:8192    SYN_RECV
> 
> Syncookie protection is enabled, the ttl turned down, so I never see more
> than three of these from any one leech at any time. But they will persist
> for hours, sometimes through to the next day.

	If you're seeing large amounts of these, then yes, it may be a
syn flood.  You're doing the right things to cope with one.  It's hard
to figure out why you're getting syn-flooded.  Sometimes you did
something that ticked off a script kiddie, other times someone has
misconfigured their machine to access your network.  (This is rare for
synfloods, but common for "portscans".)  Does the IP address change all
the time?  If so, that's less likely to be persistent misconfiguration
of a remote machine and more likely to be a deliberate attack.

	I'm assuming that the connections you see in netstat never go
from SYN_RECV to ESTABLISHED, huh?  (Any TCP connection incoming to your
server will start as a SYN_RECV, but normal connections finish the TCP
handshake and establish.)

> 	Nothing shows up in http logs, and denying http service to those
> IPs in httpd.config does no good (I assume it's an ip spoof of some sort?)

	You won't normally see a synflood in Web server logs because the
TCP connection isn't up yet.  So it's still being handled by the
kernel's TCP stack, and hasn't been handed off to Apache yet.  Once the
SYN - SYN/ACK - ACK handshake is done, that's when Apache or any higher
layer software like that gets involved and GET requests and the things
you normally see in your logs start happening.

	It probably is spoofed, but you could try complaining to the
owners of that netblock with timestamped logs just in case.  That IP
doesn't have any DNS entries for it.

[scarlett] ~ > nslookup 62.13.43.60
Server:  my.isp's.name.server
Address:  ip.addy.of.server

*** my.isp's.name.server can't find 62.13.43.60: Non-existent
host/domain 

and the block is allocated to EUIT Trading in Sweden.  

[scarlett] ~ > whois 62.13.43.60
Query:     62.13.43.60
Registry:  whois.ripe.net
Results:
% This is the RIPE Whois server.
% The objects are in RPSL format.
% Please visit http://www.ripe.net/rpsl for more information.
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html

inetnum:      62.13.43.56 - 62.13.43.63
netname:      EUIT-SE-NET
descr:        EUIT-Trading
descr:        Farsta
country:      SE
admin-c:      JAH29-RIPE
tech-c:       JAH29-RIPE
status:       ASSIGNED PA
mnt-by:       AS8434-MNT
changed:      kandra at utfors.se 20010514
source:       RIPE

route:        62.13.0.0/17
descr:        UTFORS-BLK
origin:       AS8434
member-of:    AS8434:RS-PA-BLK
mnt-by:       UTFORS-MNT
changed:      hakan at utfors.net 20020424
source:       RIPE

person:       Jean-Claude Ahnland Henry
address:      EUIT-Trading
address:      Kryddgrand 6
address:      SE-12358 Farsta
address:      Sweden
e-mail:       jcah at euit.com
phone:        +46 739 380483
mnt-by:       AS8434-MNT
nic-hdl:      JAH29-RIPE
changed:      kandra at utfors.se 20010514
source:       RIPE

Results brought to you by the GeekTools WHOIS Proxy
Server results may be copyrighted and are used with permission.
Your host (165.117.35.134) has visited 1 times today. 

	And the /17 netblock is being announced by someone into the
global routing table:

my-router# sh ip bgp 62.13.43.60
BGP routing table entry for 62.13.0.0/17, version 14529598
Paths: (1 available, best #1)

	But the machine is not pingable:

my-router#ping 62.13.43.60

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 62.13.43.60, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5) 

	Traceroutes die at 

16 ge-2-3-0.se-snams001-solna-pe-1.utfors.net (212.105.101.41) [AS
8434] 252 msec 256 msec 256 msec

which is the owner of the /17 netblock.  Probably the ISP of EUIT
Trading.

> 	Any idea what this goon is up to, how to find out who's doing it,
> or any other fun things to know?

	What they're up to?  Probably idly trying to kill your web
server.  How to find out who's doing it is a big effort in coordination.
If the address is spoofed, the traffic can in theory be traced back to
its actual source by your ISP.  There has to be a constant stream of
traffic for them to do this, and they have to be using routers capable
of this and a backbone design that's capable of this.  (I do this all
the time for my ISP.)  It requires the equivalent of root access on the
routers, on every router in between you and the black hat.  So end users
can't do this trace.

	Your ISP may be able to trace the traffic through their network,
to where it exits (generally at a peer, or their upstream connection to
their ISP).  At that point they have to get the NOC of whatever network
the traffic is coming from to continue the trace, and so on back to the
source of the traffic.

	Most ISPs either won't or can't do this.  So usually spoofers
get off scot-free.  I wrote a tool to automate this process for the ISP,
but even this is hard to deal with because of weaknesses in common
router vendor OS design.  (The way most backbone routers are configured,
you cannot see every packet that passes through.  So if you're being
attacked by a small volume of traffic, it may just never show up in the
router logs and you lose the trail.)

	Wish I could be more cheerful, but the infrastructure of the
Internet is poorly designed to deal with one-way packet spoofers.
Anyone can send a stream of traffic that they don't need to recieve the
responses to, "from" any address.  Many DoS attacks fall into this
category.  It's puerile and annoying, but there are lots of childish people
who don't care and will gleefully be jerks.

	We have recently seen a new wave of DoS attacks at my job, where
someone will send a synflood that pretends to be from the address of the
victim system under attack, to intermediate servers.  (Your server may be a
good example of that.)  The intermediate servers see a synflood attack
from the victim system.  But your server is busily acking away all those
syns, and so all those acks flood the line of the victim.  And two
systems are incapacitated for the price of one.  There was a massive
wave of this directed against a machine owned by the Israeli government
last week.  Several ISPs saw it.  The people whose web servers were
being synflooded complained about the Israeli machine, and the Israeli
machine had been knocked off the Net by all the acks.  It was very
difficult to clean up after.  Strategically placed nullroutes contained
the attack traffic, but engineers from many ISPs spent hours doing this,
since the attackers kept changing what intermediate servers they were
targeting.  Huge pain in the ahem, and I had better things to do with my
day.  

Cheers,
Raven

"You found the Amulet of Yendor!"