Date: Fri, 14 Jan 2005 00:40:00 +0100 From: Max Laier <max@love2party.net> To: freebsd-pf@freebsd.org Subject: Re: Two feature suggestions for pf.. Message-ID: <200501140040.10885.max@love2party.net> In-Reply-To: <53197.81.84.175.77.1105644490.squirrel@81.84.175.77> References: <53197.81.84.175.77.1105644490.squirrel@81.84.175.77>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart3296732.ilp3DIKOYj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 January 2005 20:28, security@revolutionsp.com wrote: > Hi, > > I hope this is the right place to discuss this.. I've had a couple of > features that I think would fit nicely in pf, but only now I'm sending > this email.. =46irst of all, thanks. Second of all, I'd like to repeat what I said some= time=20 or another: I see pf4FreeBSD as a port not as a fork, hence I encourage tha= t=20 you bring up suggestions for new features with the OpenBSD folks - unless=20 it's a FreeBSD specific - first. Once it makes it's way into a new OpenBSD= =20 release it will also make it's way into FreeBSD (sooner or later). > First of all, I believe pf is the best firewall around, I've been using it > since there was a port available to FreeBSD :-). Also, sorry if this was > previously discussed as I did not check the archives. > > Here are my two proposed features for pf: > > 1) Add the username of the blocked packet to the pf log. Currently, it's > hard to trace an outgoing blocked packet to a username unless you're > watching real-time. For example: > > 2005-01-11 03:03:40.777286 rule 92/0(match): block out on em0: IP > xxx.xxx.xxx.xxx.59167 > zzz.zzz.zzz.zzz.6667: FP 0:24(24) ack 1 win 32832 > <nop,nop,timestamp 21705093 1375749783> > > I think the username that triggered the rule would fit really nicely and > would be really handy.. like this: > > 2005-01-11 03:03:40.777286 rule 92/0(match): block out on em0: IP > xxx.xxx.xxx.xxx.59167 > zzz.zzz.zzz.zzz.6667: FP 0:24(24) ack 1 win 32832 > <nop,nop,timestamp 21705093 1375749783> user UserName > > This would greatly reduce the time needed to find someone abusing the > firewall from inside the system, for example trying to portscan someone > and most of the packets hitting the firewall.. This shouldn't be too hard > to implement. Though I agree that this might be helpful on busy, multiuser shell servers,= I=20 don't think it will happen. For one, it's overly expensive to look up the= =20 user to a socket. Moreover, it's not the job of the firewall to enforce=20 local restrictions (or to log local events). If you want sophisticated=20 control (and logging) of the activity of your local user you can either use= =20 the MAC framework or restrict possible evildoers into jails. Hacking it in= to=20 pf is not a good idea - IMO. > 2) Different blocked traffic goes to different logfiles > > My other idea is based on the following concept.. Normally your server > sits there, serving requests etc, blocks some scans on the firewall, > random bruteforce attacks, and so on. But, if unfornately your server is a > target of a DDoS attack, then all the attack log will be with the rest of > the junk your server receives. Altough not impossible, filtering the log > to obtain only the DDoS attack log for analysis still takes it's time. My > suggestion is: Why not allow a directive on pf.conf that let's you specify > to which logfile that rule should be logged to ? Using this model, you > could set up some rules aimed at blocking traffic, but then the logging > will be on it's own, private, separate file. You could set up several > rules you know will never be matched unless there is an attempt to attack > the server (etc), and, when matched, they'll be easily available on a > (possibly) small logfile, instead of the geral, big big log. > This also helps a lot tracking failed attack attempts, each on it's own > log.. thus cutting down the time one needs to find any blocked packets in > the logs: You always know it will be in file A,B,C.. You can do that. Tcpdump/libpcap offer means to filter on a certain rule=20 number etc. You can either have pflogd logging all into one (big) logfile= =20 and split it afterwards with tcpdump -r or you can write a modified pflogd= =20 that would do the splitting online. > Again, if these have already been discussed in the past, I'm sorry. If > not, please give some feedback. Not really discussed before (if my memory servers me right), but don't worr= y=20 about such things too much. Feedback and suggestions greatly appreciated. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3296732.ilp3DIKOYj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5wbaXyyEoT62BG0RArF3AJ9KKamzG8fRroDYwJKEmCF8vCr6XQCaA6Fw VV5nEhqIyw4kz1XK72Q+Ifo= =Iojk -----END PGP SIGNATURE----- --nextPart3296732.ilp3DIKOYj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501140040.10885.max>