sshguard-users — User questions and answers, bugs, and general support

Re: [Sshguard-users] protecting a server with password authentication disabled

[Henri S. <hen...@gm...>]

> What version of SSHGuard are you using? 

SSHGuard version : 1.6.1 : OK, not the latest but it is fairly recent right? 

Note : This is SSHGuard was installed via brew on a Mac OS X system. I have confirmed that if password authentication enabled and you do not connect with a key and instead try to use a password, then it SSHGuard works great!

> What pre-auth disconnect message showed up in the logs?

Connection closed by 123.255.41.127 [preauth]

If password authentication via PAM is enabled, then using the key to connect with say an incorrect user and attempting to use the key will cause SSHGuard to detect this. 

I suspect what causes the detection to work is the following line within the logs : 
input_userauth_request: invalid user test

But the above line will not show up if PAM is disabled. If I have misunderstood, then please let me know. Hopefully it is something simple which will resolve this and allow SSHGuard to block the inbound connections when password authentication and PAM is disabled.

Any ideas, happy to give them a try!

--------------------------------------------------------------------
InstallPKG, an open source installation system. Install multiple apple .pkg and .mpkg files via the command line : http://www.lucid.technology/tools/installpkg

Re: [Sshguard-users] protecting a server with password authentication disabled

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

On 04/18/2016 16:39, li...@la... wrote:
> I did find some instructions (in previous message). However, I was
> wondering why this was not part of the standard configuration or if
> there was a simple flag which needed to be set to enable blocking of
> these pre-auth attacks?

You should not need to do anything special to block pre-auth failures on
a recent SSHGuard.

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

Re: [Sshguard-users] protecting a server with password authentication disabled

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

On 04/18/2016 15:33, Henri Shustak wrote:
> This was not the case at least when I attempted to repeatedly connect
> with incorrect keys over 15 times, the connection was still open.
> This is why I sent the initial message. It seems like it would be a
> good idea to block this kind of pre-auth disconnect.
> 
> I did find some instructions (in previous message). However, I was
> wondering why this was not part of the standard configuration or if
> there was a simple flag which needed to be set to enable blocking of
> these pre-auth attacks?

What version of SSHGuard are you using? What pre-auth disconnect message
showed up in the logs?

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

Re: [Sshguard-users] protecting a server with password authentication disabled

[<li...@la...>]

While sshguard is in the state of permanent blocking, I'd be hesitant to block guesses at keys since they are a low probably‎ of succeeding. However sshguard should be blocking these attempts. 



  Original Message  
From: Henri Shustak
Sent: Monday, April 18, 2016 3:33 PM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] protecting a server with password	authentication disabled


>> If you use a key, is there any advantage to blocking the port 22
>> password guessers? That is, sshguard does protect other services. I'm
>> thinking an IP that attacks ssh is likely to attack other services.
>> The hacker/bot doesn't know passwords are not used for ssh.
> 
> If your sshd is configured to allow only key logins, password guessing
> attempts will show up as "preauth" disconnects. SSHGuard treats these
> messages like any other attack and blocks accordingly.

This was not the case at least when I attempted to repeatedly connect with incorrect keys over 15 times, the connection was still open. This is why I sent the initial message. It seems like it would be a good idea to block this kind of pre-auth disconnect.

I did find some instructions (in previous message). However, I was wondering why this was not part of the standard configuration or if there was a simple flag which needed to be set to enable blocking of these pre-auth attacks?

Thanks.



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] protecting a server with password authentication disabled

[Henri S. <hen...@gm...>]

>> If you use a key, is there any advantage to blocking the port 22
>> password guessers? That is, sshguard does protect other services. I'm
>> thinking an IP that attacks ssh is likely to attack other services.
>> The hacker/bot doesn't know passwords are not used for ssh.
> 
> If your sshd is configured to allow only key logins, password guessing
> attempts will show up as "preauth" disconnects. SSHGuard treats these
> messages like any other attack and blocks accordingly.

This was not the case at least when I attempted to repeatedly connect with incorrect keys over 15 times, the connection was still open. This is why I sent the initial message. It seems like it would be a good idea to block this kind of pre-auth disconnect.

I did find some instructions (in previous message). However, I was wondering why this was not part of the standard configuration or if there was a simple flag which needed to be set to enable blocking of these pre-auth attacks?

