Re: Re: Reality check: IPFW sees SSH traffic that sshd does not?

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 "freebsd-security-unsubscribe@freebsd.org"