DEV Community: Prem Kumar Santhanam

Understand Authentication — NTLM vs Kerberos vs LDAP

Prem Kumar Santhanam — Sun, 21 Jun 2026 13:23:07 +0000

This blog provides an in-depth analysis of three popular authentication methods — NTLM, Kerberos, and LDAP — to recommend an efficient and secure authentication solution for a startup or for people who are starting their careers in cybersecurity.

This analysis aims to identify the best-suited method for protecting user identities and maintaining data integrity in a company environment. The three authentication methods each offer unique strengths and face specific limitations. Each method was evaluated across several dimensions, including usage scenarios, security strengths, limitations, and potential vulnerabilities.

NT LAN Manager (NTLM) Authentication

What It Is

NTLM (NT LAN Manager) is an authentication protocol that was developed by Microsoft and used in Windows-dependent environments. Its function is to somehow restrict access and secure communication in the form of a challenge-response. It employs hash-based rather than sending plaintext passwords, which reduces some risks but does not provide the encryption required for full security.

Purpose

The purpose of NTLM is to verify the identity of users within a network and control access to network resources, providing a basic level of security that restricts unauthorized access. It was designed to support Windows-based networks, offering a protocol that could authenticate users without exposing their passwords during transmission.

How They Work

The server challenges a client trying to authenticate, and the client responds with a hash that corresponds to the password. The NTLM password is encrypted with a one-way hash. The password is first hashed into a binary large object of fixed length, and this binary hash is used for authentication instead of the password. This method of operation reduced the chances of a plain-text password traversing the network, which was considered an improvement in security at that time. NTLM uses a six-step challenge-response mechanism to authenticate users :

Step 1: The user’s device (client) initiates the authentication process by sending an access request to the server.

Step 2: Upon receiving the request, the server creates a random challenge (a numeric value) and sends it back to the client. This challenge is unique for each authentication session, providing a fresh element in each exchange.

Step 3: The client uses the stored password hash to encrypt the received challenge, generating a unique response. The password hash itself is generated by applying a hashing algorithm that the client can use for verification.

Step 4: The client returns the computed response to the server. This response acts as proof of the user’s identity, as it can only be generated correctly with the correct password hash.

Step 5: The server compares the response received from the client to its own computed response, using the stored password hash for that user. If the two responses match, it verifies that the client has the correct password hash, authenticating the user.

Step 6: Once the server confirms the validity of the client’s response, it allows the user access to the requested resources.

Where They Are Used

Essentially, NTLM is supported mainly on Windows OS networks and within the legacy systems themselves to assist in the processes that require the use of older systems. The NTLM authentication method has been discontinued in favor of secure authentication protocols. NTLM is still applicable in certain scenarios:

Intranets and Internal Networks: NTLM is typically used in IT departmental groups when there is little to no need for external access. Because it is so simple to deploy and works with many outdated systems, it is perfect for most places where maintaining older systems is a priority, but protective measures are not a necessity.
Legacy Systems: Most, if not all, companies that utilize an outdated IT architecture still use NTLM authentication to connect their machines operating on an older version of Windows. Where systems have not migrated to Kerberos or other current protocols, NTLM is useful, including in scenarios for small or medium-sized enterprises where migration resources are unavailable.

Implementing on the company network

Implementing NTLM in the company infrastructure would generally be limited due to its security vulnerabilities, such as susceptibility to pass-the-hash attacks and lack of encryption in transit. However, there are a few good cases where NTLM might be used in a supporting role:

Internal Administrative Access: NTLM could be used to control authentication to internal information administrative systems or back office, where employees need operational resources. Such may be appropriate where these systems are in a closed network, isolated from any external threats.
VPN and Remote Worker Access: It uses an offline infrastructure, and hence, we can authenticate remote employees accessing company resources through a VPN by means of NTLM. This is not the best option due to NTLM’s weaknesses; it could be used for a short-term or transitional situation where stronger protocols such as Kerberos cannot be used because of technical limitations or a lack of sufficient resources.

Strengths

Resource Efficiency: The great advantage of NTLM, as stated by its minimal infrastructure requirements, is that many servers, encryption keys, or wide area network alterations do not have to be drawn. For a company with limited technical resources, NTLM offers a flexible user authentication method that does not require such an extensive configuration as for more complicated protocols.
Low Management Overhead: NTLM does not need the centralized management infrastructure that protocols such as Kerberos require. Unlike Kerberos, which is much more complex and involves KDCs, NTLM is a hash-based protocol that simplifies the management of the authentication process and does not require as complex IT staff to manage.

Weaknesses

