Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our current hardware firewall allows for blocking incoming and outgoing ports. We have two possibilities:

  1. Block certain troublesome ports (unsecured smtp, bittorrent, etc.)
  2. Block all but a few approved ports (http, https, ssh, imap-ssl, etc.)

I see several downsides with option 2. Occasionally web servers are hosted on non-standard ports and we would have to deal with the resulting issues. Also, there is nothing preventing a malicious or unwanted service from being hosted on port 80, for instance. What are are the upsides?

share|improve this question
Tough first day? – Campo May 10 '10 at 19:05
You say that you sometimes have webservers hosting on non-standard ports--Wouldnt you want to know what webservers are hosting on what ports? I would think #2 would be a positive in that regard. – Josh Brower May 10 '10 at 20:21
For 1, if you are trying to prevent bittorrent (or other protocol) use, realize that people can still proxy/VPN to another machine and bypass your restrictions. Eg, in a school, adding firewall/hostname restrictions is a great way to teach kids about how to use proxy and VPN servers (which can be run on port 80, thereby not getting filtered by your simple firewall). SMTP is an exception, since malware can't proxy/VPN (it would defeat the purpose of sending spam from millions of random IPs), and 25/tcp is absolutely required for delivering messages to any mail hosts on the internet. – gregmac May 10 '10 at 20:43
"Occasionally web servers are hosted on non-standard ports" - I would say "occasionally" is an overstatement. We have a setup like #2, and in the total lifetime the firewall has been in (say 5-ish years) we've had to open 2 non-standard ports for web traffic (then, we limited that port to the remote web servers IP). IMHO #2 is the way to go. – Ben Pilbrow May 10 '10 at 23:43

In scenario (2), if a machine within the networks becomes infected by some malware, you prevent it from either sending mail (if you block or transparently proxy SMTP), or connecting to the IRC channel it’s designed to be remote-controlled from (or similar backdoors).

Edit Obviously, in either of these scenarios it’s not going to stop everything, but it will stop quite a lot of the common bots from turning your network into a source of spam e-mail and the like.

share|improve this answer
+1; or downloading harmful payload. – pQd May 10 '10 at 19:46
It will prevent naive malware - if they're using port 80 or 443, chances are those aren't blocked so it will still operate. Blocking port 25 to all but your own SMTP server is a very good idea though, since port 25 is actually the only port that can be used to deliver mail directly (without relaying) and thus will make spam trojans ineffective. – gregmac May 10 '10 at 20:40

The upside is that you stop everything which cannot adapt (spam email malware, etc) and everyone who doesn't know how to get around it.

The other answers here seem to be of the nature "whatever you do I will get around it so don't even bother trying", but the majority of people do not know how to do things to get around firewall restrictions so you reduce the risk of trouble a lot.

On top of that, if someone can get to a service outside your firewall first try because the port is open, that's one thing, but if they have to deliberately work their way around your firewall that's quite another. It might give you more evidence to demonstrate misuse of computer systems, for instance.

And for regulatory compliance or auditing reasons you might need to justify every port open on your firewall, it would be better to be able to say "Port 1433 outbound because accounts need it for program Q even though it might open the door to some misuse" than "SQL works because we haven't bothered blocking anything".

tl;dr: Security isn't about one silver bullet solution which fixes anything, and option 2 can be another layer in helping to reduce risk and misuse.

share|improve this answer

If someone was going to run bittorrent on say port 80 it really makes no difference which option you choose but option 2 gives you a better chance of blocking unwanted traffic. You mention the possibility of having to open extra ports for special web sites but, depending on your firewall, you may be able to open those ports only for specific targets.

With option 1, when you start blocking ports to restrict traffic that traffic will almost certainly move to another port. In the end you'll find you need to close so many ports that you're pretty much back to where you would have been had you chosen option 2 at the start.

Bittorrent doesn't run on any particular port, so forget any dream you may have of blocking it that way. Even blocking access to all known tracker sites is pretty ineffective with today's trackerless systems.

There are admins who believe they have successfully blocked bittorrent traffic from their networks. Based on my own experiments as a bittorrent user I don't think I could ever be that confident. Of course I don't have access to all the different makes and models of firewalls to test against, so may simply be unaware of an effective system.

share|improve this answer

A simple answer is with #2, you don't need to be an expert on the use of every port, just the ones actually allowed by you. When a new IM/P2P service comes out that uses a different default port you don't have to do a single thing to block it. Option #2 also it allows you to know exactly what protocols are in use on your network and who asked you for them to be made available.

share|improve this answer
Knowing which ports are open is not the same as knowing which protocols are in use. Any protocol can be made to run on any port. – John Gardeniers May 11 '10 at 10:54
True. If you opening outgoing ports you can't audit the protocol without additional work (i.e. packet inspection.) But if you are opening incoming ports you can audit the application binding to that port on the server. Any rogue application using an already bound port would need to replace an existing application which would cause a service outage you are likely to notice. – Chris Nava May 11 '10 at 18:36

I prefer option #3 - block access to all ports, and proxy the services you need. In the vast majority of cases, this works well. In fact, most of the time, all you need is a web proxy - as mail is frequently handled by an internal server (or use outlook's RPC-over-http).

Most web proxies will also let you specify which ports you're allowed to make HTTP connections on - so you don't have to open up firewall holes for non-standard sites. Additionally, a web proxy may (depending on setup) give you some protection against users abusing that service by tunnelling VPN etc.

As Mo says, it's also highly beneficial from the perspective of limiting the spread of malware, and indeed those grey areas where users try to use their own software or email accounts. Even if you do want to allow that, you'd want to know first, I hope!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.