When we request information from another computer we need to be specific. So what does that mean?
Well, for instance, we may say “show me this web page” or we may say “show me the page in a way no one else can see my interaction with it”. We know from another of the Cop's cornerstone guides, the Web Protocols 101, that for the former request we tell the serving computer that we want to use a set of rules – a protocol – called HTTP and, for the latter, secure request, that we tell the server to use HTTPS.
Or, if we want to explore and manage files we could specify to use FTP or SFTP. Else we could say, “hey server, I want to administer you using this method” or “I want to look at my email using that method”, and so on.
The format for these requests often looks familiar:
The destination could be a file on a server. The protocol may be HTTP …
So, to recap, we tell some destination what kind of task we want to perform and, assuming the server is turned on and connected to the same network, such as the web, the service (or daemon) relevant to that job negotiates our request with its associated program. To resolve a webpage, for example, you knock on the door for HTTP and the doorman – the HTTP daemon – checks on what you want before sending your request to its associative program, in this instance a web server like Apache that, in turn, assembles the request along with colleagues like PHP and MySQL, ultimately serving up a web page.
Now, because there are lots of possible tasks – FTP, SSH, HTTPS etc – and with each of these having their own programs, their particular services keep watch, awaiting our queries, on their own dedicated doorways. We call those ports.
And because we don't want just anyone to do just anything on our server, using those ports for malicious purposes, we set down some rules of engagement using a variety of tools.
So really, you see, it's all perfectly easy to understand after all. And praise be for that!
Our network defense toolkit
Just as a castle has things like ramparts, a moat and a drawbridge, so our server has its defenses and wpCop's Server section is devoted to setting those up. In addition to the Server Networking Guides so far, over the course of the next few tutorials we'll be adding things like:
- An iptables firewall, else a pretty GUI-based firewall
- TCP wrappers, again to allow or deny access to stuff
Plus, we close unnecessarily open ports, we tighten some internal server settings called the network stack and, later in wpCop's Defense in Depth guides, we add a flashy piece of kit called a Network Intrusion Detection System (NIDS) and install an awfully clever web application firewall (WAF) that's designed to protect web platforms like WordPress.
So that's nice.
Let's take a closer look at the openings through which the server traffics data, and which pose such a risk to our WordPress sites and its underlying server (and to our local development machines, for that matter).
What are ports and which are which?
As said, ports are doorways, portals, things through which data passes in both directions. But because our hard work sits on one side of the entrance, openings are dangerous.
Some ports have to be open, 24-7, because we need them for things like – duh! – serving up our sites, for managing the server, for administering data and apps like WordPress, for accessing backups or, if we run a mail server, to enjoy all that spam. Then there are proxy ports, S/FTP ports, and another few besides.
We cannot close all these gaping holes, such as the ones serving up our sites, and wpCop is concerned largely with addressing precisely that problem. Then again, we can close almost all of them, so we will.
Bricking up the doors
The point is to close off as many ports as possible and to disable its corresponding service.
So what ports do we need? These are those most commonly used:
- 21 for FTP, a risky protocol best replaced by SFTP (which runs under the SSH port)
- 22 is the default port for SSH. We change it in Harden SSH
- 23 for Telnet. Don't use that. SSH is far safer
- 25 for SMTP e-mail. Close it unless you run a mail server.
(If you run Postfix or similar for e-mail using Google Apps, close it) - 53 for nameservers which very few of us run
- 80 for HTTP. You'll be wanting that one open 😉
- 110 for POP e-mail. Ditto port 25
- 443 for SSL/HTTPS. Leave that open for secure web pages
- 995 for POP again but now using SSL or TLS security. Ditto 25 again
As promised, wpCop outlines how properly to check what you need, closing off the rest, in Disable Daemons & Close Server Ports.
But …
If you want to get all preppy on ports then look at Wikipedia's expansive port number guide. Don't neglect the External links from that page, either. They include some delicious examples of port exploits.
Fired up on firewalls
As well as getting round to canning redundant services we must create access controls using a firewall, else check that what we have is up to par.
wpCop considers two splendid options. To recap:
- In the ConfigServer firewall setup guide we'll set up this cracking open source GUI that bundles its firewall with intrusion detection and some nice analysis features and which works nicely with Webmin that we set up in How to Setup Webmin (and Secure it).
- Alternatively we have the common-or-garden iptables solution, a packet filtering framework with which we manage rules from the command line.
Which firewall should I use?
The bottom line is that they both do the same thing.
If you like GUI's and have installed Webmin then you'll probably prefer ConfigServer.
If you are confident to use the terminal, else prefer not to use a control panel with the added risk * associated with opening its required port, then go the iptables route.
If in doubt, try both, gaining some education along the way and, if you do want to do that, vpsBible recommends first playing with iptables.
Either way, see you there.