Lack of Encryption for Data in Transit: NTLM does not provide for the encryption of the challenge-response swap during an authentication process. This absence of encryption puts the user’s password hash and other sensitive information at risk of interception. In this manner, the attackers are able to capture data and seek to abuse it in attacks involving certain manipulation, for example, replay attacks.
Susceptibility to Pass-the-Hash Attacks: In this attack, a hacker captures a hashed password and reuses it to gain unauthorized access, without needing to know or decrypt the actual password. This is possible because NTLM relies heavily on hashes, which can be captured and exploited by attackers with network access.

Common Attacks

Replay Attack

The NTLM system is susceptible to replay attacks due to its absence of encryption or session validation features. A replay attack is when an attacker captures the client-server authentication via a valid handshake and attempts to resend that exchange for malicious gain. The NTLM method does not have any features built into it to mitigate or combat the abuse of identical credentials or information, so whenever a credential is obtained by an attacker, it can always be used to impersonate the real user.

As an example, suppose a malicious individual sitting on the network could take over a valid NTLM authentication session between an employee and the network resource server. This type of attacker is not looking for intervention and can use the same credentials over and over again, enabling them to traverse the internal resources to gain the same permissions as the employee and spark an attack on internal tools such as sensitive order records and customer profiles.

Brute-Force and Dictionary Attacks

Also described as passwords cracking attack is a form of attack whereby hackers aim to achieve the generation of a password by hitting the hash with several iterations of the password or even common password phrases. Attackers have been able to carry out such attacks because the NTLM hashes are considered weak, which makes them easy to crack with today’s computational power.

For Instance, if an attacker gains access to NTLM hash values — such as through a compromised database — they could use a brute-force or dictionary attack to decode weak passwords. By using software that rapidly tests common password combinations against the hash, the attacker could retrieve plaintext passwords from poor hashes.

Kerberos

What It Is

Kerberos is a network authentication system that was created in the 1980s at MIT as its first implementation, and technologies and techniques have undergone progressive advancement in the current era. It was specifically created to minimize credential leakage during communication and ensure trust relationships between users and servers. The primary function of Kerberos is issuing ‘tickets’ to users and servers as authentic login qualifiers for virtually all secure transactions through a Key Distribution Center (KDC), which transaction takes place via server authentication and encryption.

How They Work

The entire process revolves around the Key Distribution Center (KDC), which acts as the trusted authority for issuing authentication tickets. This process is divided into two main stages:

Initial Authentication and Ticket Granting Ticket (TGT) Issuance: Any user of a network configured with a Kerberos authentication system must first log in by submitting their user name and password credentials from a device, the first time they connect to the Kerberos-protected network. This request is sent to the Authentication Server (AS), which, together with a directory service form the KDC. The credentials of the user are verified by the AS, which, if found correctly entered, grants a Ticket Granting Ticket (TGT), which is encrypted with a hash of the password for the user account. The TGT is a string used to represent the user by his/her credentials, which the user can use whenever he/she desires to access other services on the network without running through a login process every time.
Service Ticket Request and Access: After being issued a TGT, the user can then make a request for certain services that are provided on the network. To do this, they use the TGT and reach the service that issues tickets for thematic network resources, which is TGS, or rather Trusted Gateways, as in the KDC structure. The TGS will have the task of confirming the validity of the TGT, and if affirmative, supply a ticket that renews service to the asset that was requested by virtue of the ticket that it validates.

Here’s a breakdown of each step and the role of each component in this process:

Step 1: The user logs into the Kerberos-secured network by providing their credentials, and the client software on the user’s device encrypts the password and sends an authentication request to the Authentication Server (AS) within the KDC.

Step 2: The AS verifies the user’s credentials by comparing them with its stored records. If valid, the AS generates a Ticket Granting Ticket (TGT), which includes a session key encrypted with the user’s password hash. This ensures that only the user can decrypt the TGT.

Step 3: When the user needs access to a network service, they present their TGT to the Ticket Granting Server (TGS), which is also part of the KDC. The TGS verifies the TGT and, if valid, issues a service ticket specific to the requested service. This service ticket is also encrypted with the session key and is valid only for the duration needed to access the service.

Step 4: The user sends the service ticket to the specific network service they wish to access, and the service validates the service ticket using the session key, confirming the user’s identity. Once validated, the service grants the user access to the requested resource, allowing them to interact with the network without re-entering credentials.

Where They Are Used

Its ability to securely authenticate users and services across untrusted networks makes it well-suited to complex, multi-user settings where frequent access to various resources is needed. Here are some key real-world applications of Kerberos:

Corporate and Enterprise Networks: For secure logging in and managing various resources within its internal resource such as file servers, databases, applications, and shared drives, several corporations with a deep intranet implement a mechanism named Kerberos.
Educational Institutions: Many colleges and research institutions, where there are thousands of users, tend to use KERBEROS in these directions: access and authentication of users to resources like academic databases, library systems, and student portals. Students and staff are effortlessly provided with access to a variety of departments and roles due to the controlled central management of user accounts.