Thanks.

Re: [Sshguard-users] protecting a server with password authentication disabled

[<li...@la...>]

‎I was thinking once only ssh accepted keys, then ssh guard would have nothing to "see". If sshguard in going to block ssh password attempts even if you set up your system to only accept keys, then the end result is the same. 

Come to think of it, my VPS only allows keys for ssh, so I've been running with passwords blocked all along. 

Regarding the other services, my though was any IP that was hacking ssh is likely to hack say Dovecot, so might as well block the ssh attempt even if the system doesn't accept passwords.

Which brings me to the question, how do I verify Dovecot failures have been blocked? And if the answer is to attempt some incorrect login to Dovecot, hopefully my IP won't be blocked forever, which I believe is the current state of sshguard. 


  Original Message  
From: Kevin Zheng
Sent: Sunday, April 17, 2016 3:33 PM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] protecting a server with password authentication disabled

On 04/17/2016 14:18, li...@la... wrote:
> If you use a key, is there any advantage to blocking the port 22
> password guessers? That is, sshguard does protect other services. I'm
> thinking an IP that attacks ssh is likely to attack other services.
> The hacker/bot doesn't know passwords are not used for ssh.

If your sshd is configured to allow only key logins, password guessing
attempts will show up as "preauth" disconnects. SSHGuard treats these
messages like any other attack and blocks accordingly.

Whether other services are protected or not depends on how your firewall
rules are set up.

> Then if the answer is no, once password logins are not allowed on
> ssh, should the blocking list be wiped?

Not sure what this question is asking.

Best,
Kevin

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

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] protecting a server with password authentication disabled

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

On 04/17/2016 14:18, li...@la... wrote:
> If you use a key, is there any advantage to blocking the port 22
> password guessers? That is, sshguard does protect other services. I'm
> thinking an IP that attacks ssh is likely to attack other services.
> The hacker/bot doesn't know passwords are not used for ssh.

If your sshd is configured to allow only key logins, password guessing
attempts will show up as "preauth" disconnects. SSHGuard treats these
messages like any other attack and blocks accordingly.

Whether other services are protected or not depends on how your firewall
rules are set up.

> Then if the answer is no, once password logins are not allowed on
> ssh, should the blocking list be wiped?

Not sure what this question is asking.

Best,
Kevin

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

Re: [Sshguard-users] protecting a server with password authentication disabled

[<li...@la...>]

If you use a key, is there any advantage to blocking the port 22 password guessers? That is, sshguard does protect other services. I'm thinking an IP that attacks ssh is likely to attack other services. The hacker/bot doesn't know passwords are not used for ssh.

Then if the answer is no, once password logins are not allowed on ssh, should the blocking list be wiped?



  Original Message  
From: Kevin Zheng
Sent: Sunday, April 17, 2016 2:00 PM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] protecting a server with password authentication disabled

On 04/17/2016 13:24, Henri Shustak wrote:
> I have been looking at ways to use SSH Guard to protect a server
> which only accepts key based authentication. I did find a discussion
> about enabling protection for pre-auth :
> 
> https://sourceforge.net/p/sshguard/mailman/message/32351603/
SSHGuard recognizes attempts to log into a server that is configured to
disallow all but key logins (preauth failures) as attacks.

> Basically, I am curious to know if there is a simple option to enable
> protection for SSHD which only accept key-based authentication or if
> the recommended approach is to dive in and start modifying various
> files.

You need to modify sshd_config to disallow password logins. Check your
operating system vendor's documentation for how to do so. It varies
between operating systems, but it generally is either
"ChallengeResponseAuthentication No" or "PasswordAuthentication no".

Best,
Kevin

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

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] protecting a server with password authentication disabled

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

On 04/17/2016 13:24, Henri Shustak wrote:
> I have been looking at ways to use SSH Guard to protect a server
> which only accepts key based authentication. I did find a discussion
> about enabling protection for pre-auth :
> 
> https://sourceforge.net/p/sshguard/mailman/message/32351603/
SSHGuard recognizes attempts to log into a server that is configured to
disallow all but key logins (preauth failures) as attacks.

