Finding And Interpreting Windows Firewall Rules

by Joakim Kävrestad

Determining with whom and in what way a computer has communicated can be important and interesting in several types of examinations. Communications can be an important part of analyzing if and how a computer has been remote controlled or with whom the computer has shared information. It can also be a good way to determine if a computer has been compromised or infected with malware.

If a computer is compromised and controlled remotely by a rogue user, that user needs to have an established connection to the computer. Further, many types of malware are used to steal and send information to someone, and simply need to be connected with a so-called “command and control” server that can control their behavior. A common denominator for everything that needs to communicate is that it has to pass through the firewall. For those of you who are not networking gurus, a firewall is a software or device that acts as a gatekeeper and decides what traffic is allowed to enter and leave a computer or network. Also, it will often log historic connections. Windows-based computers typically use the built-in Windows Firewall, and artifacts associated with it can provide important information to a forensic expert.

In essence, the Windows Firewall will examine IP addresses and port numbers in IP-based network traffic to make decisions on what traffic is allowed to enter and leave a computer. Traffic that is determined to be good is allowed to pass through, and traffic that is deemed bad will be blocked. IP addresses are the addresses used by computers to communicate over the Internet and port numbers are used to address traffic to a certain service. Many services are assigned specific port numbers to use for communication. Thus, if a port number assigned to a certain service – say the remote control software TeamViewer – is allowed to pass through the firewall, there is a fair chance that that TeamViewer has been installed on the computer. Likewise, some malware is known to use a specific port number and thus, if a port number associated with that malware is identified, a strong indication of infection is found. You may also analyze the firewall log to see which IP addresses a computer has been communicating with. This information can tell you if the computer has been in touch with someone that it should not be in touch with, and possibly assist in identifying an intrusion.     

Analyzing Firewall Rules

When analyzing the Windows Firewall there are essentially two main pieces of information to care about. The first is the current traffic rules: they dictate what ports, IP addresses and applications are allowed or blocked at the moment. The other is the firewall log files. These provide historic data about previous connections. Logging is unfortunately not enabled by default, but it is worth looking for the log file since it will provide a lot of information if it is present. They are located in the Windows registry in the SYSTEM hive under the following key:


Get The Latest DFIR News

Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month.

Unsubscribe any time. We respect your privacy - read our privacy policy.


\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules

The data looks as follows; the highlighted rules are dummy rules created for the purpose of this article.

As previously described, the firewall rules decide what traffic is allowed to enter or leave the computer. Each registry value is one rule and the general structure is attribute1 | attribute2 | …| attributee. Let’s zoom in on the first underlined rule to see how the rules are structured. The rule begins with 

v2.10|Action=Block|Active=TRUE|Dir=In

The very first attribute is a version number, and the second attribute describes if the action of the rule allows or blocks traffic. The third attribute decides if the rule is active or not, and the fourth attribute describes the traffic direction the rule is concerned with. If it says in, the rule is applied to incoming traffic and if it says out the rule is applied to traffic leaving the computer. The rest of it shows the actual matching rules. The matching rules decide what traffic the rule matches and the specified action is applied to all traffic that match the matching rules. The matching rules can include a number of different attributes, the most important for forensic purposes being:

  • Protocol, which decides what protocol the rule should match. A small experiment performed by the author revealed that 6 is TCP, 17 is UPD, and 1 is ICMP.
  • Lport, which decides the local port.
  • Rport, representing the port of the remote computer.
  • LA4 or LA6, which represent the local IPv4 or IPv6 address.
  • RA4 or RA6, which represent the remote IPv4 or IPv6 address.
  • App, which represents the application the rule should match, making it possible to have application-specific rules. For instance, Firefox may be able to communicate using port 80 (used for web traffic), while Skype may not.
  • Name, which is just a name given to the rule.
  • Profile, which determines under which firewall profile the rule is applied. The Windows Firewall has three different profiles (Domain, Private and Public), and a network connection will be assigned a profile. Usually, when a computer is connected to a new network, the user is asked which profile to apply to the connection. 

The way that firewall rules work is that the specified action is applied to all traffic that matches all the matching rules. For the sample rule, all incoming traffic using TCP and destined to the local port 9000 will be a match, and the action says that it will be blocked. Further, it appears as if the absence of a matching attribute is equivalent to a wildcard, meaning that all possible values of that attribute will be considered a match. For instance, our sample rule does not contain the Profile or LA4 attribute, meaning that it matches all profiles and IPv4 addresses. The forensic value of these rules is that they can reveal what programs and services are allowed to communicate through the firewall, and a rule for a service or application is a good indication saying that the service is or was installed. Further, firewall rules can reveal malware or intrusions, as these sometimes add firewall rules to enable rogue communication with the outside world.

Analyzing Firewall Log Files

The second artifact of importance when analyzing the Windows Firewall is the traffic log. If logging has been enabled it can provide data about historical connections. This log file tracks how the rules has been applied and describes what traffic was allowed through, or blocked by, the firewall. The log file is named pfirewall.log and located in [systemroot]\Windows\System32\LogFiles\Firewall. There can also be a file called pfirewall.log.old that contains historical data. The snippet below is a part of a firewall log file, and each row is one piece of traffic.

Looking at the first row beginning with a date, the date is followed by an action, in this case ‘allow’, meaning that the traffic was allowed. Next is the protocol, usually TCP or UDP followed by the source IP and destination IP. In this file, source IP is the local computer’s IP address and remote is the remote party; the computer the local computer is communicating with. The next values are source and destination port number.

The next interesting part is the final word in the line, ‘send’ or ‘receive’, which shows if the traffic was sent from or received by the local computer. In this case, the full row is interpreted as follows: UDP traffic sent from the local computer to the IP 172.217.22.174 using port number 443 was allowed. This log file can show what remote IP addresses the local computer communicated with, and the port numbers can provide information about what services have been used during communications. As such, it can be used to find remote connections, malware and intrusions. 

About The Author

Joakim Kävrestad is currently teaching and researching in digital forensics and information security at the University of Skövde, in the south of Sweden. Before entering his current position he worked as a Forensic Expert with the Swedish police and led hundreds of forensic examinations in all typed of criminal investigations. Joakim is freelancing as a forensic expert in criminal investigations through his own company and has authored two books on the subject: Guide to Digital Forensics and Fundamentals of Digital Forensics

2 thoughts on “Finding And Interpreting Windows Firewall Rules”

  1. I am puzzled by referencing the “[systemroot]\Windows\System32\LogFiles\Firewall” older Win 7 log that is not used any longer. “The Microsoft-Windows-Windows Firewall With Advanced Security/Firewall” logs 2004 and 2006 event IDs and the Security log for 5156 events for traffic flow would be what to collect and focus on moving forward Win 7, 2012 Server and later. This older log has to be enabled, and is normally locked, so difficult to read for the layman. Using standard logs is preferred and what you would collect with Log management solution agent. So why this older log over the Event logs?

    • Hi,

      I could come up with some nice and fancy explanation, but id rather just be honest. It was the sources i looked at, and they are interpreted as stated in the article. I would look at events 2006 and 2004 as a good place to verify rule changes, especially to find strange modifications and deletes. However, i find the registry easier to work with in order to see the “current” setup.

      As for events 515x, you are 100% correct and I agree and thank you for your input.

Leave a Comment