From owner-freebsd-pf@FreeBSD.ORG Mon Nov 10 09:20:13 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 12E3C106564A for ; Mon, 10 Nov 2008 09:20:13 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id D1AF48FC1F for ; Mon, 10 Nov 2008 09:20:12 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2247587rvf.43 for ; Mon, 10 Nov 2008 01:20:12 -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=+kvFn92WPkBSAN7ldwAakYSYYs2HBJuVsveNmZejvFk=; b=id09ZvkF38zU7lxt60I9FdbwGv99v+lqDsl6thJ7i5FlYG7Sb7jANXfdfgn9RcI67/ oKQTYzHlKxNSicBUUblyW62tXHYocEsasum/8CN9vCbIrsKJ8C3eri0j/64ZHlwuDgH7 ov++XuSjmiOkqXMTLoxe6sRZsSOWsiLN1LqV8= 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=JKfd+g4fVfeFgdb+C5jEsCBm7y+4ZqmcaRqpcR+tTRKDAN18rfi3FakYSXBtRxKACm g5N+JrEt424M1yajjwo5Ew+t3B+s3xbLm1+dwsBEY5U5NGAshHxmbVGm2Q7IBd2VYjvE sI6YZUU/9m0l8aQg2pT5rSymhJ3EOW+O2687o= Received: by 10.143.5.21 with SMTP id h21mr2288314wfi.183.1226308812207; Mon, 10 Nov 2008 01:20:12 -0800 (PST) Received: by 10.143.93.6 with HTTP; Mon, 10 Nov 2008 01:20:12 -0800 (PST) Message-ID: <1814bfe70811100120if6b7102p54905f1f7dde98ae@mail.gmail.com> Date: Mon, 10 Nov 2008 10:20:12 +0100 From: "Elvir Kuric" To: "Peter Maxwell" In-Reply-To: <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> 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> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> 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: Mon, 10 Nov 2008 09:20:13 -0000 Hi Peter, Thank you for this excessive answer and it is really helpful. On Sun, Nov 9, 2008 at 6:47 PM, Peter Maxwell wrote: > Hi Elvir, > > I'd second the advice given further up the thread about getting your > ISP to filter upstream - that's about the only really effective > solution. Once UDP packets hit your firewall's external interface > there's very little you can do about it. > > The only other advice I could offer is; > > i) Make sure the block rule for UDP gets hit first or very early in > the rulebase (this can actually make a lot of difference for large > rule sets) - and that the packet is dropped immediately without having > to traverse the rest of the rule set (i.e. use "block quick" and "set > block-policy drop"). > UDP drob rule is at very begginig, it is clear to stop packets which are not necessary in network as soon as possible just to prevent them to " eat " CPU, memory resources, etc > ii) Ensure you're using a good NIC, the CPU offload abilities in Intel > (and I think Broadcom) cards can reduce the impact on CPU generally. This could be weak point in chain. I will try to change some hardware, maybe the whole machine, it is not some representative hardware. But for purpose of filtering ( with udp hosts ) it works super. > > iii) Repeating the advice given from others in the thread above, only > use logging very carefully. > > iv) Check the limits on the state table are high enough (and that you > have enough memory to accomodate this) - its not entirely uncommon for > a DDoS attack to completely fill the state table and block legitimate > traffic (might be worthwhile checking that this isn't happening). > > v) There may be some mileage in tinkering with the udp timeout values, > but it could also be counter productive if the state processing is > faster than the initial rule processing - so you'd have to test this > for yourself. If the bad traffic is coming from a massive range of > source addresses (spoofed or not), then you're better clearing them > from state quickly - if there is only a selection of source IPs then > keep them in state longer. > > vi) Is your connection got enough bandwidth to handle legitimate > traffic alongside the DoS traffic - if it doesn't you're stuck anyway. > > viii) Can you upgrade the CPU on the box? > As I said, I will upgrade box, change it, with some better, this one is not very good. > > The ALTQ facilities will not help you with this. ALTQ only queues > *outgoing packets* so cannot help with incoming UDP. The reason you > may sometimes see advice that ALTQ can manage incoming packets is to > do with TCP return ACK packets, you can ensure the return ACK packets > don't have to compete with outgoing traffic by restricting outgoing > bandwidth just a little - and hence speeding up your TCP connections. > But again, no use here. Regarding this all is clear, UDP is connectionless so tracking it will not be useful, :) and as you write is could help just to manipulate with ack answers in tcp connections > > To be honest I'm slightly surprised that CPU resource is the first > limit you've hit, its usually going to be bandwidth. Packets filters > are generally very very fast at doing simple drops - is the actual > transfer of data or VPN stuff that usually kills a firewall. How wide > is your connection? > 1Mb/2Mb > Cheers, > > Peter > > ---------------------------------- > http://www.allicient.co.uk/ > Nice regards, Elvir Kuric > > > > > > > > > 2008/11/9 Elvir Kuric : >> 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 >> _______________________________________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >