Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am a programmer in an argument with our sys admin. Currently on our webserver (not in a dmz) we have port 80 blocked and the https port (423) i believe unblocked. The admins reasoning is that it secures the server. I informed him that there are 0 hacks/attacks over port 80 to worry about. Can anyone point me to some literature supporting/refuting my claim. Thank you very much.

environment windows server 2003 serverpack 2

share|improve this question
2  
HTTPS typically travels over 443/tcp. –  EEAA Jul 19 '11 at 14:37
    
I wish the stack exchange network would force users to give a reason for a down vote. So the commentor/questioner would know why their comment/question was downvoted. –  george9170 Jul 19 '11 at 14:54
1  
There are NEVER "0 hacks/attacks". Full stop. Never assume security, unless the computer is turned off and buried in a hole. As a developer, you should be well versed in attack vectors over the http protocol - protocol vulnerabilities (ie SSL renegotiation) and service vulnerabilities (ie directory traversal) aren't your problem, but numerous flavors of application vulnerabilities certainly are. –  Shane Madden Jul 19 '11 at 14:56
    
@george9170: Hover over the 'downvote' button -- the tooltip tells you why it was downvoted. –  womble Jul 19 '11 at 18:01
    
When I'm setting up a webserver I reflexively block port 80 as well. Too many things default there and leave themselves half-configured and open to exploit. Once the server is ready to use, I open it back up if there is a good use-case for it. And claiming port 80 has no hacks/attacks is sophistry... you're working on a webserver and that is default port for webserver software. –  Mark Jul 19 '11 at 19:52
add comment

3 Answers

up vote 10 down vote accepted

There is much more to securing a server than just blocking a few ports. Typically on a server, you implement a "default deny" policy that blocks traffic to all ports and then you exempt only the specific ports that you need. So if you don't need ports 80 and 443, then by all means, they should be blocked.

You are most likely correct in saying that there are no known vulnerabilities directly against port 80. What you need to ask yourself is whether or not there are any vulnerabilities in whatever application is listening on those ports. That is where security issues happen 99.9% of the time.

It sounds like your aim is to force users of your application to only use the HTTPS channel via port 443. Rather than outright blocking port 80, I would highly suggest opening that port up and just doing a redirect to HTTPS for any clients that connect there. That way, users can type in "example.com" in their browser, and they automatically get redirected to "https://example.com". This is not a necessity, but it is generally a good practice to improve UX.

share|improve this answer
5  
+1 Typically the application listening on TCP/80 is also the one that would listen on TCP/443 meaning that turning off TCP/80 wouldn't offer any additional security. If an application listening on TCP/80 has a security issue, it is highly likely it also has a the same security issue even on TCP/443. The purpose of providing SSL/TLS on port 443 is verification and encryption as opposed to defending against hacking attempts. That said, from a sysadmin POV unbinding TCP/80 reduces the attack surface because any ports not specifically required should be disabled. –  Lewis Jul 19 '11 at 15:01
add comment

It is a lot more about the services listening on that port than the port itself. Even Skype can listen on port 80 (caused a lot of headaches setting up WampServer before I found out what was using the port!)

It's a good idea not to open any ports that aren't needed. If there aren't any exploits for IIS out right now (and I doubt it), there might be in the future. Why leave the port open for kicks and giggles if you don't need it?

Also, wouldn't it be a good idea to back up your claims before using them in an argument? It seems pretty funny to me that you lied to your sysadmin, and then came running for us to back you up. :)

share|improve this answer
    
There must be some confusion. I said "There are 0 hacks over port 80" Which the port itself is in question Not what software you are running. The other users understood the question, can you tell me what i should rephrase in questions like this in the future so they are not ambiguous. My question itself is not a lie, it is a fact. As I have accepted an answer stating so. Again, please tell me how to make my question clearer for people to understand. –  george9170 Jul 19 '11 at 14:58
    
You're right that there are no attacks on the port itself, but it's easy to assume that you would be running IIS on that port if you're on Windows Server 2003 and that you're using port 443. Now, if no services are running on the port for whatever reason, you are correct in saying no attacks are possible, but that is still not a good reason not to firewall the port. –  gparent Jul 21 '11 at 14:13
add comment

Here is a list of exploits that can use port 80: http://www.doshelp.com/Ports/80.htm

As I understand it, if you leave IIS in default configuration, port 80 is the point of entry for any exploit targeting IIS.

At the end of the day, any open port can be a vulnerability, which is why ports that aren't needed should be closed. Obviously, a web server has to listen on some port, so service and OS hardening is an important part of running a web server. Microsoft has extensive guidance on this subject -- search TechNet for "server hardening" and you'll find the information you need.

This doesn't definitively support or refute your claim, but hopefully it will help you and your sysadmin think through the issue together.

share|improve this answer
add comment

Your Answer

 
discard

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.