Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It seems no one has asked this question before (most regard host-based firewalls).

Anyone familiar with port scanning tools (e.g. nmap) knows all about SYN scanning, FIN scanning, and the like to determine open ports on a host machine. Question is though, how do you determine the open ports on a firewall itself (disregard whether the host you're trying to connect to behind the firewall has those particular ports open or closed). This is assuming the firewall is blocking your IP connection.

Example: We all communicate with through port 80 (web traffic). A scan on a host would reveal port 80 is open. If is behind a firewall and still allows this traffic through, then we can assume the firewall has port 80 open also. Now let's assume the firewall is blocking you (e.g. your IP address is under the deny list or is missing in the allowed list). You know port 80 has to be open (it works for appropriate IP addresses), but when you (the disallowed IP) attempt any scanning, all port scan attempts on the firewall drop the packet (including port 80, which we know to be open). So, how might we accomplish a direct firewall scan to reveal open/closed ports on the firewall itself, while still using the disallowed IP?

share|improve this question

closed as not a real question by mdpc, Smudge, Chris S, MDMarra, Zoredache Nov 22 '11 at 17:54

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Since this is a site for systems administrators in a professional capacity, I would assume that most would just log into the firewall and look at the ACLs to see what is blocked. – MDMarra Nov 21 '11 at 20:51
Unless the firewall implementation was extremely crappy, there is no way you should be able to determine the set of rules/policies that are applied without attempting to communicate systems that it was put in place to protect. Even then you wouldn't k now much because there could be additional devices behind the firewall also filtering. – Zoredache Nov 21 '11 at 21:26
MarkM: I understand your point (and you're correct), but that line of thinking is narrowing the subject matter. A network administrator has three roles (depending on how you want to look at it). 4) maintain functioning of the network. 2) be able to upgrade/change the networked machines accordingly. 3) modify existing configurations to enable/restrict user usage. And 4) maintain confidentiality, integrity, and assurance of operations where appropriate. This has everything to do with security preparedness. – Rahl Nov 21 '11 at 21:27
Zoredache: That is an excellent point (in reference to my below conversation with Shane Madden), in that there be other network points along the path between the firewall and host trying to be connected to that confuse matters. – Rahl Nov 21 '11 at 21:30

You don't. There's no distinction, from a packet filtering perspective, between what the host is showing you and the firewall is showing you. If you scan the firewall's IP address itself (assuming it has an IP address at all), it's unlikely to be using the same rules as it does for traffic bound to the host behind it.

However, in some configurations, you may accidentally be shown what the firewall is allowing.

Take the example of a host that responds to traffic on ports that it's not listening with a rejection (a RST packet, which is normal TCP behavior), and a firewall that drops traffic silently. Say the host listens on only 80, but the firewall lets 80 and 25 in to it. The firewall lets through the port 25 traffic, which the host rejects, port 80, which the host connects, and blocks all others.

nmap would show that host as having port 80 open, port 25 closed, and all other ports filtered. nmap's built to show when this kind of difference is present, to help you determine the behavior of the host that you're looking at.

share|improve this answer
Yes - this is close to what I'm talking about. :) What kind of scanning technique would you use with nmap (or any other tool) to accomplish getting the firewall to respond (even if it's a RST packet)? That's what I'm trying to explicitly determine. – Rahl Nov 21 '11 at 21:01
@Rahl You can't send traffic to the firewall directly, you're always sending it to the host and trying to discern the firewall's behavior. If it's set to not respond, then it's not gonna, no matter how you scan. – Shane Madden Nov 21 '11 at 21:04
That's what I would suspect (an employer suggested otherwise to me - hence my investigation here). Sticking with that assumption (I'll have a chat with him later), how would you go about determining all the open ports on a firewall (there's no interest in knowing which ports are open on the host in this scenario). My thinking is that (social engineering wise), you could set up a machine behind the firewall that accepts all port traffic. Then, from outside the firewall, you can contact that machine on every port and whatever port responds with traffic is an open firewall port. – Rahl Nov 21 '11 at 21:08
This social engineering attack would still be flawed however, because the packet filtering of the firewall would block the IP address. And since IP spoofing isn't possible in this scenario (reverse dns lookup resolves this issue) (and we're assuming a legitimate IP address isn't compromised), this ultimately would seem not to work. – Rahl Nov 21 '11 at 21:11

If you use a web service to perform the port scan, or run the port scan against your external IP address from an external location, you'll see which ports are open on the firewall.

This is the first web service I found by doing a Google search; probably others out there too:

share|improve this answer
I think he's talking about scanning an unknown firewall from outside of his own network. – MDMarra Nov 21 '11 at 20:52
Thank you for the answer, unfortunately the probe tool doesn't work against firewalls. It only works against hosts. I'm not looking for a program to solve this problem though, I'm trying to learn about a technique that could be effective (e.g. christmas scanning or fragmented fin scanning). – Rahl Nov 21 '11 at 20:56
MarkM: Precisely. Scanning from "outside" of the network and not being listed on the "allow" (thus, inherintly "disallowed") list of the firewall, that screens by IP address. And I'm not looking for answers related to IP spoofing (wouldn't work anyways, due to reverse dns lookups) or social engineering tactics - just wondering how you port scan a firewall. – Rahl Nov 21 '11 at 20:57

If you own the firewall and want to perform functional tests against it, you can set up a sniffer on a spanned port of the switch connected to its DMZ interface prior to your scan. That way, you can catch any occurrence of packets that got through, even if the target host happens to be down or doesn't respond on a particular port. It gives you more visibility than the tool performing the scan can provide.

share|improve this answer

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