Home server/Remote access

Security

Unlike a desktop, a server is always working, accepts connections from the internet (your desktop is normally firewalled and doesn't have any ports open) and is easy to discover (especially if you send mail from it). It's under a bit more risk, and its worth thinking about what intrusions you will try to prevent and how.

Threat model

There are 4 main classes of attackers, grouped by what sorts of security measures are appropriate for them.

Busybodies

These are extremely unmotivated people like asshole flatmates or nosy neighbors (who end up on your WAN). They will rarely even try anything, and if they do, they will make the tiniest of efforts and give up at the first sign of difficulty.

Just put good passwords on your shit and don't tell them to anyone, and it will be enough for this group.

Casual snoopers

These are attackers who actually have a strong motive to get your data, but aren't competent and don't have the resources to make a serious attack. Say a burglar steals your computer. Of course he will try turning it on and seeing if there's anything interesting inside. He will not hesitate at all, unlike the previous group. Hopefully, he will see a password prompt, and after a few tries, give up on trying to guess it. However, again unlike the previous group, he will not stop there. If at all computer literate, he will try to plug the hard drive into another computer, or boot from a LiveCD. At that point it's possible that you will be the victim of identity theft.

Technically, this group has physical access, so by the common maxim of computer security, you have already lost. But in practice, they could only defeat your security theoretically. In practice, they don't know how to actually leverage that physical access, and probably won't bother trying.

Full disk encryption will deter this group, since they don't have the resources to defeat, and will simply give up and just sell the hardware at that point. Encryption takes a lot of work to defeat, and most of the shit people encrypt honestly isn't valuable or worth bothering with.

Skids

Within even the first day of your server's uptime, you will realize that there's tons people constantly trying to hack your machine. There is a sliding scale: There are tons of shitty script kiddies just randomly scanning ports over a range of IPs, and when they see your server responding, they start trying to bruteforce the SSH. This is extremely common and very easy to protect against. On the other hand, there are some extremely determined, very skilled hackers who buy 0days on the black market and use them, but these will probably be rarer, and they will prefer go after juicier targets like banks before coming after your home server full of animu porn.

The way to defend against this group is to configure your server for strong security, always keep your software up to date as new exploits appear, and keep a close eye on signs of intrusion. Defending against this group is probably the bulk of your security related maintenance workload.

At the same time, you have to recognize that you the only way to have perfect security is to turn off your server and disconnect it from the internet. Consider something like the Heartbleed bug: There is nothing you could have done to protect against it, even if you acted the moment the news broke (you could have been attacked before the news were out). That said, if a bad guy got hold of Heartbleed, he probably wouldn't attack you (there are much better targets), and just because you can't have perfect security, doesn't mean you shouldn't have any security. Lockpicks exist, but we still lock our doors.

Hardcore attackers

The last class is attackers with very high competence, extensive resources, who are highly motivated to come after you. This is basically a government agency (CIA/NSA/FBI/Chinese spies) or a serious hacker (eg. hired by a company) targeting specifically you. Note that, as opposed to the 0day hacker from the previous class, these attackers are targeting specifically you. So the argument that they have "bigger fish to fry" does not apply anymore: Either the government is after you because you did something they don't like, or a someone paid a hacker to get you, either way the attacker will not stop until they've tried every trick in the book (and it's a very big book).

There isn't much you can do about this group. You could try to take some measures, but they will be very inconvenient, and some may even be dangerous or borderline illegal. For one, the government could easily gain physical access to your system by producing a warrant, and unlike a burglar, they actually could and would take advantage of that physical access. Given this, your best option is to not attract any attacks in the first place: Don't do anything illegal, don't be an important person targeted by cyber warfare, and don't piss off any hackers, or anyone who would pay a hacker. Anything beyond that is out of this document's scope.

Recommended security policy

Going by the above model, these recommendations aim to deter entirely the first two groups, deter as much of the third group as possible, without taking any additional measures for the fourth group.

GNU/Linux

• If you are behind a router, only forward ports you need.
• When installing the OS, encrypt your entire drive (except for /boot which is needed to actually boot before the disk is unlocked). Because you need to enter a password at boot to decrypt, you will not be able to reboot remotely, but the alternative of not encrypting is unacceptable. Try not to kill your server when you're not around to boot it.
  • Encrypting only your home directory is not adequate. There is sensitive data outside the home directory as well.

Protecting Your Private Network

As mentioned above, only forward ports which are needed. Your firewall should reject all traffic which isn't either in response to an existing connection, or destined for a forwarded port. You might encounter guides which tell you to drop traffic rather than reject; however, this can cause problems with legitimate applications and provides little to no actual security. The same goes for ICMP echo requests/replies; you achieve little by blocking them, and dropping innocuous ICMP traffic can be problematic for legitimate connectivity tests.

Make sure to keep your router firmware updated, as vulnerabilities are often patched in newer versions (at least, from the companies which bother even releasing them). If your device doesn't receive support in the form of firmware updates and security fixes, consider running community-maintained firmware such as OpenWRT.

Securing your shell

If anyone breaks into your shell, you are FUCKED. They will own your whole server within minutes. There are bots that do nothing but scan for vulnerabilities on random IP addresses all day long, and they will hammer your SSH port like it's Natalie Portman's butthole. You need to secure that shit as your first priority, and here's how:

Add a non-root user. Then, while logged in as root, do this:

visudo

Go down to the bit where it says # User privilege specification, and copy the setup for the root line. So, if your non-root user is "faggot," make it look like so:

# User privilege specification
root     ALL=(ALL) ALL
faggot   ALL=(ALL) ALL

We are going to use ssh & ssh-keygen in this tutorial because its consistently available on almost all platforms, including GNU/Linux, BSD, and OSX (by default), and Windows (You're not going to use wangblows and also worry about NSA backdoors are you?). You can also use PuTTY if you need a GUI crutch or something else entirely, but if you were a tard like that, you probably shouldn't use this page, amirite?

OpenSSH includes a program called ssh-keygen. To generate a public/private key pair run:

ssh-keygen -t ed25519 

With ed25519 the default bitsize is plenty secure (the -b flag is ignored for ed25519 anyways) - nobody's gonna crack that shit easily, the NSA infiltrated the RSA, and DSA is old and insecure, so fuck that. Use the default locations to store your key and enter a strong password when prompted, this is not meant to authenticate you against the SSH server, but to keep the private key secure in case it's stolen from your client machine. When done, it will output 2 files (id_ed25519.pub and id_ed25519) to ~/.ssh. To use the keys for ssh authentication just copy id_ed25519.pub to .ssh/authorized_keys in the home directory of faggot on your server.

use sftp and log in as your non-root user. Then do this:

put .ssh/id_ed25519.pub

you can exit sftp, now use ssh to log in as your non-root user. Then do this:

mkdir .ssh && cp id_ed25519.pub .ssh/authorized_keys && rm id_ed25519.pub

Now take ownership of it:

chmod 600 ~/.ssh/authorized_keys

DO NOT EXIT SSH YET, but open a second ssh session and connect to your server. If it all goes well, your login will look something like this:

Using username "faggot".
Authenticating with public key "ed25519-key-########"

Assuming that works, close your previous ssh session and do this:

sudo nano /etc/ssh/sshd_config

You can change the SSH port here to a random number - that's optional though, because hacker bots are gonna find it anyhow. But if you do change it don't forget to use -o port=#### when loging in as well.

But DO make the following changes:

PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UsePAM no

Add the following to the bottom if missing:

UseDNS no
AllowUsers faggot

If you have additional users, put a space after "faggot" and add the next user, and so on if you have more.

Save these changes and restart your SSH server. On Debian, or any other system using sysvinit or OpenRC setup it would be:

sudo /etc/init.d/ssh reload

If you are using systemd, it would be:

sudo systemctl restart sshd 

BOOM. Assuming all went well, you have now set up your shell so that 1) "root" cannot log in, 2) ONLY "faggot" can log in, and 3) "faggot" can ONLY log in using their private key file instead of a password. You'll still want to set up and install fail2ban or similar to secure things further.

Oh, and don't lose that private key file. You cannot recreate it, so losing it means you are doomed. Back it up in multiple places. You may wish to place a copy on a floppy drive (if you're a time-traveller from 1995) or USB stick as well, for safekeeping.

Securing your shell even more (and everything else)

Even with your shell secured, its still gonna get hammered, and that's going to get irritating quick. Given enough time, even your super-secret keyfile can eventually be guessed. Well, guess what? You can ban the SHIT out of those bots with fail2ban.

fail2ban monitors your log files (any of them, not just SSH). If it sees too many login failures, it bans the offending IP for as long as you configure it to. It won't prevent a distributed brute-force attack, but it will help a LOT.

• How To Protect SSH with fail2ban on Debian 7
• How To Protect SSH with fail2ban on CentOS 6
• How To Protect SSH with fail2ban on Ubuntu 12.04

Please note that if you are going to install iRedMail (below), it will install and configure fail2ban for you. You may still wish to tweak its settings though.

fail2ban

fail2ban is a utility that scans your system log files and bans anyone who tried to make logins and fails. With the default settings, 3 failed SSH logins trigger a 10 minute ban for that IP. This makes brute-forcing very difficult. Usually hackers see the ban and move on, they don't bother even waiting for the 10 minutes to run out.

sudo apt-get install fail2ban

