Linux Secure Server

Rootkit

Rootkit is a term for a software package that grants root access to your system for an attacker. They are the death of a Linux system, unlike a Windows server, there is not much you can do to solve the problem. It is always best to know when this has occurred so you can reinstall and restore the system. Because most rootkits are created by script-kiddies, sometimes knowing a specific rootkit exists will be sufficient to remove and repair. Google the rootkit to determine the best solution.

rkhunter is a great method for detecting rootkits, Trojans and changes required on the system to make it more secure. To obtain the package:

sudo apt-get install rkhunter

Just like an AV system, the package will have updates that will help detect signatures of rootkits, Trojans and security changes. To update the package:

sudo rkhunter--update

sudo rkhunter --check or -c

Forcing Password Aging

We have talked about this throughout our class, but an important security measure that should always be taken is to assure that our users have their password limitations. On most Linux and Unix distros, the chage command will help us enforce this for users.

To view a users’ configuration:

sudo chage -l username

To edit a user’s settings:

sudo chage -E (expiration date) -m (minimum password age) -M (maximum password age) -I (inactivity period days before expiration) -W (warning period before expiration) username

A little complicated in comparison to an AD policy. How could you make this easier as an admin?

PAM

Ubuntu, and most Linux ditros, use PAM modules to handle all authentication. As we modified the PAM configuration to change the authentication types used at login, we can also modify the requirements for authenticating. Basically, PAM allows us the ability to create a policy for logging in.

sudo apt-get install libpam-cracklib

The PAM module pam_cracklib will allow us to provide direct requirements for all authentication, creating our policy that dictates password complexity, aging, locking, etc. The configuration of the module is managed in the /etc/pam.d/common-password file. To add the module to authenticating:
sudo vim /etc/pam.d/common-password (or your choice of editors)

Update the pam_cracklib.so line to include complexity, let’s review:

password requisite pam_cracklib.so retry=3 minlen=10 difok=3 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1

    • Maximum of three attempts at getting an acceptable password

    • 10-character minimum length

    • Minimum of three characters different from the last password

    • Requirement that the password contain at least one

      • Digit

      • Lower-case character

      • Upper-case character

      • Other character

Despite setting the number of retries, some daemons must be configured individually to change this setting. SSHD is one of these daemons, to make this change we have to edit the /etc/ssh/sshd_config file and add the MaxAuthTries value:

MaxAuthTries 3

Then restart the daemon:

sudo service ssh restart

Locking Down Root

Root user is the one of the biggest holes in a Linux and Unix system. It is best to lockdown this user access as quickly as possible. First, a root user should not have access to remotely access a system, instead they should only be allowed to connect to the console. First we will remove access for the root user to SSH to the system. If you:

grep Root /etc/ssh/sshd_config

PermitRootLogin yes

# the setting of "PermitRootLogin without-password".

You can see that the root user is not locked down by default. Let’s change this setting by modifying the value to “no”:

sudo vi /etc/ssh/sshd_config

PermitRootLogin no

Next, it is also a good idea to, once users have sudo access, disable the root account:

sudo passwd -l root

CHROOT

Basically, the concept of a chroot is an application jail. The concept is to place the applications that need to be secured into a directory where they seem to be in the / directory, so they cannot traverse upwards and out.

The following are some possible uses of chroots:

  • Isolating insecure and unstable applications

  • Running 32-bit applications on 64-bit systems

  • Testing new packages before installing them on the production system

  • Running older versions of applications on more modern versions of Ubuntu

  • Building new packages, allowing careful control over the dependency packages which are installed

Closing Holes

Aside from our systems we run, our biggest holes are open ports that do not need to be open for our system to run. We know how to view the ports that are open on our system:

netstat -at

nestat -nat

We can view the ports that are open to decide what needs to stay open and what services we need to shutdown to secure our systems. Ports are generally open by services running, so when we decide what needs to be closed, we can shutdown the services and prevent them from starting.

In some distros, we can still use the chkconfig utility to shutdown services.

In Ubuntu, we can use the service command to manage services temporarily with upstart.

Check the services running:

sudo service –status-all

We know how to stop and start, even restart. What if we want to shutdown a service even after reboot with upstart?

sudo update-rc.d service stop sequence-num levels

For those services using upstart:

sudo sh –c “echo ‘manual’ > /etc/init/SERVICE_NAME.override”

or, if we have configured an XMing or XWindows connection, simply install the bum package and run that.

Upstart will be deprecated in the new release for the simplified Systemd package, using the systmectl command.

Mostly, back to our installs document, we can use sysv-rc-conf to visually manage services.