Research Infrastructure

Minimum Linux Security

 

These pages contain basic advice on how to secure a Linux host. The information is aimed at academics, postdoctoral research staff and postgraduates at The University of Manchester. Questions may be emailed to its-ri-team@manchester.ac.uk.

130.88.0.0/16 vs 10.99.0·0/16

Unless there is good reason, use a 10.99.0.0/16 IP address. SSH access from off-campus is not a good reason! For the latter, use a hardened SSH gateway (as provided by the RI team).

Patching

Linux hosts should be configured to patch themselves automatically everyday. The default configuration for all major Linux distributions (including Redhat, Fedora, Debian and Ubuntu) is to do this.

Any host configured with a 10.99.0.0/16 IP address will need to have a proxy configured to allow patching from an off-campus site.

Example

For Yum, on Redhat, add

proxy=http://updateproxy.manchester.ac.uk:3128

to /etc/yum.conf.

Passwords

All passwords should be around 16 characters long, or better, and should include some non-alphanumeric characters (e.g., punctuation characters).

Firewall

Unless there is good reason all services listening on a Linux host (e.g., SSH and/or HTTP) should be firewalled to prevent global access. For example, all access other than that from on campus should be blocked.

(If you need a globally-accessible Web/HTTP server, use a professionally-managed School/Faculty/ITServices facility; if you need global SSH access to your Linux host, consider using the gateway mentioned above).

Services/Daemons

Turn them off

Linux hosts are by their nature servers. So it is quite possible for a default install of a Linux distro to have daemons/processes listening for connections. Unless you really need them, simply switch off these services (even if they are firewalled — better security comes in layers).

It is easy to find listening daemons using netstat:

root> netstat -ltpn

Example: Debian

On a default install of a Debian desktop the results might be:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3212/sshd       
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      2830/cupsd      
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      3156/exim4      
tcp        0      0 0.0.0.0:38439           0.0.0.0:*               LISTEN      1847/rpc.statd  
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1792/rpcbind    
tcp        0      0 0.0.0.0:6000            0.0.0.0:*               LISTEN      3421/X          
tcp        0      0 0.0.0.0:113             0.0.0.0:*               LISTEN      3127/inetd      

Here:

  • cupsd and exim4 are listening only on 127.0.0.1, local loopback, so can eb considered secure;
  • sshd, rpc.statd, rpcbind, X and inetd are all listening for connections from anywhere — not a good idea unless you are prepared to spend the time required to continually monitor these services (as professional sysadmin staff do).

Stop the RPC-related services:

Unless you have NFS mounts, then:

service nfs-common stop
service rpcbind stop
    # ...or, for the old-school:  /etc/init.d/nfs-common stop, etc...

to eliminate the RPC-related daemons. Then stop these services from starting again after a reboot:

update-rc.d nfs-common remove
update-rc.d rpcbind remove
    # ...or, for the old-school, simply remove the appropriate s-links from the rc?.d directories...

Stop the inetd wrapper:

Unless you have any services wrapped by inetd

service openbsd-inetd stop
update-rc.d openbsd-inetd remove

Secure your X server:

Finally, given that almost all X11 traffic is now tunnelled through SSH, there is no need for the X11 server to be listening to anything other than 127.0.0.1, so assuming you are using startx,
ensure that /etc/X11/xinit/xserverrc contains the -nolisten options, for example

exec /usr/bin/X -nolisten tcp "$@"

and restart X.

Securing SSH: Fail2Ban and

Apache

Mod Security

Fail2Ban

SSH AllowUsers and DenyUsers

TCPWrappers and xinetd

System Logs

Remote Logs

Last modified on June 25, 2019 at 7:37 am by George Leaver