40 Linux Server Hardening Security Tips [2019 edition]

Securing your Linux server is important to protect your data, intellectual property, and time, from the hands of crackers (hackers). The system administrator is responsible for security of the Linux box. In this first part of a Linux server security series, I will provide 40 Linux server hardening tips for default installation of Linux system.

Linux Server Hardening Security Tips and Checklist

The following instructions assume that you are using CentOS/RHEL or Ubuntu/Debian based Linux distribution.

1. Encrypt Data Communication For Linux Server

All data transmitted over a network is open to monitoring. Encrypt transmitted data whenever possible with password or using keys / certificates.

  1. Use scp, ssh, rsync, or sftp for file transfer. You can also mount remote server file system or your own home directory using special sshfs and fuse tools.
  2. GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kind of public key directories.
  3. OpenVPN is a cost-effective, lightweight SSL VPN. Another option is to try out tinc that uses tunneling and encryption to create a secure private network between hosts on the Internet or private insecure LAN.
  4. Lighttpd SSL (Secure Server Layer) Https Configuration And Installation
  5. Apache SSL (Secure Server Layer) Https (mod_ssl) Configuration And Installation
  6. How to configure Nginx with free Let’s Encrypt SSL certificate on Debian or Ubuntu Linux

2. Avoid Using FTP, Telnet, And Rlogin / Rsh Services on Linux

Under most network configurations, user names, passwords, FTP / telnet / rsh commands and transferred files can be captured by anyone on the same network using a packet sniffer. The common solution to this problem is to use either OpenSSH , SFTP, or FTPS (FTP over SSL), which adds SSL or TLS encryption to FTP. Type the following yum command to delete NIS, rsh and other outdated service:
# yum erase xinetd ypserv tftp-server telnet-server rsh-server
If you are using a Debian/Ubuntu Linux based server, try apt-get command/apt command to remove insecure services:
$ sudo apt-get --purge remove xinetd nis yp-tools tftpd atftpd tftpd-hpa telnetd rsh-server rsh-redone-server

3. Minimize Software to Minimize Vulnerability in Linux

Do you really need all sort of web services installed? Avoid installing unnecessary software to avoid vulnerabilities in software. Use the RPM package manager such as yum or apt-get and/or dpkg to review all installed set of software packages on a system. Delete all unwanted packages.
# yum list installed
# yum list packageName
# yum remove packageName

OR
# dpkg --list
# dpkg --info packageName
# apt-get remove packageName

4. One Network Service Per System or VM Instance

Run different network services on separate servers or VM instance. This limits the number of other services that can be compromised. For example, if an attacker able to successfully exploit a software such as Apache flow, he or she will get an access to entire server including other services such as MySQL/MariaDB/PGSql, e-mail server and so on. See how to install Virtualization software for more info:

5. Keep Linux Kernel and Software Up to Date

Applying security patches is an important part of maintaining Linux server. Linux provides all necessary tools to keep your system updated, and also allows for easy upgrades between versions. All security update should be reviewed and applied as soon as possible. Again, use the RPM package manager such as yum and/or apt-get and/or dpkg to apply all security updates.
# yum update
OR
# apt-get update && apt-get upgrade
You can configure Red hat / CentOS / Fedora Linux to send yum package update notification via email. Another option is to apply all security updates via a cron job. Under Debian / Ubuntu Linux you can use apticron to send security notifications. It is also possible to configure unattended upgrades for your Debian/Ubuntu Linux server using apt-get command/apt command:
$ sudo apt-get install unattended-upgrades apt-listchanges bsd-mailx

6. Use Linux Security Extensions

Linux comes with various security patches which can be used to guard against misconfigured or compromised programs. If possible use SELinux and other Linux security extensions to enforce limitations on network and other programs. For example, SELinux provides a variety of security policies for Linux kernel.

7. SELinux

I strongly recommend using SELinux which provides a flexible Mandatory Access Control (MAC). Under standard Linux Discretionary Access Control (DAC), an application or process running as a user (UID or SUID) has the user’s permissions to objects such as files, sockets, and other processes. Running a MAC kernel protects the system from malicious or flawed applications that can damage or destroy the system. See the official Redhat documentation which explains SELinux configuration.

8. Linux User Accounts and Strong Password Policy

