Showing posts with label nmap. Show all posts
Showing posts with label nmap. Show all posts

Sunday, January 29, 2012

[Quick Notes] Various network scan types

A pentester performs several types of network scans during a test. These are usually sequential in nature, that is, we proceed with each scan, collect information and the move on to the next scan. With each scan, we gather specific information about our target environment.

1. Network Sweeps: Objective is to identify any live IP addresses in the target range - think, ping <IP> or nmap -sn <IP>.

2. Network Tracing: Here we try to determine the target network topology & create a network map - think, traceroute or nmap --trace <IP>.

3. Port Scanning: As the name suggests, we attempt to identify any open, listening TCP and UDP ports on target hosts. At this step, a pentester gets a fair idea on what kind of applications & services are running in the environment. If any of the services is/are known to be vulnerable, a tester has a potential avenue of compromising the vulnerable host.

4. OS fingerprinting: Now that we have identified the running services, we must identify the platform it is running on. Is the target a Solaris server, or is it RHEL or a Microsoft Windows 2008 server? Our exploits, other attacks and more importantly, the overall attack process for a host running a vulnerable service, for example, will vary based on what is the host OS. Once a target OS is known, a tester can research for known OS vulnerabilities, exploits & potential security controls in place. The actual attack surface on the host, hence, becomes clear with the knowledge of target OS.

Simply use nmap to fingerprint the OS (Active OS fingerprinting): nmap -O <IP> / or use p0f3 (Passive OS fingerprinting).

5. Version Scans: This scan attempts to confirm what versions of services are running on the end hosts. Knowing the service versions can also, in some cases, immediately tell a tester if a vulnerable service is implemented in the target environment. An example is SSH v1, which has known vulnerabilities. With nmap, service scan is: nmap -sV <IP>.

6. Vulnerability Scanning: At this point, we know the live IPs, listening ports, what services are running on the ports, what is the operating system and platform of the targets, and what are the versions of services running on them. This scanning phase confirms if any of the identified hosts & services have known vulnerabilities. Most vulnerability scanners today also tell if there are any known, publicly-available exploits present for an identified vulnerability, whether certain services are using no authentication or weak auth (think, default or no MSSQL 'sa' account), CVE-ID, etc.

Friday, December 23, 2011

[Quick Notes] Nmap TCP / UDP scanning

TCP Scanning:
Pretty straight...

1. TCP SYN sent
TCP SYN / ACK received
=> Target TCP Port is open
=> Nmap marks this result as 'Open'
2. TCP SYN sent
RST / ACK received
=> Target TCP port is closed
OR
=> Firewall blocked the request / response | i.e. we cannot reach that port at all
=> Nmap marks this result as 'Closed'
3. TCP SYN sent
ICMP Port unreachable received
=> A network / host firewall is blocking access to port
=> Nmap marks this result as 'Filtered'
4. TCP SYN sent
No Response received
=> Nmap resends SYN packet. If still nothing is received, then either port is closed or a network / host firewall is blocking our request packet.
=> Nmap marks this result as 'Filtered'

UDP scanning:

1. UDP datagram sent
Response received
=> Target UDP port is open
=> Nmap marks this result as 'Open'
2. UDP datagram sent
'ICMP Port Unreachable' received
=> Target UDP port is closed
OR
=> Firewall blocked the outbound response
For this scenario, Nmap checks if response is ICMP port unreachable Type 3, Code 3. If it is, then Nmap confirms that port is 'Closed'. For any other ICMP port unreachable errors - type 3, code 1, 2, 9, 10, or 13, Nmap will mark the port as 'Filtered'.
3. UDP datagram sent
No response received
This could be because of several reasons such as closed port, firewall blocking incoming UDP probe packet, firewall may be blocking outbound UDP response, or that the UDP port being probed could be expecting a data in order to respond back.
Specific to this scenario, where a UDP port may be looking for data in the incoming request packet, Nmap makes use of a handful of payloads. This payload is protocol specific like DNS 53, SNMP 161, rpc 111 etc. In response to these payloads, a relevant listening UDP port will send back a response. Therefore, the reliability of UDP scan results goes up.
=> Based on the response / no response, Nmap will mark this port as 'Open|Filtered'.

[Quick Notes] Nmap's way of probing targets

Reading up on Nmap. Thought of sharing this quick post.

Nmap probes a target before scanning it for open ports and services. Nmap address probing works as follows:-

For root / administrator users
-> If the attacker / scanning box is on the same subnet as the target, then nmap will only out ARP requests.

However if attacker sits on a different subnet than the target, then nmap will send
-> ICMP Echo Request
-> TCP SYN to port 443
-> TCP ACK to port 80
-> ICMP Timestamp Request [Type 13]
Note that Nmap sends out ALL 4 probe packets at once; it does not wait to receive response to ICMP Echo Request.

For non-root / non-administrative users
Nmap will simply start a 3-way handshake by sending
-> TCP SYN to port 80
-> TCP ACK to port 443
It does NOT send any ICMP packet.