Firewall and Intrusion Detection Log Analysis

Firewall log formats vary by vendor but share a common information model. A Cisco ASA syslog entry and a Palo Alto Networks traffic log entry contain the same semantic fields even though the text representation differs. Understanding the model lets an analyst read any vendor's log without memorising each product's syntax.

The action field is the first triage filter. Traffic that was denied never reached the destination host. Alerts generated by an IDS on denied traffic are lower priority than alerts on permitted traffic, because denied traffic cannot have resulted in compromise unless the firewall rule is misconfigured or has been bypassed by a second path. Investigators should confirm that the firewall log and the IDS alert agree on whether the connection completed before escalating.

An IDS alert record contains more semantic information than a firewall log entry. A Snort or Suricata alert includes a signature ID (SID), a message describing the detected technique, a severity classification (1 to 3 in Snort convention, where 1 is high), a protocol, the five-tuple, a payload excerpt or packet count, and a reference list pointing to CVE entries or published exploit descriptions. The message field is the most immediately useful field in triage: it names the attack technique in plain language.

IDS systems operate in two modes. In detection mode (IDS), the engine reads traffic passively and generates alerts without altering the traffic. In prevention mode (IPS), the engine sits inline and can block, reset, or modify matching traffic in real time. The mode matters for log interpretation: in IDS mode, an alert means the traffic was seen; it says nothing about whether the firewall also permitted it. In IPS mode, an alert may indicate that the traffic was blocked at the IPS before the firewall ever forwarded it.

Anomaly-based detection generates a different alert format. Rather than a named signature, the alert reports a deviation score or a behavioural description such as 'internal host scanning 30 distinct destination ports in 60 seconds'. These alerts require different triage logic: the question is not 'does this match a known attack?' but 'is this deviation explained by authorised activity?' A scheduled vulnerability scanner produces the same port-scan signature as an attacker performing reconnaissance. The triage step is to check whether the source IP belongs to an authorised scanner.

Alert triage is a four-step filter applied to every alert before investigative resources are committed. The steps are ordered by cost: cheaper checks come first, so expensive manual analysis is reserved for alerts that survive the earlier filters.

• Step 1: Was the connection permitted? Cross-reference the alert's five-tuple with the firewall log. If the firewall denied or dropped the connection, the traffic never reached the host. The alert is low priority unless the firewall rule is itself suspect.
• Step 2: Is the source on an allowlist? Internal vulnerability scanners, monitoring agents, and penetration test sources generate signature matches that are expected and authorised. Suppress alerts from these sources after verifying the schedule and source IP are consistent with the authorised activity.
• Step 3: Is the target host vulnerable? An alert for a Windows exploit targeting a Linux host is a false positive regardless of whether the connection was permitted. Check the asset inventory to confirm the destination host runs the service and operating system the signature targets.
• Step 4: Is there supporting evidence of impact? Review subsequent log entries from the target host for anomalous outbound connections, authentication events, or privilege escalation indicators. An alert that is followed by a new outbound connection from the target is a strong true-positive signal.

This triage sequence is tool-agnostic. It applies whether the analyst is working in a SIEM like Splunk or IBM QRadar, a dedicated IDS console like Security Onion, or raw log files on a forensic workstation. The SIEM accelerates the correlation at steps 1 and 4 by allowing multi-source queries, but it does not change the logic.

A forward proxy log records what firewall logs cannot: the application-layer content of web requests. Where a firewall log shows 'permit TCP 10.1.2.5:49201 -> 203.0.113.44:443', the proxy log for the same session shows the full URL, the HTTP method (GET, POST, PUT), the user-agent string, the HTTP response code, and the number of bytes the client sent and received. This detail is available even when the connection uses HTTPS, because the proxy performs TLS termination and re-encryption.

