Hacker News Reader

Comment by ryanmarsh | Hacker News Reader

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?

View on HN

Hardening (along with any other server setup/configuration) should be implemented using some idempotent configuration management software (Chef, Puppet, Ansible, etc). It's 2016, there's no need to configure servers manually.

> there's no need to configure servers manually.

Other than to learn how, which is also why I'd provide text on how and now a bash script to just do it. Not everyone's needs are the exact same, and it's better to learn how to fish than be handed a line with one hooked. Maybe I have a strong reason not to go SSH keys only? I should at least understand how they work and why they're important so I can make the decision, wrong as many people think it may be.

Right, I was thinking myself... why not have a chef recipe do this, and walk through the systems as you do that.

Ideally the server comes up and applies chef, doing the needful to secure it. Hand-cooking a server is extremely painful.

I mention Ansible and other tools in the article. The idea, as others have mentioned, is to teach a man to fish. You're much better off with having an automated way to perform this, but you shouldn't ever run anything automated that you don't understand.

We'll release an Ansible Playbook over the next week or so that follows these steps.

See related (as inspiration, or an upstream):

  - https://github.com/openstack/openstack-ansible-security
  - https://github.com/geerlingguy/ansible-role-security

Thanks man! I'll take a look.

It depends.

I'm a security guy, so it would be embarrassing and possibly bad for my career if any of my servers got hacked, but I actually don't set up servers that often--it's not part of my job. These Web 2.0 configuration management solutions change pretty fast and don't care about reverse compatibility. So between my infrequent setups my configuration scripts pretty much always break.

Contrast this with bash, which cares a whole lot about reverse compatibility, and it's a no brainer. I've got scripts where the only modifications I've made since 2005 were to add functionality or increase security, never to fix existing functionality that was broken by a change to the system. I'll take that over Chef or Ansible (both tools I've used) any day.

Would be very interested to review server hardening Bash scripts. Have you published anything on Github or elsewhere?

I have, but I don't want to associate this HN account to my GitHub account, sorry. :/

throwaway github account then? :)

Which is why your hardening code (even if it's bash scripts) should have tests, using something like Test Kitchen. It will provision a VM (or cloud server, or docker container), execute your hardening scripts against them, and then run your integration tests to verify that the machine is hardened to your specifications.

"there's no need to configure servers manually" assuming you have a configuration you can trust. Where are these published? And do you trust them?

You are right about automating.

Here is Ansible playbook I recently created https://github.com/chhantyal/5minutes

There's the argument that "just download and run this shell script as root" and "lock down your box" are fundamentally incompatible steps.

It's one of those cases where a tutorial explaining every change you're making and why you're making it really is pretty important.

Because Linux systems can vary widely. Even the same distro can have subtle - or even significant - differences from one hosting provider to another. So writing a shell script that was robust enough to "just work" would not only be complex, it would also likely suffer from readability issues (as so many complex shell scripts do) and thus many sysadmins might not want to run something that can't audit - which is quite sensible really. In fact you cannot even guarantee that Bash will be installed, that's just how annoyingly complicated this job can be.

As a side note, it's also sometimes better having a tutorial full of manual steps as that helps educate the "sysadmin" regarding best practices and some of the basics of Linux administration (if they weren't already familiar). That experience can be just as valuable as hardening the server itself.

I created an Ansible role to do the majority of the tweaks immediately: https://galaxy.ansible.com/geerlingguy/security/ (works on RHEL/CentOS/Fedora/Ubuntu/Debian/Arch).

You should really automate this process if you create more than one server, ever. It's fairly easy to get the basics, and if you don't automate it, I guarantee you'll miss one or more steps in the setup.

Because newcomers would then copy-paste the script without really understanding what's going on, and that lack of understanding will come back to bite when something breaks. Teach a man how to fish rather than giving him the fish and all that. Writing a bash script as a next step based on OP's article would be easy once you know what you are doing.

There probably are such scripts, but the educational value is bigger in the post format.

That said, if you do such things at scale, you'll likely have automated provisioning and configuration management systems in place anyway.

For example you could have images that have the static parts already pre-configured, and something like cloudinit for the ssh keys and/or passwords.

Or you provision the systems with foreman, and then use puppet for configuration management.

The Inversoft guide posted does have a corresponding GitHub repo. https://github.com/inversoft/2016-security-scripts

I think scripting all of this is great - but also agree that it is important to understand what is being performed.

You are supposed to understand the implications of all of these steps. If by accident you ever lock yourself out, you will need to know how you set it up. If you just recommend running a script, most people will not learn what they are doing.

Yes. Doing this 'manually' step by step lets you choose which things are really necessary, your configuration might be different, and forces you to learn WHAT it's doing rather than just running a script. I am not a huge fan of Arch Linux (prefer debian unstable), but this is the same principle as the Arch Linux installation process which doesn't have a monolithic installer but forces you to do the process manually step-by-step.

There was a project called Bastille which basically did exactly that: http://bastille-linux.sourceforge.net/

It would run through a series of questions about your use case to build a security policy, and then edit config files for you.

The problem is that it needs to be aware of all the different flavors of Linux it might be running on, so it's naturally fragile and requires lots of maintenance. Sadly, it hasn't been updated in a few years.

I would say the same reason we teach web developers what a linked list is. They might never use it (watch me eat my own boot here) but it's a fundamental principle upon which a lot of the tools they use are built.

It's good to know what's going on under the hood.

They could be, or you could take the route you won't regret later and use a configuration management system. Deutsche Telekom has open-sourced system-hardening cookbooks for Chef, Puppet, and Ansible.

Good to know. I did some searching and found them here: http://dev-sec.io/

Thanks for linking it - was on my phone.

My dotfiles repo includes an "initialize_debian_server.sh" that basically does all this. It's definitely doable.

just cut and paste all of the commands into a single script if you want one?

Sure! That way it's just a matter of doing

    su -
    curl -sS https://some.random.host/trust-me.sh | bash -

What could go wrong?

Not really. It's more like `./provision.sh your-new-host.example.org`

(Because why in the world would anyone want to type in things by hand? Laziness for any repetetive manual labor is a greatest virtue of any good sysadmin.)

Reply on news.ycombinator.com