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?

2
  • 1
    Why not figure out why Denyhosts isn't working? It's pretty effective.
    – ewwhite
    Jul 29, 2014 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). Jul 29, 2014 at 22:07

2 Answers 2

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.

3
  • 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. Jul 30, 2014 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. Jul 31, 2014 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". Jul 31, 2014 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.

6
  • 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. Jul 29, 2014 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, 2014 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? Jul 29, 2014 at 22:17
  • 1
    Or keep the host key the same! Jul 30, 2014 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, 2014 at 6:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .