pf vs. RST attack question

[Jeremy Chadwick]

On Mon, Oct 06, 2008 at 09:34:46AM +0100, Matthew Seaman wrote:
> Jeremy Chadwick wrote:
>> On Mon, Oct 06, 2008 at 08:19:09AM +0100, Matthew Seaman wrote:
>>> Jeremy Chadwick wrote:
>
>
>>>> 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.
>
> It's no such thing.  This is the recommended standard practice when designing
> firewalls: always start from the premise that all traffic will be dropped by
> default and add specific exceptions to allow the traffic you want.  Trying to
> work the other way round is a recipe for disaster: 'allow everything, but block
> what is then shown to be deleterious' means that you're always playing catch-up
> as changes on your servers expose new attack vectors and as attackers discover
> and try to exploit those holes.  Not recommended, unless you actually /like/
> being paged in the wee small hours.

What I mean by 'draconian': "block drop all" includes both incoming
*and* outgoing traffic.

I have absolutely no qualms with "block in all", but "block out all" is
too unrealistic, depending greatly on what the purpose of the machine
is.  Any outbound sockets are going to be allocated dynamically (e.g.
non-static port number), so there's no effective way to add pass rules
for outbound traffic.  Using uid/gid is not sufficient.

I often advocate using "block in all", "pass out all", and then adding
specific "pass" rules for incoming traffic (e.g. an Internet request
wishing to speak to BIND on port 53, Apache on 80/443, etc.).

Like I said: I'm being 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.
>
> You have a point here, I will certainly admit that.  In my experience, I've not
> yet run into that scenario.  I've tended to see systems more easily DoSed by
> running out of pf states due to excessive DoS traffic to allowed ports than to
> any extra load from pflogd and newsyslog from logging denied traffic.  The
> machines in question already log so much legitimate traffic from Squid and Apache
> that pflog is trivial by comparison.  Of course, now I've said 'it never happens'
> I'm expecting half our firewalls to explode any minute now...

:-)  I sure hope not!  The situation we experienced came as a great
surprise, and it wasn't something I even remotely considered when
setting up the rules in question.

Since then, "log" has been removed from all of our rules, but I keep
pflog running in the case that "something" starts happening and I need
to temporary add "log" to rules + /etc/rc.d/pf reload to see what's
going on.  Of course, tcpdump also works wonders here.

Good discussion!  (And I hope the OP is learning something :-) )

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