Auditing a local network with Nmap and Wireshark It's one of the most effective ways to understand what's really happening in your infrastructure, detect overexposed services, and see what information an attacker could see if they infiltrate your network segment. These are two well-established tools, widely used by both administrators and penetration testers. When combined effectively, they allow you to go from a simple snapshot of open ports to a detailed analysis of every packet in transit.
In this article we will bring together Everything you need to set up a complete audit From a local network: from the concepts of port scanning, TCP flags, and scan types in Nmap, to advanced filtering with Wireshark to detect these scans and play cat and mouse with evasion techniques. You'll also see examples of teaching environments with virtual machines, typical lab exercises (ping sweep, SYN scan, NULL scan, MITM with Bettercap), and several additional tools that complement Nmap and Wireshark.
What is a port scan and why does it matter in an audit?
A port scan It's an automated process that sends packets to all or some of the 65.535 TCP/UDP ports on one or more computers to see which ones respond and how. From these responses, we can deduce which services are active, what operating system might be running, and even if there are firewalls filtering the data.
For an attacker, a good port scan is the way to locate “entry points” and weak pointsThis includes misconfigured services, outdated versions with known vulnerabilities, or open protocols like Telnet, FTP, or HTTP. For an administrator or auditor, the same scan reveals what's exposed, what needs to be shut down, and what requires better protection.
It is important to be clear that It's not a good idea to open more ports than necessaryMany routers, servers, or applications can leave ports open "just because," or because someone opened them for testing and no one ever closed them again. Scanning your own network with Nmap helps you get an accurate inventory of what's accessible from inside or outside.
In addition to inventory, it is important Use firewalls and intrusion detection systems that filter unwanted access and log suspicious connection attempts. And, of course, keep systems, routers, and services updated to reduce the impact of any ports that, for business reasons, you absolutely have to keep open.
What is Nmap and what can it do on a local network?
Nmap (Network Mapper) It's a free, open-source utility designed to discover devices on a network, analyze which ports they have open, and what services are listening in the background. It runs via the command line on Linux, Windows, and macOS, and has an optional graphical interface called Zenmap.
With Nmap you can detect hosts both on the local network and over the Internet: computers, routers, switches, IoT devices, servers, etc. In addition to listing which ports are open or filtered, it can attempt to identify the operating system, the version of the services, and launch security scripts (NSE) that automate penetration testing.
Among its most relevant features is support for different types of scansIt supports TCP (SYN, connect, FIN, NULL, Xmas…), UDP, ICMP, and some more advanced methods that attempt to evade certain firewalls. It also allows working with IPv4 and IPv6, and scanning single hosts, IP ranges, or entire subnets.
One of Nmap's strengths is that It allows scanning large volumes of targets. quite efficiently. It can control the level of aggressiveness, packet transmission speed, and degree of parallelism. This is useful both for planned audits of corporate networks and for simulations in teaching labs.
Port states and scan types in Nmap
When Nmap finishes a scanIt classifies each port into one of several states that are important to understand, because their interpretation is fundamental to the audit:
- openThere is an application accepting connections on that port (TCP or UDP). This is an obvious attack surface.
- closedThe port is responding, but no service is listening. The host is alive, but that specific port isn't providing any traffic. Ideally, it should be blocked by a firewall.
- filteredA firewall or filter prevents Nmap from determining whether it is open or closed (no clear answer).
- open|filtered: It is not possible to know if it is open or filtered, typical in certain special UDP or TCP scans (FIN, NULL, Xmas).
- closed|filtered: ambiguous state used in very specific techniques such as IP idle scan.
In a real audit, we usually start with quick scans of the most common ports to get a first photo:
nmap 192.168.1.2
If we want to go all out, it's possible force scanning of all 65.535 ports from a host:
nmap -p 1-65535 192.168.1.2
It's also very common to limit the range to specific ports or blocks that interest us. For example, from 20 to 200:
nmap -p 20-200 192.168.1.2
In addition to port status, Nmap allows you to do operating system and service version detection with a single command, at the cost of being somewhat noisier:
nmap -A -v 192.168.1.2
This OS detection isn't perfect, but it's usually pretty accurate overall. Within the Linux world, pinpointing the exact model and specific version is a different story altogether.
TCP flags, scan types and how to detect them
Nmap takes advantage of the different TCP flags (SYN, ACK, FIN, RST, PSH, URG…) to perform more or less stealthy scans. In CTF-type challenges, for example, it's common to use a "stealth" SYN scan. In defensive environments, it's useful to recognize these patterns in logs or Wireshark.
To understand the scans, you need to be clear about the Classic TCP handshakeSYN → SYN/ACK → ACK. From there, variations can be played that send or not certain flags and cut the connection with a RESET instead of ending the cycle normally.
Many explanations assign numerical values to TCP flags so they can be summed and filtered. For example:
| Head | Price |
|---|---|
| SYN | 1 |
| SYN / ACK | 2 |
| ACK | 4 |
| DATA | 8 |
| FIN | 16 |
| RESET | 32 |
With this encoding method, it is possible, for example, to use the field in Wireshark tcp.completeness and filter by the sum of flags that appear in a specific stream to locate scanning patterns.
Full TCP handshake (connect scan)
In a “full” scan with Nmap (what is known as TCP connect scanOption -sT), the client establishes the entire connection with the server: SYN → SYN/ACK → ACK and, after exchanging some traffic, it closes with a RESET or a normal FIN.
If you capture this sequence in Wireshark and sum the flag values according to the table above (for example SYN + SYN/ACK + ACK + RESET), you can filter with tcp.completeness = 39 to locate connections that have been established and completely broken.
This type of scan is the easiest to detect, since It leaves a trace in the service logs. (web, FTP, Telnet, IMAP, etc.) and in the system log files. In a typical lab, if you have rsyslog running, you'll see messages in /var/log/syslog, /var/log/auth.log, /var/log/daemon.log and similar services when Nmap completes the handshake to services such as in.fingerd, inetd, telnetd, ftpd, dovecot o postfix/smtpd.
SYN “stealth” scan
El SYN scan or “stealth” scan (option -sSThis is one of the most commonly used methods because it is fast and, in principle, less conspicuous. Here, Nmap sends a SYN signal. If the port is open, the server responds with SYN/ACK, and instead of replying with ACK to complete the connection, the scanner disconnects with a RESET.
From Wireshark's point of view, the typical sequence of an open port will be SYN → SYN/ACK → RST, whose sum of flags according to the previous scheme would be (1 + 2 + 32) = 35. Filtering by that value of tcp.completeness It is possible to locate connections that appear to be SYN scans without a complete handshake.
At the application log level, this method is more discreet because Most services fail to register a sessionHowever, if the system has firewall rules that log connection initiation SYN packets, connection attempt entries will appear.
NULL scan and other “weird” scans
Another classic technique is the NULL scan (option -sN), in which Nmap sends TCP packets without any active flags. Although it may sound strange, some TCP stacks react differently to open or closed ports, allowing Nmap to infer the port's state.
In a NULL scan, If the port is closed, it usually returns an RST.While if it's open or filtered, it may not respond. To detect this with Wireshark, you can use filters on... tcp.flags and leave only those segments with all flags set to zero.
Along the same lines, we have scans like the Xmas scan (FIN + PSH + URG), the FIN scan or similar combinations, which try to exploit nuances of the TCP standard or specific implementations to discover ports without following typical handshake patterns.
Controlling Window Size as a Nmap hint
Another feature that can be used to detect scans is the Window Size TCPThe window size is the amount of data a host advertises it can receive. Certain versions of Nmap use fixed values for some types of scans.
For example, it is common in a standard Nmap SYN scan to find SYN packets have a Window Size of 1024 bytes, whereas in “normal” connections of a specific system different values are used (such as 64240 or 65535, depending on OS and configuration).
In Wireshark you could apply a filter like tcp.window_size == 1024 combined with certain flags to locate suspicious patterns. As an attacker or penetration tester, Nmap allows you to modify this behavior with parameters such as --win to avoid leaving such an obvious signature.
Detecting and analyzing Wireshark scans and “unusual” ports
Wireshark It is the protocol analyzer par excellence In the world of network security, it captures packets, decodes them layer by layer (Ethernet, IP, TCP/UDP, HTTP, TLS, etc.), and allows you to apply very fine filters to keep only the traffic you are interested in investigating.
A very practical way to detect scans is to filter by activity in unusual portsIf you have a legitimate web server, it's normal to see traffic to ports 80 or 443. What's not so normal is seeing a lot of attempts to random ports like 1234, 31337, or 4444.
In a corporate network, you can establish a list of “Suspicious” ports associated with malicious frameworks or frequently used attack tools, and filter in Wireshark by those ports to see if there are any probes or unexpected connections. This can be supported by public spreadsheets that compile ports associated with malware and exploitation frameworks.
From a defensive point of view, Wireshark also allows See how different types of Nmap scans behave that you launch yourself in your laboratory, to learn to recognize them: number of packets per port, flags, times between packets, system responses, etc.
Combining filters such as tcp.completeness, tcp.flagsThe number of different ports touched in a short time and window sizes allow you to build manual rules or get inspiration for IDS/IPS rules.
Typical lab: scanning with Nmap and capturing with Wireshark
In many educational settings, a virtualized network environment with VirtualBox to practice risk-free traffic scanning and analysis. A typical example includes three GNU/Linux machines on an internal network: interno1 (192.168.100.11) interno2 (192.168.100.22) and observador (192.168.100.33), each with a fixed MAC address.
The services that are left running by default on these machines are usually numerous: Apache 2, Telnet, SSH, FTP, Finger, MySQL, SMTP (Postfix), POP3 and IMAP (Dovecot), DNS (BIND)… ideal for a scanner like Nmap to have a good number of ports to find.
The first step in that laboratory is usually Enable rsyslog on internal1 to record everything that happens: it is activated with systemctl enable rsyslog y systemctl start rsyslogThus, log files begin to fill up in /var/log , the syslog, auth.log, daemon.log o kernel.log.
From the observing machine, a ping sweep Use Nmap to discover which devices are active on the 192.168.100.0/24 network:
nmap -sP 192.168.100.0/24
Once the active hosts have been identified (excluding the observer itself), scans of the type TCP connect against each of them to see which ports are open and which services are running:
nmap -sT -v -T4 192.168.100.11
nmap -sT -v -T4 192.168.100.22
Then it is repeated against internal1 adding operating system and version detection of the services:
nmap -sT -O -sV -T4 192.168.100.11
Next, the logs of interno1 are consulted, for example with tail -200 /var/log/syslog | lessto check how were those scans recorded? in the various daemons and services, and appreciate the trace left by a TCP connect scan.
Comparing noisy and "stealthy" scans with firewalls and logs
To see the difference in trace between various Nmap techniques, in that same laboratory a iptables rule on internal1 which records any attempt to initiate a TCP connection (SYN packets with NEW status) with an easily recognizable prefix:
iptables -A INPUT -i enp0s3 -p tcp \
--tcp-flags SYN SYN -m state --state NEW \
-j LOG --log-prefix "INICIO CONEXION:"
While the file is being monitored /var/log/syslog with tail -fFrom the observer, three different scans are tested against internal1:
- TCP connection scanning (
-sT). Generates “START CONNECTION:” entries and, in addition, logs in the services that complete the handshake. - SYN scanning (
-sS). It produces “START CONNECTION:” entries, but most services do not log a session because the connection is not completed. - NULL scanning (
-sNIt does not raise the SYN flag, therefore it does not match the firewall rule and The prefix does not appear in the logs, making it more discreet in the eyes of that specific policy.
This comparison helps us understand that Not all types of scans are detected using the same rules. And that, as defenders, we must go beyond "only SYN" if we want to see more camouflaged attempts.
From scanning to MITM: Bettercap, Wireshark and encrypted services
In a second part of the practice, the observer machine is used to Perform ARP and MITM poisoning attacks with Bettercap and then analyze the captured traffic with Wireshark or with the module itself net.sniff from Bettercap. The goal is to compare the exposure of clear protocols (Telnet, HTTP) versus encrypted alternatives (SSH, HTTPS).
Prior to this, SSL support is enabled in Apache on interno2, generating a self-signed certificate with make-ssl-cert to /etc/apache2/ssl/apache.pem, configuring default-ssl.conf to use that file as a certificate and key, activate the SSL module with a2enmod ssl and the default SSL site with a2ensite default-ssl, and restarting Apache.
The first check is performed tshark in observer Listening on the internal network interface, and meanwhile, Telnet and HTTP sessions are opened from internal1 to internal2. Since there is no man-in-the-middle attack, the traffic flows directly between internal1 and internal2, and tshark sees almost none of this flow. This demonstrates that without additional tricks, a third host on the same network doesn't always see external traffic.
If you review the ARP tables for internal1 and internal2 (arp -n), it is observed how each one associates the other's IP to their real MAC, already observer only with their IP and their MAC, without interference.
ARP poisoning and traffic capture
The next step is to start Bettercap in observer mode and activate the modules net.recon y net.probe To discover devices on the network and verify that 192.168.100.11, 192.168.100.22, and 192.168.100.33 appear with their respective MAC addresses. Optionally, the Bettercap web interface can be enabled, although it is not essential for practical purposes.
In parallel, it is launched again tshark in observer to see which ARP frames are appearing. The module's objectives are configured from the Bettercap console. arp.spoof (internal1 and internal2) and the attack is activated with:
set arp.spoof.internal true
set arp.spoof.targets 192.168.100.11,192.168.100.22
arp.spoof on
At that point, Bettercap begins sending false ARP responses ensuring to each machine that the IP address of the other host (internal1 or internal2) corresponds to the observer's MAC address. Taking into account the Question 1The ARP messages sent are essentially "free" (unsolicited) replies that update the victims' ARP cache. As a result, in the ARP tables of internal1 and internal2, the other computer's IP address starts pointing to MAC address 08:00:27:33:33:33 (the observer's), effectively making it a man-in-the-middle.
Comparing Telnet, SSH, HTTP, and HTTPS under MITM
With MITM active, the module is used net.sniff from Bettercap To dump the traffic between internal1 and internal2 into different .pcap files depending on the service being tested, excluding ARP with a filter:
set net.sniff.filter "not arp"
set net.sniff.output /tmp/telnet.pcap
net.sniff on
Meanwhile, from internal1 a Telnet session is opened to internal2 with username “username” and password “username”, files are listed, and the session ends. The file /tmp/telnet.pcap It is then analyzed with Wireshark, and it is trivial to see credentials and commands in plain text following the corresponding TCP flow.
The experiment is repeated using SSH, saving in /tmp/ssh.pcapAnd this time, although the establishment of the SSH connection and the exchange of keys can be observed, The username and password data are encrypted.It is not possible to see credentials in Wireshark, only encrypted frames.
The same applies to HTTP versus HTTPS: with net.sniff dumping to /tmp/http.pcap, a navigation with Lynx or a graphical browser towards http://interno2.ssi.net It leaves HTTP requests and responses completely readable (headers, cookies, parameters, etc.). However, when repeated with https://interno2.ssi.net and analyzing /tmp/https.pcap, it is observed the TLS handshake (ClientHello, ServerHello, certificates, etc.) and then only encrypted traffic labeled as TLS 1.3.
With the filter in hand, you can focus your gaze on tls Within Wireshark, follow the corresponding TCP flow and verify that, although all traffic passes through the attacker, does not have access to the plaintext content unless he manages to break or abuse the encryption somehow.
Customization, Nmap NSE, and integration with other solutions
One of the reasons Nmap remains so powerful today is its high degree of personalization and automationAt the command line level, almost everything is configurable: specific ports, timeouts, number of retries, degree of parallelism, stealth level (profiles T0 to T5), packet fragmentation, spoofed source IP and MAC, etc.
There is also the Nmap Scripting Engine (NSE)This ecosystem of scripts allows you to go far beyond simply checking "port open/closed." There are scripts for brute-forcing SSH or FTP, detecting insecure configurations, checking for known vulnerabilities, obtaining detailed banners, testing against web servers, Samba, DNS, and more.
For example, to attempt a brute-force attack on SSH port 22 of a specific host using two dictionaries, you can use:
nmap -p 22 --script ssh-brute --script-args userdb=usuarios.txt,passdb=claves.txt,ssh-brute.timeout=4s 99.99.99.99
Similarly, to check if an FTP server allows anonymous access or to brute-force credentials, there are scripts such as ftp-anon o ftp-brute. These are launched chained to a -sV -sC or individually as appropriate.
Another advantage is that Nmap integrates very well with other tools. The results can be saved in multiple formats (plain text, XML, grep-friendly, combined with -oA) and then feed subsequent processing, dashboards or even tools like Metasploit, inventory systems or event correlation engines.
At an enterprise level, implementing Nmap as part of a security program involves defining usage policies, scan planning, results analysis, and continuous updatesScanning once and putting it in a drawer isn't very useful; you have to repeat, compare, and act on the findings.
Taken together, using Nmap and Wireshark to audit a local network, complemented by other tools, provides a very complete picture of how services behave, what is actually exposed, and what information an attacker could see or manipulate, making it clear why it is worth investing in encryption (SSH, HTTPS), closing unnecessary ports, a good firewall configuration, and constant monitoring of logs and network traffic.