Use the useradd / usermod commands to create and maintain user accounts. Make sure you have a good and strong password policy. For example, a good password includes at least 8 characters long and mixture of alphabets, number, special character, upper & lower alphabets etc. Most important pick a password you can remember. Use tools such as “John the ripper” to find out weak users passwords on your server. Configure pam_cracklib.so to enforce the password policy.

9. Set Up Password Aging For Linux Users For Better Security

The chage command changes the number of days between password changes and the date of the last password change. This information is used by the system to determine when a user must change his/her password. The /etc/login.defs file defines the site-specific configuration for the shadow password suite including password aging configuration. To disable password aging, enter:
# chage -M 99999 userName
To get password expiration information, enter:
# chage -l userName
Finally, you can also edit the /etc/shadow file in the following fields:

{userName}:{password}:{lastpasswdchanged}:{Minimum_days}:{Maximum_days}:{Warn}:{Inactive}:{Expire}:

Where,

  1. Minimum_days: The minimum number of days required between password changes i.e. the number of days left before the user is allowed to change his/her password.
  2. Maximum_days: The maximum number of days the password is valid (after that user is forced to change his/her password).
  3. Warn : The number of days before password is to expire that user is warned that his/her password must be changed.
  4. Expire : Days since Jan 1, 1970 that account is disabled i.e. an absolute date specifying when the login may no longer be used.

I recommend chage command instead of editing the /etc/shadow file by hand:
# chage -M 60 -m 7 -W 7 userName
Recommend readings:

10. Restricting Use of Previous Passwords on Linux

You can prevent all users from using or reuse same old passwords under Linux. The pam_unix module parameter remember can be used to configure the number of previous passwords that cannot be reused.

11. Locking User Accounts After Login Failures

Under Linux you can use the faillog command to display faillog records or to set login failure limits. faillog formats the contents of the failure log from /var/log/faillog database / log file. It also can be used for maintains failure counters and limits.To see failed login attempts, enter:
faillog
To unlock an account after login failures, run:
faillog -r -u userName
Note you can use passwd command to lock and unlock accounts:
# lock Linux account
passwd -l userName
# unlock Linux account
passwd -u userName

12. How Do I Verify No Accounts Have Empty Passwords?

Type the following command
# awk -F: '($2 == "") {print}' /etc/shadow
Lock all empty password accounts:
# passwd -l accountName

13. Make Sure No Non-Root Accounts Have UID Set To 0

Only root account have UID 0 with full permissions to access the system. Type the following command to display all accounts with UID set to 0:
# awk -F: '($3 == "0") {print}' /etc/passwd
You should only see one line as follows:

root:x:0:0:root:/root:/bin/bash

If you see other lines, delete them or make sure other accounts are authorized by you to use UID 0.

14. Disable root Login

Never ever login as root user. You should use sudo to execute root level commands as and when required. sudo does greatly enhances the security of the system without sharing root password with other users and admins. sudo provides simple auditing and tracking features too.

15. Physical Server Security

You must protect Linux servers physical console access. Configure the BIOS and disable the booting from external devices such as DVDs / CDs / USB pen. Set BIOS and grub boot loader password to protect these settings. All production boxes must be locked in IDCs (Internet Data Centers) and all persons must pass some sort of security checks before accessing your server. See also:

16. Disable Unwanted Linux Services

Disable all unnecessary services and daemons (services that runs in the background). You need to remove all unwanted services from the system start-up. Type the following command to list all services which are started at boot time in run level # 3:
# chkconfig --list | grep '3:on'
To disable service, enter:
# service serviceName stop
# chkconfig serviceName off

A note about systemd based Linux distro and services

Modern Linux distros with systemd use the systemctl command for the same purpose.

Print a list of services that lists which runlevels each is configured on or off

# systemctl list-unit-files --type=service
# systemctl list-dependencies graphical.target

Turn off service at boot time

# systemctl disable service
# systemctl disable httpd.service

Start/stop/restart service

# systemctl disable service
# systemctl disable httpd.service

Get status of service

# systemctl status service
# systemctl status httpd.service

Viewing log messages

# journalctl
# journalctl -u network.service
# journalctl -u ssh.service
# journalctl -f
# journalctl -k

17. Find Listening Network Ports

Use the following command to list all open ports and associated programs:
netstat -tulpn
OR use the ss command as follows:
$ ss -tulpn
OR
nmap -sT -O localhost
nmap -sT -O server.example.com

18. Delete X Window Systems (X11)

