secure Linux Server using Hardening Best Practicies
Server Administration

Secure Linux Server Using Hardening Best Practices

In the previous post we talked about some Linux security tricks and as I said before, we can’t cover everything about Linux hardening in one post, but we are exploring some tricks to secure Linux server or you can say some basic server security so we can make secure Linux systems; instead of searching for ready Linux hardening scripts to do the job without understanding what’s going on, However, the checklist is so long so let’s get started.


Disable Ctrl-Alt-Delete

This is important if you don’t have the best physical security to your server.

If you are using Systems prior to CentOS 7 all you have to do is to comment out the following line in /etc/inittab  file.

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Otherwise, if you are using CentOS 7 use the following command:

$ ln -s /dev/null /etc/systemd/system/

Secure Linux Mounting

Each of your file systems is mounted to allow you to access the data stored on your system. You can mount your file systems using different options.

These options allow you to lock down the capabilities and functionality of each of your file systems. These options are controlled by the /etc/fstab  file.

LABEL=/      /       ext4     defaults       1 1

The first column is the name or label of the file system to be mounted such as / for the root volume.

The second column is the directory or location on your system where you want to mount the file system.

The third column is the type of file system like ext4.

The fourth column contains the major options you will be using to secure your file systems.

The fifth and sixth columns control the options for the dump and fsck commands.

There are many different ways to control how file systems are mounted and the following list shows some of them:

auto                       File system will be mounted automatically at boot time.

noauto                   File system will not be mounted automatically at boot time.

exec                       Execution of binaries is allowed on this file system.

noexec                  Execution of binaries is NOT allowed on this file system.

suid                       setuid bits are allowed to take effect on this file system.

nosuid                  setuid bits are not allowed to take effect on this file system.

user                       Normal users can mount this device.

nouser                  Only root users can mount this device.

owner                   Allows the owner of the device to mount the file system.

ro                           File system will be mounted read-only.

rw                          File system will be mounted read-write.

defaults               Sets this file system’s options as rw, suid, dev, exec, auto, nouser, and async.

The exec and noexec options allow you to control whether binary execution is allowed or not.

Be careful setting this option on some file systems such as /boot or / will prevent your system from booting. Since /boot must be executable to boot the system.

You can mount /home securely with noexec like this:

/dev/hda1     /home       ext4      noexec      0 2

Keep in mind that this line will prevent the execution of binaries on /home, so if you have any executables, you should take care of that.

You can mount /tmp with noexec option as a step of hardening, but keep in mind that some programs might not work properly because they use /tmp to execute. So you can test your software with this mount option, if it goes well then it’s OK.

The suid and nosuid options control the functioning of binaries with the setuid or setgid bits set on your file systems. Binaries with the nosuid option, their setuid and setgid bits will be ignored.

The user, nouser, and owner options provide control over who is allowed to mount your file systems. Only root users can mount file systems. If you have file systems with the user option specified, then any user can mount or unmount file systems.

It is recommended that you never allow non-root users to mount your file systems.

The ro and rw, read-only and read-write allow you to control whether your users and applications can write to the specific file system.

You can mount any file system as read-only like this:

/dev/hda2         /usr        ext4       ro,nodev        0 2

You can mount /boot as read-only using the same way, but keep in mind that in case of any kernel update, you have to remount it as rw to apply the update like this:

$ mount -o remount,rw /boot

You know mount options and you should be wise enough to take the decision about which directory needs which option to mount with.

Protect /etc/services File

The /etc/services file enables server and client programs to convert service names to these port numbers.

Only the “root” user is allowed to make modifications to this file. It is rare to edit the /etc/services file since it already contains the more common service names.

To improve security, we can set the immutable flag on this file to prevent unauthorized deletion or modification.

Also, that prevents accidental deleting or overwriting of such a vital file.

$ chattr +i /etc/services

Remove Unused Accounts

These vendor accounts are preinstalled on your system for some Linux system activity.

If you don’t need those accounts, it’s preferred to remove them using userdel command, and those are some of the unused users for me, your system you should know what are unnecessary users for you and remove them.

Also, you will need to remove the groups belongs to those accounts if exist using groupdel command

If you check /et/passwd  file you’ll see that the users are deleted.

If you run your own server or VPS you can set the immutable bit on /etc/passwd and /etc/shadow to prevent any unwanted changes.

If you are about adding new users to the system or installing a program that will add users, consider removing the immutable flag first.

Hardening Cron Scripts

Some scripts under /etc/cron.d have the secured permissions other not.

Consider fixing the permission for the scripts that are responsible for executing scheduled job on our server so only root can read it.

