The supported Linux distributions in the Luddy School of Informatics, Computing, and Engineering are currently Red Hat Enterprise Linux and Ubuntu per Supported Linux Configurations. However, the school recognizes that certain projects will have dependencies on other Linux distributions and we make allowances for this per the *IT Policy: Administrator Access and Self-Managed Systems (Moved). This page is intended to provide guidance to administrators of Ubuntu-based self-manged systems so they remain in compliance with IU IT policies aimed at keeping system secure. In some cases, instructions may be specific to a particular version of Ubuntu so you may have to make changes based on the version you are running.
Manual Security Updates - You will want to set up automatic installation of security updates (per the next item below) but if you want to manually update your system you can see what updates are needed and update the system with:
sudo /usr/lib/update-notifier/apt-check --human-readable sudo apt-get update sudo apt-get upgrade |
See the apt-get man page for details on the various commands and exactly what they do.
Automatic Security Updates- During the installation of Ubuntu, you will be asked if you want automated updates. You must select the option to apply security updates automatically. If you did not select this option during the initial installation, please enable it per the Ubuntu Automatic Updates Documentation. You can run "sudo debconf-show unattended-upgrades" to see if the automatic updates are enabled and you can reconfigure it with "sudo dpkg-reconfigure -plow unattended-upgrades".
Once this is set up, you should see something like the following from debconf-show:
$ sudo debconf-show unattended-upgrades * unattended-upgrades/origins_pattern: "origin=Debian,codename=${distro_codename},label=Debian-Security"; * unattended-upgrades/enable_auto_updates: true |
If you find that automatic updates are not working, check the log file for clues: /var/log/unattended-upgrades/unattended-upgrades.log
We have seen a very small number of systems that report "WARNING System is on battery power, stopping" which would be normal for a laptop on battery power but we have seen this on workstations that don't even have batteries. If you run into this you can workaround the issue by setting "Unattended-Upgrade::OnlyOnACPower" to false in /etc/apt/apt.conf.d/50unattended-upgrades. Also, is you see errors like "ERROR The URI <someurl> failed to download, aborting" in the log then you may want to take a look at the file /etc/apt/apt.conf.d/90curtin-aptproxy and be sure that any proxy settings you are using are correct there.
Automatic Removal of Old Kernels - You will also want to configure things so that unused packages are automatically uninstalled. If you don't do this then it is just a matter of time before your /boot partition fills up and which can cause various other problems. One problem it will cause is that updates will then fail and your system will no longer get security updates automatically. To enable the auto-removal of old kernel packages, edit the file /etc/apt/apt.conf.d/50unattended-upgrades and change these lines:
//Unattended-Upgrade::Remove-Unused-Kernel-Packages "false"; //Unattended-Upgrade::Remove-Unused-Dependencies "false"; |
to look like this (uncomment the lines and set to true)
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; Unattended-Upgrade::Remove-Unused-Dependencies "true"; |
Note that the first line in this example may only be there for Ubuntu 18.04
Reference: Ubuntu Community: Remove Old Kernels
Account Passwords - To be in compliance with IU policy, all account passwords must comply with the IU Passphrase Guidelines, including the 15 character minimum length. This includes the initial account you set up at install time and any other accounts you might add after the installation. In addition, account passwords must be changed no less frequently than every 2 years to be in compliance with IU policy. One good way to say in compliance with password guidelines is to set the system up so it uses the IU passphrase for account authentication. This is simple to do by just installing these packages:
sudo apt-get install heimdal-clients libpam-heimdal |
When promoted for the kerberos domain, enter "ADS.IU.EDU".
Firewall Implementation - One of the most important security mechanisms is the implementation of a proper firewall. In the linux world, that will likely be either iptables or firewalld. With Ubuntu, UFW (Uncomplicated Firewall) is a popular frontend for managing iptables firewall rules. There is a good guide to using UFW here:
Uncomplicated Firewall Ubuntu Wiki
An alternate method is to use iptables directly. Here are some cookbook example of setting up iptables with Ubuntu 20.04 or 18.04 LTS:
Step 1: Set up the iptables rules - Here are 3 cookbook examples for 3 common use-cases. In each case, we just block all IPv6 traffic but you could open up ports for IPv6, if needed.
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -I INPUT 1 -i lo -j ACCEPT sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT sudo iptables -P INPUT DROP sudo ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo ip6tables -I INPUT 1 -i lo -j ACCEPT sudo ip6tables -A INPUT -p ipv6-icmp -j ACCEPT sudo ip6tables -P INPUT DROP ## See Step 2 below to make these changes permanent |
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -A INPUT -p tcp -s 129.79.0.0/16 --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp -s 10.0.0.0/8 --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp -s 156.56.0.0/16 --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp -s 140.182.0.0/16 --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp -s 149.159.0.0/16 --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp -s 149.160.0.0/16 --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp -s 149.161.0.0/16 --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp -s 149.165.0.0/16 --dport 22 -j ACCEPT sudo iptables -I INPUT 1 -i lo -j ACCEPT sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT sudo iptables -P INPUT DROP sudo ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo ip6tables -I INPUT 1 -i lo -j ACCEPT sudo ip6tables -A INPUT -p ipv6-icmp -j ACCEPT sudo ip6tables -P INPUT DROP ## See Step 2 below to make these changes permanent NOTE: This opens up ssh access to the primary IUB subnets, including IU Secure wireless and the IU VPN. If you need to ssh to the system from outside of the IUB network then you just need to connect to the IU VPN first. See also the sshd section in the 'Securing Services' item below if you are going to expose sshd on the network. |
If you configure ssh to be open to the world as noted in the following section you MUST take additional steps to secure ssh as noted in Block Brute-Force SSH Attacks |
We strongly discourage you from opening port 22 to the world. That opens the system up to all types of attacks and settings things up this way requires that you take steps to mitigate the risks as noted in the following section. sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -I INPUT 1 -i lo -j ACCEPT sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT sudo iptables -P INPUT DROP sudo ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo ip6tables -I INPUT 1 -i lo -j ACCEPT sudo ip6tables -A INPUT -p ipv6-icmp -j ACCEPT sudo ip6tables -P INPUT DROP ## See Step 2 below to make these changes permanent NOTE: If you open port 22 to the world (which is strongly discouraged) then you must take precautions as noted in the next section. If you leave it only open to IU then you can use the IU VPN to connect when outside of IU which is preferable (as in the previous example). See also the sshd section in the 'Securing Services' item below if you are going to expose sshd on the network. |
Step 2: Install iptables-persistent to manage and save the config
You can use iptables-persistent to save and manage the iptables config. Just install that and accept the defaults to save out the current configuration:
sudo apt-get update sudo apt-get install iptables-persistent OR, if this package was already installed run: sudo netfilter-persistent save NOTE: Rules will be saved to /etc/iptables/rules.v4 during install. |
Step 3: Manage further changes - If you need to make any further rules changes then you can do that by running the appropriate iptables commands and then saving them out. Just keep in mind that since you added the DROP rule as the last rule in the chain you can't simply append new rules since they will be ignored. Instead, you must insert new rules before the final DROP rule. Here is a cookbook example of how you could add to opening a specified port after you have the initial rules set up.
# Open up a specified port by inserting the rule into the chain sudo iptables -I INPUT 3 -p tcp --dport NNNN -j ACCEPT *** You must replace NNNN with the actual port number you want to open # If you wanted to open up a port to only the host with IP address 1.2.3.4 you could do that with: sudo iptables -I INPUT 3 -s 1.2.3.4 -p tcp --dport NNNN -j ACCEPT # Verify that the rule looks good and is in the right place sudo iptables -v -L --line-numbers # Save it out sudo netfilter-persistent save |
Here is another example showing how to remove an existing rule:
# View the current rules, with line numbers sudo iptables -v -L --line-numbers # Identify the rule you want to remove and note the line number. Remove that line by number sudo iptables -D INPUT N Note: Replace 'N' with the line number of the rule to remove # Verify that the rules looks good and the rule has been removed sudo iptables -v -L --line-numbers # Save it out sudo netfilter-persistent save |
Require ssh keys from outside of the IU network - This is a really attractive option because it gives you unrestricted access from outside of IU but only using ssh keys. It is also extremely simple to set up by making a quick change to the sshd configuration as follows:
1) Set the following configuration parameter in /etc/ssh/sshd_config to prevent password authentication: PasswordAuthentication no 2) At the end of /etc/ssh/sshd_config add this block to allow password authentication but only from IU subnets: Match Address 129.79.*.*,156.56.*.*,149.159.*.*,149.160.*.*,149.161.*.*,140.182.*.*,149.165.*.*,10.*.*.* PasswordAuthentication yes 3) Restart sshd sudo systemctl restart sshd |
Once this is set up, then you can use ssh keys from anywhere to connect. Please see the KB page Using SSH Key Authentication On The Unified Linux Systems for information about using ssh keys with a variety of operating systems and ssh clients. This KB page is written in the context of connecting to a Luddy School RHEL Linux system but the process for connecting to any other linux system is virtually identical. There are also lots of resources on the web describing how to set up ssh keys so you can get further information by searching for "ssh keys" plus your operating system and ssh software name for details (eg. google "windows putty ssh keys" or "linux openssh ssh keys").
Stop using ADS authentication - If you absolutely must have sshd open to the world and the above options for restricting access or password-based authentication are not feasible for whatever reason then you should not use ADS authentication (per step Account Passwords above). But, if you go this route it is critical that you use local passwords that meet IU password requirements. Just keep in mind that this option offers ZERO protection in the case where login credentials are compromised which is why this approach is not recommended.
Remove or Disable mDNS/avahi-daemon - You should ensure that avahi-daemon is not running and providing mDNS services. This is almost certainly not needed on the IU network and can leave the system open to abuse. You can just remove the avahi-daemon package entirely (preferred) or disable it as follows:
Preferred: Remove the service sudo apt-get remove avahi-daemon WARNING: Depending on how you have networking set up, you may have important package dependencies on avahi-daemon so removal may also remove other important packages. Look at the list of packages to be removed carefully and if you see packages other than those for avahi and mdns you may want to just disable/stop it. Alternate: Disable and stop the service echo manual | sudo tee /etc/init/avahi-daemon.override sudo systemctl stop avahi-daemon NOTE: We disable it this way rather than via a normal systemctl disable because there are other packages (such as cups) that may restart it even though it is disabled. |
sshd - See the above section "Block Brute-Force SSH Attacks" for information about securing sshd against brute force attacks. Many distributions also enable insecure protocols so you should add the following 2 lines to the /etc/ssh/sshd_config file and restart the sshd service to correct this:
# Ubuntu 16.04 # ============ Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256 |
SSL - If your site supports https/SSL you should disable SSLv1, SSLv2, and TLSv1 (aka. TLSv1.0) and only support TLSv1.1 and later. The following SSL configuration parameters are recommended:
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!RC4:!3DES:!IDEA SSLHonorCipherOrder on |
ssl_protocols TLSv1.1 TLSv1.2;
". You should also review the other security recommendations for SSL at Strong SSL Security on nginx.SSL - If your site supports https/SSL, you should disable SSLv1, SSLv2, and TLSv1 (aka. TLSv1.0) and only support TLSv1.1 and later. There are different ways of doing this depending on the connector type you are using, but when using JSSE connectors you can use the following in the HTTPS connector configuration in the server.xml:
sslProtocol="TLS" sslEnabledProtocols="TLSv1.2,TLSv1.1" |
Auditd - You must set up auditd as described at Configuring and auditing Linux systems with Audit daemon. There is also information in the IU KB page INTERNAL (iu-kb): About Splunk audit configurations (you must log in to view this page). You can install this on Ubuntu with:
sudo apt-get install auditd audispd-plugins |
Here is a minimal /etc/audit/audit.rules
file that meets IT-12 requirements on a system with no sensitive data:
-D -b 320 -a exit,always -F arch=b64 -S open -F exit=-EACCES -a exit,always -F arch=b64 -S open -F exit=-EPERM -a exit,always -F arch=b32 -S open -F exit=-EACCES -a exit,always -F arch=b32 -S open -F exit=-EPERM |
This will log all failed file access attempts as well as both failed and successful logins. On a system with sensitive data, you must also log all successful file accesses. For example, if you were storing sensitive data in /home/goodies then you would add the following to the above auditd rules:
-w /home/goodies -p wrxa |
Once you have the audit.rules file configured, you can restart auditd and verify by running:
sudo systemctl restart auditd sudo auditctl -l |
Please let us know if you need any help setting this up.
VMware Tools Installation - If you are setting up a Ubuntu VM in the IU Intelligent Infrastructure (II) system you must install VMware tools. We recommend you use the open VMware tools as follows:
sudo apt-get install open-vm-tools |
If you have any questions about this or need further assistance, please contact us via the help desk.