Hacky New Year!

I feel I’ll get back to the video topic I’ve started with the previous post, but this time I want to share something I wanted to for some time now – to be more precise, since January. So yeah, in January my home media server was hacked. Nothing serious, nothing has been destroyed or stolen, it was just a bot that bruteforced its way into the server and tried to install a copy of itself – a typical move if you want to have a botnet that grows on its own. This little fella, however, put me on the devops path. I was always somewhat curious about network stuff and as a backend specialist I often worked together with devops and sysadmin folks. First, i was furious – How the hell could this happen to me?!?! I’ve been working with Linux in the last 10+ years, come on WTF?! Then I realized that I’ve made two crucial mistakes – during configuring the services on the machine, I’ve left a user responsible for running a service to exist with its default password and guess what, I’ve left the SSH service vulnerable by letting users log in from anywhere, using a single username+password combination, over the default port 22. You don’t even have to be a sysadmin to know how foolish these were… So here’s something that became my mantra since January when it comes to Linux:

  • Change all default passwords
  • Disable password-based login. Use SSH key pairs!
  • Change the default SSH port.

In January, this looked pretty hardcore to me. It felt like “Wow, I’m safe now!” However now, three months later I’ve already laugh at that statement. As I’ve said, this incident put me on the devops path and luckily enough for me, I have a devops colleague, who is happy to share his knowledge with others. I’ve learned a buttload of things from him since then and also, I’ve extended my own experience extensively via experimenting. (Geez, what’s with all the ex’s in this last sentence??? 😀 ) So, here are a few things I added to the above list since then:

  • Use fail2ban to get rid of bruteforce attempts. This little tool enables you to disable login attempts for a given IP/user after a configured amount of failed retries.
  • Set up a basic firewall on the machine. If you don’t want to mess around a lot, use UFW (Uncomplicated FireWall). It can be set up in minutes.
  • Never use your media server or smart home center as your primary entry point to your home network. Use a login server – this is usually referred as a gateway or a bastion. If you’re on the poor side, use a Raspberry Pi or an old PC as the login server and have your sensitive data on a separate machine. If your login server gets compromised, you can wipe it clean safely without losing data. Having two separate machines with separate users, etc. also adds another layer of security.
  • Never use a Windows PC as your primary entry point either. OSes like Windows 10 are not meant for this and you’ve to fiddle around a lot with security settings unnecessarily. Use Linux for this. Period.
  • If you’re running network services on your login server that need configuring, consider using Docker. It adds another layer of security and in case the machine is compromised, you don’t have to re-do everything from scratch – you can just restore stuff from Docker images.
  • For setting up stuff you need to do each time to install a Linux server (like configuring SSH access, Samba, etc) consider using Ansible. It’s an easy tool developed for automatic provisioning (software installation and configuration) on servers. Also, you can use it to create “clones” of your server or to set up a cluster of multiple, similar servers.
  • Set up a notification system. Considering that most people nowadays have smartphones with email clients installed on them, configuring an email sending mechanism for “oh crap!” situations on your server yields you instant notifications about hack attempts. Fail2ban is prepared for sending emails by default for example. Setting up email sending can be a bit tricky, but for example with a Gmail account, you can do it freely and safely. Unfortunately you’ll have to Google for this, depending on the Linux distro you use.
  • Hide your server behind your router and open ports only that are necessary. Also, do a strict port forward – e.g. the SSH port you’ve opened up should be routed only to your login server, and even if you’re running SSH service on other machines, don’t let them accessible from the outside! If you’re running a web server, use your login server as a proxy as well.

There’s still a lot to learn and I’m pretty sure that a real, experienced hacker could cut through my defenses like a knife through butter, yet it feels exciting and a real achievement. And as I said, this whole thing put me on the devops path. I’m dead serious – I’m already preparing for my first AWS (Amazon Web Services) certification. (This worth another post i guess…)

Posted in iNi Blog Tagged with: , , ,

What the …

A die hard coder's blog about basically anything slightly related to programming, gaming, IT, etc. Stuff I've experienced, opinions and rants, written in mostly a caffeine-happy state of mind. Oh, and some articles too...

The Archives