Nmap/Short Course/Lecture 10
From charlesreid1
Main page: Nmap/Short Course
Contents
Summary and Objective
This session will focus on how Blue Teams use Nmap to verify security controls and ensure adherence to policies.
Objective: To teach students how to utilize Nmap and the Nmap Scripting Engine (NSE) for security auditing tasks, including verifying compliance with security policies, identifying rogue devices, and testing the efficacy of firewall rules and network segmentation.
Notes
Recap & Introduction to Security Auditing with Nmap
Quick Recap of Lecture 9
In our last lecture, we initiated our exploration of Nmap for Blue Team operations by focusing on network inventory and asset management. We discussed how to perform comprehensive network discovery, establish asset baselines using Nmap's XML output, and leverage Ndiff to track network changes over time. This foundational knowledge of "what's on the network" is crucial for effective defense.
What is Security Auditing?
Security auditing is a systematic, measurable technical assessment of how an organization's security policy is being employed on its systems and networks. It's an active process of verifying that security controls are implemented correctly, are functioning as intended, and are adequate to meet security goals. Unlike passive policy reviews, a security audit often involves active testing and probing to confirm configurations.
What is Compliance?
Compliance refers to adhering to specific laws, regulations, standards, and internal organizational policies. Examples include PCI DSS (Payment Card Industry Data Security Standard) for organizations handling credit card data, HIPAA (Health Insurance Portability and Accountability Act) for healthcare information, or an organization's own internal security policies that dictate, for instance, which services are allowed to run or which cryptographic standards must be used. Non-compliance can lead to fines, legal action, reputational damage, and increased risk of breaches.
Nmap's Role in Auditing and Compliance
Nmap serves as a powerful tool for security auditors to actively test and verify network-level security configurations and policy adherence. It can help answer questions like:
- Are there any unauthorized services running on our servers?
- Are our systems using strong encryption protocols as required by policy?
- Are firewalls correctly blocking traffic between network segments?
- Are there any rogue devices connected to our network that violate policy? Nmap provides the means to gather empirical evidence about the state of network security controls.
Auditing for Policy Violations with Nmap & NSE
Nmap can be used to actively check for common policy violations and weak configurations.
Identifying Prohibited Services or Ports
Many organizations have policies that restrict or prohibit the use of certain services deemed risky. For example, Telnet (unencrypted remote access), unencrypted FTP, or VNC might be banned. Nmap can be used to scan the network specifically for these forbidden ports.
# Scan a subnet for Telnet (port 23) and VNC (ports 5900-5903) sudo nmap -sS -p T:23,T:5900-5903 --open 192.168.1.0/24 -oN prohibited_services.nmap
The --open option ensures Nmap only reports hosts where these ports are actually open. Any hits would indicate a policy violation that needs investigation. This can be expanded to include any port or service your organization's policy deems unauthorized.
Checking for Weak Configurations with NSE
NSE scripts are invaluable for auditing specific configurations against security best practices or policy requirements:
SSL/TLS Cipher Auditing: The ssl-enum-ciphers script can connect to SSL/TLS enabled services (like HTTPS, SMTPS, IMAPS) and enumerate the supported cipher suites, key exchange methods, and protocol versions. This helps identify services using weak or deprecated ciphers (e.g., SSLv3, RC4) that violate security policies.
sudo nmap -sV -p 443 --script ssl-enum-ciphers <target_IP_or_range>
[Instructor: Run 'sudo nmap -sV -p 443 --script ssl-enum-ciphers <your_lab_web_server_IP>' and show an example where some weak ciphers or SSLv3 might be enabled.] PORT STATE SERVICE VERSION 443/tcp open ssl/http Apache httpd 2.4.x | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_RSA_WITH_RC4_128_SHA (weak) | TLS_RSA_WITH_3DES_EDE_CBC_SHA (strong) | compressors: | NULL | cipher preference: server | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (strong) | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (strong) | compressors: | NULL | cipher preference: server |_ least strength: C
This output would highlight the presence of TLS_RSA_WITH_RC4_128_SHA as a weak cipher.
Default Credentials: Some NSE scripts in the auth category (or specific service scripts) can check for default credentials on devices like routers, printers, or applications. While these can be intrusive (brute category), carefully selected safe or discovery scripts like ftp-anon or those checking for common SNMP community strings (snmp-brute with a list of common strings, or snmp-info which often gets the community string if it's 'public') can identify policy violations regarding default credentials.
# Check for anonymous FTP sudo nmap -p 21 --script ftp-anon <target_IP> # Attempt to get SNMP info with common community strings sudo nmap -sU -p 161 --script snmp-info --script-args snmpcommunity=public <target_IP>
Regularly running such checks helps ensure that systems are configured according to security policies and best practices.
Identifying Rogue Devices and Unauthorized Access Points
Unauthorized devices on the network pose a significant security risk as they are often unmanaged, unpatched, and can bypass security controls.
What are Rogue Devices?
A rogue device is any unauthorized piece of hardware connected to the corporate network. This could be an employee's personal laptop or phone, an unauthorized wireless access point, an IoT device brought from home, or even a malicious device planted by an attacker. These devices are outside the scope of IT management and can introduce vulnerabilities or become pivot points for attackers.
Nmap for Rogue Device Detection
Nmap helps detect rogue devices primarily through comprehensive network inventory and comparison:
- Maintain an Authorized Asset Inventory: This is a database or list of all legitimate, known devices on the network, including their IP and MAC addresses.
- Perform Regular Nmap Scans: As discussed in Lecture 9, conduct regular, thorough Nmap scans of all network segments (
sudo nmap -sn -PR <subnet>for local segments, and port scans for active services). - Compare Scan Results to Inventory: Use Ndiff or custom scripts to compare Nmap's findings (live IPs and MAC addresses) against the authorized asset inventory. Any device found by Nmap that is not in the authorized list is a potential rogue device and needs immediate investigation.
# Example workflow:
# 1. Export authorized MACs to a file: authorized_macs.txt
# 2. Run Nmap scan and get live hosts with MACs:
sudo nmap -sn -oG - 192.168.1.0/24 | grep "Status: Up" | awk '{print $2, $3}' > current_live_hosts.txt
# 3. Script a comparison between current_live_hosts.txt and authorized_macs.txt
OS fingerprinting (-O) can also help identify suspicious device types. For instance, finding a device fingerprinted as a "gaming console" on a secure server VLAN would be highly suspicious.
Detecting Rogue Access Points (WAPs)
A rogue WAP is an unauthorized wireless access point connected to the wired corporate network. It can allow attackers to bypass perimeter defenses and gain direct access to the internal network.
- While Nmap isn't a dedicated wireless scanner like Kismet or Aircrack-ng, if a rogue AP is bridging wireless clients onto the wired network, Nmap can help by identifying these unexpected wired clients. If your Nmap scans suddenly show a cluster of new, unknown devices with MAC addresses from consumer-grade wireless adapter vendors in a specific network segment, it might indicate a rogue AP is present there.
- Some NSE scripts like broadcast-wlan-info (if the Nmap host itself has wireless capabilities and is on the same wireless network as the rogue AP, which is a different scenario) or sniffer-detect (which tries to identify if the target machine is in promiscuous mode, possibly indicating it's part of a rogue setup) might offer clues, but these are more specialized. The primary method with Nmap on the wired side is identifying unexpected client devices. Effective rogue AP detection often requires combining Nmap's findings with dedicated wireless scanning tools and physical security walkthroughs.
Verifying Firewall Rules and Network Segmentation
Firewalls and network segmentation are critical for limiting the blast radius of a security breach. Nmap can help verify they are working as intended.
Importance of Firewalls and Segmentation
Firewalls enforce access control policies between network segments, while network segmentation divides a network into smaller, isolated zones (e.g., DMZ, internal user VLANs, server VLANs, guest VLAN). This "defense-in-depth" strategy aims to prevent an attacker who compromises one segment from easily accessing others. Regular auditing is needed to ensure these controls remain effective.
Using Nmap to Test Firewall Efficacy
Nmap can be used to actively test firewall rules by scanning targets from different network perspectives:
From External to DMZ/Internal: Simulate an external attacker. Scan your public-facing IPs and DMZ servers from an external test IP. Are only the explicitly allowed ports (e.g., TCP/80, TCP/443 for web servers) open? All others should be closed or filtered.
# From an external test machine, scan your public web server sudo nmap -sS -Pn -p1-1024 <public_web_server_IP>
From DMZ to Internal: If a DMZ server were compromised, what could it reach in the internal network? From a test machine in the DMZ, scan critical internal servers. Access should be highly restricted.
Between Internal Segments: Scan from a user VLAN to a server VLAN, or from one department's VLAN to another. Are the segmentation rules (e.g., only allowing access to a specific database port from the application server VLAN) correctly enforced? The ACK scan (-sA) can be particularly useful for inferring firewall rule sets by showing which ports are filtered (firewall is likely blocking) versus unfiltered (firewall is allowing ACK packets through, host is responding with RST).
# From a host in VLAN A, ACK scan a host in VLAN B to check filtering sudo nmap -sA -Pn <target_IP_in_VLAN_B>
Verifying Network Segmentation
The goal is to confirm that traffic cannot flow between segments where it's not supposed to.
For example, if you have a guest wireless network, devices on that guest network should not be able to reach any internal corporate resources. Place a test Nmap scanner on the guest network and attempt to scan internal IP ranges.
# From a test machine on the Guest VLAN: sudo nmap -sS -Pn -T4 10.0.0.0/8 # Attempt to scan internal corporate ranges
Ideally, all probes should time out or be explicitly denied (ports filtered or closed). Any open ports or responsive hosts indicate a segmentation failure.
Lab
The lab for this lecture would involve setting up basic firewall rules in a virtual environment and having students use Nmap from different "zones" to verify if those rules are working as expected.
In the Corporate Network (Scenario 1), students use Nmap and NSE to check for policy violations (e.g., services running on non-standard ports, weak ciphers on an internal web app). Attempt to identify a "rogue" device planted in the network.
Flags
