Home >> System Security >> Hardening OS security Linux/Unix

– As you know OS security encompasses many different techniques and methods which ensure safety from threats and attacker. OS security allows different applications and programs to perform required tasks and stop unauthorized interference.
– OS have two main vendor Linux and Window, and the guideline to fix each OS is defferent, so in this tutorial i just forcus to Linux/Unix OS, The guideline Security Linux/Unix have 9 part as below:


1. Update System Security Patches

– Risk: Installing vulnerable kernel of linux, that means we put system at risk. Exploiting known vulnerabilities, attackers can perform privilege escalation attack to gain admintrative access.
– Solution: Verify Linux kernel version, using uname –r command. For each kernel major version, the minor and patchlevel version must be greater than following versions:,,, 3.0.44, 3.2.30.
Linux version includes three numbers, each separated by a dot, the naming schema as follows:
Linux-major.minor.patchlevel: Linux kernel used odd minor version numbers to denote development releases and even minor version numbers to denote stable releases
For example: linux-3.10.5:
– The major version: 3
– The minor version: 10 (stable release)
– The patchlevel version: 5
– Upgrade linux kernel with internet connection:
+ Redhat/Fedora/CentOS:

+ Debian/Ubuntu:

– Upgrade linux kernel with no internet connection:

Upgrading from a package provided by current distribution.
o Step 1: Set up a new virtual machine installed the same kernel version with system which has to be upgraded. The virtual machine must be able to access the internet.
o Step 2: Using virtual machine you just set up to download all rpm packages for upgrading.
– On Redhat/Fedora/CentOS: Run the following commands:

Transfer all rpm packages in /opt/upgrade directory from virtual machine to system. And then install them using rpm command with option -ivh instead of -Uvh.
Reboot system for the changes to take effect.
 On Debian/Ubuntu: Run the following commands:

Transfer all deb packages in /opt/upgrade directoty from virtual machine to system. Install all packages using dbpg –i [package] command.
Reboot system to take effect.

2. Establish User Accounts and Strong Password Policy

2.1 Remove all unnecessary accounts

– Risk: Attacker can use unnecessary account to attack to your system.
– Solution: Review and list all active accounts. Remove all unnecessary account.
Step 1: To list all active accounts on your system, run:

Step 2: To remove specific account, run:

2.2 Verify no account has empty passwords

– Risk: Attacker can access system without entering password.
– Solution: List all accounts which have no password or password set to blank and set new password for these accounts:
To list all accounts for empty passwords, run:

2.3 Verify no non-root accounts have UID set to 0

– Risk: If an account has UID set to 0, the account has full permissions to access the system.
– Solution: Make sure only root account has UID set to. If there is any other account has UID set to 0, your system may be already compromised.
To list all accounts with UID set to 0, run:

2.4 Password must include at least 8 characters long and mixture of alphabets, number and special character

– Risk: Short or simple password could be recovered.
– Solution: Establish strong password policy for all user accounts. Password must include at least 8 characters long and mixture of alphabets, number and special character.
Using PAM module to establish strong password policy.
– On Redhat/Fedora/CentOS, open /etc/pam.d/system-auth file
– On Debian/Ubuntu/OpenSuse, open /etc/pam.d/common-password file
Add or edit password section as following:
– For pam_cracklib module:

– For pam_passwdqc module:
password requisite pam_passwdqc.so min=disabled,disabled,disable,disable,8 If module pam_cracklib or pam_passwdqc not installed, install them:
+ On Debian/Ubuntu, run:

+ On OpenSuse, run:

+ On Fedora/Redhat, run:

2.5. Password must be hashed with SHA-512

– Risk: Account password is hashed and stored in /etc/shadow file. If password is hashed by weak algorithms like md5, sha-128 or sha-256, it may be recovered by attaker.
– Solution: Using SHA-512 algorithm to hash account password. This can be achieved by following steps:
Step 1: Open /etc/pam.d/system-auth file (Redhat/Fedora/CentOS) or /etc/pam.d/common-password (Debian/Ubuntu/OpenSuse), in password section, replace old hash algorithms by sha-512 as following:
password sufficient pam_unix sha512 shadow [other options]
Step 2: Open /etc/login.defs file, edit or add:

Step 3: open /etc/libuser.conf file, edit or add:

Step 4: Force user to change password to take effect.

2.6. Password must expire after 90 days

– Risk: Password is used for a long time could be recovered.
– Solution: User password must expire after 90 days.
Open /etc/login.defs file, edit PASS_MAX_DAYS option as following:

