Suggestion: SSHD pseudo/fake mode. Source available.

Hi,

SSH brute force attacks seem to enjoy increasing popularity. Call me an
optimist or a misrouted kind of contributer to the community, but on our
company server I actually go through the logs and report extreme cases
to the providers of the originating IP's. With the increasing number of
these attacks, however, I have now decided that it's better to move the
SSHd to a different port. The downside is: it was actually fun to report
a failed brute force attack from time to time!

Alright, I know, there are IDS's available, and scanners, etc., etc.,
.... but one benefit of having a real daemon on port 22 is that it keeps
the intruder busy and produces evidence through failed login attempts
and usernames in the logfiles. So I thought it might be sensible to
build a and run a fake server running on port 22 that behaves
essentially like an original SSH daemon (key exchange, password request,
...) but strictly denies every attempt to login, even if the password
turns out to be right.

I don't know if anyone else would find such a feature useful. But I
learned that it's just a few lines of additional code. I've run this
against release 3-9.p1 of OpenSSH.

In short, here's what I did:
- added a new command line flag "-T" for trap to trigger the internal
"trap_mode" flag
- added a "trap" flag to the "authctxt" type that is set according to
"trap_mode" when a new context is created
- extended the conditionals in auth1.c etc. to circumvent
"authenticated"=1 when "authctxt->trap==1", even if the authentication
itself was successul.

Little effort for a trap that's almost impossible to identify as such.
If there's any interest in this solution, I would willingly provide a
patch file! Tiny little problem: I've never contributed to an open
source project before and don't know how to create this patch file
thing. Is that just the output of a "diff"? If someone tells me or could
point me to a short (!) tutorial, it's all yours.

And if you don't like having such an option in your sshd, well, no one
forces you to use it. But somebody else might be happy to have it.

Regards


Daniel

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev