On Tue, Oct 23, 2007 at 05:59:31PM -0700, Rob wrote: > On 10/23/07, david l goodrich <[EMAIL PROTECTED]> wrote: > > On Tue, Oct 23, 2007 at 02:55:41PM -0700, Rob wrote:
> > > Note that I wouldn't use a flush global directive for a rule like > > > this, because it can lead to a neat DoS where somebody can spoof one > > > of your own IP addresses and shut down any ssh sessions you have > > > active. > > > > > > Here's a working sample from my own currently active pf file: > > > > > > pass in on $ext proto tcp to <server6> port smtp keep state \ > > > (max-src-conn 15 max-src-conn-rate 10 / 45 overload <smtp-overload>) \ > > > queue 6smtp > > > > Mine's pretty similar, if a bit more verbose. And I don't use > > max-src-conn or queueing. > > Huh. > > What's your output from pfctl -s rules -v ? >From my original email... > > > > > # pfctl -sr | grep attack > > > > > block drop in log quick proto tcp from <sshd_attackers> to any > > > > > pass in log proto tcp from any to any port = ssh keep state > > > > > (source-track rule, max-src-conn-rate 3/30, overload > > > > > <sshd_attackers> flush global, src.track 30) > > > > > # > > Also, I should parrot some of the earlier conversations that have been > on this list on this subject (limiting attempts at ssh attacks). Doing > this with a max-src-conn-rate rule probably isn't what you really want > to do anyway; there are some good log file analyzers which would be > better suited to this (see http://www.ossec.net/, > http://www.ossec.net/en/attacking-loganalysis.html, and > http://marc.info/?l=openbsd-misc&m=118660109014882&w=2); strong ssh > passwords are the best defense against dictionary attacks; etc. At > best, all you're really doing is keeping your authlog a bit leaner, > and maybe compiling a list of evildoers. Understood that this is not going to be a be-all end-all from a security perspective, and that it isn't going to save me from being stupid and having weak passwords. It's still a useful mitigating control. That said, my original question wasn't about whether or not this is a good idea, it's about why what PF claims to do and what PF does seem to be different. --david
