Why shouldn't I run my non-web server software on port 80?

Question

Considering there are so many draconian firewalls in the world, is there any reason I shouldn't run server software on port 80 to guarantee greatest possible accessibility? It seems that the most common firewall exception is to allow outbound connections on port 80. I understand that any sort of packet inspection would still block my non-HTTP traffic but if that is the case I'm sure the firewall wouldn't have any other open outgoing ports anyway.

If the server already has a webserver on port 80 is it possible to use some sort of virtual host listening on port 80 (i.e. myDomain.com:80 and myApp.myDomain.com:80 on the same machine)?

Answer 1

To answer you second question "is it possible to use some sort of virtual host listening on port 80":

Yes, there is, and it called virtual hosting and are handled by most modern webservers. But then all the requests from your application has to start with the HTTP protocol 1.1, where a host is specified. Your application probably has to be a CGI application . But thats probably not what you want.

The other way is to let your application take control of port 80 and redirect all http-queries to the webserver. Its messy and if your application goes down, so does the webserver.

The solution is to have more than one IP-address on your server (you can bind more than one ip-address on a nic). Then you can bind mydomain.com:80 at address 1 to the webserver and myapp.mydomain.com at address 2 to the application, but they still are on the same server.

And to answer your first question: "is there any reason I shouldn't run server software on port 80": Yes, it is bad practice. Expect to get a lot of http-queries from automated scanning. You can choose to answer them with a correct http-header or ignore them.

Answer 2

I can think of two reasons: first, if you're doing it to get around a company firewall you'll be in violation of security policy and second, you'll be using a reserved port for a protocol that it isn't registered for which could cause significant confusion to clients trying to interact with your system (like, Google, for instance) and significant headaches for your application when they do.

EDIT On Unix systems low numbered ports require privileged accounts to run. This would be another reason to avoid doing it in that environment as your application may need higher privileges than otherwise required.

Answer 3

It is not possible to do virtual hosting for other domains listening on port 80. Only one process can listen on a port. Virtual hosting happens at the application layer based on the HTTP headers.

The other problem you may run into is proxy servers. Not the sort that the user sets up, but automatic proxies by companies or ISPs. These won't understand your application's protocol and will likely fail.

Lastly, if your application is running on a Unix/Linux variant, port 80 will require root privileges.

Answer 4

If you need to do this, why not just wrap your network comms code with a SOAP interface or an HTTPHandler?

Then your packets will conform to HTTP, you'll get through firewalls and everyone's happy?

It will be much easier than resolving all the installation and operations issues you'll get from multi-purposing port 80.

Answer 5

I will confess to having worked around a Draconian firewall by having an ssh server listen on port 80 back home and using ssh tunnelling to provide access to other servers and services. I hasten to add that I did this with the blessing of the people administering the firewall---we all agreed that it was the best solution to the problems at hand.

I hasten to add that this tactic renders port 80 useless for its intended purpose, which was fine with me since it was my personal workstation anyway. If you have only one machine in your domain it would be a problem. But having a machine I could dedicate to serve ssh from port 80 created no installation or operations issues. I just ran /etc/init.d/apache stop and then ran an sshd to listen to port 80. Then I was good to go for the few months I needed to do this.

Automated scanners who come knocking on port 80 of my personal workstation can go hang :-)