Linux Firewall Engineering: Filtering & Access Control

I configured a Linux gateway with iptables to control traffic between two virtual networks. The work covered default policies, stateful forwarding, a client-specific Telnet exception, ICMP rate limiting, and an experiment with connection-rate controls. I verified behavior using client commands and firewall counters, with mixed results in the final scan-control stage.

The rules ran on the gateway. INPUT covered traffic addressed to the gateway itself, OUTPUT covered traffic it originated, and FORWARD covered traffic crossing between the LANs. I flushed rules and reapplied the default policies between experiments, so the following stages represent separate configurations.

I set INPUT and FORWARD to DROP and left OUTPUT at ACCEPT. This required explicit permission for traffic entering or crossing the gateway while allowing the gateway to initiate traffic. I then permitted new connections from the inside interface and established or related return traffic from outside.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A FORWARD -i eth1 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Enlarge

Enlarge

The inside host successfully pinged Kali with three replies and no loss. My report also describes a failed inbound ping, but that screenshot targets 192.168.1.10 rather than the inside host at 192.168.2.10. It therefore does not reliably verify the intended inbound-blocking test.

For the Telnet exception, I identified the Windows XP machine’s MAC address with ipconfig /all and allowed TCP port 23 from that source on the outside interface. Windows reached a Metasploitable login session, while the Kali attempt remained at “Trying”. The matching firewall counter also increased.

Enlarge

Enlarge

This was an access-control exercise using a legacy lab service. A MAC match identifies a source on the adjacent network segment; it is not a substitute for user authentication or an encrypted remote-access protocol.

In a fresh ruleset, I allowed incoming echo requests at one packet per second with a burst allowance of three, and allowed echo replies back out. Normal ping received five replies from five requests. The flood test sent 757 packets and received 14 replies, approximately 98% loss.

iptables -A FORWARD -i eth0 -o eth1 -p icmp --icmp-type echo-request -m limit --limit 1/second --limit-burst 3 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -p icmp --icmp-type echo-reply -j ACCEPT

Enlarge

Enlarge

The limit match supplies a shared allowance for packets matching this rule. The result shows rate restriction in this test, not a general denial-of-service defense or an ability to distinguish intent.

For the final stage, I added service exceptions and experimented with the recent module to track new TCP traffic from Kali. My written configuration described a ten-hit threshold over 30 seconds. However, the captured final rules use a 15-second window and place HTTP accepts before the recent checks. These are materially different configurations.

Enlarge

Reviewing that screenshot also reveals a broad ACCEPT for new TCP traffic below the threshold, duplicate entries, and zero hits on the scan DROP rules. As written, the broad ACCEPT can permit traffic beyond the intended service exceptions, and the earlier HTTP accepts bypass the later checks. The screenshot does not demonstrate that the rate-control drop rule triggered.

Enlarge

Enlarge

Enlarge

The HTTP counters show that packets matched an allow rule; they do not establish a completed TCP handshake or HTTP response. My original report suggested an environment issue, but the supplied evidence does not establish the cause. Nmap’s discovery result likewise cannot establish that the host cannot be enumerated.

A follow-up would first reconcile the active rules with the intended policy: remove duplicate entries, restore only the required service permissions, and check rule order. I would then retest each allowed flow in both directions, recording counters and packet captures to locate the missing replies. These changes and tests have not been performed as part of this write-up.

For scan controls, I would compare discovery-enabled scanning with a lab scan that skips discovery, then test bursts above and below the threshold, slower probes, and multiple sources. A rate threshold may affect legitimate clients opening many connections while missing slower activity.

The stateful-forwarding and ICMP experiments gave me practical experience with interface direction, connection state, and measurable filtering behavior. Reviewing the final stage reinforced that a rule counter is only one piece of evidence: it must agree with the client result and return path. A timed-out command or incomplete scan should lead to investigation, rather than being counted automatically as a successful security control.