Expand description
An implementation of a subset of the nmap scanning tool.
Simple example
use pistol::tcp_syn_scan_single_port;
use std::net::Ipv4Addr;
fn main() {
// If you don't want to provide the `source address`, you can provide the `interface` for the program to infer.
let src_ipv4 = Some(Ipv4Addr::new(192, 168,213, 129));
// If the value of `source port` is `None`, the program will randomly generate the source port.
let src_port = None;
// The destination address is required.
let dst_ipv4 = Ipv4Addr::new(192, 168,213, 128);
// The source address and interface must provide at least one
let i = None; // let i = Some("ens33");
// `max_loop` indicates the maximum number of loops that the program will wait for the target packet in a loop.
// The larger the value, the longer the wait time for the program to scan.
// And the smaller the value, the more unreliable the program's scanning results increases.
let max_loop = Some(32);
// Test with an open port `80`.
let ret = tcp_syn_scan_single_port(src_ipv4, src_port, dst_ipv4, 80, i, true, None, max_loop).unwrap();
println!("{:?}", ret);
// Test with an closed port `9999`.
let ret = tcp_syn_scan_single_port(src_ipv4, src_port, dst_ipv4, 9999, i, true, None, max_loop).unwrap();
println!("{:?}", ret);
}Output
192.168.72.136 80 open
TcpScanResults { addr: 192.168.72.136, results: {80: Open} }
192.168.72.136 9999 closed
TcpScanResults { addr: 192.168.72.136, results: {9999: Closed} }
Structs
Enums
Functions
- ARP Scan. This will sends ARP packets to hosts on the local network and displays any responses that are received. The network interface to use can be specified with the
interfaceoption. If this option is not present, program will search the system interface list forsubnetuser provided, configured up interface (excluding loopback). By default, the ARP packets are sent to the Ethernet broadcast address, ff:ff:ff:ff:ff:ff, but that can be changed with thedestaddroption. Whenthreads_numis 0, means that automatic threads pool mode is used. - ICMP Ping. In addition to the unusual TCP and UDP host discovery types discussed previously, we can send the standard packets sent by the ubiquitous ping program. We sends an ICMP type 8 (echo request) packet to the target IP addresses, expecting a type 0 (echo reply) in return from available hosts. As noted at the beginning of this chapter, many hosts and firewalls now block these packets, rather than responding as required by RFC 1122. For this reason, ICMP-only scans are rarely reliable enough against unknown targets over the Internet. But for system administrators monitoring an internal network, this can be a practical and efficient approach.
- IP Protocol Scan. IP protocol scan allows you to determine which IP protocols (TCP, ICMP, IGMP, etc.) are supported by target machines. This isn’t technically a port scan, since it cycles through IP protocol numbers rather than TCP or UDP port numbers.
- TCP ACK Ping. The TCP ACK ping is quite similar to the SYN ping. The difference, as you could likely guess, is that the TCP ACK flag is set instead of the SYN flag. Such an ACK packet purports to be acknowledging data over an established TCP connection, but no such connection exists. So remote hosts should always respond with a RST packet, disclosing their existence in the process.
- TCP ACK Scan. This scan is different than the others discussed so far in that it never determines open (or even open|filtered) ports. It is used to map out firewall rulesets, determining whether they are stateful or not and which ports are filtered. When scanning unfiltered systems, open and closed ports will both return a RST packet. We then labels them as unfiltered, meaning that they are reachable by the ACK packet, but whether they are open or closed is undetermined. Ports that don’t respond, or send certain ICMP error messages back, are labeled filtered.
- TCP Connect() Scan. This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, otherwise the port isn’t reachable. One strong advantage to this technique is that you don’t need any special privileges. Any user on most UNIX boxes is free to use this call. Another advantage is speed. While making a separate connect() call for every targeted port in a linear fashion would take ages over a slow connection, you can hasten the scan by using many sockets in parallel. Using non-blocking I/O allows you to set a low time-out period and watch all the sockets at once. This is the fastest scanning method supported by nmap, and is available with the -t (TCP) option. The big downside is that this sort of scan is easily detectable and filterable. The target hosts logs will show a bunch of connection and error messages for the services which take the connection and then have it immediately shutdown.
- TCP FIN Scan. There are times when even SYN scanning isn’t clandestine enough. Some firewalls and packet filters watch for SYNs to an unallowed port, and programs like synlogger and Courtney are available to detect these scans. FIN packets, on the other hand, may be able to pass through unmolested. This scanning technique was featured in detail by Uriel Maimon in Phrack 49, article 15. The idea is that closed ports tend to reply to your FIN packet with the proper RST. Open ports, on the other hand, tend to ignore the packet in question. This is a bug in TCP implementations and so it isn’t 100% reliable (some systems, notably Micro$oft boxes, seem to be immune). When scanning systems compliant with this RFC text, any packet not containing SYN, RST, or ACK bits will result in a returned RST if the port is closed and no response at all if the port is open. As long as none of those three bits are included, any combination of the other three (FIN, PSH, and URG) are OK.
- TCP Idle Scan. In 1998, security researcher Antirez (who also wrote the hping2 tool used in parts of this book) posted to the Bugtraq mailing list an ingenious new port scanning technique. Idle scan, as it has become known, allows for completely blind port scanning. Attackers can actually scan a target without sending a single packet to the target from their own IP address! Instead, a clever side-channel attack allows for the scan to be bounced off a dumb “zombie host”. Intrusion detection system (IDS) reports will finger the innocent zombie as the attacker. Besides being extraordinarily stealthy, this scan type permits discovery of IP-based trust relationships between machines.
- TCP Maimon Scan. The Maimon scan is named after its discoverer, Uriel Maimon. He described the technique in Phrack Magazine issue #49 (November 1996). This technique is exactly the same as NULL, FIN, and Xmas scan, except that the probe is FIN/ACK. According to RFC 793 (TCP), a RST packet should be generated in response to such a probe whether the port is open or closed. However, Uriel noticed that many BSD-derived systems simply drop the packet if the port is open.
- TCP Null Scan. Does not set any bits (TCP flag header is 0). When scanning systems compliant with this RFC text, any packet not containing SYN, RST, or ACK bits will result in a returned RST if the port is closed and no response at all if the port is open. As long as none of those three bits are included, any combination of the other three (FIN, PSH, and URG) are OK.
- TCP SYN Ping. The function send an empty TCP packet with the SYN flag set. The destination port an alternate port can be specified as a parameter. A list of ports may be specified (e.g. 22-25,80,113,1050,35000), in which case probes will be attempted against each port in parallel.
- TCP SYN Scan. This technique is often referred to as “half-open” scanning, because you don’t open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and wait for a response. A SYN|ACK indicates the port is listening. A RST is indicative of a non-listener. If a SYN|ACK is received, you immediately send a RST to tear down the connection (actually the kernel does this for us). The primary advantage to this scanning technique is that fewer sites will log it. Unfortunately you need root privileges to build these custom SYN packets. SYN scan is the default and most popular scan option for good reason. It can be performed quickly, scanning thousands of ports per second on a fast network not hampered by intrusive firewalls. SYN scan is relatively unobtrusive and stealthy, since it never completes TCP connections.
- TCP Window Scan. Window scan is exactly the same as ACK scan except that it exploits an implementation detail of certain systems to differentiate open ports from closed ones, rather than always printing unfiltered when a RST is returned. It does this by examining the TCP Window value of the RST packets returned. On some systems, open ports use a positive window size (even for RST packets) while closed ones have a zero window. Window scan sends the same bare ACK probe as ACK scan.
- TCP Xmas Scan. Sets the FIN, PSH, and URG flags, lighting the packet up like a Christmas tree. When scanning systems compliant with this RFC text, any packet not containing SYN, RST, or ACK bits will result in a returned RST if the port is closed and no response at all if the port is open. As long as none of those three bits are included, any combination of the other three (FIN, PSH, and URG) are OK.
- UDP Ping. Another host discovery option is the UDP ping, which sends a UDP packet to the given ports. If no ports are specified, the default is 125. A highly uncommon port is used by default because sending to open ports is often undesirable for this particular scan type.
- UDP Scan. While most popular services on the Internet run over the TCP protocol, UDP services are widely deployed. DNS, SNMP, and DHCP (registered ports 53, 161/162, and 67/68) are three of the most common. Because UDP scanning is generally slower and more difficult than TCP, some security auditors ignore these ports. This is a mistake, as exploitable UDP services are quite common and attackers certainly don’t ignore the whole protocol. UDP scan works by sending a UDP packet to every targeted port. For most ports, this packet will be empty (no payload), but for a few of the more common ports a protocol-specific payload will be sent. Based on the response, or lack thereof, the port is assigned to one of four states.