Stateful refers to the “state” of the connection between the outside internet and the internal network. A stateful firewall keeps track of the connections in a session table. When a packet comes in, it is checked against the session table for a match. If a match is made, the traffic is allowed to pass on to its destination.
Older firewalls (Stateless) relied on Access Control Lists (ACLs) to determine if traffic should be allowed to pass through. In stateless firewalls, the firewall’s default rule is to block, then the ACL is used to tell the firewall what should be allowed to pass through it and in what direction (e.g. HTTP traffic, Email traffic, Secure FTP traffic…)
ACL Example
An explanation for the layman
When a user surfs to a website, he/she asks that website to send information back. As the user’s traffic passes through the firewall, the firewall records some information, namely the port where the traffic is coming from and the destination port. At the same time, the firewall creates an entry in the session table allowing for traffic to flow back in the reverse direction, so that the webpage can respond to the user.
Session Table Excerpt
When traffic returns to respond to the request, the firewall checks its session table and if a match is found, the traffic is allowed to pass, otherwise the firewall performs extra checks (i.e. it checks against an ACL/Firewall rules) to verify if the incoming traffic should be allowed to continue or be blocked altogether.
The life of a session (the amount of time the connection is allowed to stay open) can be determined a few different ways, by either specifying a Timeout in the Firewall, relying on Client Side Cookies which will remain for the duration of the browser session, or simply by the sessions being dropped from the table as it fills up.
Considerations for the Auditor
Stateful firewall determines what is allowed to come in based on what was allowed to exit. The next logical question to ask of the auditee is, “What safeguards are in place to stop unwanted or unauthorized traffic not only from coming in but leaving the organization as well?”
If a firewall is not configured to block all outgoing traffic and relying on rules and Access Control Lists put in place to control what internet traffic is allowed to leave the network, then a rogue app or piece of malware could easily dial out of the internal network and form a path back in for an exploit.
Common Configuration Pitfalls, Oversights and Risks!
- Default Username and Password: Sometimes something as simple as resetting both the default username and password goes overlooked. I’ve seen it go overlooked in entire organizations on multiple firewalls before! The argument is made that something like Radius Authentication is used to integrate Active Directory access controls into the firewall, but it is my understanding that if Radius Authentication fails, the firewall will revert to using the local login credentials.
- Remote Administration: I think it should always be disabled. If admins want to remotely administer their firewalls, they should VPN into an internal server and access the firewall control panel from within the network.
- DHCP Server: Look for this feature to be disabled unless you are told that the firewall is in fact used as the enterprise DHCP server. I have never seen that be the case in an organization before.
- Logging: Be sure logging is enabled and better yet, ask who has access to those logs and who can manipulate them. You should probably verify that the logs are being sent to a central log server like a WORM (Write Once, Read Many) device and a solid retention policy is in place.
- Policies: Look for defined corporate policies that outlines all allowed Services, Protocols and Ports used and their business justification then have the network administrator demonstrate how those are implemented within Access Control Lists and Firewall rules. This post does a good job of describing the difference between firewall rules and ACLs.
- Physical Security: It is important that someone (like the copy machine repair guy or a network analyst who fancies himself a hacker) does not have the ability to physically plug a hub into any physical interfaces on routers or firewalls. This opens the door to network sniffing. Unencrypted data on the network can then be read, pashword hashes collected and decrypted and VOIP calls potentially listened to.
This is a very brief rundown and over time we’ll explore more of these items in detail. Feel free to leave comments, help us improve our posts and suggest topics for future ones!
A special thanks to Josh England, Sr. Security Engineer at Cox Communications, for his help clarifying and simplifying a few concepts for me.
I’d also ask when the last time the firewall rules were reviewed and updated. Applications, websites, vendors, and business partners come and go (just like employees), and old rules need to be removed. Otherwise, they are holes that can be exploited.
I haven’t found a company yet that does this. When one company migrated their physical firewalls to virtual firewalls, they just moved all the rules as is.
The problem with updating rules is that you might accidentally take down and important link or app. That’s why most companies are loath to update their firewall rules.
When auditing firewalls, the first thing I look for are “any any” rulesets. Additionally, I look to see if *all* firewall rules are commented. If rules are not commented, it is extremely time consuming for new employees, etc. to quickly ascertain what each rule is doing. If they are not commented and there is not good change control through another mechanism, extremely outdated rules tend to linger (such as an ex-administrator having 3389 left open from his home!!!).