Blocking udp flood trafiic using pf, hints welcome

[fbsdmail at dnswatch.com]

Greetings, see below...

> 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.

Hello Jeremy,
 I just joined this list. Then started parsing the archive, and
ran into this - what you refer to, is exactly the reason I'm getting
off my a$$ and getting PF configured on my servers - something I've
been too busy to get to, but now finding myself /having/ to. :(
To the point. I'm receiving an inordinate amount of UDP traffic lodged
against DNS on all the servers. I immediately fired off emails to the
RP's, and received prompt responses. /However/ one of the RP's indicated
they've been up against this since /Christmas/. While I'm not going to
mention the Firm, I will tell you that they are quite large
(xxx.xxx.128.0/20 - xxx.xxx.128.0 - xxx.xxx.143.255). I've now
been suffering the consequences for 3 days, with no end in sight.
So, while I have a hard time understanding how an entity managing
such a large amount of IP real-estate, can't figure out how to keep
from becoming/continuing to produce "drone's", I /do/ understand that
/I/ am capable of putting up a wall to block the abuse emanating from
their network. Which brings me here. :) Am I correct in understanding
from your response that FreeBSD PF can't effectively drop UDP packets?
My current defence (aside from my application/server block polocies)
is some sysctl(8)/sysctl(5) tunables:

net.inet.udp.log_in_vain=0
net.inet.tcp.log_in_vain=1

net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1

net.inet.tcp.icmp_may_rst=0
net.inet.tcp.drop_synfin=1

# don't accept sourcerouted packets (they are evil)
net.inet.ip.accept_sourceroute=0
net.inet.ip.sourceroute=0

security.bsd.see_other_uids=0

While all of these are not INET TCP/ICMP/SYN/UDP  related, it's
a pretty good rule of thumb for sysctl security tunables. But
isn't there some pf.conf that I can create that will simply drop all
UDP traffic from the offending IP? Based on the data in my logs, and
my understanding of all the powerful tools that are available (for both
good, /and/ evil), I'm near positive that the attacker is bouncing
the packets off the "drones" with HPING. Anyway, I felt the need to chime
in when I noticed you addressed all the topics that described my
current situation, hoping PF would be the solution (my savior).

Best wishes.

--Chris


> --
> | 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 |