X Window systems on server is not required. There is no reason to run X11 on your dedicated Linux based mail and Apache/Nginx web server. You can disable and remove X Windows to improve server security and performance. Edit /etc/inittab and set run level to 3. Finally, remove X Windows system, enter:
# yum groupremove "X Window System"
On CentOS 7/RHEL 7 server use the following commands:
# yum group remove "GNOME Desktop"
# yum group remove "KDE Plasma Workspaces"
# yum group remove "Server with GUI"
# yum group remove "MATE Desktop"

19. Configure Iptables and TCPWrappers based Firewall on Linux

Iptables is a user space application program that allows you to configure the firewall (Netfilter) provided by the Linux kernel. Use firewall to filter out traffic and allow only necessary traffic. Also use the TCPWrappers a host-based networking ACL system to filter network access to Internet. You can prevent many denial of service attacks with the help of Iptables:

20: Linux Kernel /etc/sysctl.conf Hardening

/etc/sysctl.conf file is used to configure kernel parameters at runtime. Linux reads and applies settings from /etc/sysctl.conf at boot time. Sample /etc/sysctl.conf:

# Turn on execshield
kernel.exec-shield=1
kernel.randomize_va_space=1
# Enable IP spoofing protection
net.ipv4.conf.all.rp_filter=1
# Disable IP source routing
net.ipv4.conf.all.accept_source_route=0
# Ignoring broadcasts request
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_messages=1
# Make sure spoofed packets get logged
net.ipv4.conf.all.log_martians = 1

21. Separate Disk Partitions For Linux System

Separation of the operating system files from user files may result into a better and secure system. Make sure the following filesystems are mounted on separate partitions:

  • /usr
  • /home
  • /var and /var/tmp
  • /tmp

Create separate partitions for Apache and FTP server roots. Edit /etc/fstab file and make sure you add the following configuration options:

  1. noexec – Do not set execution of any binaries on this partition (prevents execution of binaries but allows scripts).
  2. nodev – Do not allow character or special devices on this partition (prevents use of device files such as zero, sda etc).
  3. nosuid – Do not set SUID/SGID access on this partition (prevent the setuid bit).

Sample /etc/fstab entry to to limit user access on /dev/sda5 (ftp server root directory):

/dev/sda5  /ftpdata          ext3    defaults,nosuid,nodev,noexec 1 2

22. Disk Quotas

Make sure disk quota is enabled for all users. To implement disk quotas, use the following steps:

  1. Enable quotas per file system by modifying the /etc/fstab file.
  2. Remount the file system(s).
  3. Create the quota database files and generate the disk usage table.
  4. Assign quota policies.
  5. See implementing disk quotas tutorial for further details.

23. Turn Off IPv6 only if you are NOT using it on Linux

Internet Protocol version 6 (IPv6) provides a new Internet layer of the TCP/IP protocol suite that replaces Internet Protocol version 4 (IPv4) and provides many benefits. If you are NOT using IPv6 disable it:

24. Disable Unwanted SUID and SGID Binaries

All SUID/SGID bits enabled file can be misused when the SUID/SGID executable has a security problem or bug. All local or remote user can use such file. It is a good idea to find all such files. Use the find command as follows:
#See all set user id files:
find / -perm +4000
# See all group id files
find / -perm +2000
# Or combine both in a single command
find / \( -perm -4000 -o -perm -2000 \) -print
find / -path -prune -o -type f -perm +6000 -ls

You need to investigate each reported file. See reported file man page for further details.

25: World-Writable Files on Linux Server

Anyone can modify world-writable file resulting into a security issue. Use the following command to find all world writable and sticky bits set files:
find /dir -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
You need to investigate each reported file and either set correct user and group permission or remove it.

26. Noowner Files

Files not owned by any user or group can pose a security problem. Just find them with the following command which do not belong to a valid user and a valid group
find /dir -xdev \( -nouser -o -nogroup \) -print
You need to investigate each reported file and either assign it to an appropriate user and group or remove it.

27. Use A Centralized Authentication Service

Without a centralized authentication system, user auth data becomes inconsistent, which may lead into out-of-date credentials and forgotten accounts which should have been deleted in first place. A centralized authentication service allows you maintaining central control over Linux / UNIX account and authentication data. You can keep auth data synchronized between servers. Do not use the NIS service for centralized authentication. Use OpenLDAP for clients and servers.

