Menu
▾
▴
sshguard-users
|
From: Henri S. <hen...@gm...> - 2016-04-17 20:24:35
|
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. |
|
From: Kevin Z. <kev...@gm...> - 2016-04-17 21:00:10
|
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 |
|
From: <li...@la...> - 2016-04-17 21:36:00
|
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 |
|
From: Kevin Z. <kev...@gm...> - 2016-04-17 22:32:47
|
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 |
|
From: <li...@la...> - 2016-04-17 23:00:49
|
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 |
|
From: Henri S. <hen...@gm...> - 2016-04-18 22:33:12
|
>> 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. |
|
From: Kevin Z. <kev...@gm...> - 2016-04-19 20:38:29
|
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 |
|
From: <li...@la...> - 2016-04-18 23:39:19
|
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 |
|
From: Kevin Z. <kev...@gm...> - 2016-04-19 20:39:34
|
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 |
|
From: Henri S. <hen...@gm...> - 2016-04-20 02:19:04
|
> 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 |
|
From: Kevin Z. <kev...@gm...> - 2016-04-20 03:36:50
|
On 04/19/2016 19:18, Henri Shustak wrote: >> What version of SSHGuard are you using? > > SSHGuard version : 1.6.1 : OK, not the latest but it is fairly recent > right? Oops, this is embarassing. This issue was fixed right after the 1.6.3 release. So it hasn't been released yet. > 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] The development version in Git recognizes this attack. Next release is planned for early May, but in the meantime I can provide a patch against 1.6.3. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Henri S. <hen...@gm...> - 2016-04-20 06:10:14
|
> This issue was fixed right after the 1.6.3 release. So it hasn't been released yet. I can check out from the git repository / wait until it is main stream. Just glad to know that the attack is detected as an attack in the current versions! I am glad I decided to contact the list rather than start editing the code manually trying to add this particular attack detection if the problem had already been resolved. I guessed it was an attack that should be detected. Thank you for all your help and in particular taking the time to look at the problem. No need to issue a patch just for me! Thanks again! -------------------------------------------------------------------- This email is protected by LBackup, an open source backup solution http://www.lbackup.org |
Thanks for helping keep SourceForge clean.
X