Project

General

Profile

Bug #8864

SSH Guard Sensitivity/Whitelist on 2.4.4

Added by Zachary McGibbon 9 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Category:
-
Target version:
Start date:
08/31/2018
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4.4
Affected Architecture:
All

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?

Associated revisions

Revision ef4a242c (diff)
Added by Renato Botelho 7 months ago

Fix #8864: Let users modify sshguard parameters and whitelist

Revision 087a1f6b (diff)
Added by Renato Botelho 7 months ago

Fix #8864: Let users modify sshguard parameters and whitelist

History

#1 Updated by Zachary McGibbon 9 months 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'

#2 Updated by James Dekker 9 months ago

  • Subject changed from SSH Guard on to SSH Guard on 2.4.4.a.20180831.0830

#3 Updated by Nicki Messerschmidt 8 months 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?

#4 Updated by Jim Pingle 8 months 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 set to All

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.

#5 Updated by Nicki Messerschmidt 8 months 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.

#6 Updated by Alexander Müller 8 months 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

#7 Updated by Michael Reardon 8 months 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.

#8 Updated by Renato Botelho 8 months ago

  • Status changed from New to This Sprint

#9 Updated by Renato Botelho 8 months ago

  • Assignee set to Renato Botelho

#10 Updated by dean hamstead 8 months ago

Is it possible to simply disable sshguard?

#11 Updated by Steve Beaver 8 months ago

  • Target version changed from 2.4.4-GS to 2.4.4-p1

#12 Updated by Renato Botelho 7 months ago

  • Status changed from This Sprint to Feedback
  • % Done changed from 0 to 100

#13 Updated by James Dekker 7 months ago

On 2.4.5.a.20181102.0213, works as expected. Address(es) added to the whitelist are not subject to SSH Guard detection.

#14 Updated by James Dekker 7 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF