pf vs. RST attack question

[Jeremy Chadwick]

On Mon, Oct 06, 2008 at 08:19:09AM +0100, Matthew Seaman wrote:
> Jeremy Chadwick wrote:
>> On Sun, Oct 05, 2008 at 12:53:03PM -0500, Scott Bennett wrote:
>>>      I'm getting a lot of messages like this:
>>>
>>> Oct  4 14:30:00 hellas kernel: Limiting closed port RST response from 250 to 200 packets/sec
>>>
>>> Is there some rule I can insert into /etc/pf.conf to reject these apparently
>>> invalid RST packets before they can bother TCP?  At the same time, I do not
>>> want to reject legitimate RST packets.
>>
>> They're outbound RST packets coming from your box as a result of
>> incoming packets someone is sending you (possibly an attack).
>>
>> Proper firewalling rules should help defeat this, but there is no "magic
>> rule" you can place into pf.conf that will stop this.
>>
>> If you want a "magic solution", see blackhole(4).
>>
>
> block drop all
>
> looks fairly magical to me.  Stick that at the top of your ruleset as
> your default policy, add more specific rules beneath it to allow
> the traffic you do want to pass, and Robert is your Mother's Brother.
> No more floods of RST packets.

This is incredibly draconian.  :-)  I was trying my best to remain
realistic.

> (Actually, I'd recommend always adding a 'log' clause to any rules that
> drop packets like so: 'block log drop all'.  Makes running 'tcpdump -i pflog0'
> an invaluable debugging aid.)

I cannot advocate use of "log" on such "vague" rules, and my attitude is
based on experience:

We had "log" set on some of our deny rules, specifically on an entry
which blocked any traffic to an IP to any ports other than 53 (DNS).
Someone initiated an attack against that IP, to a destination port of
something other than 53, which caused pflog to go crazy with logging.

What inadvertently resulted was a local system DoS -- the system began
sporting a load average between 40 and 50, and was sluggish.

The root cause?  /var/log/pflog was growing at such a tremendous rate
that newsyslog (trying to rotate and compress the logs) could not keep
up.  When I got to it, I found 8 or 9 gzip/newsyslog processes running
trying to deal with the chaos.

Bottom line: be very, very cautious what rules you use "log" on, and be
sure to remove it once the system is in production.

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