28. Kerberos

Kerberos performs authentication as a trusted third party authentication service by using cryptographic shared secret under the assumption that packets traveling along the insecure network can be read, modified, and inserted. Kerberos builds on symmetric-key cryptography and requires a key distribution center. You can make remote login, remote copy, secure inter-system file copying and other high-risk tasks safer and more controllable using Kerberos. So, when users authenticate to network services using Kerberos, unauthorized users attempting to gather passwords by monitoring network traffic are effectively thwarted. See how to setup and use Kerberos.

29. Logging and Auditing

You need to configure logging and auditing to collect all hacking and cracking attempts. By default syslog stores data in /var/log/ directory. This is also useful to find out software misconfiguration which may open your system to various attacks. See the following logging related articles:

  1. Linux log file locations.
  2. How to send logs to a remote loghost.
  3. How do I rotate log files?.
  4. man pages syslogd, syslog.conf and logrotate.

30. Monitor Suspicious Log Messages With Logwatch / Logcheck

Read your logs using logwatch command (logcheck). These tools make your log reading life easier. You get detailed reporting on unusual items in syslog via email. A sample syslog report:

 ################### Logwatch 7.3 (03/24/06) ####################
        Processing Initiated: Fri Oct 30 04:02:03 2009
        Date Range Processed: yesterday
                              ( 2009-Oct-29 )
                              Period is day.
      Detail Level of Output: 0
              Type of Output: unformatted
           Logfiles for Host: www-52.nixcraft.net.in
  ##################################################################

 --------------------- Named Begin ------------------------

 **Unmatched Entries**
    general: info: zone XXXXXX.com/IN: Transfer started.: 3 Time(s)
    general: info: zone XXXXXX.com/IN: refresh: retry limit for master ttttttttttttttttttt#53 exceeded (source ::#0): 3 Time(s)
    general: info: zone XXXXXX.com/IN: Transfer started.: 4 Time(s)
    general: info: zone XXXXXX.com/IN: refresh: retry limit for master ttttttttttttttttttt#53 exceeded (source ::#0): 4 Time(s)

 ---------------------- Named End -------------------------

  --------------------- iptables firewall Begin ------------------------

 Logged 87 packets on interface eth0
   From 58.y.xxx.ww - 1 packet to tcp(8080)
   From 59.www.zzz.yyy - 1 packet to tcp(22)
   From 60.32.nnn.yyy - 2 packets to tcp(45633)
   From 222.xxx.ttt.zz - 5 packets to tcp(8000,8080,8800)

 ---------------------- iptables firewall End -------------------------

 --------------------- SSHD Begin ------------------------

 Users logging in through sshd:
    root:
       123.xxx.ttt.zzz: 6 times

 ---------------------- SSHD End -------------------------

 --------------------- Disk Space Begin ------------------------

 Filesystem            Size  Used Avail Use% Mounted on
 /dev/sda3             450G  185G  241G  44% /
 /dev/sda1              99M   35M   60M  37% /boot

 ---------------------- Disk Space End -------------------------

 ###################### Logwatch End #########################

See Common Linux log files names and usage for more info.

31. System Accounting with auditd

The auditd is provided for system auditing. It is responsible for writing audit records to the disk. During startup, the rules in /etc/audit.rules are read by this daemon. You can open /etc/audit.rules file and make changes such as setup audit file log location and other option. With auditd you can answers the following questions:

  1. System startup and shutdown events (reboot / halt).
  2. Date and time of the event.
  3. User respoisble for the event (such as trying to access /path/to/topsecret.dat file).
  4. Type of event (edit, access, delete, write, update file & commands).
  5. Success or failure of the event.
  6. Records events that Modify date and time.
  7. Find out who made changes to modify the system’s network settings.
  8. Record events that modify user/group information.
  9. See who made changes to a file etc.

See our quick tutorial which explains enabling and using the auditd service.

32. Secure OpenSSH Server

The SSH protocol is recommended for remote login and remote file transfer. However, ssh is open to many attacks. See how to secure OpenSSH server:

33. Install And Use Intrusion Detection System

A network intrusion detection system (NIDS) is an intrusion detection system that tries to detect malicious activity such as denial of service attacks, port scans or even attempts to crack into computers by monitoring network traffic.

