Host Hardening

by: Jeff Hatfield

pd: July 13, 2015

Linux helps keep you secure through Security In Depth. Below are some additional measures to improve the security posture of your system.

Firewall

Cyber security experts recommend the use of a firewall even if your system is behind another firewall such as a home router. Fortunately, Linux has a built-in firewall called iptables. Many distributions come with this firewall enabled by default to block network inbound traffic. Traffic  which most certainly could offer a relatively easy means of compromise to your system.

With iptables you can secure your system against inbound and outbound traffic, but the learning curve can be lowered by using GUI tools. Such tools are provided in both Fedora and Linux Mint distributions (and others), but both vary in tools and implementation.

Fedora 22 has firewalld (similar to iptables) enabled on first boot of the system, whereas Linux Mint has iptables, but is disabled on first boot. Although having a firewall turned on is wise, most Linux distributions do not have network accessible services listening (or open) by default.

Linux includes many services that can be enabled and this list is just a short sample: samba (windows file sharing), ssh (secure shell), http (web server), ipp or cups (network print server), kodi (media center), and mpd (music player daemon), ...

Fedora Linux's Firewall Configuration tool

The terminal can be used to open the ‘system-config-firewall’ tool and perform configuration changes. The example shows the Trusted Services with a single item checked - SSH. This would allow ssh access into the system.

Additional information can be found at the Fedora FirewallD wiki.

Simple iptables configuration

Iptables configuration files are stored in different locations based upon the distro’s specific requirements, but in general you’ll find the file below /etc/

Fedora’s iptables config. with additional rules to prevent ping attacks & sample zones.

/etc/sysconfig/iptables

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:FORWARD_ZONES - [0:0]
:FORWARD_direct - [0:0]
:INPUT_ZONES - [0:0]
:INPUT_direct - [0:0]
:IN_ZONE_public - [0:0]
:IN_ZONE_public_allow - [0:0]
:IN_ZONE_public_deny - [0:0]
:OUTPUT_direct - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES
-A INPUT -p icmp -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_ZONES
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -j OUTPUT_direct
-A IN_ZONE_public -j IN_ZONE_public_deny
-A IN_ZONE_public -j IN_ZONE_public_allow
-A IN_ZONE_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A IN_ZONE_public_allow -p udp -m udp --dport 631 -m conntrack --ctstate NEW -j ACCEPT

Controlling ssh access:

External TCP Port

Modify the router’s port forwarding to use a random high port (from 2400-65535) to throw off script kiddies and bots from the normal port ssh port 22. This simple trick reduced my bot attacks from unmanageable attempted access levels (thousands per day on port 22) down to Zero. By keeping the server’s ssh port on 22, I can maintain access simply by using ssh username@server.mydomain.

Disable ssh root login

# vi /etc/ssh/sshd_config

## change the value ‘PermitRootLogin yes’ to

PermitRootLogin no

Client Authentication

A bullet-proof method of allowing login on a server with ssh access is to utilize public key authentication. Once username/password login has been disabled and PKI enabled, the server is protected from bot-based password attacks.

# vi /etc/ssh/sshd_config

## Add or uncomment the line

PubkeyAuthentication yes

Copy public key

Save the sshd_config file and generate your private/public key on your laptop, desktop or android app.

Copy the public key into the server’s ~/.ssh/authorized_keys file with the tool ssh-copy-id user@server.domain (see man page for additional information).

Restart the sshd daemon (service sshd restart or systemctl restart sshd) and ssh into the server as the username you have on the server.

TCP Wrappers

The system’s /etc/hosts.allow provides further restriction to the system’s ssh service by allowing only a specific host or zone to ssh into the system. This option may not be practical if a user requires external access to a system within your network (i.e. from a smart phone app such as JuiceSSH, ConnectBot or a laptop on a remote network).

# vi /etc/hosts.allow
ALL: 127.0.0.1 # localhost

ALL: 192.168.1.0/24 # Internal Network

Restrict ssh Access

If a group of users named ‘internal’ require ssh access into the system, access can be tightly controlled by adding the requirement to the sshd configuration file.

# vi /etc/ssh/sshd_config

## add the group ‘ssh-users’

AllowGroups ssh-users

ssh Cipher Suites

Restricting the encryption Ciphers used for the ssh application to only those known to provide adequate further increases security (ref stribika.github.io for more info).

# vi /etc/ssh/sshd_config

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,\ aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Next topic of discussion - Encryption.