Security Toolbox

Hardening Linux for Production Use

© Nikolay Okhitin, Fotolia.com

© Nikolay Okhitin, Fotolia.com

Author(s):

To protect your production server from attacks, employ these common security tools to help safeguard your system.

Special Thanks: This article was made possible by support from Linux Professional Institute

A standard server or minimal install (CentOS) provides you with a secure server system, but its production usefulness is very limited. To make a server production ready, you’ll have to install software such as web services, DNS, DHCP, Samba/CIFS, print services, and databases. Because these services communicate over the network, security vulnerabilities are an inevitability. Exposing any service provides an attack vector. However, there are actions you can take to protect your systems and your data from attacks.

There are too many utilities available, both free and commercial, to help secure your systems. This article provides you a brief overview of the most common methods and utilities to help you maintain system security. Please remember that security is a best effort and that no system is 100 percent secure, but using these hardening suggestions will make it more difficult for malicious actors to compromise your systems.

Low-Hanging Fruit

At a minimum, you must prevent easy hacks on your system by updating it as soon as it comes online and then at least weekly thereafter. Developers release security and performance updates daily. Systems must be kept up to date, or they are vulnerable to attack. The other minimum barrier to attack is to enforce complex passwords. Don’t allow users to use simple, dictionary passwords on systems. Additionally, users should be forced to change passwords every 90 days and prevented from reusing the same password.

You can also minimize local (insider) hacks by logging off when you leave your system unattended. This rule applies to servers, workstations, and SSH sessions alike. This simple act will prevent any malicious user passing by your unlocked computer from stealing root access.

Don’t minimize the obvious protections such as regular backups and physical security. Performing backups is a security method that many administrators overlook. Destructive malware that might change critical files can be easily restored from a backup to their former states. Limiting physical access to systems is a good deterrent for those who want to steal directly from a system with a USB drive or who want to see if an administrator has remained logged in to a console. Only administrators need access to areas where servers are housed.

Multifactor Authentication

Multifactor authentication (MFA) is the best line of defense against password cracking by guessing, brute force, or dictionary attacks. Adding a second factor to logins is a very strong deterrent for account hacks. However, MFA isn’t 100 percent foolproof as some hackers have devised ways to phish your MFA tokens. Before logging in, you should always be aware of where you are entering your passwords and any codes or tokens for additional factors. MFA deters most low-level hackers. Professional hackers and advanced persistent threat (APT) groups will resort to phishing and other social engineering methods to acquire a token, code, or one-time password (OTP) from you.

The answer to these so-called soft tokens and their vulnerabilities is hardware tokens, such as YubiKeys, which are USB-based hardware tokens that require fingerprint verification as the second factor. These hardware tokens require something that you are (fingerprint) rather than something you know (password, passphrase, or picture recognition) or even something that you have (a hardware token that generates random numbers).

Pruning Unused Services

When it comes to system services, less is more – meaning that you should run as few system services as possible while still maintaining a productive environment for yourself and your users. I’ve always used the “one service per server” rule. Virtual machines make this practice a lot more economical than purchasing one physical system per service. One system per service is a good idea, because, if your Samba/CIFS server is compromised through some exploited vulnerability, your other servers that are not running Samba/CIFS will be protected – that is if you’ve implemented MFA.

You can begin with a minimal CentOS installation, which provides one external service: SSHD. An external service means one that is available to other hosts on the network as a service or listening port. Whichever distribution or installation you choose, you should perform a quick test to check which services are set to automatically start and which ones are listening for network connections.

There are two commands that provide you with the information required for making decisions about which services and protocols to trim and which ones need protection and monitoring. The first is chkconfig (Listing 1), which checks the runlevel information for system services.

Listing 1

chkconfig

$ chkconfig
netconsole   0:off   1:off   2:off   3:off   4:off   5:off   6:off
network      0:off   1:off   2:on    3:on    4:on    5:on    6:off

The second command, nmap, scans a system for open ports. The nmap command can be used locally or remotely. You should do both. Run an nmap scan locally to determine which services are network-facing and which ones are localhost only. Performing the same scans remotely and locally will help determine if there are any rogue services running on your systems. It will also help you to protect ones that are legitimate but may be overlooked by other methods.