It is a good practice to deploy any integrity checking software before system goes online in a production environment. If possible install AIDE software before the system is connected to any network. AIDE is a host-based intrusion detection system (HIDS) it can monitor and analyses the internals of a computing system. I recommended that you install and use rkhunter root kit detection software too.

34. Disable USB/firewire/thunderbolt devices

Type the following command to disable USB devices on Linux system:
# echo 'install usb-storage /bin/true' >> /etc/modprobe.d/disable-usb-storage.conf
You can use same method to disable firewire and thunderbolt modules:
# echo "blacklist firewire-core" >> /etc/modprobe.d/firewire.conf
# echo "blacklist thunderbolt" >> /etc/modprobe.d/thunderbolt.conf

Once done, users can not quickly copy sensitive data to USB devices or install malware/viruses or backdoor on your Linux based system.

35. Disable unused services

You can disable unused services using the service command/systemctl command:
$ sudo systemctl stop service
$ sudo systemctl disable service

For example, if you are not going to use Nginx service for some time disable it:
$ sudo systemctl stop nginx
$ sudo systemctl disable nginx

36. Use fail2ban/denyhost as IDS (Install an Intrusion Detection System)

Fail2ban or denyhost scans the log files for too many failed login attempts and blocks the IP address which is showing malicious signs. See how to install and use denyhost for Linux. One can install fail2ban easily:
$ sudo apt-get install fail2ban
OR
$ sudo yum install fail2ban
Edit the config file as per your needs:
$ sudo vi /etc/fail2ban/jail.conf
Restart the service:
$ sudo systemctl restart fail2ban.service

37. Secure Apache/PHP/Nginx server

Edit httpd.conf file and add the following:

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Options all -Indexes
Header always unset X-Powered-By

Restart the httpd/apache2 server on Linux, run:
$ sudo systemctl restart apache2.service
OR
$ sudo systemctl restart httpd.service
You must install and enable mod_security on RHEL/CentOS server. It is recommended that you edit php.ini and secure it too.

38. Protecting Files, Directories and Email

Linux offers excellent protections against unauthorized data access. File permissions and MAC prevent unauthorized access from accessing data. However, permissions set by the Linux are irrelevant if an attacker has physical access to a computer and can simply move the computer’s hard drive to another system to copy and analyze the sensitive data. You can easily protect files, and partitons under Linux using the following tools:

39. Backups

It cannot be stressed enough how important it is to make a backup of your Linux system. A proper offsite backup allows you to recover from cracked server i.e. an intrusion. The traditional UNIX backup programs are dump and restore are also recommended. You must set up encrypted backups to external storage such as NAS server or FreeNAS server or use cloud computing service such as AWS:

40. Other Recommendation and conlcusion

This page explained Linux server hardening security tips. Please see the following pages for more info:

