Date: Sun, 9 Nov 2008 03:21:25 -0800 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Elvir Kuric <omasnjak@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: Blocking udp flood trafiic using pf, hints welcome Message-ID: <20081109112125.GA36707@icarus.home.lan> In-Reply-To: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 09, 2008 at 10:37:29AM +0100, Elvir Kuric wrote:
> I am playing with pf tool on openbsd/freebsd platforms and it is super
> tool for firewalls. On thing is interesting for me, and I am hopping
> someone has expeience with this.
>
> If I say
>
> block log all
> block in log (all) quick on $ext_if proto udp from any to $ext_if
>
> this would block all traffic on $ext_if, but on my ext_if I recive a
> lot of ( huge amount ) of udp generated traffic which make me a lot
> of problems.
> I also tryed to add small pipe and play with ALTQ to handle this but
> it did not help a lot. Also I know that every packet which hit my
> ext_if should be
> processed ( or least take a little processor resources, if I block
> it with keyword quick ), but I am wondering is there some way to
> decrease impact on system
> when a lot of packets arive in short time.
>
> My question would be, what are your experinces with battling against
> boring udp flooders ? Platform are FreeBSD / OpenBSD and all works
> like a charm except time to time, stupid udp flood atacks.
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. :-)
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).
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.
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.
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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081109112125.GA36707>