0

So just for fun I opened up SSH to the world and a few bots have latched on to my server (unsuccessfully trying to log in by password). But of course this fills up the logs. I've attempted to use DenyHosts, but somehow it's not really working, so I thought, "Why not use a honeypot?"

The problem is, I want to allow good logins while sending everyone else to the honeypot.

Is there any way to filter in correct logins to the real SSH server and leave everyone else in the honeypot?

  • 1
    Why not figure out why Denyhosts isn't working? It's pretty effective. – ewwhite Jul 29 '14 at 21:58
  • 1
    @ewwhite Because all indicators say it "is" working, namely, hosts pile up on the hosts.deniedssh file, but the audit log still fills up with denied attempts (from the same host). – Tsaukpaetra Jul 29 '14 at 22:07
4

If you want to allow legitimate SSH logins while disallowing (via honeypot) fake, I'd change tack.

Put your SSHD on another port, like 2323 or some other oddball port, and forward connections to that. Ideally you have a separate machine for that, so you can tell your router to forward port 2323 to internal machine XYZ port 22.

Open port 22 to be forwarded to your honeypot machine ABC on port 22.

If at all possible set up your network so the honeypot is in a DMZ away from your legitimate network systems. Otherwise you're asking for problems.

  • It seems that using another port altogether seems to be the simplest solution overall. Perhaps I was being hopeful the coolness factor would be worth it, but the headache seems to be greater than the gain. – Tsaukpaetra Jul 30 '14 at 4:02
  • 1
    When it comes to IT/admin tasks, coolness factor is rarely ever as beneficial as doing something in a simple, maintainable way. – Bart Silverstrim Jul 31 '14 at 13:33
  • Agreed. But my primary server started out as a "wouldn't it be cool" project. ;) I am after all one of the pioneers to get VirtualBox running on a FreeNAS system "the easy way". – Tsaukpaetra Jul 31 '14 at 16:11
1

Using a tool like fail2ban as a starting point will allow you to treat those trying to brute-force differently from legitimate users.

Usually fail2ban will just reject the connections, but I guess it wouldn't be hard to modify it to redirect the connections to a honeypot instead.

The tricky part is actually going to be the host key. On one hand you don't want the honeypot to have access to your host key for security reasons. But on the other hand you don't want the attackers to notice that they are directed to a different SSH server.

  • In my mind the hackers wouldn't notice being redirected to the real server, as they would never give the right creds to begin with. – Tsaukpaetra Jul 29 '14 at 22:07
  • @Tsaukpaetra The host key is sent to the client before credentials are sent to the server. Obviously, since sending your password to a server before you had seen its host key would completely defeat the security SSH was offering you in the first place. – kasperd Jul 29 '14 at 22:11
  • True this is. Seems the logistics would get tangled because of that first step, wouldn't it? But would a bot really notice or care that the public key magically changed after three tries? – Tsaukpaetra Jul 29 '14 at 22:17
  • 1
    Or keep the host key the same! – Joe Sniderman Jul 30 '14 at 0:26
  • 1
    @JoeSniderman There is much higher risk that an attacker would find an exploit to copy the host key from the honeypot than copying the host key from a host, where they cannot login. If the host keys are identical, then after the attacker has copied the host key from the honeypot, that same host key could be used in a mitm-attack against the real SSH server. – kasperd Jul 30 '14 at 6:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.