Implementing on the company network

As a startup, you can consider Kerberos as an efficient and steady solution to provide both customer and internal authentication. It's derived from a ticket-based approach, lowering the frequency with which passwords are required, thereby reducing the opportunities for password misuse. Here are some ways Kerberos could be implemented:

Secure Internal Operations: Kerberos can also be deployed for the internal users, for employees and administrators, who need to perform back-end access to internal applications like inventory databases, customer management systems, and any internal resources.
Customer Identity Management: Even though Kerberos is not normally used for e-commerce, for direct and customer-related authentication due to the level of complexity, it can fit very well as a part of other tools focused on identity management.
Payment and Financial Systems: Kerberos can also be deployed in the payment gateways and in the financial systems to protect the relations of the e-commerce site with the payment systems. In these systems, Kerberos provides additional security since each transaction request is authenticated, allowing sensitive financial data to be better protected.

Strengths

Enhanced Data Protection for Growth: However, as business organizations grow, security threats are bound to increase. The ticketing and encryption features of Kerberos provide a layered security that is able to scale with the organization and therefore prevent data loss and unauthorised access.
Support for Cross-Platform Environments: As companies grow, they may have to chart a mix of technologies, including Windows, Linux, and cloud-based services. Kerberos can perform well in a cross-platform environment. So the companies will be able to grow and enhance their resource base without having to change authentication technologies.

Weaknesses

Vulnerability to Password-Guessing Attacks: With low or easily guessed passwords, Kerberos, despite its encryption, still remains prone to dictionary and brute force attacks. Those who obtain encrypted Kerberos tickets or session keys might use brute force to crack weak ones.
Complex Configuration and Management: Kerberos is both time and energy-consuming as it demands proper setup, time coordination among the devices, and effective updates. Kerberos can only be effective when users and systems are well synchronized, owing to the time-stamping of tickets that prevents the repetition of transactions from various users.

Common Attacks

Pass-the-Ticket (PtT) Attack

Pass-the-ticket attack refers to attackers obtaining any of the already obtained valid Kerberos tickets, especially the Ticket Granting Ticket (TGT) that does not belong to them, and using that ticket to gain access. The ticket contains some information concerning the users who own it, and since attackers manage to acquire the ticket, they can bypass all passwords and pretend to be the owner of the ticket, allowing them to move around the network.

For Instance, an attacker breaches an employee’s device and captures a valid Kerberos TGT during the breach. By means of the pass-the-ticket technique, the attacker has the former’s TGT and impersonates that employee to use other network services without the former’s actual password. In this way, attackers may be able to get into the system’s administrative, customer’s, or even financial records area without being discovered and thus, may be able to steal sensitive information and money.

Replay Attack

The attacker intercepts an existing valid authentication exchange and retransmits some parts of the packet in order to gain access that did not belong to them. Through the use of time stamps on the tickets, Kerberos claims to prevent replay attacks. Time measuring and management, however, must be reasonably accurate, thus leaving the door open to abuse. If the network time is not uniform, attackers may use this weakness to their advantage and utilize old tickets that they’ve acquired.

For instance, if an attacker intercepts a Kerberos ticket while it is in transit between the client and server, this attack could allow unauthorized access to order management or inventory systems, where attackers could modify orders, cancel transactions, or manipulate stock records.

Lightweight Directory Access Protocol (LDAP)

What It Is

Lightweight Directory Access Protocol is an open standard-based protocol that is utilized to retrieve and control directory information within an IP-based network. It acts as a central point of management, where it retains and arranges related information regarding users, devices, and resources in a form. Being system and application-friendly, it becomes very useful in handling authentication in heterogeneous environments. It is usually applied in enterprise networks for the purpose of authenticating and authorizing users, enabling the administrator to handle many users and access to network resources from one point.

Purpose

LDAP provides management of users and resources in the network from one central point with safe and secure authentication and directory access. The solution helps organizations to efficiently enforce access control policies, keep a single repository of user credentials, and enable seamless authentication for users across different applications.

How They Work

LDAP’s authentication process involves verifying a user’s identity by comparing their credentials against information stored in a centralized directory. This directory, structured as a hierarchical tree, contains user entries (or objects) with attributes such as usernames, passwords, email addresses, and roles. When a user attempts to authenticate, LDAP uses bind operations to validate their credentials.

Step 1: When a user attempts to access a resource or application, their device (client) initiates a bind request to the LDAP server. The bind request includes the user’s Distinguished Name (DN), a unique identifier within the directory, and the user’s password.