The following nmap commands (Listing 2) work both locally and remotely. For remote scans, use the remote host’s IP address and localhost for local scans.

Listing 2

nmap Scanning for Open TCP Ports

# nmap –sT IP_Address
Remote: 
# nmap -sT 192.168.1.59
Starting Nmap 6.40 ( http://nmap.org ) at 2019-05-29 16:08 CDT
Nmap scan report for 10.50.48.59
Host is up (0.74s latency).
Not shown: 999 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
Nmap done: 1 IP address (1 host up) scanned in 60.18 seconds

Local:
# nmap -sT localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2019-05-29 16:07 CDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0016s latency).
Other addresses for localhost (not scanned): 127.0.0.1
Not shown: 998 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
25/tcp open  smtp
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds

The nmap command in Listing 3 listsboth UDP and TCP ports for a host. You may replace localhost with the IP address of the remote host you want to scan.

Listing 3

nmap Scanning for Open UDP and TCP Ports

# nmap -sTU localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2019-05-29 16:25 CDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0014s latency).
Other addresses for localhost (not scanned): 127.0.0.1
Not shown: 1997 closed ports
PORT   STATE         SERVICE
22/tcp open          ssh
25/tcp open          smtp
68/udp open|filtered dhcpc
Nmap done: 1 IP address (1 host up) scanned in 1.42 seconds

The lsof (LiSt Open Files) command (Listing 4) displays a list of processes and to which ports they are bound.

Listing 4

lsof

# lsof -i
COMMAND   PID   USER  FD   TYPE DEVICE SIZE/OFF NODE NAME
chronyd  2429 chrony   1u  IPv4  20062      0t0 UDP localhost:323
chronyd  2429 chrony   2u  IPv6  20063      0t0 UDP localhost:323
dhclient 2766   root   6u  IPv4  22028      0t0 UDP *:bootpc
sshd     2959   root   3u  IPv4  22893      0t0 TCP *:ssh (LISTEN)
sshd     2959   root   4u  IPv6  22909      0t0 TCP *:ssh (LISTEN)
master   3207   root  13u  IPv4  23647      0t0 TCP localhost:smtp (LISTEN)
master   3207   root  14u  IPv6  23648      0t0 TCP localhost:smtp (LISTEN)

The netstat command (Listing 5) lists listening TCP and UDP ports for a system. Those listed as localhost can only be reached on the local system, but those listed as 0.0.0.0:<protocol> are accessible over the network. You can’t eliminate all listening ports, because doing so would render your system useless as a server, but these commands provide you with a snapshot view of potential entry vectors to your system by malicious actors.

Listing 5

netstat

# netstat -l 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address     Foreign Address    State
tcp        0      0 0.0.0.0:ssh       0.0.0.0:*          LISTEN
tcp        0      0 localhost:smtp    0.0.0.0:*          LISTEN
tcp6       0      0 [::]:ssh          [::]:*             LISTEN
tcp6       0      0 localhost:smtp    [::]:*             LISTEN
udp        0      0 0.0.0.0:bootpc    0.0.0.0:*
udp        0      0 localhost:323     0.0.0.0:*
udp6       0      0 localhost:323     [::]:*
raw6       0      0 [::]:ipv6-icmp    [::]:*             7

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Nmap Methods

    How does the popular Nmap scanner identify holes in network security? In this article, we examine some Nmap analysis techniques.

  • Nmap Scripting

    Nmap is rolling out a new scripting engine to automatically investigate vulnerabilities that turn up in a security scan. We’ll show you how to protect your network with Nmap and NSE.

  • Nmap Workshop

    In "The Matrix Reloaded," Trinity uses Nmap to hack into the power grid to pave Neo's way to the architect of the virtual world. However, the port scanner is also ideal for more mundane purposes – such as discovering vulnerabilities in your domestic network.

  • Charly's Column

    Many tools keep growing with each new version, but Nmap 4.00 has lost weight thanks to the Diet-Nmap project. The latest incarnation of Nmap is not only quicker, it is also more frugal with memory.

  • Scanning with Zenmap

    Discover your network with the user-friendly Zenmap network scanner.

comments powered by Disqus