> Basically, I am curious to know if there is a simple option to enable
> protection for SSHD which only accept key-based authentication or if
> the recommended approach is to dive in and start modifying various
> files.

You need to modify sshd_config to disallow password logins. Check your
operating system vendor's documentation for how to do so. It varies
between operating systems, but it generally is either
"ChallengeResponseAuthentication No" or "PasswordAuthentication no".

Best,
Kevin

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

[Sshguard-users] protecting a server with password authentication disabled

[Henri S. <hen...@gm...>]

I have been looking at ways to use SSH Guard to protect a server which only accepts key based authentication. I did find a discussion about enabling protection for pre-auth : 

https://sourceforge.net/p/sshguard/mailman/message/32351603/

Basically, I am curious to know if there is a simple option to enable protection for SSHD which only accept key-based authentication or if the recommended approach is to dive in and start modifying various files.

Any feed back on this would be great. I understand that attacks against a good key should not be an issue. But is seems like stopping anything from trying to connect the the server with some sort of malicious intent over and over again is a good idea.

Re: [Sshguard-users] Skip blocking, ban directly

[Benno Z. <bz...@li...>]

Thanks! Consider this solved.

> To: ssh...@li...
> From: kev...@gm...
> Date: Tue, 12 Apr 2016 08:17:44 -0700
> Subject: Re: [Sshguard-users] Skip blocking, ban directly
> 
> On 04/12/2016 08:10, Benno Zeeman wrote:
> > I understand the score value. If it is set to 10, it will block a user.
> > I don't want anything temporarily; I don't want it to block, I want it
> > to ban at a score of 30 (3 attacks).
> 
> In that case set the threshold to 30 (same as the blacklist score).
> 
> -- 
> Kevin Zheng
> kev...@gm... | ke...@be... | PGP: 0xC22E1090
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
 		 	   		  

Re: [Sshguard-users] Skip blocking, ban directly

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

On 04/12/2016 08:10, Benno Zeeman wrote:
> I understand the score value. If it is set to 10, it will block a user.
> I don't want anything temporarily; I don't want it to block, I want it
> to ban at a score of 30 (3 attacks).

In that case set the threshold to 30 (same as the blacklist score).

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

Re: [Sshguard-users] Skip blocking, ban directly

[Benno Z. <bz...@li...>]

I understand the score value. If it is set to 10, it will block a user. I don't want anything temporarily; I don't want it to block, I want it to ban at a score of 30 (3 attacks).
Thanks for responding,bzeeman

> To: ssh...@li...
> From: kev...@gm...
> Date: Tue, 12 Apr 2016 07:50:46 -0700
> Subject: Re: [Sshguard-users] Skip blocking, ban directly
> 
> On 04/12/2016 00:42, Benno Zeeman wrote:
> > I'm running sshguard on a simple up-to-date Arch Linux server. According
> > to the Arch wiki you can ban users after a single failed login. I'd like
> > to do something similar, but with three failed login attempts.
> > 
> > Problem is that "-a 1 -b 30:/var/db/sshguard/blacklist.db" doesn't work,
> > as sshguard doesn't accept an abuse threshold below 10. So, how to
> > disable the abuse threshold, and skip the blocking.
> 
> You should set -a to 10 (the default score for each attack). The -a
> argument is given a score, not the number of attacks.
> 
> Best,
> Kevin
> 
> -- 
> Kevin Zheng
> kev...@gm... | ke...@be... | PGP: 0xC22E1090
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
 		 	   		  

Re: [Sshguard-users] Skip blocking, ban directly

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

On 04/12/2016 00:42, Benno Zeeman wrote:
> I'm running sshguard on a simple up-to-date Arch Linux server. According
> to the Arch wiki you can ban users after a single failed login. I'd like
> to do something similar, but with three failed login attempts.
> 
> Problem is that "-a 1 -b 30:/var/db/sshguard/blacklist.db" doesn't work,
> as sshguard doesn't accept an abuse threshold below 10. So, how to
> disable the abuse threshold, and skip the blocking.

You should set -a to 10 (the default score for each attack). The -a
argument is given a score, not the number of attacks.

Best,
Kevin

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

[Sshguard-users] Skip blocking, ban directly

[Benno Z. <bz...@li...>]

