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

[Don C. <do...@co...>]

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.

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?

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.

sshguard can be much more relaxed ...  that's why it can use the whole 
sshd/syslogd/sshguard path, and still be useful.

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.

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).


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.

Since you asked about general usage stuff -- Two other features I'd like 
are :

1) allow blocking state to be reset to zero on a successful login from a 
host.
2) I've also thought about region based weighting of blocking -- probes 
from strange countries could be treated harshly...

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 ;->).

Don



On 01/25/16 16:33, Kevin Zheng wrote:
> On 01/24/2016 09:40, Don Coleman wrote:
>> sshguard (as of 1.6.2) operates internally on ip addresses.   It maps
>> hostnames to ip addresses only at startup time, and this is
>> fundamentally flawed, as hostname to ip addresses mappings change over time.
> The whitelisting feature itself might be fundamentally flawed. I believe
> the original intent was to prevent self-lockouts. However, SSHGuard is
> designed to mitigate brute-force attacks, so if SSHGuard was designed
> perfectly (which it isn't) and you aren't brute-forcing yourself, then
> you shouldn't need whitelisting.
>
> If you want to prevent self-lockouts, the best thing to do is add a
> firewall rule that unconditionally allows your traffic. But if you can
> do that, why not deny all traffic except for your own?
>
> If you use blacklisting, whitelisting is potentially useful. Otherwise,
> SSHGuard will always unblock your address after a certain amount of
> time. It shouldn't be too long since you're not brute-forcing yourself.
>
> I'd like to hear more from people who use some combination of
> whitelisting and blacklisting: what do you use it for? I (personally)
> don't use either and find it difficult to justify a correct but somewhat
> complex feature as keeping hostnames updated.
>
> (I believe ntimed has a good solution for the "hostnames changing from
> underneath you" issue. It was designed for addresses that come and go,
> such as pool.ntp.org, but sounds like it could be used here.)
>
> Best,
> Kevin
>