Date: Mon, 6 Oct 2008 00:26:11 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: Scott Bennett <bennett@cs.niu.edu>, freebsd-questions@freebsd.org Subject: Re: pf vs. RST attack question Message-ID: <20081006072611.GA13147@icarus.home.lan> In-Reply-To: <48E9BBED.7090607@infracaninophile.co.uk> References: <200810051753.m95Hr3N5014872@mp.cs.niu.edu> <20081006003601.GA5733@icarus.home.lan> <48E9BBED.7090607@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081006072611.GA13147>