I'm running sshguard on a simple up-to-date Arch Linux server. According to the Arch wiki you can ban users after a single failed login. I'd like to do something similar, but with three failed login attempts.
Problem is that "-a 1 -b 30:/var/db/sshguard/blacklist.db" doesn't work, as sshguard doesn't accept an abuse threshold below 10. So, how to disable the abuse threshold, and skip the blocking.
Thanks,bzeeman 		 	   		  

Re: [Sshguard-users] SSHGuard blocking my home DSL IP

[Robin S. <ras...@gm...>]

On Fri, Mar 18, 2016 at 11:30 PM, Kevin Zheng <kev...@gm...> wrote:

[snip]


> > That passage implies that there is a way to "clean out stale entries"
> > from the blacklist database other than simply deleting the whole thing.
> > I seem to have missed what that is.  Do you know?
>
> Yep, it's plain text now! In the next major release I hope to
> automatically prune the blacklist.
>
>
And now that I actually look, I see that /var/db/sshguard/blacklist.db is
indeed plain text.  I had looked not very long ago and I'm certain it was
binary.  Again, my apologies for not looking.

Thanks,

Robin Smith

Re: [Sshguard-users] SSHGuard blocking my home DSL IP

[<li...@la...>]

With the blacklist in plain text now, I have a suggestion. If ultimately the blacklist is going to get an automatic  prune mode, i.e. it becomes dynamic, would it be possible to have a second blacklist used by sshguard but not created by sshguard. For instance, you have a list of known bad actors that you don't even want to give the chance to be blocked. Or in the case of Tor, you have a list created by "other means" that contains the current Tor exit nodes.  

"Other means" is the problem of the sys admin. Just specify the format. But since the second blacklist file could be dynamic, it would need to be read periodically by sshguard.

  Original Message  
From: Kevin Zheng
Sent: Friday, March 18, 2016 9:31 PM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] SSHGuard blocking my home DSL IP

On 03/18/2016 18:50, Robin Smith wrote:
> But I found the problem, and I should have seen this earlier: my home IP
> was blacklisted because of a few fatfingered attempts at logging in
> witth password authentication from my phone.. I could clear the IP out
> of table 22 by using the VNC connection to my VM, and then things were
> fine until I needed to do a reboot (there were a couple of security
> updates in 10.2 requiring a new kernel). I had already whitelisted my
> DSL modem's current IP (which usually is stable unless there's a power
> outage), but what I failed to realize is that the blacklist database is
> loaded at startup *before* the whitelist file and, in addition,
> whitelisting doesn't override the blacklist. There's a bit of code on
> the web for editing /var/db/sshguard/blacklist/.db, but I used the
> cruder method of deleting the blacklist database and restarting. This
> does make me wonder: what exactly is the whilelisting file for, if its
> entires are not overridden by whitelisting? 

Right. By default, the FreeBSD rc.d script enables blacklisting. The
stuff you found on the web applies to earlier versions of SSHGuard,
where the blacklist file is an opaque binary. Now it's plain text; open
it up using a text editor and delete the lines you don't want. Remember
that you'll need to restart SSHGuard for it to load the new blacklist.

Currently, the blacklist is loaded before the whitelist is. If an
address appears in the whitelist, it will not be blocked or blacklisted,
but if it's already in the blacklist the whitelist won't unblock it. So
you'll have to delete yourself from the blacklist. I consider this
behavior buggy but haven't gotten around to fixing it.

> Thanks very much for your reply. In this case, I just didn't take a
> close enough look at what was going on,so I feel like an idiot. However,
> this passage from the man page for sshguard is a little pussling (under
> the '-b thresh:file' option):st
> 
> "Blacklisted addresses are added to file so they can be read at
> the next startup. Blacklisted addresses are never automatically
> unblocked, but it is good practice to periodically clean out
> stale blacklist entries."
> 
> That passage implies that there is a way to "clean out stale entries"
> from the blacklist database other than simply deleting the whole thing. 
> I seem to have missed what that is. Do you know?

Yep, it's plain text now! In the next major release I hope to
automatically prune the blacklist.

Best,
Kevin

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

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] SSHGuard blocking my home DSL IP

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

