Simply the name, firewall, conjures up an image of a great wall of fire burning anything that is unauthorized and trying to pass through.
Just as the name suggests, in the digital world, a firewall prevents an unauthorized access to or from a network. A firewall is usually at the perimeter of a private network and the open Internet, it acts as a barrier and allows traffic through based on a set of pre-defined rules:
The preceding image clearly demonstrates the functioning of a firewall. As we can see, the network traffic can either pass through or be rejected by the firewall when found to be contrary to a pre-defined rule. The key factor of interest for us is the fact that every interaction with the firewall leaves a trace. This is reflected in the form of an entry in the firewall logs. Network forensic investigations require us to understand the firewalls and events that produce the entries in the log files. As the Digital 007s, it's our job to "make the firewalls talk".
One of the fundamental things that we need to understand is that a firewall is a system or group of systems that act as a bouncer whose job is to decide who enters or who does not enter our network. In simple words, a firewall controls the access to our network and this is usually based on a number of rules implemented by a network administrator. In addition to this, it plays a crucial role of keeping tabs on every one that accesses our network or even attempts to access it for whatever reason.
Some firewalls are designed to permit just a single kind of traffic through them, such as e-mails. While others may be configured to protect the network from unauthorized logins from the outside world. Firewalls can provide a single choke point to the network. This choke point can be used to implement effective security and audit rules in order to protect and monitor the network, as shown in the following:
Let's enhance our understanding about firewalls by examining the different types of firewalls.
Firewalls have a long and checkered history. They began their career as Access Control Lists (ACLs) embedded in routers that are still in use today to the new and highly touted Next-Generation Firewalls (NGFWs).
Let's take a look at the different types of firewalls.
The National Institute of Standards and Technology (NIST) 800 - 10 broadly classifies firewalls into the following three distinct types:
- Packet Filter firewalls
- Stateful Inspection firewalls
- Application/Proxy firewalls
In today's networked environment, there is a fairly high degree of overlap with a number of commercial products having features of all the three categories as well.
These firewalls determine the access to internal or external resources based on the Access Control Lists. Filtering may be on the basis of source or destination IP addresses, ports, protocols, time range, and so on. All this information is available in the packet header. The packet filter examines the header and based on a specified set of rules (ACLs), this decides whether to allow it to go through (ACCEPT) or stop it from passing (DROP), as shown in the following image:
One key point to remember is that such firewalls have NO insight into the packet content and makes its decision to allow or disallow specific packets based on the packet-header conformance to the ACL's setup at the time. These firewalls operate at the network level of the OSI model.
However, their weakness lies in their very nature. Let's take a situation where the ACL in use allows an open port 80. This is fairly common as this is used for HTTP (www) requests. Any malicious user can setup their packets to be crafted so that they are directed to port 80 and are routinely passed through.
While these firewalls have been around for a long time, they should not be discounted. They are fairly widespread, provide a very fast response, and are a part of an organization's defense in depth security stance.
Stateful inspection firewalls were the next major evolutionary step. One major weakness in the packet filter type of firewalls was the their ability to be fooled by the information in the header. While they would look at and analyze a packet with SYN in the header, they would allow a packet with an ACK right through, assuming that it was in response to the SYN of a previous packet. This allowed malicious individuals to craft specialized packets with ACK configured so that the firewall just let the packet through. This was due to the fact that the packet filter firewall did not maintain a record of the state of communications between devices. Therefore, stateful packet inspection firewalls were born:
They classify and track the state of traffic by monitoring all the connection interactions until a connection is closed. They collect all the packets related to an interaction, determine their acceptability, and then release them to the network. These operate up to layer four of the OSI model. This is the transport layer.
These firewalls are a major help in thwarting Distributed Denial of Service (DDOS) attacks.
These firewalls work on the application level of the TCP/IP stack. These address applications such as browser traffic (HTTP), telnet, or File Transfer Protocol (FTP) traffic. These firewalls are designed to intercept, examine, and drop or accept packets traveling to and from an application. As a part of their role, they are designed to drop other packets without any acknowledgment to the sender, as shown in the following image:
While these firewalls can be set up to inspect and intercept network packets containing Trojans and Worms, this comes at an extra latency cost, resulting in delays in packet forwarding.
Application firewalls can work by hooking into socket calls and filtering connections between the lower layers (of the OSI model) and the application layer. Firewalls that perform such a function are often called socket filters. Another role that application firewalls are involved in is managing Network Address Translation (NAT) and Port Address Translation (PAT). A key strength of application firewalls is the information that is collected in the logs.
Application firewalls come in two varieties: network-based application firewalls and host-based application firewalls. While a network-based application firewall monitors calls through the OSI stack, a host-based application firewall monitors activity through system calls. This can monitor application input and output, the system service calls made by an application, as well as the calls made from or to it.
Just as we had seen earlier in the case of proxy servers, the logs collected by firewalls are a major asset to the investigator. Most firewall vendors have their own log formats that they make available to users for use. Sometimes, they have a large number of fields, which really increases the granularity of the investigation. However, most firewall logs share some common characteristics.
These include date and time. Let's look at the logs generated by a CyberRoam appliance:
Now that we see all the variables involved in a log, let's see a few log entries so that we can relate to them when we work on a case:
Event: Firewall Traffic
Denied Component: Firewall Rule
Sample Log:
date=2015-08-07 time=16:27:27 timezone="GMT" device_name="CR500ia" device_id= C070123456-ABCDEF log_id=010102600002 log_type="Firewall" log_component="Firewall Rule" log_subtype="Denied" status="Deny" priority=Information duration=0 fw_rule_id=3 user_name="" user_gp="" iap=2 ips_policy_id=0 appfilter_policy_id=0 application="" in_interface="PortG.16" out_interface="PortB" src_mac=00:0d:48:0a:05:45 src_ip=172.16.16.95 src_country_code= dst_ip=192.168.5.2 dst_country_code= protocol="UDP" src_port=42288 dst_port=53 sent_pkts=0 recv_pkts=0 sent_bytes=0 recv_bytes=0 tran_src_ip= tran_src_port=0 tran_dst_ip= tran_dst_port=0 srczonetype="" dstzonetype="" dir_disp="" connid="" vconnid=""
Event: Local ACL traffic allowed
Component: Local ACL
Sample Log:
date=2015-08-07 time=14:44:57 timezone="GMT" device_name="CR500ia" device_id= C070123456-ABCDEF log_id=010301602001 log_type="Firewall" log_component="Appliance Access" log_subtype="Allowed" status="Allow" priority=Information duration=30 fw_rule_id=0 user_name="" user_gp="" iap=0 ips_policy_id=0 appfilter_policy_id=0 application="" in_interface="PortG.2" out_interface="" src_mac=00: 0:00: 0:00: 0 src_ip=172.16.16.54 src_country_code= dst_ip=192.168.52.31 dst_country_code= protocol="ICMP" icmp_type=8 icmp_code=0 sent_pkts=1 recv_pkts=1 sent_bytes=212 recv_bytes=212 tran_src_ip= Firewall Log Format tran_src_port=0 tran_dst_ip= tran_dst_port=0 srczonetype="" dstzonetype="" dir_disp="" connevent="Stop" connid="3153155488" vconnid=""
Event: Local ACL traffic denied
Component: Local ACL
Sample Log:
date=2013-08-07 time=13:25:27 timezone="IST" device_name="CR500ia" device_id=C070100126-VW717U log_id=010300602345 log_type="Firewall" log_component="Appliance Access" log_subtype="Denied" status="Deny" priority=Information duration=0 fw_rule_id=0 user_name="" user_gp="" iap=0 ips_policy_id=0 appfilter_policy_id=0 application="" in_interface="PortG.4" out_interface="" src_mac=d0:17:78:d6:4c:b0 src_ip=10.104.13.140 src_country_code= dst_ip=255.255.255.255 dst_country_code= protocol="UDP" src_port=47779 dst_port=8167 sent_pkts=0 recv_pkts=0 sent_bytes=0 recv_bytes=0 tran_src_ip= tran_src_port=0 tran_dst_ip= tran_dst_port=0 srczonetype="" dstzonetype="" dir_disp="" connid="" vconnid=""
Our networks are constantly being probed from the Internet and from an investigation perspective, it pays to look within the firewall logs for the IP addresses that are rejected. This gives us a view into what is being probed and we get an insight into what we should work at protecting.
Another thing to look out for in our firewall logs are the unsuccessful login attempts. This is a great indicator that our network is under attack and it also indicates the specific resource that is being targeted at the time.
Assuming that we have a good idea of the normal outbound traffic from our systems, our firewalls will give us a great insight into the traffic that is not characteristic. This kind of traffic may be indicative of a bot infection and highlight the servers trying to report in.
As we can see, there is a wealth of information in these firewall logs. Therefore, we must keep an eye on the evidence from firewalls as this can definitely be an asset to our network forensic investigation.
Let's move on to see what we can find from another crucial network component—routers.