🐧 If you liked this page, please support my work on Patreon or with a donation.
🐧 Get the latest tutorials on SysAdmin, Linux/Unix, Open Source & DevOps topics via:
CategoryList of Unix and Linux commands
File Managementcat
FirewallAlpine Awall CentOS 8 OpenSUSE RHEL 8 Ubuntu 16.04 Ubuntu 18.04 Ubuntu 20.04
Network Utilitiesdig host ip nmap
OpenVPNCentOS 7 CentOS 8 Debian 10 Debian 8/9 Ubuntu 18.04 Ubuntu 20.04
Package Managerapk apt
Processes Managementbg chroot cron disown fg jobs killall kill pidof pstree pwdx time
Searchinggrep whereis which
User Informationgroups id lastcomm last lid/libuser-lid logname members users whoami who w
WireGuard VPNAlpine CentOS 8 Debian 10 Firewall Ubuntu 20.04
150 comments… add one
  • Gini Aug 21, 2017 @ 3:35

    Well listed items,
    Thanks

  • david May 27, 2017 @ 6:55

    Thanks for all the good stuff you provide us !

    I noticed within the sentence “Read your logs using logwatch or logcheck” le link on logwatch keywork redirect to a 404 page. Do you have any updated link for that ?

  • LinuxHostSupport.com May 5, 2017 @ 16:23

    Another useful security measure is to protect SSH with two-factor authentication. You can use the Google authenticator. It can be easily installed and configured.

  • Vadhvi Apr 18, 2017 @ 22:57

    I love this awesome tutorial. thanks you!!! Can you update it for CentOS 7? Pretty please!!!

  • raju seth Mar 29, 2017 @ 19:47

    I am using to secure my CentOS 6 server. Very good guide.

  • Vadhvi Mar 29, 2017 @ 19:17

    Thanks great tips for my CentOS 6.8 server.

  • Smin Rana Nov 8, 2016 @ 6:17

    Great!

  • Ben Dover Sep 30, 2016 @ 17:36

    For the record,
    SSL = Secure Sockets Layer, not Secure Server Layer
    but you knew that.

  • IRE Jul 9, 2016 @ 12:22

    Will there be an updated one for CentOS 7.x and RHEL 7.x ?

    thanks

  • securityinfo Sep 9, 2015 @ 17:25

    #20 talks about TrueCrypt but that software is not supported anymore.

  • Pankaj Sep 5, 2015 @ 12:14

    Nice information sir

  • sudheer Apr 4, 2015 @ 17:26

    Thanks a lot for securing my server in simple steps

  • Mohammad Hossein Oct 9, 2014 @ 11:03

    Instead of number #2 try jailing it’s a more appropriate technique.

    • Mohammad Hossein Oct 9, 2014 @ 11:03

      * Number #3

  • Steve Sep 19, 2014 @ 22:13

    oh and #9: the MYTH that Chroot is insecure… is just that. a MYTH. the Chroot is only as secure as the system administrator defines it.

    there is a reason why it is built in as a core security feature and principal of SSH, Apache, Dovecot, Sendmail, Postfix, Bind, OpenVPN, and just about any other software that allows outside user interaction with internal system functionality. if you think that they have implemented faulty secure mechanisms in the base system of our linux operating systems… you are wrong.

    the rules are simple: do not run any services in chroot as Root. do not run any services inside the chroot which are running under the same user outside the chroot. if possible, seperate each service into its own chroot. use namespaces to virtualize /tmp and /var/tmp in order to inhibit race conditions. do not mount unessecary devices or filesystems. if you do mount a device or filesystem, ensure its permissions are set to “as restrictive as possible”. only include nessecary applications and libraries. find a way to keep these up to date. if you cant keep them up to date easily, then hardlink or bind mount them. audit all setuid/setguid bit applications. clean up dangling symlinks. use a minimal copy of /etc/passwd and /etc/group. and so on an so forth.

    why are these rules “simple”? because most of the are the same rules you should be enforcing on the BASE system. your BASE system security is just as important as your chroot security. chroot is NOT a replacement for an overall audit.

    chroot is still relevent in a wide range of use case scenarios. so do not be afraid to use it. the MYTH that you can easily break out of a chroot is also just that. a MYTH.

    security is only effective when used in LAYERS, and file system virtualization of any kind is a very essential layer to any security solution.

    YES, chroot was invented for a totally different purpose. but so was a whole wack of things in life. over time it has evolved to suit a plethora of different purposes, including for layering security. in fact, chroot led to namespaces, which led to virtualization. you can think of openvz as Chroot on steroids. this may be over simplifying it, but it does not effect my point.

    • Cody Sep 27, 2014 @ 13:12

      It isn’t that chroot is insecure per se. It is that it has risks (some of which depend on if the file systems are properly separated i.e., on different partitions, just like your point in regards to #6). And yes, you’re right: security is a layered concept (I would rather extend your point and suggest that without layers it isn’t security, at all). And yes, chroot has uses, many uses (e.g., building packages, analysis of something that is potentially risky, …, the latter which would be better in a VM like you refer to). But this question is all one needs to think about:

      Why is it that the chroot system call (see chroot(2) ) will give an unprivileged user the error EPERM (ie permission denied) ? Sort of like why is it that chown has similar restrictions. Of course, there’s more than one thing that can prevent chroot from working, but that’s not really relevant (if anything it makes the point more relevant, consider that a paradox if you want).

      FreeBSD’s jail syscall is stronger as is noted in the Linux man page for chroot.

      So it isn’t a myth any more than being logged in as root for anything beyond what absolutely must be done as root, is a bad idea. Don’t have time to read the rest (only by chance saw your response to #6) but you’re absolutely correct: technology evolves and that is a good thing indeed. Still, there is a reason chroot is restricted (just like chown).

  • Steve Sep 19, 2014 @ 21:53

    #1: the root vs sudo debate is entirely based on ignorance. the idea that “if the user is compromised, all they have to do is sudo” is simply wrong. the exact same thing applys to the root user, if they are compromised, yet minus the sudo. what sudo offers is the ability to resrict said user (with proper confuration), to specific subsets of functionality within the server. moreover, the administrative user should have a complex user name, along side a password. this means that the would-be attacker needs to brute force both a username, and a password. this decreases the likelyhood for success exponentially. finally, the sudo user should be combined with something like Two-Factor Authentication. this makes said user incredibly difficult to succumb to an attack.

    #2. remote logging is NOT for constantly monitoring. it IS something all distributed networks should employ. and it DOES serve a purpose. purpose number one is the forensic logging. in the event of an intrusion, this provides an off site server where log files have been untouched by any attacker. this may be the only way to figure out what has happenend to the system, and aids in identifying the security hole, repairing it, and preventing future intrusions by such means. this helps a security analyst decide whether or not the entire system has been compromised, or just part of it. and this leads me to number three

    #3 Intrusion Detection or Prevention Software is of CRITICAL importance. to claim that these things add to the “noise” is just an excuse, and lazyness, on the side of the system administrator. IDS software essentially takes the place of all those people who used to monitor forensic logging components. the idea is to create an automous system and security blanket that detects emerging threats, responds to events in real time, and alerts system administrators based on policy and threshold. combined with remote logging, this can be done with fairly low over head, and can be maintained with fairly low overhead. the ideal IDS is a combination of a generic firewall policy, file integrity checksum database software, brute force detection software, web and application firewall software, and automatic log file analysis software. this system should be able to manipulate the firewall to respond to immediate threats. and once this system is tuned for a specific use case scenario, it should be generate almost NO “noise” for the system administrator. in fact, it should lessen any noise generated by a constant barrage of botnets and rouge hosts (that which constantly probe any system).

    one must make note: fail2ban is NOT intrusion detection or prevention software. it may be used as part of the over all security CHAIN… but does not cover all the essential bases. furthermore, it’s used mostly as a set-it and forget-it tool. and in this state, is only useful for brute force attacks. nothing more. and only reacts against a small number of predefined patterns.

    #4 Firewall Rulesets are another CRITICAL component of any security audit. its inherently unethical for any system administrator to ignore this. after your system wide policy is defined, a generic rule set can be created to defend against generic attacks. this rule set should use split horizon like topology to ensure a back door is always available to the system administrator, and to ensure that server-to-server channels are only accessable to desirable system. a basic incoming connection ruleset helps protect against malicious malware from listening for connections in the user-space high port range. and each user should be restricted using the “owner” module available in linux, so that they are only allowed to connect out to a predefined set of servers, and on a predefined set of ports. another great feature is to ratelimit or set quotas for SYN packets going out per-user. all this helps deter malicious scripts from connecting back to a command and control center, from downloading counterparts to malware, and helps prevents the machine from participating in denial of service attacks.

    5#. Auditing the software on your distributed network is essential. we are after all depending on a open source network of programmers, and security is intended… but often times realized as an afterthought. its not all that difficult to purge packages not in use. anybody who thinks this is irrelevant negates the understanding of just how a compromise is usually acheived.

    where this becomes much more relevant however, is when you are activley running server software or services that have not been compiled with the latest kernel hardening features. i can guarantee that a large majority of production servers are running software without these features compiled in. settings kernel flags becomes a MOOT POINT if the software it self has not been compiled to USE THEM! this often means compiling and installing software from a more security wise, or up to date repository. sometimes it means recompiling the software on your own.

    6# its STILL important to have data on seperate partitions. however, current technology allows us to make this much easier. why define seperate partitons for everything when you can remount specific areas of your system with size allocation restrictions. again, choosing NOT to implement safe guards is just plain laziness. this is often accomplished with a one liner in your FStab

    7# encryption of files IS important. however, this is usually over-thought. typically, it would make the most sense to encrypt things like: back up partitions. off-site storage. physical back up devices. system administrator /home volumes. anything with SENSITIVE information. just because it is time consuming doesn’t mean you should void the process. again, please refrain from laziness. just re-think the process. there is no need to encrypt EVERYTHING, just the IMPORTANT things. moreover, automatic encryped file systems (using tools like encfs) makes this incredibly easy. there is NO excuse.

    #8 refrain from laziness. it will be your undoing.

Leave a Reply

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

Use HTML <pre>...</pre>, <code>...</code> and <kbd>...</kbd> for code samples.