This article sheds light on Firewall Logs in incident investigations. We explore key behaviors and patterns for effective threat detection
As part of our ongoing series, we have been discussing the value and criticality of ensuring the right logging and visibility is available in your organization. The rationale behind this is that, when and if an incident occurs, the incident response team is able to use the logs to identify what happened and how. In a previous article, we discussed investigating suspicious emails, whether it is a phishing email, business email compromise or otherwise. For the focus of this article, we will narrow in on a component that is present in every organization whether they are on premise, or the cloud, firewalls.
How is a firewall defined? A firewall is a network security device that monitors incoming and outgoing network traffic and determines whether specific traffic should be allowed or blocked based on a defined set of security rules.
There are many types of firewalls that are applicable to various environments such as your traditional physical firewalls, next generation firewall with features such as intrusion detection and prevention, and there are application firewalls which are not physical but applications within cloud environments to add layers of protection to hosted applications and services and various workloads an organization may be running for their company.
Prerequisites to the Investigation
As we have discussed in depth with other components of our security architecture, understanding what your organization has in place and at each layer will help you ensure you have the correct logs, the correct level of logging and ensuring you have the firewalls being forwarded to a central logging and/or SIEM solution such as Splunk or Azure Sentinel or whatever your organization may be using. Once the incident response and security operations teams are satisfied that they are receiving the right firewall logs and they are included in correlation rules, the stage is set for prompt and efficient investigations.
Investigating Unusual Outbound and Inbound Connections
While most organizations correlate firewall logs with other network logs looking for indicators of compromise which are then highlighted in a SIEM, it is not plausible to expect that all malicious activity will be detected without threat hunting. Here are some key behaviors and patterns to look for in logs in your company’s firewall. This is not a conclusive or an exhaustive list, but it is a great place to begin.
- Compromised systems may start sending out traffic that doesn’t look like the rest of your traffic. Perhaps an attacker is trying to exfiltrate data, or a bot may be simply trying to contact its C&C infrastructure. So look carefully at outbound traffic logs from your perimeter firewalls such as Bytes IN/Out , Traffic allowed on firewall access control list , User account changes,bandwidth and CPU utilization exceeds.
- Consider looking at source geolocation as well, though as before, don’t fall into traps. Block the inbound and outbound traffic from a Geo-blocked IP to known signature.
- Check for denied inbound traffic from an IP towards particular port or generic ports which can be used as an early warning for your teams of what it is coming towards you in the near future.
- Denied outbound traffic: When you rule out misconfiguration issues in your infrastructure, to have denied outbound traffic is concerning and you wonder what is happening inside your network that is causing the traffic being denied in the firewall. If the traffic is being restricted, is it because your security policy has previously considered that scenario or communication before, and is now preventing it from happening?.
- Some botnets C2 protocols communicate port TCP 443 by using a proprietary protocol rather than HTTP over SSL. This means that monitoring the port 80 denied/blocked connections to a fixed count will help to control botnet connection.
- Monitoring the SSH port 22 for an unusual inbound and outbound connection can prevent unknown connections since backdoors on hacked endpoints and networks typically run on standard services such as SSH on port 22 in order to blend with normal traffic and hide.
- Look for protocol-port mismatches. For example, having HTTP traffic on high ports, or maybe even something like SSH on TCP 80 is the sign of an external target to an organization. Attackers often like to overload TCP 80 to slip through loosely secured perimeter networks.
- SMB (Server Message Block ) is commonly used by attackers to communicate outbound and exfiltrate data from networks. So looking for/creating rules based on malicious SMB connections such as Destination Ports 137 (UDP) , 138, 139 or 445 (TCP) from Same Source IP, Destination Port and Different Destination IP running for every 5 minutes will reduce SOC analysts manual work.
- Hunt for excessive denials from a single external source, as this is a common attack nowadays. Create a search based on Same Source IP, Traffic Direction Remote to Local & Firewall or ACL Denies.
- Rules can be created for excessive denies from a single internal host, although it will mean having to monitor a huge number of internal and outbound firewall denies on a single server. This could, for example, reveal network fingerprinting or a misconfigured device. Rules can be created depending upon Same Source IP, Traffic direction Local to Remote, Local to Local, Firewall or ACL Denies with 3000 Denies / 30 Minutes. You may need to tune out things such as asset scanners, vulnerability scanners and the like from this rule.
- During internal network scanning, an attacker may attempt to connect to a large number of ports from a single host; to see which ports are open. This will stand out among normal network traffic. SIEM Rule can be created depending upon Same Source IP, Traffic direction Local to Remote, Local to Local, Firewall or ACL Denies with 100+ Different Destination Ports within 1 Hours. We can apply it the same for denies from the internal host to many destinations.
- Hunt for 100+ distinct external IP addresses initiating a connection to the same target IP over a distinct destination port in every 5 minutes or last 30 Minutes.
- If a scan is followed by a Port Opening, look for network traffic potential violations.
- In a 10-minute period, check for high-severity firewall alarms between any source address and the public destination address.
- Analyze the traffic of the source IP which was involved in the previous attack as destination IP to make sure the machine is not infected.
- Check for the traffic from private IP connecting to public address which is malicious or with a bad reputation.
- Check for excessive firewall denies from a single host. Detects more than 500 blocked attempts from a single source address to a single destination address within an hour.
- Check for 200+ blocked hits from an IP towards multiple destination IP targeting multiple/single ports within an hour.
- Look for Commutation to an external/Geo-Blocked IP address which is blocked: (a) Communication to a rare country IP address which is blocked (b) Allowed communication to IP address of same country / same subnet. (c) Allowed inbound communication from same IP to DMZ server (d) Allowed communication from same public IP to multiple port
- Hunt for multiple MAC addresses from a single source address.
- In a relatively short period, a single source address with a private IP address communicates to a distinct destination port.
- IP Proxy Server Communication (Firewall/Proxy) A malicious payload or process that causes an endpoint to communicate with known bad domains is indicated by traffic to known suspicious proxy domains/IP.
- Checking for source or firewall is taking an unusually long time to connect.
In summary, firewalls, whether application, host based, or physical, can contain a wealth of information that can be pivotal in either threat hunting or incident response.
