Step 4 – putting it all together and letting the world in.
This document is the final part of a set of four which collectively describe:
Step 1 – upstream SMTP authentication using TLS with postfix;
Step 2 – getting a mailman listserver running with postfix;
Step 3 – configuring lighttpd with SSL for mailman;
Step 4 – putting it all together and letting the world in.
The document describes the final steps required to expose the combination of webserver, MTA and mailman to the outside world.
Up to this point, we have not allowed inbound connections. We have tested outbound connections to ports 25 and 995, and (possibly) also ports 110 and 587 on our upstream provider’s mail servers. None of this should have necessitated any change to your NAT firewall/router configuration. But the whole point of this exercise is to allow in connections to the mail server for delivery of mail to our list(s). We also want to allow members of the list to reach mailman on the webserver so that they can manage their subscriptions and read old postings.
Opening up a server to inbound connections from the internet is not a process to be taken lightly. You need to be certain that this is what you want to do before going any further. In particular, if you have only ever run linux on a home PC behind a NAT firewall with no inbound connections permitted, you may wish to think twice before going any further – and then thinking again, and again. You do not want to run mailman, a web server and an MTA on the same box that you use to browse the web and read your email. By far the best approach would be to run this set of services on a remotely hosted system secured and managed by a professional ISP or hosting service. There are plenty of good commercial companies out there who will provide all you need to do what we have described here. You could even rent a shell service on a remote server and build everything there. But I guess that if you have read this far, then you are intent on providing the service locally at the end of your DSL line – possibly on a slug. Bear in mind though, that you will be responsible for all traffic going out of your systems. You will also be charged for that traffic by your ISP. If you become the source of spam (or worse) you will be very unpopular and could easily lose your connection. The newly generated traffic on your DSL line could also impact on your own access to the net – perhaps slowing it at a time when you want to use it for some vitally important, bandwidth intensive, or low latency dependent activity such as on-line gaming.
Hardening a linux server and securing a network is a huge topic and way outside the scope of this set of documentation. It is something I may get around to writing about in future, but there are already a host of good references both on-line and (my preference) in paper form. So unless you are confident that you know what you are letting yourself in for, I recommend that you spend some time reading about hardening linux servers, securing web and mail servers and network partitioning before going any further.
That said, at the minimum this is what you need to do:
1. Disable all services other than the ones you require on the host you are about to expose. In this case that means that netstat will report listening services only on ports 22, 25, and 443. Port 22 is the ssh daemon (you have to manage the server somehow), 25 is the postfix MTA and 443 is the SSL web. You should not be running an unencrypted web service on port 80 (unless you really want or need to).
2. Firewall the server to restrict inbound connections to those ports (and in the case of the ssh daemon to restrict the source address to your management IP address) and allow outbound connections only to your upstream relay address on port 25. You will also need to allow out DNS queries on port 53 – but only to your local DNS server.
3. Ideally place the server on its own subnet within your network so that you can isolate it as much as possible.
4. Open up inbound connections through your NAT firewall to the server only on ports 443 and 25 and only by port forwarding. Resist the temptation to allow all traffic in to its address (typically described as “assigning the public address of your network to a device” or “allowing all traffic to a DMZ host” or similar). You never know when a future upgrade (apt-get dist-upgrade for example) might introduce or replace a service you believed you had disabled. That could bite you.
5. Check that your web server is not offering any “default” cgi scripts in cgi-bin. If it is, delete them. You don’t need PHP on the box, so get rid of it.
6. Check your log files regularly. Get to know what “normal” traffic patterns look like and be on the lookout for attack signatures. Typical signs that your are being probed are messages such as “Relay access denied” in your mail logs or long series of 404 status responses to GET requests for non-existent files in your web access logs (I get lots of probes for old PHP vulnerabilities). Consider installing a logwatcher to automate logfile analysis (take a look at logwatch, log2mail, swatch etc) and be prepared to spend some time tuning the watchers to get the level of alerts that you are comfortable receiving. You will be probed. Bots on the net will look for known vulnerabilities – typically they will be probing for open mail relays or open web proxies. Live with it, or disable inbound traffic. You can’t stop it happening.
7. Keep an eye on your router traffic. Beware of sudden spikes in outbound traffic. It could mean that you have been compromised and your server is being used as a proxy relay or as a warez store for malcontents. Be prepared to block the service quickly while you analyse what went wrong and clean up.
8. Resist any temptation to “fight back” or otherwise engage with any addresses logged which suggest that you are being probed. Apart from being largely pointless, a waste of bandwidth, and in many countries actually illegal, it is highly probable that the source address you have logged is owned by an innocent third party who has already been compromised and is simply host to a bot. The majority of probes will come from compromised home PCs sitting at the end of DSL lines – probably in the USA.
9. Firewall all other hosts (including your main PC) on your network to deny any and all connection attempts from the Mailman host. Of course, if you run DNS on a local machine other than your NAT router, you will need to allow that machine to accept DNS queries from the host, but nothing else.
10. Relax. If you can’t, you shouldn’t be doing this.
Now we need to tell the (legitimate) world that we are running a mail and webserver to allow them to connect. You will need access to the DNS for your domain. Typically this is provided by your ISP through some form of web based “control panel”. You need to do the following:
– set up an MX record pointing to your external IP address (not the internal IP address of your mailman host – that should not be reachable). The MX record should point to the name of the host set up in Step 1 above – i.e. “lists.ourdomain.org”.
– similarly set up an A record pointing the name of the web host (probably also “lists.ourdomain.org”) to the external IP address of your NAT router.
As mentioned above, if your ISP does not give you a fixed IP address, then you will need to map your variable external address to a fixed name through a dynamic DNS service such as dynDNS. You can then advertise the dynamic DNS name as the destination for your inbound mail and https traffic.
Good luck – and have fun.