Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Nov 2007 23:21:19 +0100
From:      Pieter de Boer <pieter@thedarkside.nl>
To:        Remko Lodder <remko@FreeBSD.org>
Cc:        freebsd-hackers@freebsd.org, "Joel V." <joel@smail.ee>
Subject:   Re: Welcome to Hell / Mysterious networking troubles on FreeBSD
Message-ID:  <4748A3DF.401@thedarkside.nl>
In-Reply-To: <47489B7C.90000@FreeBSD.org>
References:  <000101c82ed9$4d0986b0$0200a8c0@windsor> <47489B7C.90000@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Remko Lodder wrote:

> Joel V. wrote:
>> Hopefully the situation will be fixed soon. One final question though: are
>> there any quick steps one can take to protect their server from DDOS attacks
>> like these?
>>
> If someone wants to flood your network connection with packets there is
> nothing you can do about it, your line can only handle so much packets
> even if you just drop them or something.
> 
> You'll just have to wait till the ISP can resolve it or the attack
> stops :(
Well, that all depends on the impact the flood has on your network 
connection and what kind of contract you have with your upstream 
provider. If the amount of traffic coming in over your uplink does not 
exceed the available uplink bandwidth by a large margin, you will not 
noticeably suffer packet loss due to congestion. I've had a 100MBit/s 
DDoS-attack against a server that was connected to a 100MBit/s link and 
didn't even notice it, even though I was logged in over SSH. Such 
amounts of traffic may cost you a lot of money though, so it may be wise 
to filter it at the upstream even if it doesn't degrade performance 
noticeably. From your e-mails I concluded your link was swamped, due to 
too much traffic coming in. If that's the case, there's not really much 
you can do..

Generally speaking, the following may help. A possibly important factor 
to consider is the number of packets per second you're receiving. Given 
the packet size of over 9000KBytes in your tcpdump output, the packet 
rate can't be too much. However, if you're receiving, let's say 80Mbit/s 
in 64 bytes small packets, that's 150Kpps, which can have quite an 
impact depending on what your system does with all those packets.

So, what you want your system to do, is to handle as much packets per 
second as possible, and to have them thrown away as soon as possible. 
Using interrupt coalescing, polling, checksum or possible even 
reassembly offloading will help against deadlocks. When there's only 
one, or a limited set of attacking IP addresses, it's probably easiest 
to just block traffic from that addresses in the first rule of a 
firewall. Even when lots of hosts are attacking, firewalling them may be 
beneficial (be sure to use tables in your firewall configuration, 
instead of lots of per-address rules!). As far as I've seen in the past, 
only a small amount of DDoS-attacks are  based on spoofing the entire 
32-bits address range (most hosts can only spoof the host-part of the 
address due to filtering on access routers). So if the largest part of 
traffic you're seeing comes from non-spoofed or hardly-spoofed 
addresses, firewalling becomes possible.

If firewalling isn't an option and traffic is sent to a port that isn't 
listening, blackholing (sysctl net.inet.tcp.blackhole and 
net.inet.udp.blackhole) can be useful. This ensures that your system 
doesn't send ICMP unreachables or TCP RST's back. By default, FreeBSD 
ratelimits these to 200 per second, which should suffice. Still, in that 
case the packets will have to traverse more of the TCP/IP stack, so if 
you're seeing lots of packets per second, blackholing may reduce the 
load somewhat.

Lastly, if the packets can not be filtered because they are sent from 
lots and lots of random source addresses, or firewalling isn't an 
option, and the packets are sent to an active service, the service 
itself could possibly be tuned to handle the load better. For DNS 
there's not much options besides running a more performant nameserver or 
dropping incorrect queries without sending a 'REFUSED' answer. For other 
applications accept_filters may be useful or possibly ratelimiting 
built-in the service (inetd, ntp, sendmail/postfix, etc).


So, even though DDoS-attacks are hard to handle, there's still some 
possibilities left. The only thing nothing can be done about without 
help from the uplink ISP(s) is having a lot more traffic coming in over 
the uplink than it can handle.

Good luck with your sucky situation,

-- 
Pieter



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4748A3DF.401>