Detect outgoing port blocking with nmap and portquiz.net

By Michael Altfield, on July 3rd, 2018

This post will describe how to detect if your network is blocking outgoing ports. In this test, we'll be using nmap and the fine website portquiz.net

The Problem

As a sysadmin, I often need to access services running on ports other than 80 and 443. Of course, I spend about as much time interacting with servers over ssh as I do in a web browser.

As a traveling sysadmin, I'm often confounded by the silly ways that other sysadmins have attempted to "secure" their networks and "enforce" censorship. Indeed, I was quite shocked today to find that (when I visited the San Bernardino County Public Library in Twentynine Palms just outside Joshua Tree National Park in Southern California) I couldn't ssh into any of my servers!

user@ose:~$ ssh opensourceecology.org
ssh: connect to host opensourceecology.org port 32415: Connection timed out
user@ose:~$

My server wasn't down. To be sure, I tried my personal server; it failed too.

user@personal:~$ ssh michaelaltfield.net
ssh: connect to host michaelaltfield.net port 2222: Connection timed out
user@personal:~$

The Test

To get a list of common outgoing ports that are _not_ blocked on your network, run the following command:

user@personal:~$ nmap portquiz.net | grep -i open
21/tcp   open   ftp
80/tcp   open   http
143/tcp  open   imap
443/tcp  open   https
465/tcp  open   smtps
587/tcp  open   submission
993/tcp  open   imaps
1935/tcp open   rtmp

If you're patient and want a more complete list, you can try this command--but know that it will take significantly longer to complete:

user@personal:~$ time nmap -p- portquiz.net | grep -i open
21/tcp   open   ftp
53/tcp   open   domain
80/tcp   open   http
143/tcp  open   imap
443/tcp  open   https
465/tcp  open   smtps
587/tcp  open   submission
993/tcp  open   imaps
1935/tcp open   rtmp
4070/tcp open   unknown

real	3m48.324s
user	0m18.885s
sys	0m29.077s
user@personal:~$

Note that the second command showed one additional port.

As you can see, the malicious middleware installed at the SBC Public Library is blocking all outgoing ports except 21, 53, 80, 143, 443, 465, 587, 993, 1935, and 4070.

Why this works

This test works because of the way portquiz.net is utilizing iptables to forward all tcp ports (excepting ports 22, 21, and 25) to their webserver running on port 80. Their "Portquiz.net : how it works" page shows their iptables configuration:

# Generated by iptables-save v1.4.14 on Sun Aug 25 12:43:34 2013
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i lo -j RETURN
-A PREROUTING -p icmp -j RETURN
-A PREROUTING -m state --state RELATED,ESTABLISHED -j RETURN
-A PREROUTING -p tcp -m tcp --dport 22 -j RETURN
-A PREROUTING -p tcp -m tcp --dport 21 -j RETURN
-A PREROUTING -p tcp -m tcp --dport 25 -j RETURN
-A PREROUTING -p tcp -m tcp --dport 80 -j RETURN
-A PREROUTING -p tcp -m tcp --dport 443 -j RETURN
-A PREROUTING -p tcp -j DNAT --to-destination :80
COMMIT
# Completed on Sun Aug 25 12:43:34 2013
# Generated by iptables-save v1.4.14 on Sun Aug 25 12:43:34 2013
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j DROP
COMMIT
# Completed on Sun Aug 25 12:43:34 2013

The Solution

Obviously, if my ssh server was running on port 21, 53, 80, 143, 443, 465, 587, 993, 1935, or 4070, then I would be able to ssh into it from the SBC Library. Unfortunately, I can't ssh into it to change that (catch-22!). Fortunately, there's almost always an Internet Cafe across the street that doesn't feel the need to implement such invasive censorship techniques..

In general, it may be wise for the traveling sysadmin to have some jumphost on the Internet with sshd running on port 443. Or, better, an image of a server with such a configuration sitting on a cloud service somewhere that can be spun up as needed from a web browser.

And, god forbid, if they ever try to block SSH with DPI, there's always stunnel.