Re: Enhancement req.: run script on event

From: Richard E. Silverman (slade@shore.net)
Date: 12/31/01 

From: slade@shore.net (Richard E. Silverman)
Date: 30 Dec 2001 23:19:15 -0500

>>>>> "SS" == Steve Snyder <swsnyder@home.com> writes:

    SS> I get a lot of logged messages in this format:

    SS> sshd[26526]: Did not receive identification string from 000.111.222.333.

    SS> This is different from the "authentication failed" msg I get when
    SS> my fat finger fail to type in my name/pass correctly. I'm told
    SS> that this sort of message indicates an attempt to exploit old
    SS> security flaws on my current version of OpenSSH.

No. All it indicates is that something connected to your sshd, then
closed the connection before sending anything. This allows the remote
host to read the initial SSH version string and find out what SSH protocol
and software version you are running. That might perhaps be a prelude to
a crack attempt. It might also be:

* a legitimate user checking to see what software you're running, so as to
  know how to set up her keys

* an innocuous information-gathering tool, like ScanSSH
  (http://www.monkey.org/~provos/scanssh/)

* someone who typed in an ssh command, then quickly decided to issue it
  with different options and interrupted it with ^C

    SS> What I would like to do is block all IP traffic from the source
    SS> address causing the message to be generated (in the example above,
    SS> 000.111.222.333).

This will likely block plenty of perfectly innocuous sources as well, and
possibly irritate and inconvenience your users.

    SS> Yes, I'm aware that I can periodically scan the system logs to
    SS> extract the addresses from the messages, but that leaves a gap
    SS> between scans, allowing further break-in attempts.

"tail -f /var/log/messages | your-program" would seem to be timely
enough. I don't see a reason to add this complexity to sshd when it
already reports the information you want immediately via syslog, where you
can get at it in a variety of ways.

Also, your suggestion poses a security problem. All someone has to do is
spoof a single TCP connection from a victim source address to cause your
server to block that address, possibly belonging to a legitimate user. An
attacker could quickly block access to an entire IP subnet having
subverted only one machine on it, for example. 

-- 
  Richard Silverman
  slade@shore.net