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.
Related Posts
Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡
Hehe... catch-22
Funny they don't call it catch-443 or catch-80