Three proxy log patterns are particularly relevant in network forensic investigation. First, command-and-control beaconing: malware checking in with its controller produces regular outbound HTTP or HTTPS requests to the same destination at fixed or jittered intervals. The proxy log shows a pattern of short GET requests to the same URL, with small inbound payloads and consistent timing. Second, data exfiltration over HTTP: large POST requests from an internal host to an external address, especially if the user-agent string is absent or unusual, indicate data being sent out. Third, malware downloads: a GET request returning an executable MIME type or a very large binary payload, particularly from a newly registered or low-reputation domain.

Proxy logs also authenticate the user. If the proxy requires Kerberos or NTLM authentication, the log records the domain username alongside the source IP. This breaks the usual ambiguity of network log analysis, where an IP address may be shared by multiple users on a dynamic DHCP network. Matching the proxy username to Active Directory account records is a standard step in attributing an incident to a specific employee or compromised credential.

Reconstructing an attacker's path from logs is a pivoting exercise. An investigator starts with the earliest known indicator, typically an IDS alert or an anomalous firewall entry, and uses the source and destination IPs as search keys to find all related entries across every log source within the relevant time window. Each new entry may introduce additional IPs or domains, which become the next search keys. The process continues until the chain of activity is fully mapped or a dead end is reached.

A typical attacker path visible across log sources follows a recognisable sequence. Initial access appears as an inbound permitted connection to an externally facing service, often accompanied by an IDS alert for a known exploitation technique. Post-exploitation lateral movement appears as new permitted connections originating from the initially compromised internal host to other internal addresses, particularly on ports associated with administrative protocols (SMB on 445, RDP on 3389, SSH on 22, WMI on 135). Data staging and exfiltration appear in the proxy log as large outbound POST requests or in the firewall log as high byte-count sessions to external addresses on ports 80, 443, or non-standard ports.

Gaps in the log record are themselves forensic evidence. If the firewall logs show a permitted connection but the IDS has no alert for that session, either the traffic did not match any signature (the attack technique is novel or obfuscated), the IDS was not positioned to see that traffic segment, or the IDS was offline or saturated during that window. Documenting the gap and its possible explanations is part of the reconstruction. An attacker who knows where the IDS sensors are may deliberately route traffic to avoid them.

Experienced attackers modify their behaviour to reduce log visibility. Understanding the common evasion techniques allows an analyst to recognise their signatures in the logs and adjust the investigation accordingly.

• Low-and-slow scanning: Instead of scanning all ports in seconds (which triggers anomaly alerts), an attacker sends one probe per hour over days. The firewall log contains the events but they are far apart in time. Correlation across a long time window rather than a short burst is required to detect this pattern.
• Protocol tunnelling: DNS tunnelling, ICMP tunnelling, and HTTP tunnelling move data within protocols that the firewall permits. The firewall log shows permitted DNS or ICMP traffic; the IDS may detect the encoding if a specific signature exists, but many tunnelling implementations are not captured by default signature sets.
• Fragmentation and padding: IP fragmentation splits an attack payload across multiple packets, so no single packet matches the full signature. Some IDS engines reassemble fragments before matching signatures; others do not. Checking whether the IDS in question performs fragment reassembly is a prerequisite for interpreting the absence of a signature alert.
• Mimicking legitimate traffic: Command-and-control traffic that uses real browser user-agent strings, established TLS certificates, and HTTP response codes that mimic CDN traffic is difficult to distinguish from legitimate web use without content inspection or behavioural analysis. The proxy log is the primary detection point; firewall logs alone will not flag it.
• Using permitted services: Exfiltrating data through cloud storage services (Dropbox, OneDrive, Google Drive) or code repositories that the organisation's firewall permits to legitimate users. The firewall log shows a permitted HTTPS connection to a known-good domain; only the proxy log (with SSL inspection) reveals the volume and direction of the data transfer.

Each evasion technique produces a characteristic gap or distortion in the log record. Recognising the distortion tells the analyst where to look for compensating evidence from a different log source. The principle is that no attacker can simultaneously evade every log source. An attacker who hides from the IDS through fragmentation still appears in the firewall log; one who hides from the firewall by using permitted ports still appears in the proxy log if application-layer inspection is enabled.