From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 13:44:54 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D6661065673 for ; Sun, 9 Nov 2008 13:44:54 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id E0C4E8FC0C for ; Sun, 9 Nov 2008 13:44:53 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1977765wfg.7 for ; Sun, 09 Nov 2008 05:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Ig+kZTy8YnKbb8YS65L2K8557gFSdyeJHzuW6YMEvuE=; b=BHHNFznfWntNflUCo03H0Z39QA9FyC6kwBdeMlE7odZRNiSb1r7+kxcIHGikMz+Ico NK8eTUSZkMx3fV9okEpDxVwJGzN551KsVhjzFZ+YrSzyt8gLaz7CUZVycaBD0hrx2zTt pzORc7eW4SrcfAqqIMJ1jN9UvIS+xwm6gh7z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Y0h9BWBGll8obHtI5YFvC+PP+RXNT5C3AZnXinMHd9r/cJ4z+1bpXOqabW6XKjiJqE pWWVjUZtVn1fVTQ68EL33892gUi4Tw6+x5a9KLDRF9TGbOqbzX0THhtIrg4ryVvSGTEw Y9QnljMhD3AQQUdwEGxlaZ/wez2dmGXW6N4Ck= Received: by 10.142.223.20 with SMTP id v20mr1822393wfg.7.1226238293492; Sun, 09 Nov 2008 05:44:53 -0800 (PST) Received: by 10.143.93.6 with HTTP; Sun, 9 Nov 2008 05:44:53 -0800 (PST) Message-ID: <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> Date: Sun, 9 Nov 2008 14:44:53 +0100 From: "Elvir Kuric" To: "Jeremy Chadwick" In-Reply-To: <20081109112125.GA36707@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> Cc: freebsd-pf@freebsd.org Subject: Re: Blocking udp flood trafiic using pf, hints welcome X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2008 13:44:54 -0000 Hello Jeremy, Thank you for your time and your answer, > First, you should be very careful with use of the "log" directive on > your rules. I've personally witnessed an attack which triggered "log" > entries in block rules causing pflog to log at such a tremendous/fast > rate, that newsyslog could not rotate+compress the log files fast > enough, resulting in CPU maxing out and so on (a true self-induced > denial-of-service). Consider this warning. :-) I absolutely agree with you regarding logging, and I do not practice this, only logging specific data. The biggest problem with this DoS attacks ( udp floods ) is, processor must spend some time on packet arrive ( even dropping will take some processor power ). > > Secondly, and this is more a direct answer of your question: I believe > what you're referring to is a UDP-based DoS attack against your FreeBSD > machine(s). Actually it is OpenBSD, but it is not important for this case. > > The "block" directives you're using will only stop your FreeBSD box from > responding to those packets (whatever you do, silently deny those > packets; do not use "reject", or else your box will be trying to send > back denial responses to the attackers, which just makes the problem > worse). It *cannot* solve the problem of your network connection > becoming saturated. Block works fantastic, connection goes down due to milions of packets arrived. > > Your next question will be: "okay, so how do I solve this problem?" This > is where it gets both technical and political. There are two things to > do first: > > 1) See if the attacks are distributed (multiple IPs or even spoofed IPs > hitting your machine with UDP packets). If they're distributed or > spoofed, you're out of luck. > > If the packets are legitimate (e.g. some compromised machine on the > Internet is being used to attack you), you need to find out who own that > IP address, and contact them. ARIN (WHOIS) can be of help here. Pray > they have an abuse department. If you do not get a prompt response > (24-48 hours), try to figure out who their upstream network provider is, > and send them a similar message. Continue up the chain until you get a > response. Phone calls (even international) often work wonders > decreasing mitigation time. > > 2) Investigate your own machine. I cannot stress this enough. Most DoS > attacks I've seen in my years ARE NOT random -- there's a reason they > happen. > > The majority of attacks I've seen involve IRC in some way, either as a > central cause of attack (arguments, channel takeovers, whatever), or > indirectly (a compromised account on your machine). If your machine is > a shell box for friends/customers, I highly recommend considering *not* > permitting IRC from it; this includes bouncers and eggdrops. > > Many IRC-induced attacks are done against a machine solely to knock it > offline (so the user on IRC pings out for a channel takeover, or just to > keep the user from getting back on IRC). > > And if your machine(s) run IRC servers... well, this is one of the many > dangers in hosting a server. You have to weigh what's more important to > you in this case: IRC, or the availability of your machines. I speak > from personal experience as someone who used to administrate a public > EFnet server, and as someone who has used IRC for the past 16 years. > Whichever matters to you more is what you should stick with. > > The second most common reason for attack I've seen are controversial > websites or domain names -- things that induce arguments, controversy or > heated discussions, or are of a "shady" nature and would bring shady > or questionable attention to you (e.g. wehaveeggdropshellz.com). If > you host anything like this, consider suspending it, or removing the > customer due to incidents which cause the network to become unavailable. > Remember: one customer/user is not worth sacrificing all the rest. > > Finally: work with your own service/uplink provider. In the case of a > very large-scale attack, your ISP will need to do the filtering to > ensure that the packets never reach your machine. "What can they filter > on if it's DDoS?" Good question -- very little. But your uplink should > at least be told of the problem, both out of respect, and for your own > benefit (especially if you are billed for *incoming* traffic!) > > If you don't find decent answers here, I highly recommend freebsd-net > or freebsd-isp. Others may have better advice. No IRC is present here, or similar staff it is just firewal/router runing at the edge of internal network. Also on machines in internal network there is not some, "interesting " stuff. Thank you very much for your answer it is very helpful. > > Footnote: Like SMTP and spam, IRC as an entity is not evil or bad -- the > problem is that in this day and age, it can breed trouble. I don't want > to sound like I'm slamming IRC ("IRC sucks! Ban IRC!"); I'm not. I'm > simply pointing out the realities that are involved with IRC in this day > and age. The degree of anonymity DoS and IRC provide sometimes brings > out the worst in people, and that's sad. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > Kind regards, Elvir Kuric