openssh bugs - May 2017 - [Bug 2717] New: MonitoringHosts option - suppress Connection reset entries from known hosts

https://bugzilla.mindrot.org/show_bug.cgi?id=2717

            Bug ID: 2717
           Summary: MonitoringHosts option - suppress Connection reset
                    entries from known hosts
           Product: Portable OpenSSH
           Version: 7.5p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: john+mindrot at paladyn.org

In a system which is being monitored by a known monitoring server, or
servers - for example using the nagios check_ssh plugin, the log file
will have entries of the form

 sshd[30102]: Connection reset by 192.168.1.39 port 48706 [preauth]

Suppressing these messages, when the connection is made by a known
monitoring server would make it easier to spot probes from hostile
systems.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2717

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
This looks like a bug in nagios:
https://sourceforge.net/p/nagiosplug/bugs/196/

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2717

--- Comment #2 from john+mindrot at paladyn.org ---
(In reply to Damien Miller from comment #1)
> This looks like a bug in nagios:
> https://sourceforge.net/p/nagiosplug/bugs/196/
That bug refers to where the connection is not properly closed by
check_ssh. My point is that if there is a connection to my system,
checking, for example to see if sshd is running, and possibly what
version it is running, then if the connection came from a system
outside my control then this is a probe by an attacker, and should be
logged. If it comes from my monitoring system, which could be checking
frequently to make sure that sshd is still running, then logging those
checks just adds noise to the log file.

Systems which process those logs, such as fail2ban, denyhosts, snort
etc can all post process the monitoring host (or hosts) entries out,
but it would make real probes more obvious in the logs if the
monitoring connections were suppressed.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2717

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au
   Attachment #2979|                            |ok?(dtucker at zip.com.au)
              Flags|                            |

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Created attachment 2979
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2979&action=edit
Allow LogLevel to appear in sshd_config Match blocks

I think the best way to do this would be to allow LogLevel to appear
inside Match blocks, so you can do:

Match 192.20.123.45
  LogLevel quiet

LogLevel is only currently supported at the top level of config and not
inside Match, so this patch fixes that.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2717

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2979|ok?(dtucker at zip.com.au)     |ok+
              Flags|                            |

--- Comment #4 from Darren Tucker <dtucker at zip.com.au> ---
Comment on attachment 2979
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2979
Allow LogLevel to appear in sshd_config Match blocks

Nice solution!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2717

--- Comment #5 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to Damien Miller from comment #3)
> Match 192.20.123.45
ITYM "Match Address 192.20.123.45"

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2717

--- Comment #6 from john+mindrot at paladyn.org ---
(In reply to Damien Miller from comment #3)
> Created attachment 2979 [details]
> Allow LogLevel to appear in sshd_config Match blocks
> 
> I think the best way to do this would be to allow LogLevel to appear
> inside Match blocks, so you can do:
> 
> Match 192.20.123.45
>   LogLevel quiet
> 
> LogLevel is only currently supported at the top level of config and
> not inside Match, so this patch fixes that.

Very elegant solution - thank you

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2717

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2717

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.