Step 2: The LDAP server receives the bind request and searches its directory tree for the DN provided in the request. Once it locates the user’s entry, the LDAP server retrieves the stored credentials (password) associated with the DN to prepare for validation.

Step 3: The LDAP server compares the password provided in the bind request with the password stored in the user’s directory entry. If the credentials match, the bind operation is successful, and the user is authenticated. If the credentials do not match, the bind operation fails, and access is denied.

Step 4: Upon successful authentication, the LDAP server establishes a session for the user.

Step 5: LDAP uses Access Control Lists (ACLs) to determine which resources or directory information the authenticated user can access. They are configured based on individual users, groups, or organizational units.

Step 6: After authentication, LDAP supports attribute-based searches within the directory. These searches allow applications to retrieve specific information tied to the user’s entry, such as group memberships, roles, department, or organizational unit.

Step 7: Once the user completes their tasks or logs out, the session is terminated, closing their access to the LDAP-controlled resources.

Where They Are Used

LDAP is widely used in various enterprise, educational, and government settings where centralized user management and secure authentication are essential. Here are some common real-world applications and scenarios:

Educational Institutions: For universities or schools with large populations of students, faculty, and staff, LDAP is commonly used for identity management and access. Educational institutions can utilize LDAP directories as an effective way of managing access to various resources on campus, like library databases, student portals, learning management systems, and research tools, through an automated process from a single point of control.
Single Sign-On (SSO) Systems: It is usually extended to include SSO procedures, allowing a user to log in only once to a computer and gain access to various resources without the need to log in again.

Implementing on the company network

In the company backend, it will provide centralized user management and secure authentication for both employees and customers. Here are some:

Single Sign-On (SSO) for Internal Applications: Often, employees have many applications that they use, such as an analytics application, a CRM app, and email, etc. It would connect with an SSO service so that the employees can authenticate once and access many internal applications smoothly.
Customer Identity Management: It can be applied at the backend for handling management and customer authentication for people who logon to the e-commerce site. It might keep track of customer data, including the user ID, hashed password, and the account status, and use those to check if the request to log on has been reported.

Strengths

Cross-Platform Support for Flexibility: Many companies operate on different platforms and software. One of the advantages of using LDAP is that it provides a good adaptation since it not only cuts across Windows but also Linux and Unix, as well as cloud application and thus reduces the acquisition and setup of multiple authentication applications.
Support for Encryption (LDAPS): LDAP can operate over SSL/TLS-encrypted connections, known as LDAPS, which secures the communication between clients and servers.

Weaknesses

Lack of Built-In Encryption: By default, LDAP does not encrypt data in transit. Unless configured to use LDAPS (LDAP over SSL/TLS), sensitive information such as usernames and passwords can be transmitted in plaintext, leaving it vulnerable to interception by attackers.
Limited Support for Direct Customer Authentication: LDAP is generally better suited for internal user authentication and enterprise environments. It is not commonly used for direct customer-facing applications, as it lacks certain features designed for customer identity management, such as self-service account recovery and multi-factor authentication (MFA).

Common Attacks

Man-in-the-Middle (MitM) Attacks

However, LDAP by default does not encrypt data in transit, and LDAPS (LDAP over SSL/TLS) would need to be first enabled in order to avoid man-in-the-middle (MitM) attacks. In a MitM attack, it is assumed that an attacker intercepts the communication between a client, typically an application, and the LDAP server and is thus able to capture usernames, passwords, and other sensitive information in plaintext. This is a serious threat, particularly for environments where LDAPS is used to secure the connection, and none has been put in place.

Brute-Force and Dictionary Attacks

LDAP directories are also susceptible to brute-force or dictionary attacks in which an intruder tries to guess usernames and passwords in order to break into the system. Because LDAP is widely regarded as a centralized authentication system, succeeding in a brute attack could enable the attacker to breach several applications and systems that are linked to the directory. Slowly shifting password policies and the absence of multi-factor authentication (MFA) may also expose LDAP directories to additional heightened vulnerability to these attacks.

Conclusion

After a comparative analysis of three different authentication methods, LDAP presents the best scalability, security, and manageability. Its centralization and integration abilities suit a growing enterprise, and TLS/SSL encryption will protect data on the fly. Even though NTLM is relatively simple to configure, it is not appropriate for data protection in an e-commerce framework due to its security flaws. Kerberos is strong on security; this might be overkill for small teams in terms of resources.

Strengthening Network Defense for a fashion startup (Proposal)

Prem Kumar Santhanam — Fri, 19 Jun 2026 03:58:34 +0000

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.

Existing Topology

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.

Proposed Topology

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.

Rule Proposal

Attack Stimulation performed