Date: Sun, 9 Nov 2008 17:47:54 +0000 From: "Peter Maxwell" <peter@allicient.co.uk> To: freebsd-pf@freebsd.org Subject: Re: Blocking udp flood trafiic using pf, hints welcome Message-ID: <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> In-Reply-To: <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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"). 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. 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? 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. 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? Cheers, Peter ---------------------------------- http://www.allicient.co.uk/ 2008/11/9 Elvir Kuric <omasnjak@gmail.com>: > 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7731938b0811090947j4796680cj7344ca3333c05779>