A firewall is a complex device that can be easily misconfigured. In this video, you’ll learn about connectivity misconfigurations, security policy problems, and misconfigured ACLs or applications.
<< Previous: Troubleshooting NIC TeamingNext: Troubleshooting Operating System Security Issues >>
When you’re working on configuring a firewall, there are a number of things that can go wrong. You should first look at how you’re accessing the firewall. Check the management interface. This is often another interface on the firewall that is completely separate from the firewall interfaces.
You want to check the IP address, subnet mask, default gateway as if you were configuring it as an individual device. Once you know that you can configure the firewall from its management interface, we can look at how the firewall is physically connecting to the rest of the network.
In a previous video, we looked at the differences between a virtual wire, a Layer 2 bridged, and a Layer 3 routed configuration for a firewall. So you should, of course, check to see how your firewall’s configured and confirm that it is connected to the network in the proper way.
Because a firewall is a relatively complex device and the interfaces on the firewall can be configured in so many different ways, it’s a very good idea to confirm exactly what cable is plugged into what interface and what happens to be connected to the other side of the cable. You may want to trace back the cables and confirm that you’re getting a feed from exactly where you expect, or you may be connecting to the wrong interface in the wrong way and getting no throughput through the firewall.
If you’re connecting the firewall in a Layer 3 mode, then it is effectively a router. And you’ll want to check the routing tables of the firewall to make sure the data is flowing in the ways that you would expect. In some ways, logging what the firewall is doing is often just as important as the control that the firewall is providing.
So you may want to check how your firewall is logging. Is it writing logs to a local drive? Or is there a drive across the network that it’s sending syslog information to? You want to check and make sure that you’re logging this information. Maybe you’re logging it to multiple locations. You want to be sure that all of that data is there so that you can create historical reports and go back in time to see what passed through the firewall at a particular time and date.
Once your firewall is up and running, the connectivity correct, your routing tables are fine, and you’re logging the information in the way you would expect, now we need to look to see how the security policies themselves are configured. You have to find some way to take the business requirements that have been given to you and translate those into a form that the firewall will now be able to process.
Of course, you want to protect the data that’s inside of your organization. But at the same time, you have to allow people to pass through the firewall to perform their jobs. Your firewall rules are usually evaluated from the top rule. And they go all the way to the bottom rule from there. And they’re followed in order from the top to the bottom.
If you’re having a problem getting data through the firewall, you may want to check the logs and see what rule is blocking the information that you’re trying to pass through the firewall. Any time traffic is denied, there is usually an entry made in the logs so that you can see exactly what happened and what rule happened to cause this data to be denied.
Some firewall administrators will put a Deny All rule at the bottom of their security rules, which effectively makes this an explicit Deny rule base. That means that if any traffic is evaluated and it goes through the entire security rule base and gets to the very last rule, it is automatically denied, and therefore also written to the log.
Some firewall rule bases are very large. And if someone is having a problem communicating through the firewall, you yourself may have to start at the very top of the list and use your own reasoning skills to determine where along the way this particular traffic is getting denied.
Many firewall access control lists or security rule tuples will include source IP address, destination IP address, interface information, or other details. So you’ll want to find as much of that information as possible when you’re trying to determine why some traffic might be allowed or dropped through the firewall.
You also have to consider, especially for firewalls that are in a Layer 3 mode, if network address translation is enabled and how the firewall handles performing the NAT. Does it evaluate the traffic prior to performing the network address translation? Or does it perform the network translation first, and then evaluate through your security rules? You’ll have to check with the manufacturer of the firewall to determine how it’s handled on that particular device.
And some firewalls are smart enough to know exactly what application you’re using. They don’t need an IP address or a port number. They’ll recognize if someone’s trying to post to Twitter or if somebody is trying to use the administrative functions of SharePoint. And you can tell your firewall to allow or deny that traffic based on the application criteria.