tl;dr Vidéotron ISP blocks incoming connections on TCP ports 25, 54, 80, 135, 137, 138, 139, 445, 646, 711, 1080 and 4444.
For some time, I wanted to host my own web server from my home network. It was not intended for my main website since I want to mess with my home server. As I was settings up Apache, I noticed that I was not able to reach my web server from outside my LAN. I already have a few ports redirect (SSH, media server, Git server, etc.) for services that I want to reach from the WAN, and I never had a problem. But for some reason, I was not able to reach the default HTTP port 80.
I fired up Wireshark to understand that connections are getting dropped.
After a few searches, I understood that my ISP Vidéotron (one of the big players in Québec province) is blocking incoming connections to multiple common ports, such as 25 or 80. This is very unfortunate…
I’m guessing their rationale is if you are hosting are public server at home, you should be paying for an enterprise connections. They might argue that they are preventing malware traffic, i.e. preventing infected clients to act as a spam server. I feel that it’s mostly pecuniary and, in the case of a web server, causing more harm than good.
Whether the reasoning, I am stuck behind their firewall and its rules. To circumvent those, I could host my server on an unblocked port, such as 8080. I know that this solution suits a few people, but I do not like it for me. I purchased a fancy (not so fancy) domain name and I would like to hide “:8080” from that URL. Another bypass would be to rely on a third party, such as NoIP, to redirect incoming traffic. Personally, I do not like that solution. If possible, I would avoid adding another actor in the equation to prevent failure. On top of that, NoIP is pushing pretty hard their paid products but I don’t blame them for it.
I solved my problem with hosting on 443, which is not a blocked port. In 2017, web hosting should be HTTP SSL encrypted. I believe my ISP is inconsistent since, to help prevent malware traffic, they should block 80 and 443. Because of this irregularity, I chose to investigate to understand which ports are blocked for incoming connections. For this work, I went with the most trivial solution in my experience: open all the ports and try to reach them from outside my LAN.
First, I redirected connections on all ports to my dedicated virtual machine. Unsurprisingly, the web UI of my gateway did not allow me to redirect a big range of ports. Such validation was only client side, so I was able to tamper the form request.
I then had the first 10 000 TCP ports opened and redirected to my dedicated machine.
Second, I modified a Python script that uses multithreading to spawn multiple TCP servers. My script relies on the native modules SocketServer and threading. It was surprisingly easy on the memory, but I believe memory usage would spike with active connections.
Having everything setup, I was ready to start the test. I chose to only check the first 5000 TCP ports. It would have been very surprising to find anything blocked after the port 1024 but we never know what we can find.
With Nmap, I scanned my home network from my VPS to discover that 12 ports were filtered: 25,54,80,135,137,138,139,445,646,711,1080,4444. I present each port with its common associated application, as defined by the IANA.
- 25: SMTP, protocol used by mail servers. By blocking this port for incoming connections, spam relays are mitigated.
- 54: Apparently, Xerox Network Systems. I have no idea why this port is blocked.
- 80: HTTP
- 135, 137, 138, 139 and 445: Microsoft end-point mapper, NetBIOS services and SMB. Vulnerabilities in Active Directory environment are frequently exploited. By blocking ports associated with those, ISP are reducing attacks surface since such ports should not be open to the WAN.
- 646 and 711: Protocols used by routers (LDP and TDP). It is possible that my gateway uses those ports, so they might be false positives.
- 1080: Commonly associated with SOCKS to make use of proxies. Frequently used by malware to communicate to command and control center or to open a backdoor.
- 4444: No commonly associated protocol. Could be Kerberos, and is the default port when creating a Metasploit payload. I do not understand why they are blocking this port since malicious payloads typically do not use the default port.
There it is. I did not test UDP ports, so I have no idea about a home DNS server or VPN server. Future works.
Fun fact: During the few seconds that all of my ports were opened, I received a few connections. Dem internet bots always scanning for low-hanging fruits!