From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 24 22:21:23 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CCBA16A418; Sat, 24 Nov 2007 22:21:23 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (cl-92.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:5b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 053BA13C44B; Sat, 24 Nov 2007 22:21:23 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from [192.168.1.10] (s55915f73.adsl.wanadoo.nl [85.145.95.115]) by mail.thelostparadise.com (Postfix) with ESMTP id 1CC4761C24; Sat, 24 Nov 2007 23:21:21 +0100 (CET) Message-ID: <4748A3DF.401@thedarkside.nl> Date: Sat, 24 Nov 2007 23:21:19 +0100 From: Pieter de Boer User-Agent: Thunderbird 2.0.0.6 (X11/20071105) MIME-Version: 1.0 To: Remko Lodder References: <000101c82ed9$4d0986b0$0200a8c0@windsor> <47489B7C.90000@FreeBSD.org> In-Reply-To: <47489B7C.90000@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 24 Nov 2007 22:34:48 +0000 Cc: freebsd-hackers@freebsd.org, "Joel V." Subject: Re: Welcome to Hell / Mysterious networking troubles on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2007 22:21:23 -0000 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