Bug #8864
closed
SSH Guard Sensitivity/Whitelist on 2.4.4
100%
Description
I am running 2.4.4.a.20180831.0830 and noticed that my Icinga monitoring started to show issues with SSH. When I looked in the logs I saw the following:
Aug 31 17:04:09 sshguard 39986 Attack from "192.168.0.2" on service 100 with danger 10.
Is this a new feature and if so how do I tune it to allow my Icinga server to check SSH?
Updated by Zachary McGibbon over 5 years ago
Sorry I meant to put 2.4.4.a.20180831.0830 in the topic after 'SSH Guard on 2.4.4.a.20180831.0830'
Updated by Anonymous over 5 years ago
- Subject changed from SSH Guard on to SSH Guard on 2.4.4.a.20180831.0830
Updated by Nicki Messerschmidt over 5 years ago
I just want to chime in on this. I just updated my pfsense to 2.4.4 and very soon after I got notifications from my nagios system. Is there any way to whitelist IPs?
Updated by Jim Pingle over 5 years ago
- Subject changed from SSH Guard on 2.4.4.a.20180831.0830 to SSH Guard Sensitivity/Whitelist on 2.4.4
- Target version set to 2.4.4-GS
- Affected Architecture All added
- Affected Architecture deleted (
)
There isn't a way to set a whitelist currently. But if your monitoring system relies on a probe that is triggering an alert, that sounds more like a problem in the monitoring system.
I sent maybe 100 probes immediately to a 2.4.4 box with that only tested the TCP port and it never triggered sshguard. I then sent a handful that caused a login failure and it tripped after only three attempts.
If your ssh test is actually causing a login failure, try changing it to one that does a simple TCP handshake instead of checking the banner or whatever else it's doing.
Updated by Nicki Messerschmidt over 5 years ago
Well... I'm using the default check_ssh plugin of nagios. This plugin connects to the ssh server and checks before authentication if there really is a ssh server responding and what version number is reported. That in intself should not trigger an alarm. The corresponding logfile on the pfsense looks like this:
pfsense sshd[xxxxx]: Connection closed by xxx.xxx.xxx.xxx port 45345 [preauth]
According to the sshguard website whitelisting is possible using single IPs or using a whitelist file.
At least give the option of restarting/disabling sshguard via the interface. Right now it is a process that interferes with normal operations in a way pfsense did not before and there is no way to control this behaviour.
Updated by Alexander Müller over 5 years ago
I found following workaround:
- create whitelist file for sshguard following sshguards file format (https://www.sshguard.net/docs/whitelist/). put the file somewhere in the filesystem
- adjust /etc/inc/system.inc / line 1062:
auth.info;authpriv.info |exec /usr/local/sbin/sshguard -w $fullPathToYourWhitelist
- Navigate to Status > System Logs > Manage Logs and save without any changes
Would be really cool to have a proper configuration function in the webConfigurator. My monitoring systems (icinga2) gets blocked during ssh probes
Updated by Michael Reardon over 5 years ago
Alexander Müller wrote:
I found following workaround:
- create whitelist file for sshguard following sshguards file format (https://www.sshguard.net/docs/whitelist/). put the file somewhere in the filesystem
- adjust /etc/inc/system.inc / line 1062:
[...]- Navigate to Status > System Logs > Manage Logs and save without any changes
Would be really cool to have a proper configuration function in the webConfigurator. My monitoring systems (icinga2) gets blocked during ssh probes
Thanks! This seems to be working well enough for me for the time being.
Updated by dean hamstead over 5 years ago
Is it possible to simply disable sshguard?
Updated by Anonymous over 5 years ago
- Target version changed from 2.4.4-GS to 2.4.4-p1
Updated by Renato Botelho over 5 years ago
- Status changed from 13 to Feedback
- % Done changed from 0 to 100
Applied in changeset ef4a242c0df1b69b3348997165afc8555471202c.
Updated by Anonymous over 5 years ago
On 2.4.5.a.20181102.0213, works as expected. Address(es) added to the whitelist are not subject to SSH Guard detection.