fail2ban comes with a bunch of rules already set up. To see these, type sudo fail2ban-client -d (fail2ban runs as root so you won't get anything without sudo). For best results, the jails should be reviewed and fine tuned. There is a manual here: http://www.fail2ban.org/wiki/index.php/MANUAL_0_8

fail2ban keeps a log where it records IPs it banned. You can see it with nano /var/log/fail2ban.log. After a few days, a bunch of Chinese IPs should pop up.

To quickly analyze the banned IPs, run grep Ban /var/log/fail2ban.log. Paste the resulting lines into text editor of your choice and replace the regex .*Ban with an empty string. You will now have the list of IPs. Paste these into a batch geolocator tool like this one.

Protecting from DDoS and shit

Use Fail2Ban (and/or DenyHosts) and perhaps a redundant computer in the DMZ. Also never use passwords, only keyfiles.

fwknop - Single Packet Authorization

Normally, your server needs to keep a port open for each service you want to provide. However, hackers love trying to break in the moment they find an open port.

SPA solves the problem by keeping ports close when not in use. How does the server know to open them when you need to talk to it? You pick a port, say 12345, to use for SPA. The server listens on that port but never replies, so there is no way to tell that it's open (and everything else is closed). Every packet arriving on 12345 is actually inspected, the server is waiting for a packet that was encrypted with the correct key. Once a valid packet is detected, the server opens up the ports you need for a few minutes, letting you connect, and then closes them again (you stay connected).

Mail servers

Obviously it's bad for your mail server to get compromised. If hackers break into a mail server, they can start sending spam, so these are high value targets. As soon as they find out that your mail ports are open (and they'll find out very quickly thanks to scanning ports+harvesting your address), they'll come right for you.

If your server starts sending spam, you will be taken for a spammer by all the major spammer blacklists. Your ISP may receive abuse complaints, and they'll be wanting to ask you wtf is going on. If the attacker does something illegal (eg. spam is illegal in Murka) you could get the authorities coming after your server, too. And when all this is over and the dust settled, you'll realize that your domain is now on every blacklist under the sun, all your emails bounce so you can't talk to anyone, and it's a huge pain to get off the blacklists ("I'm totally not a spammer guys, that was just a hacker!").