On 03/18/2016 18:50, Robin Smith wrote:
> But I found the problem, and I should have seen this earlier: my home IP
> was blacklisted because of a few fatfingered attempts at logging in
> witth password authentication from my phone..  I could clear the IP out
> of table 22 by using the VNC connection to my VM, and then things were
> fine until I needed to do a reboot (there were a couple of security
> updates in 10.2 requiring a new kernel).  I had already whitelisted my
> DSL modem's current IP (which usually is stable unless there's a power
> outage), but what I failed to realize is that the blacklist database is
> loaded at startup *before* the whitelist file and, in addition,
> whitelisting doesn't override the blacklist.  There's a bit of code on
> the web for editing /var/db/sshguard/blacklist/.db, but I used the
> cruder method of deleting the blacklist database and restarting. This
> does make me wonder: what exactly is the whilelisting file for, if its
> entires are not overridden by whitelisting? 

Right. By default, the FreeBSD rc.d script enables blacklisting. The
stuff you found on the web applies to earlier versions of SSHGuard,
where the blacklist file is an opaque binary. Now it's plain text; open
it up using a text editor and delete the lines you don't want. Remember
that you'll need to restart SSHGuard for it to load the new blacklist.

Currently, the blacklist is loaded before the whitelist is. If an
address appears in the whitelist, it will not be blocked or blacklisted,
but if it's already in the blacklist the whitelist won't unblock it. So
you'll have to delete yourself from the blacklist. I consider this
behavior buggy but haven't gotten around to fixing it.

> Thanks very much for your reply.  In this case, I just didn't take a
> close enough look at what was going on,so I feel like an idiot. However,
> this passage from the man page for sshguard is a little pussling (under
> the '-b thresh:file' option):st
>  
>   "Blacklisted  addresses  are added to file so they can be read at
>     the next startup. Blacklisted addresses are never  automatically
>     unblocked,  but  it  is  good practice to periodically clean out
>     stale blacklist entries."
> 
> That passage implies that there is a way to "clean out stale entries"
> from the blacklist database other than simply deleting the whole thing. 
> I seem to have missed what that is.  Do you know?

Yep, it's plain text now! In the next major release I hope to
automatically prune the blacklist.

Best,
Kevin

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

Re: [Sshguard-users] SSHGuard blocking my home DSL IP

[Robin S. <ras...@gm...>]

On Fri, Mar 18, 2016 at 7:57 PM, Kevin Zheng <kev...@gm...> wrote:

> Hi Robin,
>
> [snip]

>
> What version of SSHGuard are you running? I'm assuming that turning off
> SSHGuard makes this problem go away?
>
>
1.6.3  (the current version in the FreeBSD ports tree).


