Blocking udp flood trafiic using pf, hints welcome

[fbsdmail at dnswatch.com]

Hello Peter, and thank you for your reply...

On Sun, January 18, 2009 5:10 am, Peter Maxwell wrote:
> Comments inline...
>
>
>> 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:
>>
>
>
> Chris, you've rather missed the point here: pf can easily drop the UDP
> packets, however *whatever* you do there's going to be CPU cycles used to
> drop them.  You could use a whole different array of packet
> filters/firewalls to drop the UDP packets but its still going to drag down
> your firewall machine and/or internet connection.  Hence the only real
> solution is upstream filtering, or if you are piering directly your router
> should be fast enough.

Oh, I understood the thread topic, but got the impression from
Jeremy's reply, that attempting to block UDP via PF wasn't feasible.
It was also my understanding that the OP's biggest shortcoming was
his attempt to log all the communication.

For me neither will be an issue;

1) I'm not interested in anything more than "first attempts" in
the logs.

2) All the servers have a spare onboard NIC that I haven't even
enabled yet. Which means I can "bind" them, there-by allowing me
better throughput to hadlde excessive traffic.

3) they are all multi-cpu servers. So I have enough cycles available.

Thanks again, for taking the time to reply.

--Chris

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