sshguard-users

[Sshguard-users] Dynamic hostnames in the whitelist

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

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.

I'm currently working around this by restarting it once a day. This is 
effective, but kludgy..

I searched the archives for this list, and didn't see any mention of 
this issue, so I presume most people aren't concerned with white listing 
dynamic hostnames.

sshguard uses getaddrinfo() to map hostnames to ip addresses.  This is 
not the proper interface for long-running daemons to be using.

It probably should be using the res_* functions.   It should track the 
ttl of hostname mappings in it's whitelist, and re-map them once the ttl 
expires.  If the remap fails or takes too long, it should probably 
continue using the old value for a short additional time, say 5 to 10 
minutes, before trying again (as sshd is already mapping the name to IP 
address on each request, a valid mapping should already be in a nearby 
dns cache).

Any interest in this?

Thanks,
Don

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

[James H. <jam...@gm...>]

It sounds like an interesting patch. Going by the TTL is a good hint for
how long to track the resolution. I would also suggest parameters for
minimum and maximum TTLs to honor. I use a dynamic updated name hosted at
google domains. It uses a ridiculously short TTL. I could see others in a
similar situation wanting to reduce DNS calls or avoid annoying a provider.

On Sun, Jan 24, 2016 at 9:40 AM, Don Coleman <do...@co...> 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.
>
> I'm currently working around this by restarting it once a day. This is
> effective, but kludgy..
>
> I searched the archives for this list, and didn't see any mention of
> this issue, so I presume most people aren't concerned with white listing
> dynamic hostnames.
>
> sshguard uses getaddrinfo() to map hostnames to ip addresses.  This is
> not the proper interface for long-running daemons to be using.
>
> It probably should be using the res_* functions.   It should track the
> ttl of hostname mappings in it's whitelist, and re-map them once the ttl
> expires.  If the remap fails or takes too long, it should probably
> continue using the old value for a short additional time, say 5 to 10
> minutes, before trying again (as sshd is already mapping the name to IP
> address on each request, a valid mapping should already be in a nearby
> dns cache).
>
> Any interest in this?
>
> Thanks,
> Don
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>



-- 
James Harris
Software Engineer
jam...@gm...

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

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

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

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

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

[James H. <jam...@gm...>]

Personally I whitelist the rfc1918 address space mostly because I'm
paranoid and never want to be forced to find the monitor cable for my
machines in the closet. Further since I am paranoid I also setup high
priority firewall rules to always pass the rfc1918 addresses. When
connecting from outside my local network I can unpredictable addresses. So
white listing those isn't possible. While I could blacklist all of China,
Russia, and several other places that attacks seem to originate doing so
would be a bit of a work to find all those networks and could possibly grow
my firewall tables to an unmanageable size.  I use sshguard to react to
attacks in real time. Mostly I want to shut down all further access once I
start to see ssh brute forcing. My main concern is they move from ssh brute
forcing to some other protocol that isn't as well protected.  I also use
google authenticator (https://github.com/google/google-authenticator) to
apply two factor authentication to ssh logons when coming from an outside
network.

On Mon, Jan 25, 2016 at 4:33 PM, Kevin Zheng <kev...@gm...> 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
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>



-- 
James Harris
Software Engineer
jam...@gm...

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
>

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

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