Project

General

Profile

Actions

Bug #8864

closed

SSH Guard Sensitivity/Whitelist on 2.4.4

Added by Zachary McGibbon about 3 years ago. Updated almost 3 years ago.

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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?

Actions #1

Updated by Zachary McGibbon about 3 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'

Actions #2

Updated by Anonymous about 3 years ago

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

Updated by Nicki Messerschmidt almost 3 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?

Actions #4

Updated by Jim Pingle almost 3 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.

Actions #5

Updated by Nicki Messerschmidt almost 3 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.

Actions #6

Updated by Alexander Müller almost 3 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

Actions #7

Updated by Michael Reardon almost 3 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.

Actions #8

Updated by Renato Botelho almost 3 years ago

  • Status changed from New to 13
Actions #9

Updated by Renato Botelho almost 3 years ago

  • Assignee set to Renato Botelho
Actions #10

Updated by dean hamstead almost 3 years ago

Is it possible to simply disable sshguard?

Actions #11

Updated by Steve Beaver almost 3 years ago

  • Target version changed from 2.4.4-GS to 2.4.4-p1
Actions #12

Updated by Renato Botelho almost 3 years ago

  • Status changed from 13 to Feedback
  • % Done changed from 0 to 100
Actions #13

Updated by Anonymous almost 3 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.

Actions #14

Updated by Anonymous almost 3 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF