syn DDoS attack solution

  Hi all,


  We recently got under a low traffic botnet DDoS attack.
All attacker 
nodes opened a single tcp session (just SYN part) and then
did nothing. 
This rules out rate limiting solutions and syncookie doesn't
help 
either. (Thousands of attacking nodes).


  I'd like to know you thoughts about two possible
approaches in solving 
this:

- syn proxy: already used for example by Cisco. The router
handles the 
first part of the connection and only routes packets to the
client if 
the connection seems good. (Good against single/spoofed
incoming SYNs 
but may be used to wait for the first packet with actual
data as well).
- Implement a conntrack solution that gives a timestamp to
the 
connection. Then this timestamp could be used to drop the
connection if 
no data arrives within a configured time limit (good for
open inactive 
connections only). Of course appropriate close toward the
local client 
has to be done as well.

What's your opinion?

Bye
Bgs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 31 May 2007, Bgs wrote:

>
> Hi all,
>
>
> We recently got under a low traffic botnet DDoS attack.
All attacker nodes 
> opened a single tcp session (just SYN part) and then
did nothing. This rules 
> out rate limiting solutions and syncookie doesn't help
either. (Thousands of 
> attacking nodes).
>
>
> I'd like to know you thoughts about two possible
approaches in solving this:
>
> - syn proxy: already used for example by Cisco. The
router handles the first 
> part of the connection and only routes packets to the
client if the 
> connection seems good. (Good against single/spoofed
incoming SYNs but may be 
> used to wait for the first packet with actual data as
well).
> - Implement a conntrack solution that gives a timestamp
to the connection. 
> Then this timestamp could be used to drop the
connection if no data arrives 
> within a configured time limit (good for open inactive
connections only). Of 
> course appropriate close toward the local client has to
be done as well.
>
> What's your opinion?
>


That you knowledge ot TCP/IP is poor.



Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant: 
sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC
94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With
Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFGXyiqst+vzJSwZikRAih2AJ0SY0npal/EqdwWK+/4SYOGaXY/uACg
gRtl
uhPlH5F7JzCJGHf2RgryJT4=
=Y3xX
-----END PGP SIGNATURE-----

Bgs writes:
> 
>   We recently got under a low traffic botnet DDoS
attack. All attacker
> nodes opened a single tcp session (just SYN part) and
then did nothing.
> This rules out rate limiting solutions and syncookie
doesn't help
> either. (Thousands of attacking nodes).
> 

This is simply a SYN flood attack. It may or may not be a
botnet (though
saying botnet makes it sound sexier  ). A
decent SYN flood attack tool
would randomize the source address anyway. 

You should try reading the following as a starting point:

http://www.
securityfocus.com/infocus/1729

Your second suggestion has been implemented in the TCP/IP
stack forever. The
article above gives guidance on how to tune it in a Linux
implementation.

Ric

I have a thought about this.
I can use ipset and iptables on a bridge firewall.

ipt_recent module compares the SYN package and ACK package's
TTL. If not 
match then drop.
ipt_hashlimit module stores the concurrent connections. When
the 
connections exceed the threshold iptables would store the IP
in ipset.
ipset's iptree modules can store the IP in a fixed time.
When a IP which 
is in the iptree's list comes the firewall iptables would
TARPIT its tcp 
connection.

Is this setting effective?


Ric Messier wrote:
> Bgs writes:
>   
>>   We recently got under a low traffic botnet DDoS
attack. All attacker
>> nodes opened a single tcp session (just SYN part)
and then did nothing.
>> This rules out rate limiting solutions and
syncookie doesn't help
>> either. (Thousands of attacking nodes).
>>
>>     
>
> This is simply a SYN flood attack. It may or may not be
a botnet (though
> saying botnet makes it sound sexier  ). A
decent SYN flood attack tool
> would randomize the source address anyway. 
>
> You should try reading the following as a starting
point:
>
> http://www.
securityfocus.com/infocus/1729
>
> Your second suggestion has been implemented in the
TCP/IP stack forever. The
> article above gives guidance on how to tune it in a
Linux implementation.
>
> Ric
>
>
>
>   

> This is simply a SYN flood attack. It may or may not be
a botnet (though
> saying botnet makes it sound sexier  ). A
decent SYN flood attack tool
> would randomize the source address anyway. 

Some more info about the attack: All IPs were real IPs
otherway the tcp 
handshake wouldn't have made it. The attacker IPs were also
consistent. 
They also new about the blocked IPs as after a new bunch of
blocked IPs 
we fared OK then they added another bunch new IPs... we
played this for 
quite some time...

All connections were in the ESTABLISHED state.

> 
> You should try reading the following as a starting
point:
> 
> http://www.
securityfocus.com/infocus/1729
> 
> Your second suggestion has been implemented in the
TCP/IP stack forever. The
> article above gives guidance on how to tune it in a
Linux implementation.

That part is about syncookies, backlog queue and half open
timeouts. 
None of them applies here as all connections are legitimate
in terms of 
SYN packets and tcp handshake.

How is the handling of ESTABLISHED connections implemented
in the TCP/IP 
stack?

>> What's your opinion?
>>
> 
> 
> That you knowledge ot TCP/IP is poor.

*clap*

> 
> 
> 
> Thanks,
> 
> Ron DuFresne
> - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         admin & senior security consultant: 
sysinfo.com
>                         http://sysinfo.com
> Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF
AFCC 94B0 6629
> 
> ...We waste time looking for the perfect lover
> instead of creating the perfect love.
> 
>                 -Tom Robbins <Still Life With
Woodpecker>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> 
>
iD8DBQFGXyiqst+vzJSwZikRAih2AJ0SY0npal/EqdwWK+/4SYOGaXY/uACg
gRtl
> uhPlH5F7JzCJGHf2RgryJT4=
> =Y3xX
> -----END PGP SIGNATURE-----

Bgs writes:
> 
> Some more info about the attack: All IPs were real IPs
otherway the tcp
> handshake wouldn't have made it. The attacker IPs were
also consistent.
> They also new about the blocked IPs as after a new
bunch of blocked IPs
> we fared OK then they added another bunch new IPs... we
played this for
> quite some time...
> 
> All connections were in the ESTABLISHED state.
> 

Then your original description was incorrect or at least
inadequate. It has
nothing to do with SYN as originally suggested since an
ESTABLISHED
connection has blown past SYN, through SYN/ACK and by ACK.
It has completed
the TCP handshake, as you note above. A SYN attack/flood
would stop after
sending the initial SYN and leave the connection half-open
to exhaust the
half-open buffers.

> 
> How is the handling of ESTABLISHED connections
implemented in the
> TCP/IP
> stack?

There is likely a timer somewhere to time out connections
that are just
hanging around doing nothing. You'd have to dig around to
find it and turn
it down. You could also use something like tcpkill to get
rid of them for
you. 


Ric

Sorry if my first mail was misleading, I only slept about
5-6 hours this 
week in all :/

>> How is the handling of ESTABLISHED connections
implemented in the
>> TCP/IP
>> stack?
> 
> There is likely a timer somewhere to time out
connections that are just
> hanging around doing nothing. You'd have to dig around
to find it and turn
> it down. You could also use something like tcpkill to
get rid of them for
> you. 

What I'd like to achieve is different from the normal tcp
timeouts. I 
only want a different (quite short in terms of everyday tcp
traffic) 
timeout for connections that have not sent any data after
the tcp 
handshake. The connections that did any traffic would become
normal or 
'legitimate' and the usual tcp timeouts would apply.


About the netlink approach, here is what I was thinking
about. I have 
never coded in the netlink/netfilter space so I'm completely
in the dark 
if this can be done at all or not:

Client sends SYN to server. It arrives to the firewall. An
info is sent 
to the userspace portion and the SYN packet is DROPed. The
user space 
program logs the SYN packet and sends out an appropriately
constructed 
SYN/ACK to the client. Client sends the ACK. The info is
sent to util 
which logs the packet and puts the connection in allowed
state as it 
knows from it's own db that the tcp handshake was ok. At
this point it 
either starts the next phase or waits for the first data
packet and 
starts the next phase then (allowing the data packet after
it). The next 
phase is: userland replays the SYN handshake with the server
thus making 
it receptive to the tcp stream to come. Through netlinks
firewall part 
it would allow all subsequent traffic.

The main point is almost identical to the syn proxy thingie
in bsd and 
ios, the main difference would be the ability to add some
policy about 
when and how to let the traffic through to the server. For
example with 
delayed replay, connections in ESTABLISHED state but without
data would 
be dropped from the replay db stopping the culprit at the
firewall.

Just a thought... can it be done (technically) or should I
simply go to 
bed 

Regards
Bgs

Ric Messier wrote:
> Bgs writes:
>   
>> Some more info about the attack: All IPs were real
IPs otherway the tcp
>> handshake wouldn't have made it. The attacker IPs
were also consistent.
>> They also new about the blocked IPs as after a new
bunch of blocked IPs
>> we fared OK then they added another bunch new
IPs... we played this for
>> quite some time...
>>
>> All connections were in the ESTABLISHED state.
>>
>>     
>
> Then your original description was incorrect or at
least inadequate. It has
> nothing to do with SYN as originally suggested since an
ESTABLISHED
> connection has blown past SYN, through SYN/ACK and by
ACK. It has completed
> the TCP handshake, as you note above. A SYN
attack/flood would stop after
> sending the initial SYN and leave the connection
half-open to exhaust the
> half-open buffers.
>   

An connection is in the ESTABLISHED state once a packet has
been seen. 
So once the SYN is seen, the state is ESTABLISHED.

M4

Martijn Lievaart writes:
> 
> Ric Messier wrote:
> > Then your original description was incorrect or at
least inadequate.
> It has
> > nothing to do with SYN as originally suggested
since an ESTABLISHED
> > connection has blown past SYN, through SYN/ACK and
by ACK. It has
> completed
> > the TCP handshake, as you note above. A SYN
attack/flood would stop
> after
> > sending the initial SYN and leave the connection
half-open to exhaust
> the
> > half-open buffers.
> >
> 
> An connection is in the ESTABLISHED state once a packet
has been seen.
> So once the SYN is seen, the state is ESTABLISHED.
> 

Not last time I checked. That may be true to some degree in
iptables but in
netstat, an ESTABLISHED connection is one that has made it
through the
handshake process. Otherwise, it's in SYN_RECV state. 

Ric