CSA (312-39) SOC Simulation Lab
Master Linux host firewall visibility. In this simulation, you will learn how to configure iptables to monitor suspicious traffic during an active incident response engagement.
Scenario Context
You are a Tier 2 SOC Analyst responding to an alert at a mid-sized healthcare provider. The primary EDR agent on a critical internal database server (`db-prod-01`, running CentOS 7) has crashed. Concurrently, the network firewall has recorded sporadic, tiny bursts of encrypted traffic leaving the server's subnet, destined for an unknown external IP.
The L1 analyst suspects malware beaconing (C2 communication) but the perimeter firewall logs are aggregated and missing the granular process-to-port mapping. You have SSH access to `db-prod-01`. You need to capture exactly what the server is attempting to send out to the internet by temporarily configuring the local Linux firewall to log the egress traffic before it leaves the interface.
Security Environment
Checking the current state of the local iptables configuration on `db-prod-01`:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
12450 1.2M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 500 packets, 42K bytes)
pkts bytes target prot opt in out source destination
# Note: No explicit DROP or LOG rules for outbound traffic. Policy is ACCEPT.
*System logs (`/var/log/messages`) currently show no firewall activity.*
Question
What's Happening Here?
We suspect the database server is acting as a C2 beacon (sending data out). The perimeter firewall isn't giving us the host-level context we need. By interacting with the local Linux kernel's Netfilter framework via `iptables`, we can force the system to write packet headers to syslog (`/var/log/messages` or `/var/log/kern.log`) before the traffic leaves the NIC.
Why the Answer is Correct (B)
iptables -A OUTPUT -j LOG is the syntactically correct command to achieve our goal here.
• -A tells iptables to Append the rule to the end of a chain.
• OUTPUT targets the chain handling locally generated packets leaving the host.
• -j LOG tells the firewall to Jump to the LOG target (which writes the packet header to the kernel logging daemon).
Why the Others are Wrong
A & D: The -B flag is not a valid standard standard command in iptables. You typically use -A (Append) or -I (Insert). Using -B will throw a syntax error in the terminal.
C (iptables -A INPUT -j LOG): While syntactically valid for logging incoming traffic, the EC-Council answer key specifies B, which aligns perfectly with our need to monitor outbound (OUTPUT) beaconing traffic in this scenario.
Mini-Lesson: The Non-Terminating LOG Target
In SOC operations, you must understand how firewall rules are evaluated top-to-bottom. The LOG target is special: it is a non-terminating target.
Unlike -j DROP or -j ACCEPT, which immediately stop rule evaluation for that packet, a packet matching a -j LOG rule will be logged to syslog, and then continue down the chain to be evaluated against the next rules. Always place your LOG rules directly above your DROP rules so you log the packet right before you kill the connection.
Want to sharpen your SOC detection skills further?
Explore more CSA simulations →