In this article I will go through a series of steps to configure the most relevant settings to harden a RHEL server.
Services
Linux servers run network services. Each services has an application (daemon) listening for connections on one or many network ports.
Each service and port could potentially receive a network attack.
Here is a list of potential risks on having ports open to provide services:
- Denial of Service Attacks (DoS)— By flooding a service with requests, a denial of service attack can render a system unusable as it tries to log and answer each request.
- Distributed Denial of Service Attack (DDoS) — A type of DoS attack which uses multiple compromised machines (often numbering in the thousands or more) to direct a coordinated attack on a service, flooding it with requests and making it unusable.
- Script Vulnerability Attacks — If a server is using scripts to execute server-side actions as Web servers commonly do, an attacker can target improperly written scripts. These script vulnerability attacks can lead to a buffer overflow condition or allow the attacker to alter files on the system.
- Buffer Overflow Attacks — Services that connect to ports numbered 0 through 1023 must run as an administrative user. If the application has an exploitable buffer overflow, an attacker could gain access to the system as the user running the daemon. Because exploitable buffer overflows exist, crackers use automated tools to identify systems with vulnerabilities, and once they have gained access, they use automated root kits to maintain their access to the system.
Before we start you might want to check what services are running on your system with the netstat command.
Here is an example of a server with few services running.
I’m going to go through the most common services that require attention.
rpcbind is a service daemon that dynamically assigns ports to services line RPC, NIS and NFS.
This service has a week authentication mechanism and can assign a wide range of ports and needs to be protected by the .
If this service is needed and you are going to protect it with the firewall you will first need to make a case study to understand which networks should reach rpcbind and which not. Once you know this run this command to enable each network.
To limit TCP:
# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop' --permanent# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept' --permanent
To limit UDP:
firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop' –permanent
Repeat the last three steps for each subnet that will need access.
NIS is well known for authenticating users across the network. This service is outdated because it sends unencrypted information through the network, including passwords. Unless needed for specific reasons it’s better to not use it at all.
If your network has NIS authentication or you are planning on setting one make sure you have rpcbind behind a firewall as specified above and then go through this steps.
- Generate a random host name for the DNS master server such as o7hfawtgmhwg.domain.com and configure it.
- Generate a random like NIS domain name for your NIS server, different from the DNS server host name and configure the new name by editing the NISDOMAIN entry on the /etc/sysconfig/network file:
- Edit the /var/yp/securenets file to add each netmask/network that requires NIS authentication. If the file doesn’t exist create it.
After adding a few lines the file should look like this:
- Assign static ports to ypxfrd and ypserv daemons by adding the following lines to the /etc/sysconfig/network file:
YPSERV_ARGS="-p 834"
YPXFRD_ARGS="-p 835"
Then run the next two firewall commands for each network needing NIS to limit the networks that can use this ports.TCP# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="834-835" protocol="tcp" drop' --permanentUDP# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="834-835" protocol="udp" drop' --permanent
NFS exports could also generate security risks such as symlink attacks. For this reason use NFSv4.0 when possible which can require authentication and can operate behind a firewall.
Here are some considerations you should follow:
- Always export complete filesystems rather than just subdirectories.
- Use ro option to export filesystems whenever possible.
- Always use the ug sections to assign permissions and never o. Consequently limiting NFS access to specific users and groups on your /etc/group and /etc/passwd files.
- Take special attention to syntax on the /etc/exports file, a syntax error can lead to unwanted share configurations.
To overcome this always check your exports with the showmount –e command. - Uncomment this entries on the /etc/sysconfig/nfs file:
# TCP port rpc.lockd should listen on.
LOCKD_TCPPORT=32803
# UDP port rpc.lockd should listen on.
LOCKD_UDPPORT=32769 - Restart the nfs service “service nfs restart” and check what ports are being used by nfs to complete the needed firewall rules to limit the network access to those ports.
For this eample the following firewall rules for each network needing access should be added:
TCP
# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="20048" protocol="tcp" drop' --permanent
UDP
# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="20048" protocol="udp" drop' –permanent
TCP
# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="2049" protocol="tcp" drop' --permanent
UDP
# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="2049" protocol="udp" drop' --permanent
References
+ This article is based on the Red Hat Enterprise Linux 7 Security Guide that can be downloaded from the RedHat network here.
Disclaimer - Views expressed in this blog are author's own and do not necessarily represents the policies of aclnz.com