Hardening RHEL 7.1 Services

http://www.aclnz.com/interests/blogs/hardening-rhel-7-1-maipo-part-1-services

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.

1. Generate a random host name for the DNS master server such as o7hfawtgmhwg.domain.com and configure it.
   
2. 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:
   
   
3. 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:
   
   
4. 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' --permanent
UDP
# 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.

Hardening RHEL 7.1 User access

http://www.aclnz.com/interests/blogs/hardening-rhel-7-1-maipo-part-1-user-access

On this document I will go through a series of steps to configure the most relevant settings to harden a RHEL server.
This document is based on the Red Hat Enterprise Linux 7 Security Guide that can be downloaded from the RedHat network here.
Secure passwords
Passwords are the primary method that Red Hat Enterprise Linux 7 uses to verify a user's
identity. This is why password security is so important for protection of the user, the
workstation, and the network.
By default RHEL uses shadow passwords which eliminate this type of attack by storing the password hashes in the file /etc/shadow, which is readable only by the root user.
Strong passwords
Since the storing of passwords has already been taken care of the next step is to force the creation of strong passwords.
When users are asked to create or change passwords, they can use the passwd
command-line utility, which is PAM-aware (Pluggable Authentication Modules) and checks to
see if the password is too short or otherwise easy to crack. This checking is performed by
the pam_pwquality.so PAM module.
PAM reads its configuration from the /etc/pam.d/passwd file, but the file we want to edit for tuning password policies is /etc/security/pwquality.conf
Have a look at the configuration options:

Here are the details of what each entry means:

• difok - Number of characters in the new password that must not be present in the old password.
• minlen - Minimum acceptable size for the new password
• dcredit - Credit for having digits in the new password
• ucredit - Credit for having uppercase characters in the new password
• lcredit - Credit for having lowercase characters in the new password
• ocredit - Credit for having other characters in the new password
• maxrepeat - maximum number of allowed consecutive same characters in the new password.
• minclass - minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others).
• maxclassrepeat - maximum number of allowed consecutive characters of the same class in the new password.
• gecoscheck - Whether to check for the words from the passwd entry GECOS string of the user (0=check).
• dictpath - Path to the cracklib dictionaries. Blank is to use the cracklib default.

NOTE: Credit works like money, if you have a plus number like three you have spare and don't have to worry, but if you have a negative number (debts) you have to pay for them. For instance "ucredit = 2" means the user will have to give at least two upper case characters as part of the password for creating a password.
Something practical to do is to set a "minlen = 8" value and "minclass = 4" value. Whith this two settings you would ensure that the password has to be at least 8 characters long and that it will need to have letters Upper case, Lower case, numbers and symbols. That is what you will normally find on production servers.
Some like to uncomment dictpath and let GECOS use the default dictionary. You could go much further with this, but it is not recommended because passwords would need to be too complex and users wouldn't be able to remember them and the SA would have to be resetting passwords too often.
This is the result of a strong password file:

NOTE: As the root user is the one who enforces the rules for password creation, he can set any password for himself or for a regular user, despite the warning messages.
Password aging
This technique is used to limit the time of cracked passwords. The downside is that if you set this value too low (password change required very often) the users will tend to write their passwords down generating a weak spot.
A common practice is to specify the maximum number of days for which the password is valid.
Password aging is performed with the command "chage".
This command is normally used when hardening a system to expire old unsecure password immediately.
I will show three examples on how to use this command on a console.

1. Set a 90 day period for the password of user fpalacios to expire.
2. Expire the password for fpalacios to have the user change it on the next log on.
3. Expire the password of every user on group developers.

Account Locking
In Red Hat Enterprise Linux 7, the pam_faillock PAM module allows system administrators to lock out user accounts after a specified number of failed attempts.
Limiting user login attempts serves mainly as a security measure that aims to prevent
possible brute force attacks targeted to obtain a user's account password.
Follow these steps to configure account locking:

1. To lock out any non-root user after three unsuccessful attempts and unlock that user after 10 minutes, add the following lines to the auth section of the /etc/pam.d/system-auth and /etc/pam.d/password-auth files:
   auth required pam_faillock.so preauth silent audit
   auth sufficient pam_unix.so nullok try_first_pass
   auth [default=die] pam_faillock.so authfail audit deny=3
   unlock_time=600
   deny=3 unlock_time=600
   
   
   
   
2. Add the following line to the account section of both files specified in the previous files:
   
   account required pam_faillock.so
   I will show you the end result of one of the files:
   
   

 

How to find out files updated in last N minutes

Issue
How to find out files updated in last N minutes?

Resolution
It is simple. Use the following command:
Syntax:
find -cmin -N
where N is the number of minutes
Example:
find /suresh/home/songs/ -cmin -10
Tip:
If you would like to see path of the file's directory then use the ls command along with the above command:
find /suresh/home/songs/ -cmin -10 ls