To change password aging for specific existing account, run following command:

Administrator can use command above to manually change password aging for service accounts.

2.7. Prevent re-use of each user’s last 5 password.

– Risk: Like using password for a long time, reusing password could lead to potential security issues.
– Solution: Prevent user from reusing at least last 5 passwords.
This can be achieved by using pam_unix.so module as following:

Open /etc/pam.d/system-auth file (Redhat/Fedora/CentOS) or /etc/pam.d/common-password (Debian/Ubuntu/OpenSuse), edit or add option remember in password section:

3. Manage and configure system log

3.1. System log configuration

– Risk: If system log is not configured to record all sensitive actions. It may prevent administrator from auditing and troubleshooting.
– Solution:
o Message log, dmesg log, secure log: must be configured properly
o Log files must be stored for at least 3 months

Step 1: Open and edit /etc/rsyslog.conf file as following:

Step 2: Configure log rotation as following:

Step 3:
+ For Ubuntu/Debian: Open and edit /etc/logrotate.d/rsyslog file as following:

+ For CentOS/Redhat: Open and edit /etc/logrotate.d/syslog file as following:

Step 4: Restart log service to take effect.

3.2. Log files must be owned by root user

– Risk: After a compromise, attacker may modify or delete log files to prevent system admintrator from investigating.
– Solution: Make sure that only root user/group can modify log files.
Assume all system log files are stored in /var/log directory:
Step 1:

Step 2:

4. Configure and use soft firewall

4.1. Make sure that firewal is always turned on

– Risk: Unauthorized connection from internet or other network can access to compromise your systen.
– Solution: Using soft firewall to establish a multi-level defense against unauthorized access.
Check if iptables is running:
• On Redhat/Fedora/CentOS:

• On Debian/Ubuntu:

• On OpenSuse:

To configure iptables to start at boot:
• On Redhat/Fedora/CentOS:

• On Debian/Ubuntu:

• On OpenSuse:

4.2. Firewall must be configured to allow only necessary network connections.

– Risk: System may allow unauthorized or malicious connection.
– Solution: List all running services and their connnection to establish rules for firewall. Firewall must be configured to allow only required network connections.

4.3. Log all invalid network traffic

– Risk: If firewall is not configured to log invalid and malicious traffics, administrator won’t be able to detect attack.
– Solution: Configure firewall to log all important action, invalid or malicious traffics for auditting, troubleshooting and detecting attacks.

5. Remove all unnecessary softwares and services

– Risk: Installing unnessessary services may also installs additional security flaws. Attacks can exploit vulnerabilities which come from these services to attack system.
– Solution:
o Only install what is needed
o List all active services and verify no unnecessary service installed on system.
To list all installed service on system, run following commands:
On Debian/Ubuntu:

On Redhat/Fedora/CentOS/OpenSuse:

The following services need to removed:

6. Remote Admintration Services

– Risk: Username, password or other sensitive data tranfered over network can be captured by anyone on the same network using a packet sniffer.
– Solution: Prevent administrator from using protocol that use plain text, not encrypted format like telnet, rlogin, etc. Only use SSH, a secure protocol that encrypt data during communication with server.
Open the SSH configuration file (/etc/ssh/sshd_config) and edit following options:
 Use SSH Protocol 2 Version

 Only allow specific users

 Session timeout for client

 Disable Root login

7. File and directory permission

7.1. The PATH environment variable

– Risk: Unauthorized changes to the PATH environment variable can enable a user on the system to spoof other users including root users. Spoofing programs replace system commands and then capture information meant for that command, such as user passwords..
– Solution: Verify that environment variable $PATH does not contain relative directories (. / ..), the root directory (/), empty strings or references to unknown files.
Run following command to view value of PATH enviroment variable:

7.2. Umask must be set to 022 for normal users and 077 for root user.

– Risk: Umask is use to determine the file permission for newly created files. So that it’s necessary to set umask properly.
– Solution: Umask must be set to 022 for normal users and 077 for root user.
Step 1: Open configuration files: /etc/profile, /etc/bashrc, /etc/csh.cshrc edit or add entry below:
umask 022
Step 2: Open /etc/login.defs file, add or edit:

Step 3: Verify that umask of /etc/csh.login and files in /etc/profile.d is set to 022
Step 4: Open /root/.bashrc, /root/.bash_profile, /root/.cshrcvà /root/.tcshrc file, edit or add:

Note: Add umask entry at the end of files.

7.3. Verify no unkown SUID or SGID files

