A comprehensive study guide covering firewall log analysis, ACL configurations, proxy and WAF logs, IDS/IPS tools and rule writing, port security, and Network Access Control — the analyst's complete guide to reading and acting on security appliance data.
Objective 1.1 — System & network architecture in security operationsObjective 1.3 — Tools & techniques to determine malicious activity
1
Firewall Logs — iptables and Windows Firewall
Firewalls are an essential layer in defence, but not sufficient alone. The gated-community analogy is instructive: a perimeter gate stops outsiders, but if a trusted insider opens a door, the gate fails. Firewalls must be combined with host-based defences, IDS/IPS, and other controls — and their logs must be actively reviewed to be valuable.
What firewall logs provide
Permit / deny records
Every allowed or blocked connection attempt — the raw material for identifying holes in your security posture or evidence of inbound reconnaissance.
Port & protocol usage
What ports and protocols are actively in use across your network, and which unexpected ones should be investigated or blocked.
Bandwidth & duration
Volume and duration of individual connections — useful for spotting data exfiltration as an anomalous traffic spike at unusual times.
NAT / PAT audit trail
Complete log of all address translations — essential during incident response to map a public IP back to the internal DHCP host that held it at a specific time.
iptables log format (Linux / Syslog / CIS format)
iptables uses the standard Syslog (CIS) log format. Each entry begins with a timestamp, host name, and facility (usually kernel), followed by a log prefix indicating which rule matched (e.g. iptables input drop), and then a set of attribute=value pairs describing the packet.
iptables log entry — annotated
# Timestamp HostID Facility Rule prefix Packet details May 15 09:14:22fw01kernel:iptables input dropIN=eth0 OUT= SRC=203.0.113.55 DST=10.10.1.5 PROTO=TCP SPT=54321DPT=23← Telnet (port 23) — no server here, dropped
May 15 09:14:23fw01kernel:iptables input dropIN=eth0 OUT= SRC=203.0.113.55 DST=10.10.1.5 PROTO=TCP SPT=54322DPT=21← FTP (port 21) — no FTP server, dropped
Syslog severity levels (0–7)
Level
Name
Description
0
Emergency
System is unusable
1
Alert
Immediate action required
2
Critical
Critical conditions
3
Error
Error conditions
4
Warning
Warning conditions
5
Notice
Normal but significant events
6
Informational
Informational messages
7
Debug
Debug-level messages
Windows Firewall log format (W3C Extended Log File Format)
The Windows Firewall log is human-readable by design — comment lines at the top of each file declare the fields. The last comment line is your column key, and every data line that follows maps directly to it.
W3C log header (comment lines)
#Software: Microsoft HTTP Server API 2.0
#Version: 1.0
#Date: 2002-05-02 17:42:15
#Fields: date time c-ip cs-username s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status cs(User-Agent)
Exam priority: You must be comfortable reading both iptables and Windows Firewall log formats. Given 5–10 lines from either log, you need to identify: what was requested, whether it was permitted or denied, what port/protocol was used, and which HTTP method and response code appeared. Memorize the field order — especially the W3C format column structure.
Log management considerations
Blinding attack
When a firewall is overwhelmed and cannot log fast enough, entries are lost. An attacker who knows this can flood the firewall to blind the logging system and slip through undetected. Scope your logging and ensure adequate capacity.
Log retention
APTs have average dwell times of 6–9 months — retain logs for at least 6–12 months to have any chance of reconstructing how an attacker entered. Retention period must balance storage cost against the business case for forensic reconstruction.
Centralized collection
Never rely on logs sitting on a single appliance — if it fails, data is lost. Aggregate logs to a central repository (SIEM). Use a log collection tool to handle the volume and normalize formats across appliances.
2
Firewall Configuration — ACLs, Egress Filtering & Black Holes
Firewall rule sets are called Access Control Lists (ACLs). They are processed top to bottom — most specific rules first, most generic last. The first matching rule wins. A terminal deny any any at the bottom acts as an implicit deny-all for everything not explicitly permitted.
Reading a Cisco ACL — permit/deny logic (signature element)
The table below shows a DMZ ACL using colour to reflect each rule's action. Every real firewall ACL works the same way regardless of vendor — read top to bottom, first match wins.
Action
Match criteria
Source
Port
Destination
remark
Responses to HTTP requests from DMZ
—
—
—
permit
TCP from DMZ network
10.0.2.0/24
eq 80 (www)
any established
permit
TCP from DMZ network
10.0.2.0/24
eq 443 (https)
any established
permit
ICMP echo-reply
10.0.2.0/24
—
any
permit
UDP DNS queries
10.0.2.0/24
eq 53 (domain)
any
permit
TCP DNS queries
10.0.2.0/24
eq 53 (domain)
any
deny
Explicit deny-all (catch-all)
any
any
any
Drop vs. reject: A deny rule can either drop (silently discard — attacker gets no feedback) or reject (send TCP reset / ICMP unreachable). Dropping is preferable for security because it reveals less about your network topology and frustrates firewalking reconnaissance.
Firewalking
Firewalking is a reconnaissance technique where an attacker finds an open port on the firewall and sends packets with a TTL of one-hop past it, using the ICMP time-exceeded response to map hosts behind the firewall. Mitigation: block outgoing ICMP status messages — without the ICMP reply, firewalking fails.
Egress filtering best practices
1 — Allowlist outbound ports
Only permit explicitly needed ports (80, 443, 53) to leave your network. Everything else is blocked. This limits C2 beacon channels even if malware is installed.
2 — Restrict DNS to trusted servers
Lock DNS queries (port 53) to known-good resolvers — your own, your ISP's, or Google's. Prevents DGA malware from reaching arbitrary DNS infrastructure.
3 — Block known-bad IPs (silently)
Drop — not reject — traffic to known malicious IPs. Silent drops don't confirm your firewall's existence or its rule set to the attacker.
4 — Isolate unnecessary subnets
Block internet access from subnets that don't need it (ICS/SCADA, management networks). If they can't reach out, attackers can't reach in via that path.
Black holes and sinkholes
Black hole
Silently discard traffic
Routes attack traffic to a null interface — packets are dropped without response. Most effective at the router level (not firewall) during DDoS. Also useful for dark net IP space — route unused addresses to null so any activity is automatically discarded. Risk: legitimate users sharing the blocked subnet may also be blocked.
Sinkhole
Redirect for analysis
Similar to black hole, but diverts traffic to a separate network for collection and analysis instead of discarding. Preferred when you want to understand the DDoS source and techniques. Commercial providers (Cloudflare, Akamai) act as sinkhole networks, scrubbing traffic and returning only clean traffic to you.
Dark net / dark space: Unused IP address ranges within your allocated block that should have no legitimate traffic. Routing dark net space to a black hole means any activity automatically indicates scanning or misconfiguration — it is both a detection mechanism and a waste-elimination technique.
3
Proxy Logs — Forward, Reverse & WAF
Proxy servers act as intermediaries between clients and servers. Their logs provide a detailed record of every web request — the analyst's view of exactly what users accessed, when, from where, and what the server returned.
Forward proxies
Non-transparent
Client is explicitly configured with the proxy address. The user knows the proxy exists. Easy to bypass by reconfiguring browser settings.
Transparent (intercepting)
Implemented at the network layer — all traffic is intercepted regardless of client configuration. Employees cannot bypass it by changing browser settings. This is the preferred model for enforced corporate web filtering.
Reading a Squid proxy log
Most proxies use the Common Log Format (same structure as the Windows Firewall W3C log). A Squid log entry reveals the exact URL requested, the HTTP method, the response code, the bytes transferred, and whether the proxy permitted or blocked the request.
Squid access.log — policy change example
# Reading from oldest (bottom) to newest (top):
1286705910.344192.168.1.105TCP_MISS/200 GET http://515web.net/ ↑ Status 200 = permitted, request succeeded
1286706335.211192.168.1.105TCP_MISS/200 GET http://www.515web.net/ ↑ Still permitted ~7 minutes later
1286706427.893192.168.1.105TCP_DENIED/403 GET http://www.515web.net/ ↑ 403 Forbidden — policy updated in ~90 seconds, site now blocked
Reverse proxies
A reverse proxy sits in front of internal servers and handles all inbound requests from the internet. External clients never touch internal servers directly — they only see the proxy. This creates a single chokepoint for inbound traffic analysis and eliminates direct exposure of server infrastructure.
Reverse proxy logs are a prime source of IOA/IOC data: all inbound HTTP requests pass through them, making it straightforward to analyze status code distributions, detect scanning patterns, and identify malicious payloads in request headers or URLs — from a single log source.
Web Application Firewall (WAF)
A WAF is a specialized firewall that operates at Layer 7 — it parses HTTP request and response headers and bodies, not just IP/port tuples. This enables it to detect and block code injection attacks that pass through standard firewalls.
WAF protects against
SQL injection, XML injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and other Layer 7 application-layer attacks targeting web servers and their backend databases.
WAF log format
Most WAFs log in JSON format, capturing: timestamp, severity, URL parameters, HTTP method, and the rule context — including a reference to the vulnerability database entry (CVE, MITRE ATT&CK, or knowledge-base article) that the rule matched.
Exam rule: If a question asks how to protect a web server from SQL injection, XML injection, or XSS attacks, the answer is a Web Application Firewall (WAF) — not a standard stateful firewall. Standard firewalls can only filter by IP/port and cannot inspect Layer 7 content.
4
IDS & IPS — Tools, Logs & Snort Rules
An IDS (Intrusion Detection System) scans, audits, and logs network traffic against rule sets — it detects and alerts but cannot block. An IPS (Intrusion Prevention System) does everything an IDS does, plus it can actively block matching traffic. Most IDS software can be switched to IPS mode.
Key IDS/IPS tools
Snort
Open-source IDS/IPS
Available for Windows and Linux. Operates in sniffer, logging (IDS), or active response (IPS) modes. Uses rule sets via Oinkcode subscription (commercial, most current) or free community rule sets. The industry-standard rule format used throughout the CySA+ exam.
Zeek (formerly Bro)
Open-source IDS for Unix/Linux
Scripting-engine-based IDS that generates "notices" for significant events. Can implement shunning for IPS functionality. Also serves as a network flow analysis tool (Ch. 6) — JSON-normalized output integrates with SIEMs like Splunk.
Security Onion
All-in-one SIEM platform
Linux-based security monitoring distribution bundling Snort, Suricata, Zeek, Wireshark, NetworkMiner, and log/incident management tools. The defender's equivalent of Kali Linux. Recommended for practice — download and set up on your own network.
IDS/IPS log output formats
Unified (binary)
Machine-readable binary — requires an interpreter. Most compact format for automated processing.
Syslog
Standard Syslog format with IP, port, and matched signature. Compatible with any SIEM or syslog aggregator.
CSV
Comma-separated values — importable into Excel, parseable with regex, usable by third-party analytics tools.
tcpdump / PCAP
When a rule fires, full packet capture of the triggering traffic is saved — allows deep forensic analysis of the exact packets that matched.
Snort rule anatomy
Every Snort rule has a header (action, protocol, source/destination, direction) and a body (rule options in parentheses, semicolon-separated). The colour coding below maps each field to its role.
Rate-limits the rule — only fires after the threshold is exceeded. The IMAP rule above fires only after 30 login attempts within 30 seconds, preventing false positives from normal login failures.
flow
Matches traffic direction relative to a TCP connection state: to_server, from_server, established, stateless. Prevents the rule from firing on outbound traffic when you only care about inbound.
reference
Links the rule to an external knowledge source — a CVE number, a MITRE ATT&CK technique URL, or a vendor advisory. Gives responders instant context about what the rule is detecting.
sid / rev
Unique Snort rule ID (sid) and revision number (rev). Custom local rules must use sid ≥ 1,000,000 to avoid colliding with community and commercial rules.
Over-logging / tuning: An IDS rule that fires on every ICMP packet will generate enormous noise and desensitize analysts. Always tune rules to be as specific as possible — narrow source/destination scope, add detection_filter thresholds, restrict to relevant protocols. A noisy IDS is nearly as dangerous as no IDS — critical alerts are buried in false positives.
Exam approach for Snort rules: You will not be asked to write rules from scratch. You will be given a rule and asked to interpret it — identify the action, the source/destination addresses and ports, the direction, what content triggers it, and what the threshold is. Practice reading the IMAP brute-force rule above until you can describe each field from memory.
5
Port Security — Physical, MAC Filtering & NAC
Network appliances (switches, routers, firewalls) run embedded operating systems — often outdated Linux kernels with unpatched vulnerabilities. They need the same patching discipline as servers. Their web-based management interfaces are frequently vulnerable to XSS and CSRF; SSH shell access is far more secure.
Appliance hardening best practices
ACL restriction
Limit management access to a small number of designated admin laptops. Only those specific hosts should be able to reach management interfaces.
Designated interfaces only
Restrict management connections to a small number of specific physical ports — don't allow management from any jack in the building.
No direct internet management
Remote management must go through VPN first, then connect to the management LAN — never expose management ports directly to the internet.
SSH over web interfaces
Disable web-based admin interfaces; use SSH shells instead. Web interfaces on embedded OS are a common attack surface for injection attacks.
Three layers of port security
Physical port security
Lock switches in cabinets or closets. Physically unplug unused wall jacks from the patch panel so they carry no signal. Reconnect only when needed. Labour-intensive and error-prone but effective for high-security zones.
MAC filtering
Apply an ACL to a switch port so only approved MAC addresses can connect. Static and maintenance-intensive. Easily bypassed by MAC spoofing — an attacker sniffing the wireless network can clone an approved MAC in seconds. Not sufficient as a sole control.
Network Access Control (NAC)
Authenticates and evaluates device health before granting network access. Combines 802.1X port-based authentication with posture assessment — the strongest and most flexible of the three options.
802.1X and the NAC authentication flow
Role 1
Supplicant
The host requesting network access. Sends EAPOL (EAP over LAN) credentials to the switch.
Role 2
Authenticator
The switch or access point. Forwards credentials from the supplicant to the authentication server via RADIUS/Diameter.
Role 3
Auth Server
RADIUS or Diameter server. Validates credentials and returns an access grant or deny decision to the authenticator.
Outcome A
Access granted
Device is routed to the correct network, VLAN, or VPN tunnel based on its identity and role.
Outcome B
Access denied
Device is quarantined (remediation VLAN) or rejected outright, depending on policy.
Advanced NAC posture assessment
Beyond basic username/password, broader NAC solutions check device health before granting access. A device that fails posture assessment is placed in remediation (a restricted VLAN with access only to update servers), fixed, then re-assessed before admission.
Posture assessment checks
Antivirus running and definitions current, OS patch level meets minimum, host-based firewall enabled, no known malware present, registry/file integrity verified.
Remediation
Failed device is routed to a restricted remediation VLAN. Updates are pushed automatically. Once compliance is achieved, the device is re-admitted to the production network.
NAC access policy methods
Time-based
Grant or deny based on a time schedule. A login attempt at 2 AM from an account that normally logs in at 9 AM triggers a flag or denial.
Location-based
Evaluate the geographic origin of the connection via IP geolocation or GPS. Account logging in from Italy when the employee always logs in from Florida triggers a review.
Role-based (adaptive)
Re-evaluates authorisation based on what the device is trying to do — not just who it is. A standard user laptop attempting to join the server management subnet is rejected even if credentials are valid.
Rule-based
Complex admission policy with compound logical statements: IF user=instructor AND device=managed THEN grant; IF user=student AND device=BYOD THEN restrict. Most flexible policy type.
6
Security Onion — SIEM in Practice
Security Onion bundles Snort, Suricata, Zeek, Wireshark, NetworkMiner, and management tools into a single Linux distribution. The primary alert management interface is Sguil — a real-time alert console that pivots between packet analysis, IDS rules, and threat intelligence lookups.
Working with Sguil alerts
Alert priority
ST field colour-codes priority: red = highest, yellow = medium, descending from there. Sort by priority to work the most critical alerts first.
Show rule
Checking "Show Rule" in the lower-right panel reveals the exact Snort/IDS rule that fired the alert — the same format covered in Section 4.
Pivot actions
Right-clicking any field opens context menus to: view correlated events, open in Wireshark, open in NetworkMiner/Zeek, or perform an internet threat intelligence lookup on an IP.
Categorize events
Once reviewed, events are categorized (e.g., "CAT VI: Reconnaissance, Probes & Scans") and marked. Press F6 to apply the same category to all related alerts in bulk.
Key Sguil analysis patterns
Sguil alert analysis workflow
# Alert 3.19 — ET SCAN: Potential SSH Scan OUTBOUND Rule:alert tcp $HOME_NET any -> $EXTERNAL_NET 22 fires if 5 packets to port 22 within 120 seconds → Someone inside is scanning external SSH — investigate the source IP
# Alert 3.35 — High packet count, large download Content-Type: text/html BUT magic bytes: MZ MZ = Windows executable file header → File labelled as HTML is actually an .exe — possible malware download → Extract via NetworkMiner, run in sandbox for static/dynamic analysis
# Alert 3.95+ — Trojan download followed by C2 callout Port 80:Trojan downloaded (inbound) Port 443:Suspicious outbound — plain-text POST over HTTPS port Legitimate HTTPS starts with TLS handshake — plain text over 443 = red flag → Likely stage-one dropper establishing C2 channel
Writing and tuning custom Snort rules in Security Onion
Custom rules are stored in /etc/nsm/rules/local.rules and loaded with sudo rule-update. Rules with SID ≥ 1,000,000 are local rules. New rules should be tuned iteratively — a rule matching all ICMP will generate enormous noise; narrowing to external→internal ping bursts (itype:8, 20+ pings in 30 seconds) produces actionable alerts.
Security Onion ships with sample PCAP files under /opt/samples/ that can be replayed through the sensor using tcpreplay — giving you realistic alert generation without needing a live network attack. This is the best way to practise Sguil analysis before the exam.
Exam
Quick Reference Cheat Sheet
Firewall log formats
iptables = Syslog/CIS format (timestamp, kernel, rule prefix, attribute=value pairs). Windows = W3C Extended (comment header declares fields; last comment line is the column key).
Processed top-to-bottom, first match wins. Most specific rules at top. Explicit deny-all (deny any any) at the bottom = default-deny stance. Drop > reject (stealth). Cisco wildcard mask is inverted subnet mask.
Firewalking / egress
Firewalking = enumeration via TTL probes through open ports. Block outgoing ICMP to stop it. Egress: allowlist outbound ports, restrict DNS to trusted resolvers, drop known-bad IPs, isolate unnecessary subnets.
Black hole vs sinkhole
Black hole = silently drops traffic (null interface). Sinkhole = redirects to analysis network. Both mitigate DDoS. Router-level more efficient than firewall-level. Risk: may block legitimate users sharing IPs.
Proxy types
Forward = client → proxy → internet. Non-transparent = explicitly configured. Transparent = network-enforced, bypasses are impossible. Reverse = internet → proxy → internal server (single inbound chokepoint).
WAF
Layer 7 firewall — parses HTTP content, not just IP/port. Protects web apps from SQL injection, XSS, XML injection. Standard firewalls cannot do this. WAF logs in JSON format.
Bundles Snort+Suricata+Zeek+Wireshark. Sguil = real-time alert console. MZ magic bytes = Windows EXE disguised as HTML. Plain-text POST over port 443 = C2 red flag. tcpreplay replays PCAPs for practice.