1. sshguard Avatar sshguard
  2. sshguard
  3. sshguard
  4. Issues

False positive in "Connection closed ... [preauth]" SSH message

Issue #77 resolved
Sam Darwin created an issue

Hi,

sshguard 1.6.0-1 Ubuntu 16.04 Google Compute Engine

The Nagios monitoring system is configured by default to check if ssh is working, which seems like a reasonable check. Google Compute Engine is configured by default to have sshguard installed, which also seems like a good idea. Yet the two systems don't agree with each other. Here is log output from auth.log:

May 23 08:46:50 server1 sshd[5902]: Connection closed by 10.128.0.2 port 42370 [preauth]
May 23 08:51:50 server1 sshd[5978]: Connection closed by 10.128.0.2 port 42444 [preauth]
May 23 08:56:50 server1 sshd[6052]: Connection closed by 10.128.0.2 port 42516 [preauth]
May 23 09:01:50 server1 sshd[6126]: Connection closed by 10.128.0.2 port 42586 [preauth]
May 23 09:01:50 server1 sshguard[1603]: Blocking 10.128.0.2:4 for >945secs: 40 danger in 4 attacks over 900 seconds (all: 80d in 2 abuses over 2700s).

Nagios is not being overly intrusive, this is only one check every 5 minutes, and ssh isn't failing, the connection is merely closed.

Your answer may be the host should be whitelisted. That does fix the problem. However, is it the most elegant solution? It would be nice if popular linux distro packages mostly played nicely with each other and didn't require troubleshooting. :-)

At least one person has already reported it, Issue #53 "My problem is that I have a whitelisted host that is checking some services via nagios. Something about how it is doing things causes sshguard to want to block it. That's fine. I put it in the whitelist."

Must this be considered an attack signature? It is not a fail2ban signature... Your thoughts?

Thanks, Sam

Comments (13)

  3. Kevin Zheng

    Thanks for bringing up this issue. We added this as an 'attack' signature because bots that connected to key-only servers (and immediately disconnected) would produce this message. We didn't consider legitimate probes from, for example, Nagios.

    I'm not sure what the right thing to do is. What I do know is that in most cases where this message shows up it's undesirable bot 'log noise.' But input on whether this should still be the case is welcome.

  4. Philipp Hossner

    I got the same problem here. In my case an Icinga2 server is checking if ssh works, but also runs check commands over ssh. In sshguard 1.5 this was not a problem, but after upgrading Debian to stretch sshguard 1.7 was installed and I was forced to whitelist the monitoring. server. The problem with that is, that I still would like to block this server if behaves strangely in other ways.

    My suggestion is to either enable the user to selectively turn off attack signatures for single hosts or to parametrize the attack signature so that monitoring servers can be allowed to use ssh connections more frequently.

  5. Sam Darwin reporter

    When a software's design is quite simple, it's actually sort of unfortunate to make it more complicated, just to handle an edge-case. Nevertheless, with that in mind, a possible solution is to create different tiers or levels of checks. Different signature files. Each one has it's own permissible number of appearances in a log file before getting flagged as an attack. By default, it should be configured such that the signature "May 23 08:46:50 server1 sshd[5902]: Connection closed by 10.128.0.2 port 42370 [preauth]" would have to be much more frequent than every 5 minutes before getting blocked.

  14. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
parser
Votes
0
Watchers
5
Jira: the preferred issue tracker for Bitbucket. Join the team!