This one is pretty decent but if you want the ultimate guide check out this one:<p><a href="https://www.inversoft.com/guides/2016-guide-to-user-data-security" rel="nofollow">https://www.inversoft.com/guides/2016-guide-to-user-data-sec...</a><p>It covers 10x what all the other guides cover in terms of server and application security. It was posted a few weeks ago on HN but didn't make the front-page.
> We don't even have a password for our root user. We'll want to select something random and complex.<p>So you're taking something secure by default -- no password means no login allowed, and making it less secure. And if you have hundreds of these servers, you'll need to rotate them whenever someone on the team leaves. This is painful.<p>Simple solution: leave root password blank, don't forget your sudo password. If you can't get in, use grub or a liveCD. Or tie auth to ldap or kerberos so you _can't_ forget. This is one area where Windows has a distinct advantage: AD more or less requires admins to think at the level of network of servers, and provides a baseline set of services always present.
This is good advice on achieving the most secure SSH configuration:
<a href="https://stribika.github.io/2015/01/04/secure-secure-shell.html" rel="nofollow">https://stribika.github.io/2015/01/04/secure-secure-shell.ht...</a><p>"My goal with this post here is to make NSA analysts sad."
> I check our logwatch email every morning and thoroughly enjoy watching several hundreds (sometimes 1000s) of attempts at gaining access with little prevail.<p>This is something that actually bugs me a bit. These attacks are so common, getting emails like this every day contributes to alarm fatigue. (<a href="https://en.wikipedia.org/wiki/Alarm_fatigue" rel="nofollow">https://en.wikipedia.org/wiki/Alarm_fatigue</a>)<p>I'd love to see the Linux nightly security scripts replaced with something that only sends out emails when there's an specific <i>actionable</i> event I need to pay attention to. Ideally in a way that can easily be aggregated over all the machines I manage.
> sudo ufw allow from {your-ip} to any port 22<p>I'm surprised nobody mentioned this is a great way to shoot yourself in the foot if you don't have a static IP.
I don't mean to sound flippant but why can't these "lock down your new box" tutorials just be a bash script? Shouldn't they be?
Why do people install fail2ban then disable password based authentication entirely? I legitimately don't understand the purpose.<p>Also, they complain about log spam (from failed SSH attempts) this is one reason to move SSH to a different port. It does NOT increase security, but it DOES reduce log spam from bots trying for easy targets.
Fail2ban? sshguard? unnecessary.
Just disable ssh passwd auth (which generally is a good idea) -> done/done<p>If you don't like lognoise from ssh scanners (even if you disable passwd auth), move your sshd port to some random high port and make note of it in your ~/.ssh/config<p>Generally: if in doubt, take the more simple and elegant solution to a problem.
I prefer the “Securing Debian Manual” – it’s an <i>official manual</i> from the Debian project.<p><a href="https://www.debian.org/doc/manuals/securing-debian-howto/" rel="nofollow">https://www.debian.org/doc/manuals/securing-debian-howto/</a>
Be aware fail2ban does not handle IPv6 at all with its default configuration on Debian/Ubuntu.<p><a href="https://github.com/fail2ban/fail2ban/issues/1123" rel="nofollow">https://github.com/fail2ban/fail2ban/issues/1123</a>
Great tactical advice, but what a sad situation to be in. "Run this command, then run this command, then run this command ..."<p>There should be a single configuration file (or set of files) that declaratively describes the whole state of the machine. That way the exact situation of the server can be reviewed by just looking at files, instead of trying to poke and prod at the machine to see what commands have been run over the last X weeks.
Since I changed the default SSH port of 22 to something else (like 4422), I no longer get any of these drive-by attacks and don't need fail2ban anymore.<p>I also like to set up a simple Monit configuration to alert me about high cpu usage or when the disk space is about to run out. Instead of emailing me these alerts (and also weekly reports) I've configured Monit to post them to my Slack team of 1.<p><a href="https://peteris.rocks/blog/monit-configuration-with-slack/" rel="nofollow">https://peteris.rocks/blog/monit-configuration-with-slack/</a>
What's the reason for using a firewall?<p>Assuming that services which shouldn't be accessible to the outside only listen to localhost not the network (e.g. MySQL on a LAMP stack), isn't that sufficient?<p>(Honest question, I don't have much experience with syadmin.)
Here's an Ansible role (I made it) that automates the steps described in the article: <a href="https://github.com/LucianU/ansible-secure" rel="nofollow">https://github.com/LucianU/ansible-secure</a>.
Can somebody help me out with this question: The default config for unattended-upgrades seems to not enable reboot even if a reboot would be required to activate the upgrades.
Wouldn't that had made quite a few important upgrades in the last years effectless if they server did never get rebooted?
For those saying "why fail2ban?", fail2ban can be used for a great deal more than just watching the sshd log. You can activate fail2ban rules for apache and nginx which help significantly with small DDoS, turning spurious traffic/login attempts into iptables DROP rules. And a lot of other daemons.
I'm finding that another important step is this one:<p>apt-get install etckeeper && cd /etc && etckeeper init<p>Keeps your /etc under version control so you know what kinds of configuration changes you've perpetrated.
I have been meaning to write up a similar guide.<p>I would like to recommend using just iptables instead of ufw, I had a case on my vps where an update to ufw failed and then the firewall was not working.<p>With iptables, install iptables-persistent package so they are saved when you do restarts. Do not try to block entire country ip ranges as this slows the machine down substantially.<p>fail2ban is great, I would recommend looking at some of your system logs to figure out new rules to add.
Why don't they disable root logins with password period and only allow SSH key authentication?<p>Also if you put a passphase on your SSH key does that mean you have to enter it every time you want to SSH to the server (in order to unlock the key) or does it stay cached on most SSH clients (ssh on mac terminal, putty on windows, etc).<p>Isn't watching failed logins kind of useless? I think it is more important to see what successful logins were made.
Its a tradition to nitpick these kinds of lists. Here's my take.<p>>I generally agree with Bryan that you'll want to disable normal updates and only enable security updates.<p>Hmm, fairly certain the Ubuntu (and others) don't do major product updates or API breaking updates via apt-get. You shouldnt have to worry about breaking anything if you use normal updates. This seems a bit too conservative for me and leads to problems down the line of being on an ancient or bugged library and then having to do the update manually later, usually after wasting a couple hours googling why $sexy_new_application isn't working right on that server.<p>He setup an email alert, but not an smtp to actually send it. Also, OSSEC takes a few seconds to install and is much nicer than emailing full logs.<p>Lastly, fail2ban is becoming a sysadmin snake-oil/fix-all. Its use is questionable in many circumstances. There's a real chance of being locked out of your own server with this. If people are recommending it, they should be giving noob-friendly instruction to whitelist their IP at the very least.
Not sure if others feel this way but adding this line to sudo never felt right to me...<p>deploy ALL=(ALL) ALL<p>I usually instead limit the deploy user to a smaller subset of commands e.g. the init.d script to control a service.<p>obviously if someone gained access to deploy user we're probably sol anyway... but it just makes it seem safer... we have a to login as an ops user to install or update things on the boxes.
I created a script that does almost everything automatically using Ansible and Ansible Vault : <a href="https://github.com/guillaumevincent/Ansible-My-First-5-Minutes-On-A-Server" rel="nofollow">https://github.com/guillaumevincent/Ansible-My-First-5-Minut...</a>
I always worry that adding 2FA could make your machine inaccessible if anything happens to google-authenticator in this case. Maybe it's a little bit of paranoia but I don't like the idea of giving control over my ability to log into my server.
For protecting against brute-force login attempts, I use sshguard [1]<p>I really think this should be installed by default on distros like Ubuntu.<p>[1] <a href="http://www.sshguard.net/" rel="nofollow">http://www.sshguard.net/</a>
One of the suggestions is to make sure your public key has the .pub extension, and they imply that if someone didn't include the extension they would be reprimanded - any reason for this in particular?
> "You should never be logging on to a server as root."<p>Can someone explain me, let's say I disabled password logins and only allow login via a key, what are potential downsides of logging in as a root?
Forgot to check if the server isn't backdoored. You will be surprised how many providers add many backdoors and monitoring systems you don't need (m looking at you AWS guys).
I would be annoyed with a cryptic Audi password. I would prefer 'BatteryHorseStaple' passwords. Anything I can't remember gets written on a post it note and put next to my screen with what it is for. This is my behaviour and the problem with cryptic passwords is that there are others like me, willing to keep a good password secret and not willing to be so secret about a clumsy, easy to crack by machine but impossible to remember password.
It may be useful, at step 0, to check out the server and see <i>basic server orientation</i>. Which Linux is it (cat /etc/*-release)? How much ram and disk (htop, df)? How is the filesystem setup (mount)? What packages are already installed (dpkg -l)? What processes are running (ps aux, htop)? What did the last root, including me, do (history)? I also like to know where is the box physically, roughly (tracert, run locally).
My biggest concern with being on a VPS like Linode, once you're all done securing yourself and binding services to the local LAN IP, is an attack from within the network. The VPS you own is also accessible by others on the same subnet, contrary to what you might assume.<p>I'd love to see a ufw guide for whitelisting only your own internal IPs to be allowed access to any services for ultimate security.
Technically you don't need the root password, you can always password recovery if you have access to the box. And how exactly did you lock yourself out of every account with sudo? Of course there's always "messed up my ldap or general network settings, can't log in to fix them". There's nothing wrong with setting your root password to a random string and throwing it away, after verifying your sudo works, I guess.<p>I will admit to being lazy, and with full automation its faster to spawn a new virtual image and let ansible run its course than to do root password recovery where you boot and tell the bootloader to make the init system /bin/sh and hand edit /etc/shadow and /etc/passwd and then reboot again, etc etc. I mean I can set up a new image almost as fast as I can reboot an old image, and I set up images a lot more often than I do password recovery, so...<p>Scrap the ssh commentary and set up ssh company wide as per stribika plus or minus local modifications:<p><a href="https://stribika.github.io/2015/01/04/secure-secure-shell.html" rel="nofollow">https://stribika.github.io/2015/01/04/secure-secure-shell.ht...</a><p>"On large scale, you'll be better off with a full automated setup using something like Ansible"<p>At ANY scale you're better off, unless you're experimenting or time isn't money. It'll take longer to add the time to document and test what you're doing by hand than to convince ansible to do it for you. If you don't document or test you're just doomed, so its not like you can avoid that effort. With automation this is like "first two minutes on a server" not ten.<p>Some people like to drop a .forward in root's homedir sending mail to your sysadmin mailing list or yourself. I THINK but might be wrong that if you do that you don't have to tell logwatch whom to email to, it'll go to root then forward to the right people. More than logwatch assumes root@something.whatever exists as an email address.<p>You're missing setting up your centralized rsyslog or local equivalent, your munin/nagios/zabbix or local equivalent... I still configure zabbix by hand because I'm old fashioned but its possible to automate that.<p>NTP is also missing. You can make Kerberos a very sad faced puppy if time isn't synced. And its easy to set up to point to local trusted servers.<p>(Note, a post that's nothing but complaining still means the linked article is at least 99.9% correct, it is a nicely written wide ranging TODO list)
I have a VPS, when I first got it, it had an additional user setup for some unknown reason. I didn't know it was there until my server was hacked by a bot. I'd suggest adding one step of checking the /home directory or other places to make sure no 'unknown' accounts have been set up.
I guess I'm a pretty big noob, but why do people recommend so strongly on password protecting your private key? Losing it pretty much dooms you whether or not it's password protected. It might get you a few hours or so to react and invalidate the public key, I guess...
This is very similar to my "How To Set Up Your Linode For Maximum Awesomeness" guide:<p><a href="http://feross.org/how-to-setup-your-linode/" rel="nofollow">http://feross.org/how-to-setup-your-linode/</a>
If you open up access from/to port 80 or 443, you also open up access to all trojans/spyware/telemetry/auto-update created in the last ten years. You'll want to limit access per user and process.
It might nice if there were some cloud vendor specific addendums. For example on rackspace you almost always want to install the monitoring daemon (it's actually fairly decent and small foot print).
Instead of using unattended-upgrade, I prefer to subscribe to mailinglists and see when there are new securtiy updates.<p>One could combine that with something like rundeck where you run apt-get upgrade.
Why not make a <i>certified</i> secured best practice 99% covered snapshot and share it as part of the one-click installs that most VPS providers offer nowadays?
I think 2FA is generally bad practice and quite sad it is ubiquitous in e.g. banking and people try to shove it everywhere. It is analogous to password rules, 8-14 characters, numbers, capital letters and other signs. Yet it is very rare you can use a 40+ character passphrase. It gives a false sense of added security, while being annoying at the same time imo. It is very common, for me at least, not to have access to my phone all the time, because I left it at home, in the car etc. Not to mention if you lose it (or someone steals it) you have a huge pita to deal with.
sure makes me glad all that (and so much more) happens in the first negative 10 minutes on any server I deploy.<p>If you are doing this after your server has launched you are doing it wrong.
I'd been using this article for a couple years when I was a Linux server neophyte and now some of these things seem obvious to me. A good article for total noobs.