Blocking udp flood trafiic using pf, hints welcome

[fbsdmail at dnswatch.com]

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

On Sun, January 18, 2009 8:44 am, Peter Maxwell wrote:
> 2009/1/18  <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.
>
> Appologies, I think I've missed a post somewhere along the way - pf
> can deal with UDP no bother.
>
>>
>> For me neither will be an issue;
>>
>>
>> 1) I'm not interested in anything more than "first attempts" in
>> the logs.
>
> pf does handle UDP quite well,

Glad to hear it. :)

> although UDP is technically stateless pf
> will create a state for it based on IP/port numbers.  Default logging also
> only logs the *first* packet in a state, so if you enable logging by
> default it will only log the first packet - although in high traffic
> scenarios that in itself may kill a box.
>
>
>>
>> 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.
>
> I take it your upstream pipe(s) is/are bigger?

Somewhat dynamic.

>
>
>>
>> 3) they are all multi-cpu servers. So I have enough cycles available.
>>
>
> Then you're probably ok with the logging ;-)  Might be worthwhile
> setting up the box and testing it first, then you'll know whether the disc
> array, etc will keep up.  As you'd generally use tcpdump to view the logs,
> always copy them off the firewall box first.

Assuming I feel the need to scan the PF log(s), I imagine dump(8)
will suit me just fine. :)

>
> If you're interested, pf can also do state sync so if you've got two
> boxes you can have a redundant configuration.  Never tried it with pf, but
> have used the equivalent with Checkpoint firewalls and it is invaluable
> (e.g. you can swap then out without losing service).

Sounds like a plan. This project could turn out to be a real testament
to FreeBSD, and PF itself.

I have only one problem - this will be a first go 'round with PF.
I'll need to experiment on one of the servers. I don't suppose you'd
be willing to /suggest/ a reasonable "starting point" for a pf.conf,
would you?

Assuming you (or anyone else) would - a little more info is in order;

I'll slice out a /27 segment, and just start small. ;)
OH, and I have no private IP's involved - think dummynet.

To make the numbers easy to work with, I'll use the following:

ifconfig_fxp0="inet xxx.xxx.xxx.1  netmask 255.255.255.224"

as I mentioned, all of the servers have at least 3 /aliased/ IP's

ifconfig_fxp0_alias0="inet xxx.xxx.xxx.3 netmask 255.255.255.255"
ifconfig_fxp0_alias1="inet xxx.xxx.xxx.4 netmask 255.255.255.255"
ifconfig_fxp0_alias2="inet xxx.xxx.xxx.5 netmask 255.255.255.255"

xxx.xxx.xxx.0 --> NET
xxx.xxx.xxx.1 --> NS1 (this is the box we're dealing with)
xxx.xxx.xxx.2 --> any
...
xxx.xxx.xxx.3 --> alias0
xxx.xxx.xxx.4 --> alias1
xxx.xxx.xxx.5 --> alias2
...
xxx.xxx.xxx.30 --> gateway
xxx.xxx.xxx.30 --> BCAST

Given this scenario, what would be a simple starting (but working)
pf.conf, that would allow trapping (drop) the UDP spam, but not
really mess with anything currently in use (NFS,SSH,WWW,DNS,etc...)?
While I haven't setup PF before, I have done a boatload of reading.
Only problem being; I can't seem to find anything similar to my needs.
Most all are designed for traffic shaping, are NAT'd, or are OpenBSD
centric. So I've been afraid to try to adapt any of them on my
/first/ go'round.

My scenario /seems/ like it'd be pretty easy - assuming I had any
/prior/ experience with PF. ;)

Thank you again for your response!

Best wishes.

--Chris

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