Penetration Testing with Kali Linux OffSec

nc -nv -u -z -w 1 192.168.50.149 120-123
(UNKNOWN) [192.168.50.149] 123 (ntp) open 
Listing 53 - Using Netcat to perform a UDP port scan 
From the Wireshark capture, we’ll notice that the UDP scan uses a different mechanism than a 
TCP scan. 
Figure 32: Wireshark capture of a UDP Netcat port scan 
As shown in Figure 32, an empty UDP packet is sent to a specific port (packets 2, 3, 5, and 7). If 
the destination UDP port is open, the packet will be passed to the application layer. The response 
received will depend on how the application is programmed to respond to empty packets. In this 
example, the application sends no response. However, if the destination UDP port is closed, the 
target should respond with an ICMP port unreachable (as shown in packets 5, 7, and 9), sent by 
the UDP/IP stack of the target machine. 
Most UDP scanners tend to use the standard “ICMP port unreachable” message to infer the 
status of a target port. However, this method can be completely unreliable when the target port is 
filtered by a firewall. In fact, in these cases the scanner will report the target port as open because 
of the absence of the ICMP message. 

---

Penetration Testing with Kali Linux
PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 
141 
Now that we have covered both TCP and UDP scanning techniques, let’s review a few common 
pitfalls that can occur when performing such scans. 
UDP scanning can be problematic for several reasons. First, UDP scanning is often unreliable, as 
firewalls and routers may drop ICMP packets. This can lead to false positives and ports showing 
as open when they are, in fact, closed. Second, many port scanners do not scan all available 
ports, and usually have a pre-set list of “interesting ports” that are scanned. This means open UDP 
ports can go unnoticed. Using a protocol-specific UDP port scanner may help to obtain more 
accurate results. Finally, penetration testers often forget to scan for open UDP ports, instead 
focusing on the “more exciting” TCP ports. Although UDP scanning can be unreliable, there are 
plenty of attack vectors lurking behind open UDP ports. A TCP scan also generates much more 
traffic than a UDP scan, due to overhead and packet retransmissions. 
6.3.3
Port Scanning with Nmap 
Having built a solid understanding of port scanning fundamentals, let’s now learn about Nmap, 
the de-facto tool for port scanning. 
Nmap
253
(written by Gordon Lyon, aka Fyodor) is one of the most popular, versatile, and robust 
port scanners available. It has been actively developed for over two decades and offers numerous 
features beyond port scanning. 
Some of the Nmap example scans we’ll cover in this Module are run using sudo. This is because 
quite a few Nmap scanning options require access to raw sockets,
254
which in turn require root 
privileges. Raw sockets allow for surgical manipulation of TCP and UDP packets. Without access 
to raw sockets, Nmap is limited as it falls back to crafting packets by using the standard Berkeley 
socket API.
255
Before exploring some port scanning examples, we should understand the footprint that each 
Nmap scan leaves on the wire and the scanned hosts. 
A default Nmap TCP scan will scan the 1000 most popular ports on a given machine. Before we 
start running scans blindly, let’s examine the amount of traffic sent by this type of scan. We’ll 
scan one of the lab machines while monitoring the amount of traffic sent to the target host using 
iptables
.
256
We will use several iptables options. First, let’s use the -I option to insert a new rule into a given 
chain, which in this case includes both the INPUT (Inbound) and OUTPUT (Outbound) chains, 
followed by the rule number. We can use -s to specify a source IP address, -d to specify a 
destination IP address, and -j to ACCEPT the traffic. Finally, we’ll use the -Z option to zero the 
packet and byte counters in all chains. 
kali@kali:~$