"Reverse" firewall testing?

April 10, 2008 8:30 PM

Simply put, I would like to determine which (outgoing) ports are open and which are closed on my company's network. They have a firewall blocking most ports...so far I can only get through port 80 and port 443. I know for example, ports 23, 25, 110 and 6667 are blocked. So I may be over-thinking this, but what I think I need to do is find a way to listen on all ports (or at least a select list) on an external computer, then scan that computer's IP from inside the network to see what connects... The catch: I would like to open these ports for connections without having to install servers that actually use those ports. If we're talking a couple hundred ports, I don't want to install and configure a couple hundred server apps. (or all 65535?) Does anyone know of an app that will open 'fake' ports on a system and respond with some sort of generic server type? I know I've seen such an app before, but I just don't remember what it was called, and my google skillz are not coming through this time. Side note: I originally thought what I was looking for was a "leak tester" ...but this isn't quite right, as it is testing incoming ports, not outgoing ports. Thanks,
posted by AltReality to Computers & Internet (10 answers total)

Response by poster: Why did my fancy formatting go away when I hit the post button? It was looking good in the preview window. weird.
posted by AltReality at 8:31 PM on April 10, 2008

nmap and netcat
posted by iamabot at 8:34 PM on April 10, 2008

Portsentry will monitor all ports not opened otherwise and log the accesses thereto. Then nmap the IP address from the inside.
posted by rhizome at 8:47 PM on April 10, 2008

Best answer: In my experience it's pretty common to set 80 and 443 as the only two outgoing ports allowed, so I wouldn't be surprised if every other outgoing port is blocked.

Does anyone know of an app that will open 'fake' ports on a system and respond with some sort of generic server type? I know I've seen such an app before, but I just don't remember what it was called

Are you thinking of a Honeypot? It fakes generic server messages to try to catch or distract would-be attackers. Honeyd is a good one, and should be able to run fake servers on all of the ports on a machine.

For automating the testing of each port, you'll want to use a port scanner, such as iamabot's suggestion (nmap).
posted by burnmp3s at 8:50 PM on April 10, 2008

You realize that ports are blocked for a reason and that your IS people may be able to detect that you're probing the firewall. And that this may be a violation of your company's IS policies. And that you could maybe get fired.

If you're not in charge of the corporate firewall you probably shouldn't probe it. Just FYI.
posted by GuyZero at 9:16 PM on April 10, 2008 [1 favorite]

Best answer: Nmap the AOL IM login server. It listens on every port, so it will show you everything that's not blocked.
posted by kiltedtaco at 9:25 PM on April 10, 2008 [1 favorite]

trying-to-guess-what-you're-really-trying-to-do-filter:

Corkscrew can tunnel ssh through port 80. Openssh can tunnel any other port over that ssh connection.

Just sayin'.
posted by qxntpqbbbqxl at 9:26 PM on April 10, 2008 [4 favorites]

Response by poster: Wow thanks for the quick responses!
I think the AOL IM thing is the easiest idea....but I will check out the honeyd option as well..

And GuyZero and qxntpqbbbqxl, Thanks for the comments, although I've been tunneling SSH through port 443 for 2 years...I learned from one of the techs the other day that the system is not monitored...

I suppose they could monitor for a scan of successive ports, but I think nmap has options to scan out of order, and possibly to delay the scans over a time period.

Eh..I'm quitting the job in a week anyway...getting fired wouldn't be the worst thing hehe

Thanks everyone
posted by AltReality at 9:44 PM on April 10, 2008

If you're interested in TCP ports, you don't need them to be open on the remote end -- closed ports will respond with an RST, filtered ports you'll simply never hear back from. I would suggest reading the nmap documentation.
posted by dreadpiratesully at 6:23 AM on April 11, 2008

Although I suppose I should add that the firewall could spoof RST packets from the destination, and this behavior might be the default for some firewalls.
posted by dreadpiratesully at 6:27 AM on April 11, 2008