$ chmod 0700 /etc/cron.daily/*

Normal users don’t need to look at those scripts.

Keep in mind that if you update a program that provides a cron file on your system, consider updating the permission, or you can make a shell script that does the job for you instead.

And the same for the other cron directories like:

Securing SUID Programs

SUID (Set owner User ID) is a special type of file permissions given to a file. When you want to some tool like passwd command which writes on files belongs to root /etc/passwd and /etc/shadow the passwd command must have this SUID permission to enable normal users to use that command.

You may take a look at all programs that have this permission and consider removing that permission from unnecessary programs that you think that normal users won’t need it.

All these programs have SUID bit and normal users can run them as root. To remove that permission you can use this command:

$ chmod a-s /bin/mount

Keep in mind that some programs need that permission to work so be careful when doing that.

Risky World-Writable Files and Directories

World-writable directories and files can lead to serious problems if the attacker gains access to them.

He will be allowed to modify or delete any file and this is a serious problem.

To get all writable files on your system use that command:

Or maybe you want to get writable files only in the web folders like public_html:

To get world writable directories on the whole system, use the following command:

And the same for web folders:

You may find writable directories and files in some locations like /var/mail which have no problem but on web folders, you have to be careful about that much.

You can use some integrity check tool like tripwire as we’ve discussed that tool in the previous post.

That tool will scan your system for any world writable files and directors and warn you, so you can take action about them.

Risky Symlinks

Symlinks or symbolic links as we discussed before in a previous post basic Linux commands are useful if they used for a good purpose to simplify your work, but the attacker in some cases uses any scripting language on your server to build a symlink to travel between directories and see your files, steal passwords and gain access to all of your assets, so it’s very important to keep any eye on that.

The following command searches for any symlink and deletes it.

$ find -L /home/*/public_html -type l delete

You can change the path based on your server paths, you may also create a shell script to find those symlinks and send to your email so you can investigate how it was created.

I recommend you to review my posts about writing shell scripts.

There are many ways to stop symlink creation, if you are using PHP you can disable some serious functions, and apply Symlinks only if owner matches for your server if you are using apache.

This trick is very useful, especially when dealing with compromised systems.

There is a lot to talk about securing PHP; maybe we should make another post about that but let’s keep simple for now.

Securing Log Files

Your last line of defense is the log files. They are important as your files themselves. Log files for each running service tell you everything about that service, so you can keep track of everything happened on your system.

In the worst scenarios (like gaining root access), the attacker might delete those log files and left you without any evidence of what had happened.

Consider copying your log files to a different place or schedule a regular backup of log files to somewhere else that shouldn’t be accessible to the attacker if he gains access to your system.

Securing Linux Resources

Securing Linux Resources is a must because users can jeopardize the stability of your server if they left to use server resources without limits.

You can allocate how much memory for each user, how many processes and other server resources.

Under /etc/security there is a file called limits.conf, in that file you can specify the limits for your users like this:

The first line says for all users limit the memory usage to 500 MB.

The second line says for all users limit the number of processes to 50 processes.

All these restriction rules applied to all users expect root user.

The asterisk on both lines means all users, and some systems have users running services like www or mysql users and those service users are used by all users on the system and if we apply our restriction rules for them too, that can lead to problems.

A good solution for this problem is to add a special group and add our users to that group and apply our restriction rules to that group.

In this case, the rules will be applied for every user in this group and not to the whole users of the group.

Hardening /proc Directory

The /proc directory or as they call it (process information pseudo-file system) contains a lot of information about the currently running processes. Linux is installed by default to allow normal users to see that information. You can see what processes belong to root and what he is running and the process ID PID of each one and all other user’s processes.

Before you use this trick, you can see that normal user can see all processes even root processes.

Secure Linux Server ps -ef

The hidepid mount option allows you to hide process IDs. It takes a value of 0,1,2.

$ mount -o remount,rw,hidepid=2 /proc

And you can write it to /etc/fstab  to make it permanent so after reboot, the process IDs remains hidden.

proc    /proc    proc    defaults,hidepid=2     0 0

proc directory Hardening Best Practices

After that command, you are only allowed to see your processes. Only root users can see all processes for all users.

$ ps -ef

Secure Linux Server ps -ef

Another mount option is gid which allows users in a specific group to see /proc directory.

If the group you want to assign the permission to has ID of 100 so you can write it like this:

$ mount -o remount,rw,gid=100 /proc

Also, you can write it in /etc/fstab file

proc    /proc    proc    defaults,gid=100     0     0

The last advice for you is to keep your system and software updated always, that will protect you from many threats.

I hope you find these hardening best practices useful. Hope you can secure your Linux server and harden your system security to protect your assets and make your life easier.

Thank you.