Re: [Sshguard-users] Dynamic hostnames in the whitelist

[Kevin Z. <kev...@gm...>]

On 01/25/2016 18:15, Don Coleman wrote:
> Hm... never thought I'd need to defend the basic feature I was trying to 
> improve -- I'd sort of figured that argument had already occurred and 
> thus was moot.

Yeah, sorry about that. It's important to reevaluate once in a while.

> I understand your perspective on self-lockout and maybe just waiting a 
> bit isn't such a bad solution -- though as I also use black listing, I'm 
> a bit paranoid of being on a bad keyboard or ham fingered or something 
> and getting black listed.   And my main server is in Berkeley and I'm in 
> Barcelona... a more flexible or adaptable implementation of blocking 
> could mitigate the need for black listing and the fear of lock-outs ... 
> but is that really going to happen?

Ideally, there would be a blocking strategy that would obsolete both
whitelisting and blacklisting. There shouldn't be literal blacklisting,
either, just blocks with very long timeouts (e.g. 24 hours).

Just curious, why did you decide on blacklisting?

> A for doing it in the firewall ... well, a firewall is dealing with all 
> sorts of traffic -- it needs a super fast response time and a very small 
> foot print, and they're just *not* ever going to be doing a DNS query, 
> so supporting directly dynamic ip addresses there is a non-starter.  
> Protecting a service is something very different -- they're already 
> heavy weight, and thus you can be relatively slow in responding.

Good point. DNS queries in a firewall is unthinkable.

> My plan would be to check/refresh the whitelist just before actually 
> blocking something.  In the typical expected case, a dynamic name would 
> always be expired and a static one wouldn't be -- the only reason really 
> to pay attention to the TTL at all (one could just do a gethostbyname() 
> every time), is to not increase measurably sshguard's load on a system 
> when under a denial of service attack.

This seems reasonable. If you're interested, and you can compile from
source, I can give you a patch to test.

> As for my particular usage, yes, I use both white and black listing.  I 
> personally am not really concerned with ssh probes actually logging into 
> my system (I have very good passwords)... I just want log files that are 
> clean and only show me actual problems I need to pay attention to.  I 
> already run sshd on a non-standard port.  My sshguard configuration is 
> both slower to block something, and has a longer memory to decide to 
> block (I find probers on non-standard ports are more sophisticated).

How often do these probes try to log in?

> My syslogd.conf conf pipe line is:
> 
> |/usr/bin/grep -Fv --line-buffered $'Connection closed by\n for don from 
> ' | /usr/local/sbin/sshguard -i /var/run/sshguard.pid -p 840 -s 3600 -w 
> /usr/local/etc/sshguard.whitelist -b 160:/var/db/sshguard/blacklist.db
> 
> The grep line keeps any aborted login attempts (no password ever 
> provided) and any login attempts by don (me) from counting.

Ahh, you want to ignore aborted login attempts. I block aborted login
attempts because my server only allows key logins, and so log noise for
me are those aborted login attempts.

> 1) allow blocking state to be reset to zero on a successful login from a 
> host.

I'll keep this in mind.

> 2) I've also thought about region based weighting of blocking -- probes 
> from strange countries could be treated harshly...

Perhaps, but to me this seems somewhat out of scope for SSHGuard.

> I've only been using sshguard for a week, so I'm still learning... 
> (though I've been using tcp/ip for decades ... and I'm still learning ;->).

Thanks for your comments and suggestions. They're definitely helpful.

Best,
Kevin

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090