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.
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 (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.
$ 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.
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 localhostwith the IP address of the remote host you want to scan.
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.
# 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.
# 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
By Ken Hess