I'm in the process of automating the configuration of my VPS using Ansible. This tutorial is an excellent introduction http://lextoumbourou.com/blog/posts/getting-started-with-ans...
ansible looks pretty good. thx for the link.
About a year ago I spent several days trying to get a full puppet system. It was a real headache to be honest and many of the modules have no or very vague docs. Coming back to my setup it's very hard to read or trace what my setup is or how to do one off deployments.
Today I have started with ansible and have already gotten a huge amount done and deployed. Very happy with it. It's all in a small git repo and its very readable and concise.
This is great! I was thinking exactly along those lines, and started looking for puppet/chef scripts that are readily available. It seems that using puppet has a pretty steep learning curve, at least from what I could gather skimming the docs. Actually what I would really like to see is an interactive script, which then guides me through the process of hardening a fresh ubuntu server install, offering sane suggestion…
I'm in the process of automating the configuration of my VPS using Ansible. This tutorial is an excellent introduction http://lextoumbourou.com/blog/posts/getting-started-with-ans...
Nice, I'm on the same road. I'm also looking at Ansible, it's just that I haven't got around to it yet.
anyone who compromises [the VPN server] is in a pretty good position. Sure. But without a VPN, anyone who compromises even one of your other hosts is in the same position. It's a lot easier to audit a single-purpose VPN server for possible security issues than it is to audit all the application code running on the rest of your production systems. And I'd rate the odds of a 0-day being found at higher for most VPN sof…
Ok, just in case it wasn't clear: I am asking about the advantages of having a VPN server as a bastion host instead of another SSH server. You would ssh to the bastion host, and from there to internal hosts. With the appropriate ssh config at the client end, the tunneling through the bastion can be scripted away (using the ProxyCommand directive and RSA keys).
Routing transparency. Sure, you can script a bunch of tunnels, but it's nice to handle routing at a lower layer. Having worked with both setups, I vastly prefer the VPN solution for ease of setup, use, and maintenance.
Also, different attack surfaces. Two layers of the same security measure (ssh) is, all else equal, not quite as good as two layers involving two different measures (VPN, ssh).
> I'd also say that during the first five minutes you should set the default firewalling rules to REJECT anything and then only whitelist what is actually allowed. At which point your 'net connection blips and suddenly you wish you'd paid extra for console access.
That's how I felt about the line where he recommends only allowing the deploy user to connect from a certain number of white-listed IPs. That's great and secure until you get a phone call while you're at the airport or on vacation, and then you hope that you can SSH into a machine at the office just so you can tunnel through from a white-listed IP.
I had to do that and enabling the forwarding of the authentication agent with the -A option in the ssh client was very handy:
$ ssh -A -t office_user@office ssh production_user@production
I have the same private key in all my machines, so this worked transparently avoiding the IP restriction of iptables of the production machine.
passwd Change the root password to something long and complex. And bam! Not even a full paragraph in and security fail. root login should be disabled completely, and all use of privileges should be through sudo. Debian sets this up for you automatically upon install if you supply an empty root password. Of course, disabling root is just the beginning (and the first user created needs to be locked down, as they are no…
> root login should be disabled completely Would you care to explain why?
The foremost reason is that root is carte blanche to ruin a system. This may be fine for a developer seat or even a desktop that is not critical infrastructure (shared), but on a multi-user system (and this includes things such as email and web servers), you really should have a "think twice" prompt, along with logging of who did what and when (eg, sudo). Even if you leave root as ssh key only login, then once an attacker has gained that key (or found a remote exploit), they don't need a password; they're root. Setup administrator users who are given a limited set of sudo commands and only allow them to login via SSH with keys and require complex passwords for sudo, and that's multiple layers of protection and logging. Nothing's perfect, but it has long been recognized that root is a big gaping hole in UNIX security; that's why things like SELinux and RBAC were created, and it's why Windows for so long was so insecure (ie, the main user was essentially passwordless root).
It hasn't been updated too much recently, but I've used Bastille for this in the past, and it's in the Ubuntu repos. http://bastille-linux.sourceforge.net/
Yeah, I forgot about bastille. On their news page they claim that development has been restarted recently. Lets hope that it gains enough momentum again.
Last I checked, Bastille was broken enough that you could fix it easily (I made a few small patches myself), if you knew what you were doing. Which kind of defeats a lot of the power of Bastille, but at least it was still kind of a handy automated checklist for seasoned sysadmins.
.. and it saddens me each time I read a comment like this. It's best practice to disable remote root login. A whole industry supports this.
And, yet, the best practice seems to require an user account with full sudo priviledges. If you know the difference between that and root, please explain it, because I can't see any.
Well root is the default full access account. It is a bit easier to root@serveraddress and brute force in that way than needing to guess which account in the system has sudo access.
It also becomes easier to detect when someone is attempting to break in when you can see logs of common user names in a row fail to log in.
I went through the article and then read every single post on this thread. I am not a security expert so I won't even try to contribute except to say that I see a lot of people offering criticism without taking the extra step of explaining how they would go about hardening a fresh Linux install (or a pile-o-servers in a rack, whatever is applicable). It'd sure be nice for those of us who are not security experts to r…
Writing a canonical server security document is difficult because it depends so much on what the server is doing (what kind of application is it running? how is it accessed?) and where you're starting from. (barebones install? something pre-rolled by your VPS service?)
> No secure server is complete without a firewall. Comments like those are why I normally point people to actual security expects (like, say, Schneier), and why I recommend that new admins should ignore as much as possible the practices chanted by the industry. A secure server does not need a firewall. A firewall can be used to secure a server against a specific threat, but that's it. The days of ping of death are be…
There are so many reasons to put a decent firewall in front of your shiny server(s), but I'll leave here only one (you could find the rest on the actual security experts blogs for sure): Half open TCP connections flood.
1. You should do "apt-get dist-upgrade" to get new kernel packages as well, otherwise you are stuck on an old kernel. (You might want that. I prefer updated kernel for the security, firefoxen, etc.). "apt-get upgrade" will only update existing packages - but the kernel updates require new packages to be installed. 2. If you're on ubuntu, root already has no password, and your initial setup user (whether it is called…
Indeed dist-upgrade should be used - it isn't just kernel updates either. The server should also be rebooted. Applying kernel updates makes no good if you never apply them! screen -x is equivalent to screen -xR afaict:) I'd also add @reboot screen to crontab, which will recreate a session on startup - in my bashrc I have : if [ "a$STY" == "a" ]; then screen -x fi Other useful things include actually setting up backup…
> screen -x is equivalent to screen -xR afaict:)
"screen -x" requires a session to already exist, whereas "screen -xR" will join one if it already exists, but will create one if it does not. At least it does in v4.00 which I use. If you have a "screen" call in your @reboot, you already have a session, so they will work the same.