Organization Overview
Started last year, Luna Bags (LB) is a new fashion company that sells a variety of eco-friendly handbags and backpacks. The company has about 20 employees, mostly working from its New York main office and some working remotely from home, who are responsible for different business functions, including finance, marketing, IT, customer relations, human resources, and management executives. They hired me as a specialist in the cybersecurity team for the company to implement strategies to secure the company’s network.
Network Topology
The company has a visualized network to test the proposal. 192.168.60.0/24 is an internal network where many employees need to access internal services and the customer database. 10.9.0.0/24 is the DMZ where many public services are offered to LB’s customers.
Network Overview
Luna Bags network is divided into distinct zones to enforce security boundaries. The primary zones include the External (Internet), the DMZ (demilitarized zone for public-facing services), the Internal Network (trusted corporate LAN), and a VPN Subnet for remote users. This segmented design ensures that each zone’s traffic can be controlled and monitored.
The network is divided into four distinct zones — External, DMZ, Internal, and VPN — each protected by firewall rules that enforce strict segmentation. The External network is treated as untrusted, with only HTTP traffic to the DMZ permitted, while all other inbound traffic, including ping requests, is dropped to minimize exposure. The DMZ (10.9.0.0/24) hosts public-facing services like the web server and acts as a buffer zone; it allows limited communication with the internal network, ensuring that even if compromised, attackers cannot reach internal resources.
The Internal network (192.168.60.0/24) is Luna Bag’s secure LAN, completely isolated from the internet, along with some exceptions for internal employees, with outbound access and controlled access to the DMZ, maintaining a strong internal defense. Lastly, the VPN subnet (10.10.10.0/24) allows secure remote access, treating authenticated VPN users as internal clients while routing all their traffic through the corporate firewall. This architecture enforces a least-privilege model, ensuring that only business-critical traffic flows between zones, significantly reducing the risk of lateral movement or external compromise.
Firewall Architecture and Explanation (Rule Table Included)
The firewall configuration on the router is structured into categories of rules, each governing traffic between specific zones or handling particular types of traffic. At a high level, the firewall is set to “deny by default” — any traffic not explicitly allowed in these rules will be blocked. The rules below are processed in order, and they apply to the router’s main firewall chains: INPUT, FORWARD, and OUTPUT.
External → DMZ Traffic:
Only HTTP (port 80) from the internet to the DMZ web server (10.9.0.5) is allowed using a specific FORWARD rule. All other ports, protocols, and services are logged and dropped, preventing attackers from probing other services in the DMZ. This follows the principle of least privilege, exposing only what’s necessary.Internal → DMZ Traffic:
Internal users (192.168.60.0/24) can access the DMZ for HTTP (80) and SSH (22) using specific rules. This supports web testing and administrative SSH access without opening DMZ services to the public. Any non-approved traffic, like Telnet, is dropped by default.Internal → Internet (Outbound) Traffic:
Internal hosts are allowed to initiate outbound internet connections for browsing, email, etc., via a general rule allowing new sessions to 0.0.0.0/0. This is complemented by stateful inspection, allowing return traffic seamlessly.NAT for Internal Outbound Traffic:
The router performs NAT masquerading on outbound traffic (MASQUERADE), allowing internal private IPs to access the internet while hiding internal addressing from external entities. This is essential for internet connectivity and enhances privacy.HTTPS Access Rule:
A specific rule also permits outbound HTTPS (port 443) from internal users. While somewhat redundant due to the general outbound rule, it reinforces the allowance of secure web browsing. We may further refine this if access control policies evolve.DMZ → Internal Traffic:
The firewall blocks all new connections initiated by the DMZ to the internal network. This ensures that even if a DMZ host is compromised, it cannot reach internal resources. Only reply traffic (e.g., SSH session responses) is allowed through stateful tracking.VPN Access (Remote VPN Clients ↔ Internal Network):
The firewall securely enables remote access by allowing VPN connections on UDP port 1194 to the router’s internal IP (192.168.60.1), using the rule. Once connected, VPN clients on the 10.10.10.0/24 subnet are permitted to communicate with internal resources (192.168.60.0/24) via bidirectional FORWARD rules, allowing seamless access to file servers, printers, and other services as if the user were on-site.
Additionally, the firewall supports full-tunnel VPN functionality by applying NAT masquerading, which enables VPN clients to access the internet through the corporate gateway. This ensures their traffic is filtered and monitored like any internal user, improving security on untrusted networks. By restricting access to a defined subnet and enforcing encryption and authentication, this setup aligns with best practices for secure and manageable remote access.
Management Access (SSH to Router, ICMP Ping):
The firewall configuration permits secure SSH access to the router exclusively from the internal network (192.168.60.0/24), allowing IT administrators to manage firewall, VPN, and routing settings without exposing this sensitive service to external or DMZ sources. Additionally, ICMP echo (ping) requests are allowed from internal and optionally from DMZ hosts to their respective router interfaces for basic network diagnostics. This controlled use of ping supports troubleshooting without weakening security, as external ICMP requests are blocked, and all replies are governed by stateful inspection.Stateful Connection Tracking (Established/Related Traffic):
I configured Luna Bag’s firewall to use stateful inspection, allowing return traffic for established and related connections using iptable rules. This enables secure two-way communication without requiring duplicate rules. Packets that don’t match a valid connection, such as stray XMASs or FINs are dropped, enhancing protection against spoofed or malformed traffic. This mechanism ensures only legitimate, session-based traffic is allowed, reducing risk and simplifying rule management.Dropping Invalid or Malicious Packets:
The firewall uses connection tracking to identify and drop packets marked as INVALID, which often represent malformed, spoofed, or out-of-sequence traffic. These are logged with the prefix “DROP INVALID:” and provide valuable insights into potential attacks or network misconfigurations. This rule adds an extra layer of protection against non-standard or malicious traffic.Null, Xmas, and FIN Scan Protection:
The firewall blocks stealth scanning techniques — Null, Xmas, and FIN scans — by detecting specific TCP flag patterns and dropping such packets immediately. This prevents attackers from using these methods to discover open ports, making the network appear “filtered” and significantly harder to map or target.Rate Limiting on Web Server:
A rule caps concurrent connections to port 80 at 100 per IP, rejecting further attempts to prevent simple DoS or abuse. This rate-limiting protects server resources from being overwhelmed by excessive connections from a single source while maintaining performance for legitimate users.Default DROP Policy:
The firewall applies a strict default deny policy (iptables -P FORWARD DROP) for all traffic not explicitly permitted. This ensures that any unforeseen or misconfigured services are automatically blocked, enforcing strong access control and minimizing risk from unanticipated vulnerabilities.
Attack Stimulation and Validation
To verify that the firewall is indeed providing the intended protection, I performed a series of tests simulating both malicious attacks and legitimate traffic. Below, I outlined each test scenario, the method used, and the observed result, demonstrating that the firewall rules are effective.
Simulated Attacks (Blocked Traffic)
Null Scan
I performed a Null scan (nmap -sN) against the DMZ web server, which sends TCP packets with no flags. The firewall’s Null scan rule dropped these silently. Nmap reported all ports as “filtered” or “open|filtered,” confirming that the firewall successfully blocked the scan and concealed open ports.Xmas Scan
An Xmas scan (nmap -sX) was launched, sending TCP packets with FIN, PSH, and URG flags. The firewall’s explicit rule targeting this flag combination effectively blocked the packets. Nmap could not determine the status of any ports, verifying that the firewall prevented reconnaissance attempts.Fin Scan
I executed a FIN scan (nmap -sF), which sends TCP packets with only the FIN flag. Although not explicitly blocked, these were dropped by the firewall’s stateful inspection as they lacked a proper SYN handshake. All ports appeared filtered, confirming that the firewall blocked the scan based on connection state.DMZ to Internal Access Attempt
To validate internal network protection, I attempted to connect from the DMZ server to an internal host on random ports, but all attempts failed as expected. The firewall logged these as “FW DROP DMZ->INT” confirming that DMZ-initiated traffic to the internal LAN is effectively blocked, preventing lateral movement even if the DMZ is compromised.
Additionally, I conducted external Nmap scans targeting ports other than HTTP (80) and VPN (1194) on the DMZ server, and all were shown as “filtered.” Attempts to access closed ports (e.g., port 81) or internal IPs (e.g., 192.168.60.5) were also silently dropped. These results confirm that only explicitly allowed services are accessible externally, while everything else remains hidden and unreachable — ensuring a strong, locked-down perimeter.
Blocked Traffic Tests (Simulation of Attacks and Unauthorized Access)
Telnet/FTP from External to DMZ: Attempted to connect to DMZ server on ports 21 and 23 from the internet, were dropped silently. Logs confirmed “FW DROP EXT->DMZ” entries, validating firewall enforcement.
DMZ to Internal FTP Attempt: DMZ server tried to initiate FTP to the internal host, which failed. The connection was blocked and logged as “FW DROP DMZ->INT”, confirming strict internal network protection.
Internal Telnet to DMZ: An internal client tried Telnet to 10.9.0.5 (port 23), which timed out. Only SSH and HTTP are permitted to DMZ, proving the firewall’s service-specific rules.
DMZ to Internal HTTP Probe: A DMZ host tried to access internal HTTP services and was blocked. The attempt was logged, confirming the firewall’s DMZ-to-Internal isolation is working.
External Access to Unauthorized Ports: Nmap scans from external sources (except port 80) returned “filtered.” Attempts to access ports like 22, 81, and 3389 received no response, proving stealth protection.
Allowed Traffic Tests (Legitimate Business Connectivity)
External Access to DMZ Web Server: HTTP requests from external users to the public web server (10.9.0.5) succeeded. Verified using curl and logs showing accepted port 80 connections.
Internal Access to DMZ Web Server: HTTP requests from internal clients to the public web server (10.9.0.5) succeeded. Verified using curl and logs showing accepted port 80 connections.
Internal SSH to DMZ and Router: SSH from internal hosts to DMZ (10.9.0.5) and router (192.168.60.1) was successful. Admin access worked, while SSH from DMZ was denied, as expected.
Additional Hardening in Configuration
I have implemented several advanced hardening measures that significantly enhance the security and resilience of its firewall setup. The configuration adopts a default DROP policy, which blocks all unsolicited traffic unless explicitly permitted, reducing the risk of exposed services and making the network less visible to automated scans. Stateful inspection is used to allow only valid return traffic, ensuring that unauthorized or malformed packets are dropped, offering basic protection against certain DoS attempts. The firewall also includes detailed logging of dropped packets, enabling the security team to monitor for suspicious activity and respond quickly to potential threats.
Additionally, anti-scan rules proactively block stealthy reconnaissance techniques like Null, Xmas, and FIN scans, helping to hide open ports from attackers. A rate-limiting rule on port 80 restricts the number of concurrent connections per IP, preventing a single host from overloading the web server. The router itself is hardened by running only essential services, with unnecessary ports (like HTTP or SNMP) disabled to reduce the attack surface. Furthermore, NAT combined with private IP addressing ensures that internal systems are not directly reachable from the outside, adding both network segmentation and obscurity. Collectively, these measures form a defense-in-depth strategy that not only blocks common threats but also provides administrators with visibility and control to detect and respond to more sophisticated attacks early.
Maintenance and Future Recommendations
To sustain its strong security posture, we suggest that Luna Bags regularly audit firewall rules to align with evolving business needs and remove outdated entries. Log monitoring with alerts or SIEM integration is crucial for spotting anomalies like excessive “DROP INVALID” entries. All systems, including the router and web servers, must be kept patched to guard against known vulnerabilities. As traffic scales, additional throttling using iptables modules can help mitigate abuse. Strong VPN security, with multi-factor authentication and access reviews, is vital due to its direct link to internal resources. Finally, periodic penetration testing should be conducted to validate and enhance the firewall’s resilience against real-world threats.
