Hardening Linux Systems

This will be part one , which uses the Tryhackme room harden , which covers:

• Securing user accounts
• Group permissions
• Firewalls
• iptable configuration

Securing User Accounts

Managing the users of any system is no small task. The principle of least privilege states that each user should only have enough access to perform their daily tasks. This means that an HR Admin should not have access to the system log files. However, this may mean that an IT Administrator does have access to the HR drive but not necessarily employee information. This section will focus on securing your user accounts through the smart configuration of sudo, using complex passwords, disabling root access and locking down home directories.

The root user is the highest user in a Linux system. They are able to do anything, including modifying system and boot files. Knowing that, you can see why logging in as root is probably not ideal in most situations. Often times on a server the root login is disabled, whilst setting all the "instances" of root that a regular user would need - the powers of root rather - for tasks that modify the system for all users. This is where sudo comes in, which is a tool that allows you to specify all the root powers for each user, and you can be incredibly specific - highlighting certain programs, who they can run the program as etc.

This means that there are only a few pockets of root privilege across the network of users, making it harder for attackers to utilise an actual account, and squeezing the number of opportunities.

Often times we will need to use sudo before we run an install command,

apt install some-package
;; this changes the system, and hence is considered an administrative task, do we have
;; the permissions to run apt install ? No. And a weak user is rejected.

sudo apt install some-package
;; first we will be asked for our password.
;; Then, with the OS looks in the /etc/sudoers file to see what rights we have. 
;; if we have the permissions of root, or at least to access all the binaries,
;; then we can execute this program within root space. Think of sudo like exerting a force
;; that pushes a program into root space during its execution, and then flows back
;; into our user space.

Creating a user

I'll be doing this in the Tryhackme attackbox where there is only a root account, so this is fitting for working within that machine safely (although many of the penetration testing tools used require root privilege). New Linux users often get confused at this stage as there is the adduser and useradd commands with allow us to do the same job really, so what's the difference ? Well, the former is a perl script which simplifies the functionality of the lower-level useradd utility.

There are also the addgroup, usermod (for modifying account settings - usually for permissions) deluser , delgroup tools.

Let's make a user called alex , to do so I'm going to use the adduser command, which is the preferred option if you don't have to make any instructions portable and if you can install the script on the system by all means use it over the useradd tool itself, though there isn't much difference for simple jobs.

Here we can see that the actual password itself is not present in the /etc/passwd table, meaning that it has been encrypted and stored in the /etc/shadow file ... much better. See, if we had done this with useradd we can supply a password with the program and this wouldn't have been moved away and encrypted off to /etc/shadow , as the passwd program is responsible for these tasks. The perl script makes use of all these binaries, among others for doing work on groups etc, meaning its automated , simpler and through one interface.

Now let's see the groups that alex is in.

groups alex
;; returns alex : alex
;; meaning the alex user is only part of the alex group, but if we did

usermod -aG sudo alex
;; then this modifies the alex account to *a*ppend the supplementary *G*roup sudo to it.
;; supplementary group just being one that won't remove others, in addition to.

The su command lets us switch user and I add the dash there to just give the full login shell, details of this argument are here.

Securing the Home directory of current and new users

With home directories already instantiated the owner of said directory , or root , can change it so that other groups cannot read, write or execute anything. By default the permissions for home directories are 755 which means the owner has full permissions, the group the owner is in also have read and write, whilst other outside users and groups also have read/write. This is terrible, as it means other people can make changes to our stuff!

What we need to do is change it to something like 700 where people don't have any permissions to view our home directory unless we give them the ability to turn it on ourselves at a later date. The file /etc/login.defs specifies the permissions for new home directories, scrolling down a bit we get this:

The mask basically sets the degree to which permissions are removed from each entity:

;; having a mask of 000 would mean that each entitiy has full powers, so masks that 
;; introduce some layering , and we subtract this value from the total permissions to
;; get the permissions for each group

;; 777 - 022 = 755 , meaning full power for the owner, read and write for all else.
;; what we really need is a mask of 077 as this would only give permissions to the owner
;; 777 - 077 = 700.

Remember this is just for new users, for existing users they will have to change their directory permissions directly - and hence without a mask etc - to 700.

alex@alex:~$ chmod 700 /home/alex