Three easy steps to make your Ubuntu server more secure at MIT
In order to expedite Institute business and facilitate knowledge sharing, a server is often necessary. A file server, a web server... the possibilities are endless. But how do you protect the assets on your server from the greater cesspool that is "The Internet"? Here are three steps to take that can greatly reduce your server's risk of being breached.
Step 1: Firewall Your Services with ufw
Why should the Internet as a whole have access to every service running on your server? One simple command can tamp down the amount of traffic your server has to deal with and mitigate nefarious activity from outside MIT's network.
It is highly recommended to configure software firewall rules while physically sitting at the target machine. Firewall rule typos made while remotely connected can leave you locked out of your server.
Hosted servers obtained from IS&T via the Managed Server Hosting service make use of an external firewall and do not make utilize the system's local firewall; no additional steps are necessary by the end-user. Please contact ops-help@mit.edu if you are a Managed Server Hosting customer and have questions about filtering network traffic to your system.
Now that you're physically sitting in front of the machine in question, let's turn on Ubuntu's firewall:
sudo ufw enable
After turning on Ubuntu's software firewall, the default behavior is to deny all traffic unless explicitly told otherwise. For this reason, it is important to know what is running on your server and who needs access to it.
If you have a website being hosted on your server, you will want to add a ufw rule to permit all hosts to access port 80:
sudo ufw allow http
This rule will allow all host on the Internet or your network to connect to port 80 on your machine.
If you utilize https on your site, you'll need to add a rule for that too – as it uses a different port, 443:
sudo ufw allow https
This rule will allow all host on the Internet or your network to connect to port 443 on your machine.
Now that we understand what is running on our server, let's make some more targeted rules. We'll use Secure Shell (SSH) as an example.
Restricting SSH Access to MIT IP Addresses (Good)
sudo ufw allow from 18.0.0.0/9 to any port 22 proto tcp
This firewall rule will require users to have an MIT IP address (18.30.0.0/16 and 18.28.0.0/16) to access port 22 (SSH). Users that are on-campus – and not connected to the wireless "MIT Guest" network – will have unfettered access to your machine via port 22. Users that are off-campus will need to connect to MIT's VPN appliance to acquire an IP address in the prerequisite range.
Restricting SSH Access to MIT VPN IP Addresses (Better)
sudo ufw allow from 18.101.0.0/16 to any port 22 proto tcp
sudo ufw allow from 18.100.0.0/16 to any port 22 proto tcp
This firewall rule will require users to have an IP address in MIT's VPN range. Users that are on-campus and off-campus will need to connect to MIT's VPN appliance to acquire an IP address in the 18.101.0.0 - 18.101.255.255 or 18.100.0.0 - 18.100.255.255 range in order to access port 22 on your machine.
Firewall rules can be used to restrict/permit access to any port/service being offered by your server.
Did you know: MIT only permits SMB (port 445) connections to IP addresses in the 18.0.0.0 - 18.127.255.255 range with hardware firewall rules. You can further restrict access to your server's SMB share(s) with software firewall rules:
sudo ufw allow from 18.101.0.0/16 to any port 445 proto tcp
sudo ufw allow from 18.100.0.0/16 to any port 445 proto tcp
This firewall rule will require users to have an IP address in MIT's VPN range to connect to your SMB share.
For a full list of services, and their corresponding ports, see:
less /etc/services
Going deeper with SSH: if you really want to be an SSH Jedi, consider ditching the password. Read up on keying your SSH logins.
MIT users can also require valid Kerberos tickets for password-less SSH logins.
(More information on ufw can be found here: https://help.ubuntu.com/community/UFW)
Estimated Time To Complete: 5-10 minutes.
Step 2: Set Your Ubuntu Box To Automatically Apply Security Updates
Open source software is wonderful. Open source software needs to be patched... often. Ubuntu administrators can leverage the "unattended-upgrades" package to keep their system up-to-date with the latest bits and bytes available from developers. A great tutorial is available on Canonical's website:
https://help.ubuntu.com/community/AutomaticSecurityUpdates
Estimated Time To Complete: 10 minutes.
Step 3: Audit Logs Once A Month
It is a great idea to audit you server's access log(s) at least once a month. Set a reminder in your calendar, grab a cup of coffee and navigate to /var/log/. The file auth.log should be combed over and suspicious activity should be noted and dealt with.
Abusive access attempts that originate from MIT's network can be reported to security@mit.edu for further investigation.
Going Deeper with Log Auditing: Utilities such as Fail2Ban can automate abuse reporting and mitigation. Read up on Fail2Ban.
Estimated Time To Complete: 15-30 minutes once a month depending on log size.