Linux Server Hardening Utilizing Idempotency with Ansible: Half 2
Within the first a part of this collection, we launched one thing known as idempotency, which might present the continued enhancements to your server property’s safety posture. On this article, we’ll get a bit of extra hands-on with a take a look at some particular Ansible examples.
You’ll need some Ansible expertise earlier than with the ability to make use of the knowledge that follows. Quite than run via the set up and operation of Ansible let’s as an alternative take a look at a number of the idempotency playbook’s content material.
As talked about earlier there is perhaps tons of of particular person system tweaks to make on only one kind of host so we’ll solely discover a couple of advised Ansible duties and the way I wish to construction the Ansible position accountable for the compliance and hardening. You’ve gotten hopefully picked up on the truth that the satan is within the element and it is best to completely, unequivocally, perceive to as excessive a stage of element as potential, concerning the permutations of creating adjustments to your server OS.
Bear in mind that I’ll combine and match between OSs within the Ansible examples that observe. Many examples are OS agnostic however as ever it is best to pay shut consideration to the element. Apparent adjustments like “apt” to “yum” for the package deal supervisor is a given.
Inside a “duties” file beneath our Ansible “hardening” position, or no matter you resolve to call it, these named duties symbolize the areas of a system with some instance code to supply meals for thought. In different phrases, every part that follows will most likely be a single YAML file, akin to “accounts.yml”, and every may have with various lengths and complexity.
Let’s take a look at some examples with concepts about what ought to go into every file to get you began. The contents of every file that observe are simply the very starting of a guidelines and the next recommendations are removed from exhaustive.
That is the appliance that the majority engineers instantly look to harden when requested to safe a server. It is sensible as SSH (the OpenSSH package deal in lots of circumstances) is often just one of some ports deliberately prised open and naturally permits direct entry to the command line. The extent of hardening that it is best to undertake is debatable. I consider in tightening the daemon as a lot as potential with out disruption and would often make round fifteen adjustments to the usual OpenSSH server config file, “sshd_config”. These adjustments would come with pulling in a MOTD banner (Message Of The Day) for authorized compliance (warning of unauthorised entry and prosecution), imposing the permissions on the principle SSHD information (to allow them to’t be tampered with by lesser-privileged customers), making certain the “root” consumer can’t log in straight, setting an idle session timeout and so forth.
Right here’s a quite simple Ansible instance that you may repeat inside different YAML information in a while, specializing in imposing file permissions on our primary, important OpenSSH server config file. Observe that it is best to rigorously test each single file that you just hard-reset permissions on earlier than doing so. It is because there are horrifyingly delicate variations between Linux distributions. Imagine me after I say that it’s price checking first.
identify: Exhausting reset permissions on sshd server file
file: proprietor=root group=root mode=0600 path=/and so forth/ssh/sshd_config
To test present file permissions I favor this natty little command for the job:
$ stat -c “%a %n” /and so forth/ssh/sshd_config
644 /and so forth/ssh/sshd_config
As our “stat” command exhibits our Ansible snippet can be an enchancment to the present permissions as a result of 0600 means solely the “root” consumer can learn and write to that file. Different customers or teams can’t even learn that file which is of profit as a result of if we’ve made any errors in securing SSH’s config they’ll’t be found as simply by less-privileged customers.
At a easy stage this file would possibly outline what number of customers must be on a regular server. Normally plenty of customers who’re admins have house directories with public keys copied into them. Nonetheless this file may additionally embody performing easy checks that the foundation consumer is the one system consumer with the omnipotent superuser UID zero; in case an attacker has altered consumer accounts on the system for instance.
Right here’s a file that may develop legs and arms. Usually I’d have an effect on between fifteen and twenty sysctl adjustments on an OS which I’m glad gained’t be disruptive to present and, all going effectively, any future makes use of of a system. These adjustments are once more at your discretion and, at my final depend (as there’s between 5 hundred and a thousand configurable kernel choices utilizing sysctl on a Debian/Ubuntu field) you would possibly decide to separate off these many adjustments up into completely different classes.
Such classes would possibly embody community stack tuning, stopping core dumps from filling up disk area, disabling IPv6 fully and so forth. Right here’s an Ansible instance of logging community packets that shouldn’t been routed out onto the Web, particularly these packets utilizing spoofed personal IP Addresses, known as “martians”.
identify: Maintain monitor of visitors that shouldn’t be routed onto the Web
lineinfile: dest=”/and so forth/sysctl.conf” line=”” state=current
– community: ‘web.ipv4.conf.default.log_martians = 1’
Pay shut consideration that you just most likely don’t need to use the file “/and so forth/sysctl.conf” however create a customized file beneath the listing “/and so forth/sysctl.d/” or comparable. Once more, test your OS’s choice, often within the feedback of the pertinent information. Should you’ve not seen martian packets being enabled earlier than then kind “dmesg” (typically solely because the “root” consumer) to view kernel messages and after per week or two of logging being in place you’ll most likely see some visitors polluting your logs. It’s a lot better to understand how attackers are probing your servers than not. A number of log entries for reference can solely be of worth. With regards to taking care of servers, ignorance is actually not bliss.
As talked about you would possibly need to embody hardening the community stack inside your kernel.yml file, relying on whether or not there’s many entries or not, or just for higher readability. To your community.yml file have a take into consideration stopping old-school broadcast assaults flooding your LAN and ICMP oddities from altering your routing as well as.
Normally I might cease or begin miscellaneous system companies (and probably functions) inside this Ansible file. If there weren’t many companies then fairly than additionally utilizing a “cron.yml” file particularly for “cron” hardening I’d embody these right here too.
There’s a bundle of adjustments you can also make round cron’s file permissions and so forth. Should you haven’t come throughout it, on some OSs, there’s a “cron.deny” file for instance which blacklists sure customers from accessing the “crontab” command. Moreover you even have a large number of cron directories beneath the “/and so forth” listing which want permissions enforced and improved, certainly together with the file “/and so forth/crontab” itself. As soon as once more test along with your OS’s present settings earlier than altering these or “unhealthy issues” ™ would possibly occur to your uptime.
When it comes to miscellaneous companies being purposefully stopped and sure companies, akin to system logging which is crucial to a wholesome and safe system, have a fast take a look at the Ansible beneath which I’d put in place for syslog for instance.
identify: Insist syslog is unquestionably put in (so we are able to obtain upstream logs)
apt: identify=rsyslog state=current
identify: Guarantee that syslog begins after a reboot
service: identify=rsyslog state=began enabled=sure
The venerable Netfilter which, from inside the Linux kernel gives the IPtables software program firewall the flexibility to filter community packets in an exceptionally subtle method, is a should for those who can allow it sensibly. Should you’re assured that every of your various flavours of servers (whether or not it’s a webserver, database server and so forth) can use the identical IPtables config then copy a file onto the filesystem through Ansible and ensure it’s at all times loaded up utilizing this YAML file.
Subsequent time, we’ll wrap up our take a look at particular system recommendations and speak a bit of extra about how the playbook is perhaps used.
Chris Binnie’s newest e book, Linux Server Safety: Hack and Defend, exhibits you the way to make your servers invisible and carry out a wide range of assaults. You will discover out extra about DevSecOps, containers and Linux safety on his web site: https://www.devsecops.cc