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

[Willem J. W. <wj...@di...>]

On 26-1-2016 04:49, Kevin Zheng wrote:
> 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.

I've had a previous discussion with Kevin before on semantics...
And the fact that sshguard calls them white/blacklist does not mean that
they are per default what they say they are....

The whitelist specifies the list of adresses that will not be entered
into the blocking strategy whatever they do. However that does not
warrant whitelisting in the classical sense. IF you want that, then you
actually have to implement a whitelist strategy in your firewall and add
whitelisted hosts there.
For example if you also run fail2ban, then fail2ban might detect a
violation and add the host. So now you have 2 places to keep whitelists
if used as such. Add some of the detecting tools from Wordpress and you
have one more list to maintain.
I would use the firewall(-config) for that.

The blacklist is a different baby here. It is the list with addresses
that have not yet expired they punishment term. And upon reloading
sshguard it reinstalls this list. I guess that you can abuse this and
manually add to this list as well.
But then again, that is actually to work that out with the firewall-config.

Sshguard is in essence an intrussion detection tool, and has been
elaborated with the possibility to interact with the firewall.
That does not forgo the fact that you will need a decent strategy in
your firewall on what to do with "the good, bad and the ugly"....

If you start mixing this, you could end up with a situation where you
are doing the right thing at the wrong place.

And IMHO you need to hardcode whitelisted hosts that need 100% always
access right in the first few lines of the firewall to prevent any
lockout. Now if those hosts have dynamic IPnrs, then you have to make
something to watch this and accordingly update the firewall rules.

FreeBSD has firewall tables, and I have reserved one of the tables to
contain host ipnrs that are host I personly administer, and thus trust a
little bit more than others. Thos I do not lookout in the firewall EVER.

--WjW