Only Open the Ports You Need, Firewall the Rest
The services you run on your server connect to the outside world through ports. Each port has a number, and the service will listen for connections on that port number. This isn’t always a security risk, as you’ll often need to have ports open for users to access your service.
Ports 80 and 443 are the default ports for HTTP and HTTPS. If you’re running a web server, these need to be open. Port 22 will likely be open on any fresh Linux install, as it’s the default SSH port. You can close this port, but you’ll need to move SSH to a different port (which is a good idea anyway).
Without a firewall in place, any service that starts up a connection will be allowed access to any port by default. It’s best to have your rules defined to prevent this from happening and to ensure that nothing unexpected is running on your system. This is exactly what a firewall does—define the rules for how processes on your server can talk to the outside world.
To check what ports are currently open on your system, you can run:
Or, if you want more concise output:
These commands will list out each open port, alongside which process is using that port. Netstat only shows the PID and filename of the process, so if you need the full path you’ll have to pass the PID to the ps command. If you need to scan ports without accessing the server, you can use the client-side utility nmap.
Anything else that isn’t specifically being used to host a service should be closed with a firewall.
If everything running on your system is supposed to be open, you might not need a firewall. But without one, any unused port could easily become open by a new process you install. You’ll need to make sure that any new services don’t need to be locked down.
Don’t Run Your Services on Public IPs in the First Place
A firewall is a great security tool, but certain services shouldn’t be accessible by the whole world. If a port needs to be open, that service is vulnerable to brute force attacks and other nasty issues. But you can prevent this from happening by locking down connections to your virtual private cloud.
Databases are the prime example of this. A database like MySQL needs to have an open port for administrative connections. But if the only thing talking to the database is your web server (and you, when doing maintenance), you should keep MySQL private, and only allow it to talk to the web server. If you need to access it, you can SSH to the web server, and access the rest of the network from there.
How to Configure a Firewall
AWS, in particular, forces you to use their firewall, which is managed with security groups. Ports are all closed by default (save for port 22), so you’ll need to open them manually from their interface. You can edit the security groups for any running instance from the EC2 Management Console, and modify the inbound rules.
AWS allows you to specify the source for the rule, so you could for example lock down SSH to only your personal IP address, or make the connection between your database server and web server private.
RELATED: The Beginner’s Guide to iptables, the Linux Firewall
If you’re using other providers like Linode or regular hosting, you’ll need to configure the firewall yourself. For this, the simplest method is to use the iptables utility.
If you’re running a Windows server, you’ll need to configure the aptly named Windows Firewall, which you can do from the Windows Management Console or by using netsh.