> A temporary workaround could be to use whitelisting. But that's not
> super helpful if your IP address at home changes.
>
>
But I found the problem, and I should have seen this earlier: my home IP
was blacklisted because of a few fatfingered attempts at logging in witth
password authentication from my phone..  I could clear the IP out of table
22 by using the VNC connection to my VM, and then things were fine until I
needed to do a reboot (there were a couple of security updates in 10.2
requiring a new kernel).  I had already whitelisted my DSL modem's current
IP (which usually is stable unless there's a power outage), but what I
failed to realize is that the blacklist database is loaded at startup
*before* the whitelist file and, in addition, whitelisting doesn't override
the blacklist.  There's a bit of code on the web for editing
/var/db/sshguard/blacklist/.db, but I used the cruder method of deleting
the blacklist database and restarting. This does make me wonder: what
exactly is the whilelisting file for, if its entires are not overridden by
whitelisting?


> Have you taken a look at /var/log/auth.log, grepping for your home IP,
> and seeing if any interesting entries turn up?
>

Yes, that's where I found when and why my IP got into the blacklist.


> Older versions of
> SSHGuard treated "reverse getaddrinfo" mismatches as an attack.
>
>
I did think about that, but iit wasn't the problem in my case.

Thanks very much for your reply.  In this case, I just didn't take a close
enough look at what was going on,so I feel like an idiot. However, this
passage from the man page for sshguard is a little pussling (under the '-b
thresh:file' option):st

  "Blacklisted  addresses  are added to file so they can be read at
    the next startup. Blacklisted addresses are never  automatically
    unblocked,  but  it  is  good practice to periodically clean out
    stale blacklist entries."

That passage implies that there is a way to "clean out stale entries" from
the blacklist database other than simply deleting the whole thing.  I seem
to have missed what that is.  Do you know?

Best,

Robin Smith

Re: [Sshguard-users] SSHGuard blocking my home DSL IP

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

Hi Robin,

On 03/18/2016 09:28, Robin Smith wrote:
> I run sshguard with ipfw on a FreeBSD 10.2 virtual box hosted by
> RootBSD.  The relevant firewall entry is:
> 
> 50000 deny ip from table(22) to me
> 
> I usually access the server from my home location through a DSL line
> with AT&T.  If I put this rule in the firewall script, then rebooting or
> running the script locks me out because sshguard adds my home IP to
> table 22.  The workaround has been to remove the rule above from
> /etc/firewall-rules (the firewall script), make an ssh connection, add
> the rule:
>    ipfw add 50000 deny ip from table\(22\) to me
> Then, I look for my home IP in table 22, and upon finding it, I delete
> it from the table. (Otherwise, any further ssh connections from my home
> location get blocked). 
> 
> But why is this happening in the first place?

What version of SSHGuard are you running? I'm assuming that turning off
SSHGuard makes this problem go away?

A temporary workaround could be to use whitelisting. But that's not
super helpful if your IP address at home changes.

Have you taken a look at /var/log/auth.log, grepping for your home IP,
and seeing if any interesting entries turn up? Older versions of
SSHGuard treated "reverse getaddrinfo" mismatches as an attack.

Best,
Kevin

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

[Sshguard-users] SSHGuard blocking my home DSL IP

[Robin S. <ras...@gm...>]

I run sshguard with ipfw on a FreeBSD 10.2 virtual box hosted by RootBSD.
The relevant firewall entry is:

50000 deny ip from table(22) to me

I usually access the server from my home location through a DSL line with
AT&T.  If I put this rule in the firewall script, then rebooting or running
the script locks me out because sshguard adds my home IP to table 22.  The
workaround has been to remove the rule above from /etc/firewall-rules (the
firewall script), make an ssh connection, add the rule:
   ipfw add 50000 deny ip from table\(22\) to me
Then, I look for my home IP in table 22, and upon finding it, I delete it
from the table. (Otherwise, any further ssh connections from my home
location get blocked).

But why is this happening in the first place?

Robin Smith

Re: [Sshguard-users] configuration options

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

On 02/16/2016 00:57, li...@la... wrote:
> If you add a regex scheme, I'd like to see a test mode flag for each
> regex. That is, see what is would like to block before actually
> enabling the blocking. I rarely get anything but the simplest regex
> correct on the first try.

Could you elaborate more about what you mean with this? Something like
'sshg-parser', which is currently built but installed, that only parses
and classifies attacks from standard input without blocking?

Thanks,
Kevin

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

Re: [Sshguard-users] configuration options

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

On 02/16/2016 00:53, Christophe Meessen wrote:
> I'm confronted to such use case. An attacker has a script that tries to 
> authenticate on my port 25 (Postfix) with a few minutes interval between 
> each attempts. Although authentication on port 25 is not allowed he 
> keeps hitting his head on the door. I wish it was possible to ban these 
> attempts with a lower threshold and much longer period than the default. 
> Fail2ban doesn't allow that.

The strategy I'm thinking about is to keep timestamps of the last few,
say, 6 failed attempts from each address. Those with highly regular
intervals between attacks would be considered attackers, as should those
with very little delay between attempts.

I would have to collect some data and see if this is viable, though.

> But this is not as bad as the one trying many hundreds of time per 
> minutes. Fail2ban handles these well.
> I must admit I'm currently using fail2ban, but I keep an eye on sshguard.

Thanks for your suggestions!

Best,
Kevin

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

Re: [Sshguard-users] configuration options

[<li...@la...>]

If you look at the table 22 block list, you can spot IP addresses that are from the same organization. That is the IP addresses are close. You can prove the relation using www.ip2location.com or similar service. My point here being they could be used as a botnet to slow down the login attempts from any one IP address in the group, but the group all together can be sending login attempts at a high rate. (Basically there could be a distributed attack where each IP doesn't trigger sshguard.)

I'm not really sure how you would alter sshguard to catch botnets since there is no requirement for every IP address an organization possesses to be clustered. For the services that sshguard protects, they don't have a particularly large attack surface as compared to say a Web server. (Obviously nothing is more critical than ssh, but there are only so many ways to knock on the door.) I'm just pointing this out as food for thought since there may be some nuance to networking to see these related attackers. 

I'd like to see sshguard protect all the common network services except for the web. 

As an aside, I saved one table 22 from sshguard as a snapshot to examine. Mostly for curiosity sake, but I have been adding all the VPS, colos, hosting companies, etc. caught by sshguard to my blocking list for nginx. I don't block ISPs and universities. The majority of the attempts are not from ISPs. 

If you add a regex scheme, I'd like to see a test mode flag for each regex. That is, see what is would like to block before actually enabling the blocking. I rarely get anything but the simplest regex correct on the first try.  

  Original Message  
From: Kevin Zheng
Sent: Monday, February 15, 2016 6:15 PM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] configuration options

On 02/14/2016 10:14, dt...@gm... wrote:
> (1) config file used to input/add to/change the regular expressions used to
> trigger blocks

This would be a pretty significant change since most of SSHGuard's
functionality is compiled into the binary. I'll keep this in mind,
though; it needs to be a lot easier to add more attack signatures.

If this is something people are interested in, please comment!

> (2) A good number of attackers figure out the blocking parameters and then
> make a large number of requests at a rate that does not trigger
> blocking. I use sshguard on closed systems (no external users) and open
> systems, so my setting are very different as must (of my) users do not
> use keys and mistype their passwords.

Yes, there needs to be a better way to classify attackers.

> A nice addition would be a trigger that more than <n> failures per day
> would trigger a block. The duration should also be optional but at
> least a day. It could be <n> attempts on more than <m> users.
> 
> And on a much lower priority: a utility to prune the black list. Now I use the 
> blacklist only on closed systems.

My thinking right now is to remove "blacklisting" as a special case and
simply treating them as a really like (say, 24 hour block). The
blacklist file could be replaced with a "SSHGuard state" file that saves
all current blocks so they can be reloaded if SSHGuard restarts.

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=272487151&iu=/4140
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] configuration options

[Christophe M. <chr...@me...>]

Le 16/02/2016 03:15, Kevin Zheng a écrit :
> On 02/14/2016 10:14, dt...@gm... wrote:
>>     (1) config file used to input/add to/change the regular expressions used to
>>         trigger blocks
> This would be a pretty significant change since most of SSHGuard's
> functionality is compiled into the binary. I'll keep this in mind,
> though; it needs to be a lot easier to add more attack signatures.
>
> If this is something people are interested in, please comment!
I would vote for this because it would significantly extend the 
application domain of sshguard.
I would also suggest to change the application name because at first I 
thought sshguard was only for ssh.
>>     (2) A good number of attackers figure out the blocking parameters and then
>>         make a large number of requests at a rate that does not trigger
>>         blocking. I use sshguard on closed systems (no external users) and open
>>         systems, so my setting are very different as must (of my) users do not
>>         use keys and mistype their passwords.
> Yes, there needs to be a better way to classify attackers.
I'm confronted to such use case. An attacker has a script that tries to 
authenticate on my port 25 (Postfix) with a few minutes interval between 
each attempts. Although authentication on port 25 is not allowed he 
keeps hitting his head on the door. I wish it was possible to ban these 
attempts with a lower threshold and much longer period than the default. 
Fail2ban doesn't allow that.

But this is not as bad as the one trying many hundreds of time per 
minutes. Fail2ban handles these well.
I must admit I'm currently using fail2ban, but I keep an eye on sshguard.

>
>>         A nice addition would be a trigger that more than <n> failures per day
>>         would trigger a block. The duration should also be optional but at
>>         least a day. It could be <n> attempts on more than <m> users.
>>
>> And on a much lower priority: a utility to prune the black list. Now I use the
>> blacklist only on closed systems.
> My thinking right now is to remove "blacklisting" as a special case and
> simply treating them as a really like (say, 24 hour block). The
> blacklist file could be replaced with a "SSHGuard state" file that saves
> all current blocks so they can be reloaded if SSHGuard restarts.
>
> Best,
> Kevin
>

-- 
Bien cordialement,

Ch.Meessen