Ubuntu Server 18.04 – Lowering your attack surface

How to set a static IP address on Windows Server 2019

After setting up a new server, an administrator should always perform a security check to ensure that it’s as secure as it can possibly be. No administrator can think of everything, and even the best among us can make a mistake, but it’s always important that we do our best to ensure we secure a server as much as we can. There are many ways you can secure a server, but the first thing you should do is lower your attack surface. This means that you should close as many holes as you can, and limit the number of things that outsiders can potentially be able to access. In a nutshell, if it’s not required to be available from the outside, lock it down. If it’s not necessary at all, remove it.

To start inspecting your attack surface, the first thing you should do is see which ports are listening for network connections. When an attacker wants to break into your server, it’s almost certain that a port scan is the first thing they will perform. They’ll inventory which ports on your server are listening for connections, determine what kind of application is listening on those ports, and then try a list of known vulnerabilities to try to gain access. To inspect which ports are listening on your server, you can do a simple port query with the netstat command:

sudo netstat -tulpn
Running a port query with netstat

You don’t actually need to run the netstat command with sudo as I have, but if you do, the output will show more information than without running it, namely the names of the programs that are listening for connections (which makes it easier to associate ports, if you don’t have them all memorized). From the output, you’ll see a list of ports that are listening for connections. If the port is listening on, then it’s listening for connections from any network. This is bad. The server I took the screenshot from has several of these open ports. If the port is listening on, then it’s not actually accepting outside connections. Take a minute to inspect one of your servers with the netstat command, and note which services are listening for outside connections.

Armed with the knowledge of what ports your server is listening on, you can make a decision about what to do with each one. Some of those ports may be required, as the entire purpose of a server is to serve something, which usually means communicating over the network. All of these legitimate ports should be protected in some way, which usually means configuring the service with some sort of security settings (which will depend on the particular service), or enabling a firewall, which we’ll get to a bit later. If any of the ports are not needed, you should close them down. You can either stop their daemon and disable it, or remove the package outright. I usually go for the latter, since it would just be a matter of reinstalling the package if I changed my mind.

This leads me to the very first step in lowering your attack surface: uninstalling unneeded packages. In my case, the server has several RPC services listening for connections. These services have to do with NFS, something that this server will never be serving or using in any way. Therefore, there’s no harm in removing support for NFS from this server. It doesn’t depend on it at all:

sudo apt remove rpcbind

Now that I’ve taken care of RPC, I’ll look at other services this server is running that are listening for connections. OpenSSH is a big one. It’s usually going to be the first target any attacker uses to try to gain entry into your server. What’s worse, this is usually a very important daemon for an administrator to have listening. After all, how can you administer the server if you can’t connect to it? But, if you’re able to connect to it, then conceivably so can someone else! What should we do? In this case, we’ll want to lock the server down as much as possible. In fact, I’ll be going over how to secure SSH later in this chapter. Of course, nothing we do will ever make a server bulletproof, but using the most secure settings we can is a great first step. Later on in this chapter, I’ll also go over Fail2ban, which can help add an additional layer of security to OpenSSH.

As I’ve mentioned, I’m a big fan of removing packages that aren’t needed. The more packages you have installed, the larger your attack surface is. It’s important to remove anything you don’t absolutely need. Even if a package isn’t listed as an open port, it could be the target of some sort of vulnerability that may be affected by some other port or means. Therefore, I’ll say it again: remove any packages you don’t
need. An easy way to get a list of all the packages you have installed is with the following command:

dpkg --get-selections > installed_packages.txt

This command will result in the creation of a text file that will contain a list of all the packages that you have installed on your server. Take a moment to look at it. Does anything stand out that you know for sure you don’t need? You most likely won’t know the purpose for every single package, and there could be hundreds or more. A lot of the packages that will be contained in the text file are distribution-required packages you can’t remove if you want your server to boot up the next time you go to restart it. If you don’t know whether or not a package can be removed, do some research on Google. If you still don’t know, maybe you should leave that package alone and move on to inspect others. By going through this exercise on your servers, you’ll never really remember the purpose of every single package and library. Eventually, you’ll come up with a list of typical packages most of your servers don’t need, which you can make sure are removed each time you set up a new server.

Another thing to keep in mind is using strong passwords. This probably goes without saying, since I’m sure you already understand the importance of strong passwords. However, I’ve seen hacks recently in the news caused by administrators who set weak passwords for their external-facing database or web console, so you never know. The most important rule is that if you absolutely must have a service listening for outside connections, it absolutely must have a strong, randomly generated password. Granted, some daemons don’t have a password associated with them (Apache is one example, it doesn’t require authentication for someone to view a web page on port 80). However, if a daemon does have authentication, it should have a very strong password. OpenSSH is an example of this. If you must allow external access to OpenSSH, that user account should have a strong randomly generated password. Otherwise, it will likely be taken over within a couple of weeks by a multitude of bots that routinely go around scanning for these types of things. In fact, it’s best to disable password authentication in OpenSSH entirely, which we will do.

Finally, it’s important to employ the principle of least privilege (PoLP) for all your user accounts. You’ve probably gotten the impression from several points I’ve made throughout the tutorial that I distrust users. While I always want to think the best of everyone, sometimes the biggest threats can come from within (disgruntled employees, accidental deletions of critical files, and so on). Therefore, it’s important to lock down services and users, and allow them access to only perform the functions a user’s job absolutely requires of them. This may involve, but is certainly not limited to:

  • Adding a user to the fewest possible number of groups
  • Defaulting all network shares to read-only (users can’t delete what they don’t have permission to delete)
  • Routinely auditing all your servers for user accounts that have not been logged into for a time
  • Setting account expirations for user accounts, and requiring users to re-apply to maintain account status (this prevents hanging user accounts)
  • Allowing user accounts to access as few system directories as possible (preferably none, if you can help it)
  • Restricting sudo to specific commands (more on that later on in this chapter)

Above all, make sure you document each of the changes you make to your servers, in the name of security. After you develop a good list, you can turn that list into a security checklist to serve as a baseline for securing your servers. Then, you can set reminders to routinely scan your servers for unused user accounts, unnecessary group memberships, and any newly opened ports.

Comments are closed.