– Risk: Attacker can find file which is set with SUID or SGID and then execute file with owner’s permissions.
– Solution: Remove the SUID/SGID bits from any programs that do not need the elevated privileges.
To list all SUID and SGID files, run command bellow :

To remove SUID/SGID bits from file, run command:

Note: List of exceptions of SUID/SGID files:

7.4. Verify no unowner files

– Risk: Unowner file may also be an indication an intruder has accessed your system.
– Solution: Locate and then remove files on system that have no owner or belong to no group.
To find all unowner files:

8. Synchronize system time

– Risk: If system time is not synchronized, it may be not accurate for logging, auditing, etc.
– Solution: Synchronize system time with NTP server.
Step 1: Download and install ntl package.

configure ntp start at boot.

Open and edit /etc/ntp.conf file as following:

Edit firewall rules to allow NTP client:

Restart firewall service and start ntp:

Verify ntp is running:

9. Configure cron tasks

– Risk: The cron daemon is used to schedule processes. So make sure that it is not used to execute backdoors.
– Solution:
o Control allowed users who can use cron daemon
o Only root user may edit cron configuration file
Step 1: Remove cron.deny file:

Step 2: Add /etc/cron.allow file:

Step 3: Edit /etc/cron.allow file. Verify accounts can use cron daemon:

Step 4: Configure access permission for CRON configuration files:

Next part i will introduce how to config iptables to protect your server.


10.1. For common distrobutions of Linux:

Use 02 commands:

– “iptables-save”: save rule set out-to text file with specific format.
– “iptables-restore”: load text file into iptables rule set.

– Add firewall rules quickly
– The new rules will be applied without any error.

Note: /etc/iptables-save is the file which is storing iptables commands, and we can use another name.

All rules in /etc/iptables-save file will be loaded and apply into iptables rule set.
Examine iptables-save file:
For example, the iptables-save file has content:
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.

– “*filter”: the sign of the beginning of the rule(s) of filter table – the table uses for filtering packets
o INPUT: is a chain of iptables, table filter has 03 chains, include INPUT, OUTPUT, and FORWARD. INPUT includes packets sent to server, OUTPUT consists of packets go out from server, and FORWARD covers packets from one interface to other interface.
o ACCEPT: Chain policy of INPUT, OUTPUT and FORWARD change. The meaning: If packet doesnot match any rule of iptables, it will be accepted.
o [0:0]: The first number shows the number of packets, the second show the size of packets. These are the statistic number of non-matching rule packets and these packets were accepted.
– The next lines: the filter rules, apply from up to down.
– COMMIT: end of filter table.
To edit iptables rule(s):
Make /etc/iptables file as follow:

Configure iptables to automatically load rule file at boot time:
Open /etc/rc.local file

To stop all rules to troubleshoot:
Use following commands:

– The first command to delete all rules in all chains of iptables
– The second to remove all user chains.
– The next three commands set chain policy for INPUT, OUTPUT, and FORWARD chain are ACCEPT. And server allow all in/out connections.

10.2. For distrobutions with deamon iptables (as Redhat)

In Redhat such as Centos, Redhat, Fedora, and Oracle enterprise Linux support init script and config file for running iptables.
Use iptables by using init script (/etc/init.d/iptables):
“/etc/init.d/iptables save”: save rule set in /etc/sysconfig/iptables file.
“/etc/init.d/iptables stop”: flush (remote) all rules, chains which are made by users
“/etc/init.d/iptables start”: load rules from /etc/sysconfig/iptables.
“/etc/init.d/iptables restart”: restart iptables service
To run “#/etc/init.d/iptables start” command at boot time:

Then iptables will automatically load rules from /etc/sysconfig/iptables
Config file /etc/sysconfig/iptables-conf with some parameters:
– The parameters for loading modules of iptables
o IPTABLES_MODULES: list all modules which will be loaded when start iptables.
o IPTABLES_MODULES_UNLOAD=”yes”: reload all modules after iptables stop or restart. The default value is Yes.
– The parameters for saving rules
o IPTABLES_SAVE_ON_STOP=”no”: save current rule set or not when iptables stop. The default is No.
o IPTABLES_SAVE_ON_RESTART=”no”: save current rule set or not when iptables restart. The default is No.
– Because all iptables rules are stored in /etc/sysconfig/iptables in default, we can alter rule in this file and restart iptables to apply new rule(s).

the author

One Comment

  1. Marylou91 says:

    I see your page is in the same niche like my site. Do you allow
    guest posting? I can write high quality & unique content for you.
    Let me know if you are interested.

Leave a Reply

Your email address will not be published. Required fields are marked *