Published: February 27th 2017
Another one of those items you suddenly think "I should maybe document what I do..." A quick run-down of several of the items that I do when setting up a new system of my own that are maybe useful for helping to secure your own systems if you're slinging them on the Internet or a work-based network.
I'm assuming Debian-based systems here in my instructions, so all paths and installation methods are based on that distribution but the methods are similar for other linux distributions. I'd also welcome input from my buddies in the security industry who attack surfaces like this with digital hammers. If you know caveats or better ways please get in touch.
A warning before you begin the process - some of the configuration options here can lock you out of systems if you incorrectly key values or only part-configure systems. Make sure you have a decent connection to your box and tick off each of the steps, understanding what they do first!
Locking out repeated failures
If you're allowing SSH access to your system, Fail2Ban is a must-have. It automatically locks out access to your system if it sees repeated attempts to brute-force accounts with the wrong password.
For the average user - that's pretty much it configured now!
You can modify the settings in /etc/fail2ban/jail.conf if you wish to change the maximum retries, lock-out period and recipient of the mail reports. If you modify these remember to restart services. I'm skipping over this one as the default configuration is well generated nowadays.
Privilege escalation detection
Most security breaches revolve around privilege escalation and the program ninja
is a good way of automatically detecting these.
There is a little bit of setup to create the groups and settings once you've installed the program. Remember to note down the GID of the ninja group when you create it as you'll need that later on...
usermod -a -G ninja root
usermod -a -G ninja yourUserName
Make sure the log file is generated that can be used and only accessed by your root and ninja users:
sudo chmod o-rwx -R /etc/ninja/
sudo chmod o-rwx /var/log/ninja.log
Modify your configuration to set the group ID to the ninja group:
Restart ninja and you will now be provided with an additional access protection layer. You will have to add any user that requires sudo access to the ninja group otherwise they will not be allowed to elevate privileges.
If someone is going to smash into your system it's going to take time ( you hope ) and they're going to want a backdoor to go back and forth more easily. A rootkit is a malicious program or series of programs that sit on your machine and make it operate in ways that it isn't meant to potentially masking what it's doing at the same time. Quite often you find that programs have been modified to leak passwords or credentials or generally do things you don't want.
A good program to monitor changes to your system is rkhunter which can be set up to mail you daily logs of system checks.
To install and update the definitions:
Add in the command to run a daily system check and mail the report, changing the value of the username to the account you want to receive mail in, or alternatively if you have smtp running the email address of the recipient:
/usr/bin/rkhunter -c --cronjob 2>&1 | mail -s "Rootkit Scan Details" myusername < /var/log/rkhunter.log
This fires up your rkhunter system with a system scan in non-interactive mode ( so it does not wait for the usual "press return to continue" messages ) and pipes the output to the mail application to send your report output. Obviously, it's best to off-box your reports rather than keep reports on a potentially compromised system.
Don't forget you will need to add execution permission to the shell script:
Another key ingredient is having an idea of update path. This is often a tricky one depending on how critically you are locked to specific versions of software. If you're free to grab the latest security fixes on a stable branch you can configure automatic updates thus:
Add in the unattended package system:
The default configuration file is usually exactly what you need, but as said, if you want to tailor packages that can upgrade or are not allowed to, you can modify the /etc/apt/apt.conf.d/50unattended-upgrades file to meet your requirements. You can specify who receives notifications of the software updates in this file.
Now you need to configure the automatic updates option:
Now enter update settings:
// Do "apt-get update" every x number of days ( 0 = disable )
// Do "apt-get upgrade --download-only" every x number of days ( 0 = disable )
// Run "unattended-upgrade" security upgrade script every x number of days ( 0 = disable )
// Do "apt-get autoclean" every x number of days ( 0 = disable )
This configuration will allow daily automatic updates for you.
Security keeps moving
As with all things, securing systems isn't just a static activity that's undertaken once - It's wise to have something analysing logs on your network to pick up on trends or linked activity. The steps I've outlined are just some of those I have on my "new system checklist" pad. I'm sure if I got into it further I'd find more things I regularly undertake...
Proton Pack Build
OpenVPN Quick Setup