Good day! Thu, Mar 22, 2007 at 02:04:46PM +0100, Volker wrote: > > You can use the following rule that will put very fast SSH connectors > > to the pf table ssh_scans: > > ----- > > pass in quick on $iface proto tcp from any to $ip port 22 flags S/AUSPF \ > > keep state (max-src-conn 4, max-src-conn-rate 6/1, overload <ssh_scans> > > flush) > > ----- > > If you replace the "flush" keyword by "flush global" would give > better results as it immediately will kill all additional > connections with that host (IP address). Without the "global" > keyword just the ssh connection causing the rule overload is being > killed. > > Also a max-src-conn-rate of 6/1 (6 connections in 1 second) is IMO a > bit too friendly to those brute force script kiddies but YMMV.
I happen to make some rapid scp's that are doing about 5 or 6 connections in a minute from the ligitimate hosts, so sometimes even the ligitimate hosts are getting blocked. And if that host has another session to the server I do not like it to be dropped, since then the session will be lost and I will not be able to drop the ligitimate host from the ssh_scans manually. Whitelisting will help, but I have no persistent list of the machines I can come from. But your mileage may vary. By the way, the 6/1 rule is very good when you're firewalling the large number of clients: massive SSH scans are often hitting the full netblock, so changing the '$ip' to '<clients_table>' above you will get very good throttling for the entire network you're protecting. > While doing nearly the same as you did in your pf rules, I also let > a cron job run every 10 minutes and scan the auth log for login > errors. If a threshold value is being reached, the IP address gets > inserted into a pf table and gets blocked (forever). This is just a > second line of defense. Yeah, this is also helpful. But my setup currently gives me about 4 probes from the SSH scanners and then that host gets blocked. And the blocking for a long time (ot forever) can be not so good on the busy public login servers -- machine can just be hacked, but rapidly reinstalled and patched. Again, your mileage may vary. -- Eygene _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"