Use Case: Debugging a firewall configuration

See also a video walk through of this scenario.

Fixing a problem in a firewall configuration is usually dominated by the effort of locating the problem. The actual fix is commonly simple and obvious once the problem is known. InfoSecter helps with fixing a problem by accelerating the process of locating the problem.

For example, an IT staff member has the problem that an external website ("whoville" at 10.10.100.106) is not reachable from an internal network on a firewall with "this" configuration. The staffer could put some sniffers on the network, run a series of network tests, or use InfoSecter to see if the problem is a misconfiguration.

The staffer first fires up Visualizer. From there, he selects "New Analysis", selecting a copy of the configuration file and specifying the "Tiling" option to dissect the configuration to its constituent actions. "Cross Interface" is enabled because the staffer wants to look at traffic crossing the firewall.

When the analysis is finished, Visualizer displays the results in a grid.

To narrow down the behavior, the staffer creates a filter. He wants to look at traffic from the local network to the external server for HTTP, and an action that denies the traffic. This can be done either by typing directly or using right clicks on cells in the grid that contain the appropriate values. In either case, the resulting filter is:

Destination Address ^ 10.10.100.106 & Destination Service ^ TCP:80 &
Source Address ^ 192.168.1.0/24 & action ^ deny

This yields a single line which specifies that the traffic is denied, but also has NAT applied, so it's necessary to look at the translated source address.

The staffer clicks on the grid row and the configuration display is updated to show the translation rule, which indicates that the translated source address is 2.2.2.0. Changing 192.168.1.0 to 2.2.2.0 yields one row which is a deny for a single host in the source network.

So an explicit deny isn't the problem for the subnet. The staffer removes the check for a deny action to get a broader view.

It's now clear that the traffic to the target server is being put in a tunnel, which is not according to policy. The traffic isn't arriving because the other side isn't expecting tunneled traffic.

Why is the traffic being put in to a tunnel? The staffer sees that there are three configuration lines contributing to this behavior, so he clicks on the which highlights the first of those configuration lines, which is the one that sets up the NAT. That's not the problem, and a click on the "next line" button. That brings up a firewall permit rule, which seems fine. The next line, though, is in fact a tunnel for the traffic. It uses an object group ("ng2") and a cursor hover shows that the group does include the "whoville" server.

Being familiar with the configuration and policy, the staffer realizes that it should be group "ng3" being tunneled (as hinted at by the previous line) and that "ng2" is just a typo.