My school has a firewall which limits most outgoing ports. There're only TCP/80, TCP/443, TCP/21 allowed. Is there's a way to find out all the outgoing port allowed by the firewall?

My current idea: open all TCP ports with nc on a remote server, then use nmap to scan which ports are accessible. But how do I do if I don't have a remote server? or is there a public server that opens all the ports for this kind of tests?

For those who are concerning that I'm breaching the school's rules, I think it's not a big deal to do that. Suppose I was establishing a service in external host and wish it to be accessible by the school network, I would be willing to know which ports I could use for this service. I was not breaking anything. I believe doing it is 100% legal.

  • What kind of firewall? Is it linux based? Does it have IPTABLES? tcpdump? – cybernard Jun 16 '13 at 15:07
  • @cybernard I don't know. I don't have permission to access the firewall. It shouldn't have very complex rules, as seemly all port blockage is only done by dropping the packages directly. There should be no content filter I guess. – Shou Ya Jun 16 '13 at 16:52
  • Do you have permission from the school to do this? – cybernard Jun 16 '13 at 17:32

You can use portquiz.net, which is exactly the kind of server you're looking for. For example, following shell script does the job:

for x in `seq 1 65535`; do

    echo -ne "$x "
    curl "http://portquiz.net:$x" \
      --connect-timeout 1 \
      -o /dev/null \
      -q >/dev/null 2>&1 \
        && echo 'open' \
        || echo 'closed'

done | tee ports.lst

Note that this is going to run for quite a long time, so if you're impatient, you can parallelize the task using GNU parallel.

Also, some ports on portquiz seem to be blocked on their end (as far as I remember they're ports for SSH and HTTPS), but other than a few special cases, all of the remaining ports should be open.

  • --max-time 1 or -m 1 on curl will limit the total amount of time it is allowed to take, making this much faster. – comp500 Jan 10 '18 at 17:13

You could see if there's a different response for "Invalid outgoing port" versus "Valid outgoing port but no response from server." For example, if you know port 6667 is invalid, see what response you get (e.g. from telnet) when connecting to a server with a known 6667 port open. Compare that to the response from a non-open port on a server that is allowed by the firewall. If you can distinguish the two, then you don't need that extra server. Otherwise, you do.

Or, just ask your IT admin.

  • 1
    Most of these efforts are not entirely valid if your traffic is also subject to packet inspection, and not simple Allow/Deny connect rules. – maxwellb Jun 16 '13 at 9:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.