Monday 31 August 2015

Ethical Hacking - Module 3 : Scanning2

2.6 UDP Scan

# nmap -sU 192.168.100.100
 
This is used to find the status of UDP ports in the target range. At the start of the UDP scan, Nmap sends a 0-byte UDP packet directed towards a UDP port. The target’s response differs depending on the status of the scanned port:

  1. Open port: Data on the scanned UDP port.
  2. Closed port: ICMP error message indicating no service is running on this port.
  3. Open/Filtered port: No ICMP message; Nmap waits for the timeout, and can’t determine whether the port is open, or filtered by a firewall.
UDP can be used to detect malware/spyware effectively.

  • Uses 0 byte UDP data, causing low overhead on the network.
  • Many operating systems put restrictions on UDP traffic, thus this scan can be very slow if run on devices running those operating systems
  • Works well on Microsoft operating systems, since Microsoft does not restrict UDP port traffic.
  • Best for scanning known UDP ports used by spyware/malware for communication.
UDP has no need for SYNs, FINs, or any other fancy handshaking. With the UDP protocol, packets are sent and received without warning and prior notice is not usually expected. This lack of a formal communications process greatly simplifies UDP scanning!

 
 

The nmap output shows the results of the UDP scan:

 
# nmap -sU -v 192.168.0.10

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-11 12:44 EDT
Initiating UDP Scan against 192.168.0.10 [1478 ports] at 12:44
Discovered open port 2001/udp on 192.168.0.10
The UDP Scan took 1.47s to scan 1478 total ports.
Host 192.168.0.10 appears to be up ... good.
Interesting ports on 192.168.0.10:
(The 1468 ports scanned but not shown below are in state: closed)
PORT     STATE         SERVICE
123/udp  open|filtered ntp
137/udp  open|filtered netbios-ns
138/udp  open|filtered netbios-dgm
445/udp  open|filtered microsoft-ds
500/udp  open|filtered isakmp
1031/udp open|filtered iad2
1032/udp open|filtered iad3
1900/udp open|filtered UPnP
2001/udp open          wizard
4500/udp open|filtered sae-urn
MAC Address: 00:30:48:11:AB:5A (Supermicro Computer)

Nmap finished: 1 IP address (1 host up) scanned in 2.241 seconds
               Raw packets sent: 1489 (41.7KB) | Rcvd: 1470 (82.3KB)
 
Advantages of the UDP Scan
Since there's no overhead of a TCP handshake, the UDP scan is inherently less "chatty" once it finds an open port. However, if ICMP is responding to each unavailable port, the number of total frames can exceed a TCP scan by about 30%!

Microsoft-based operating systems do not usually implement any type of ICMP rate limiting, so this scan operates very efficiently on Windows-based devices.

Disadvantages of the UDP Scan
The UDP scan only provides port information only. If additional version information is needed, the scan must be supplemented with a version detection scan (-sV) or the operating system fingerprinting option (-O).

The UDP scan requires privileged access, so this scan option is only available on systems with the appropriate user permissions.

When to use the UDP Scan Because of the huge amount of TCP traffic on most networks, the usefulness of the UDP scan is often incorrectly discounted. There are numerous examples of open UDP ports caused by spyware applications, Trojan horses, and other malicious software. The UDP scan will locate these open ports and provide the security manager with valuable information that can be used to identify and contain these infestations.

 2.7 ACK Scan

# nmap -v -sA 68.46.234.161 -P0 

Nmap's unique ACK scan will never locate an open port. The ACK scan only provides a "filtered" or "unfiltered" disposition because it never connects to an application to confirm an "open" state. At face value this appears to be rather limiting, but in reality the ACK scan can characterize the ability of a packet to traverse firewalls or packet filtered links.

An ACK scan operates by sending a TCP ACK frame to a remote port. If there are no responses or an ICMP destination unreachable message is returned, then the port is considered to be "filtered:"



# nmap -v -sA 68.46.234.161 -P0

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-24 10:40 EDT
Initiating ACK Scan against pcp05116560pcs.tallah01.fl.comcast.net (68.46.234.161) [1663 ports] at 10:40
ACK Scan Timing: About 9.02% done; ETC: 10:46 (0:05:03 remaining)
ACK Scan Timing: About 75.68% done; ETC: 10:42 (0:00:36 remaining)
The ACK Scan took 119.13s to scan 1663 total ports.
Host pcp05116560pcs.tallah01.fl.comcast.net (68.46.234.161) appears to be up ... good.
Interesting ports on pcp05116560pcs.tallah01.fl.comcast.net (68.46.234.161):
(The 1662 ports scanned but not shown below are in state: filtered)
PORT     STATE      SERVICE
6969/tcp UNfiltered acmsoda

Nmap finished: 1 IP address (1 host up) scanned in 119.271 seconds
               Raw packets sent: 3328 (133KB) | Rcvd: 8 (368B)


Advantages of the ACK Scan
Since the ACK scan doesn't open any application sessions, the conversation between nmap and the remote device is relatively simple. This scan of a single port is unobtrusive and almost invisible when combined with the other network traffic.

Disadvantages of the ACK Scan
The ACK scan's simplicity is also its largest disadvantage. Because it never tries to connect to a remote device, it can never definitively identify an open port.

When to use the ACK Scan
Although the ACK scan doesn't identify open ports, it does a masterful job of identifying ports that are filtered through a firewall. This list of filtered and unfiltered port numbers is useful as reconnaissance for a more detailed scan that focuses on specific port numbers.


 



2.8 Idle Scan

# nmap -PN -sI 192.168.238.200 192.168.238.100



Idle scan is a port scanning technique that sends the spoofed (creation of Internet Protocol (IP) packets with a forged source IP address) packets to a system to collect the information about the services that are available. This can be accomplished by impersonating another network device referred as “zombie”.

In this method attacker can scan a target system without sending a single packet from their own IP address.

assume that Computer A wants to scan Computer B, while Computer C is being used as a Zombie.
  • A will first ask to communicate with C, from C’s response, A knows that C’s IP ID is: 1445.
  • A sends SYN to one of B’s ports asking for a connection using C’s IP address.
  • B respond to the relevant IP address, that is C with a SYN+ACK if the port is open, else if the port is closed, then it will send back a RST or nothing at all.
  • A ask to communicate with C one more time to read its IP ID again.
  • If the IP ID is 1447 (increased by two since the last transmission) then the port is open assuming that B responded with a SYN/ACK back to C, hence C had to reply with a RST packet using IP ID = 1446.
  • Else If the IP ID is 1446, (increased by one since the last transmission) then the port is close, assuming that B simply responded with a RST or nothing at all, hence C did not have to communicate back.
The awesome thing about idle scan is that it allows you to scan a host WITHOUT EVER SENDING PACKETS TO IT.

To scan host 192.168.1.100 for example using zombie pc at 192.168.1.200, we use nmap:


# nmap -PN -sI 192.168.238.200 192.168.238.100
 
# nmap -PN -p20-25 -sI 192.168.1.152 192.168.0.131

-sI: is used to run Idle Scan. -PN: is necessary for stealth, otherwise packets would be sent to the target from your real addres. -p20-25: scan ports 20, 21, 23, 24 and 25. 192.168.1.152: Zombie IP. 192.168.0.131: Target IP.

Nmap's idlescan is an ingenious way of scanning a remote device. Nmap uses idlescan to gather port information using another station on the network, and it will appear that the scanning process is initiated from this third-party IP address instead of the nmap station. Although this seems complex, it's a simple process of examining IP fragmentation identification sequences and implementing IP address spoofing.

Before launching an idlescan, a "zombie" station must be identified. This third station will be the pivot point of the idlescan. There are two important requirements associated with this station:

  • The unsuspecting zombie station must be idle (thus the name "idlescan"). The idlescan needs an idle zombie workstation to ensure that the IP identification frames will remain consistent throughout the duration of the scan.

  • The zombie station must provide consistent and predictable IP identification (IPID) values. If the operating system of the zombie does not provide predictable IPIDs, nmap will provide an warning before the scan begins:

  •       WARNING: Idlescan has erroneously detected phantom ports -- is the proxy
          192.168.0.7 (192.168.0.7) really idle?
          
    If the scan cannot complete because of too many inconsistencies, nmap provides a final error message:
          Idlescan is unable to obtain meaningful results from proxy 192.168.0.7
          (192.168.0.7).  I'm sorry it didn't work out.
          QUITTING!
      
The target of the scan can be any system. These two requires requirements are only associated with zombie station.

To begin the idlescan process, nmap first sends a SYN/ACK to the zombie workstation to induce a RST in return. This RST frame contains the initial IPID that nmap will remember for later.


 
 
 


# nmap -v -sI 192.168.0.7 192.168.0.5
 

WARNING: Many people use -P0 w/Idlescan to prevent pings from their true IP.  On the
other hand, timing info Nmap gains from pings can allow for faster, more
reliable scans.

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-24 15:25 EDT
Idlescan using zombie 192.168.0.7 (192.168.0.7:80); Class: Incremental
Initiating Idlescan against 192.168.0.5
Discovered open port 135/tcp on 192.168.0.5
Discovered open port 6969/tcp on 192.168.0.5
Discovered open port 445/tcp on 192.168.0.5
Discovered open port 139/tcp on 192.168.0.5
The Idlescan took 9 seconds to scan 1663 ports.
Host 192.168.0.5 appears to be up ... good.
Interesting ports on 192.168.0.5:
(The 1659 ports scanned but not shown below are in state: closed|filtered)
PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
6969/tcp open  acmsoda
MAC Address: 00:11:43:43:A8:34 (Dell   (WW Pcba Test))

Nmap finished: 1 IP address (1 host up) scanned in 12.629 seconds
               Raw packets sent: 3743 (150KB) | Rcvd: 191 (8786B)
#  



2.9 Protocol Scanning

# nmap -v -sO 192.168.11.1

Want to identify what protocols are running on the target machine.  Known as Internet Protocol scanning, used to determine the protocols a given host is using.

 

IP PROTOCOL SCAN 
This Scan is used to find the ip protocols in use .

# nmap -v -sA 192.168.11.1




2.10 OS Scan

# nmap -O 192.168.1.2

OS fingerprinting techniques can be generalized into two categories, active and passive. 

Active fingerprinting is a lot easier than passive fingerprinting, and is much more likely to return the information an attacker wants. The main reason why an attacker may prefer a passive approach is to reduce the risk of being caught by an IDS, IPS, or a firewall.

Active fingerprinting works by sending packets to a target and analyzing the packets that are sent back.

Almost all active fingerprinting these days is done with Nmap. Nmap is usually used by network adminstrators to monitor the security of their networks.

Passive fingerprinting sniffs TCP/IP ports, rather than generating network traffic by sending packets to them. Hence, it’s a more effective way of avoiding detection or being stopped by a firewall.

Passive fingerprinting uses a pcap (packet capture) API. In GNU/Linux and BSD/Unix operating systems, pcap can be found in the libpcap library, and for Windows, there’s a port of libpcap called WinPcap.

While sniffing traffic, passive fingerprinting does its best to determine a target machine’s OS by analyzing the initial Time To Live (TTL) in packet IP headers, and the TCP window size in the first packet of a TCP session, which is usually either a SYN (synchronize) or SYN/ACK (synchronize and acknowledge) packet.

Passive fingerprinting can make a guess of a target’s OS, because different OSes have different TCP/IP implemetations.
But it’s imperfect to rely on those typical figures. The TTL can be changed as a sniffed packet goes from router to router. TCP window sizes can change according to a number of variables, too.
Hence, passive OS fingerprinting is less accurate than active OS fingerprinting, but may be a technique chosen by an attacker or penetration tester who wants to avoid detection.

  2.11 Window Scan


# nmap -v -sW 192.168.0.67

The window scan is similar to an ACK scan, but the window scan has the advantage of identifying open ports.

The window scan is named after the TCP sliding window, not the operating system of a similar name. It's called the window scan because some TCP stacks have been found to provide specific window sizes when responding to an RST frame.



# nmap -v -sW 192.168.0.67

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-24 11:37 EDT
Initiating Window Scan against 192.168.0.67 [1663 ports] at 11:37
Discovered open port 23/tcp on 192.168.0.67
Discovered open port 21/tcp on 192.168.0.67
Discovered open port 111/tcp on 192.168.0.67
The Window Scan took 1.91s to scan 1663 total ports.
Host 192.168.0.67 appears to be up ... good.
Interesting ports on 192.168.0.67:
(The 1660 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
21/tcp  open  ftp
23/tcp  open  telnet
111/tcp open  rpcbind
MAC Address: 00:10:A4:07:61:30 (Xircom)

Nmap finished: 1 IP address (1 host up) scanned in 2.749 seconds
               Raw packets sent: 1710 (68.4KB) | Rcvd: 1664 (76.5KB)

Advantages of the Window Scan
The window scan operates very simply. Nmap sends a single ACK packet request, and a single RST packet is returned for every scanned port. The network traffic is kept to a minimum, and the scan itself looks relatively innocuous when viewed in a protocol decode.

The window scan doesn't open a session, so there's no application log associated with the window scan's method of operation. Unless there are additional firewalls or network limits at the operating system level, the scan should go unnoticed.

Unlike the ACK scan, the window scan is able to identify open ports. If the destination station's operating system is susceptible to this kind of scan, the window scan becomes a very useful method of port identification.

Disadvantages of the Window Scan
The window scan doesn't work on all devices, and the number of operating systems vulnerable to this unintended window size consistency is dwindling as operating systems are upgraded and patched.

The window scan builds custom ACK packets, so privileged access is required to run this scan.

When to use the Window Scan
The window scan is a useful when looking for open ports while simultaneously maintaining a low level of network traffic. When vulnerable operating systems are identified, the window scan provides a low-impact method of locating open ports.

2.12 Vanilla Scanning

This is the simplest of all scanning techniques and it involves sending packets to each and every port and detecting whether they respond or not. If there is a response from a port, it indicates that the port is open and it can be used to launch an attack. However, since this is a very simple scan, it can be detected and logged by network perimeter devices.
2.13 ICMP Echo scanning / List scan

# nmap -sL -v 192.168.0.10

The list scan isn't really a scan, but it does provide nmap with some troubleshooting and testing capabilities. The list scan simply lists the IP addresses that would normally be actively scanned.

The list scan doesn't ping the host names, and it doesn't send a TCP ACK to the default port number. If reverse DNS resolution is disabled with –n, the list scan is completely silent on the network, with no frames transmitted or received.

 The list scan output shows this lack of activity by identifying the IP address as "not scanned:"
# nmap -sL -v 192.168.0.10

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-11 13:12 EDT
Host 192.168.0.10 not scanned
Nmap finished: 1 IP address (0 hosts up) scanned in 0.255 seconds
# 
 
Advantages of the List Scan
The list scan is a good method to sanity-check a complex nmap scan prior to starting a large batch process or a large group of IP addresses. If any of the IP addresses are defined incorrectly on the command line or the option file, the list scan will identify the errors. These problems can be identified and repaired prior to running any "live" scans.
 
Disadvantages of the List Scan
The list scan isn't really an active scan. It doesn't show availability, it doesn't find any ports, and it doesn't directly connect with an end device.

When to use the List Scan
At first glance, the list scan doesn't appear to be very helpful. What good is a scanning tool that doesn't actually scan anything?
The list scan is often used as a sanity check when a complex scan is defined. If a separate application provides nmap with a list of IP addresses, it may be helpful to have nmap step through a dry-run prior to starting the "production" scan process. For large network audits, this process could be the difference in a successful scan and hours of wasted time!
The list scan is also a useful tool to run "what if" scans. Nmap allows many different IP address options that include randomization, abbreviated subnet mask notation, wildcards, and address ranges. The list scan will confirm the scan process prior to an actual scan.
The list scan implements a reverse DNS lookup for every host specified in the list scan. This means that nmap can be fed a list of IP addresses, and nmap will automatically use the default DNS server to convert the IP addresses to names. This makes it easy to find interesting device names!
 
  2.13 Inverse TCP Flag Scanning (NULL, Xmas, Fin)


Attackers send TCP probe packets with various TCP flags (FIN, URG, PSH) set or with no flags, no response means port is open and RST/ACK means the port is closed.

Nmap can perform an inverse TCP flag port scan, using the following flags:-sF(FIN probe),-sX(XMAS probe), or -sN(NULL probe)
 
 2.14 Version Detection

# nmap -sV -v 192.168.0.10

The version detection scan runs in conjunction with another scan type that will identify open ports. If another scan type is not specified on the command line, nmap will run a TCP SYN scan (for a privileged user) or a TCP connect() scan (for non-privileged users) prior to running the version detection scan.
If open ports are found, the version detection scan will begin the probing process with the remote device. The version detection scan communicates directly with the remote application to uncover as much information as possible.


The scan output displays the application information for each open port, although not all version numbers in this example were identified. The open ports were located by a TCP SYN scan that ran prior to the version scan.
In this example, an open TCP port 520 was located by the SYN scan but the version scan did not recognize the service. A fingerprint was created and nmap provided an URL to use for submission of the unknown service.

# nmap -sV -v 192.168.0.10

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-11 12:41 EDT
Initiating SYN Stealth Scan against 192.168.0.10 [1663 ports] at 12:41
Discovered open port 80/tcp on 192.168.0.10
Discovered open port 3389/tcp on 192.168.0.10
Discovered open port 3306/tcp on 192.168.0.10
Discovered open port 445/tcp on 192.168.0.10
Discovered open port 135/tcp on 192.168.0.10
Discovered open port 139/tcp on 192.168.0.10
Discovered open port 520/tcp on 192.168.0.10
The SYN Stealth Scan took 1.54s to scan 1663 total ports.
Initiating service scan against 7 services on 192.168.0.10 at 12:41
The service scan took 100.01s to scan 7 services on 1 host.
Host 192.168.0.10 appears to be up ... good.
Interesting ports on 192.168.0.10:
(The 1656 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE       VERSION
80/tcp   open  http          Apache httpd 2.0.53 ((Win32))
135/tcp  open  msrpc         Microsoft Windows msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds  Microsoft Windows XP microsoft-ds
520/tcp  open  efs?
3306/tcp open  mysql?
3389/tcp open  microsoft-rdp Microsoft Terminal Service
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/xxxxxxxx:
SF-Port520-TCP:V=3.81%D=4/11%Time=425AA8E8%P=i686-pc-linux-gnu%r(RPCCheck,
SF:24,"\x80\0\0\(r\xfe\x1d\x13\0\0\0\0\0\0\0\x02\0\x01\x86\xa0\x01\x01\x97
SF:\|\0\0\0\0\0\0\0\0\0\0\0\0");
MAC Address: 00:30:48:11:AB:5A (Supermicro Computer)

Nmap finished: 1 IP address (1 host up) scanned in 102.375 seconds
               Raw packets sent: 1757 (70.3KB) | Rcvd: 1664 (76.5KB)

Advantages of Using Version Detection
Version information is valuable information! Version scanning for service information provides easier management of patches and updates. A network security manager can scan every host in an organization to verify that software is at the correct versions. Stations showing older software revisions are identified and further action can be taken.

Disadvantages of Using Version Detection
The version scan also opens sessions with the remote applications, which will often display in an application's log file. These sessions are almost always necessary, and can't be avoided if the version scan is going to decisively determine the application type and version.

Version detection will only work with TCP or UDP port scans.

When to use Version Detection
The name and version of a service can provide the security team with information that it can use to keep the network applications patched and up-to-date. The server team can use version scans to confirm that a series of upgrades have been completed successfully. If unknown stations are found during a ping scan, the version scan can help determine what applications these 'rogue' stations are providing!

 2.15 IP Protocol Scan

# nmap -sO -v 192.168.0.10

The IP protocol scan is a bit different than the other nmap scans. The IP protocol scan is searching for additional IP protocols in use by the remote station, such as ICMP, TCP, and UDP. If a router is scanned, additional IP protocols such as EGP or IGP may be identified.

An unavailable IP protocol does not respond to the scan. The MAC addresses are displayed to emphasize the IP layer conversation that occurs between the stations:



The nmap output shows the IP protocol types available on a Windows-based workstation:

# nmap -sO -v 192.168.0.10

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-11 12:46 EDT
Initiating IPProto Scan against 192.168.0.10 [256 ports] at 12:46
Discovered open port 6/ip on 192.168.0.10
Discovered open port 1/ip on 192.168.0.10
The IPProto Scan took 5.70s to scan 256 total ports.
Host 192.168.0.10 appears to be up ... good.
Interesting protocols on 192.168.0.10:
(The 253 protocols scanned but not shown below are in state: open|filtered)
PROTOCOL STATE    SERVICE
1        open     icmp
6        open     tcp
17       filtered udp
MAC Address: 00:30:48:11:AB:5A (Supermicro Computer)

Nmap finished: 1 IP address (1 host up) scanned in 6.620 seconds
               Raw packets sent: 511 (10.3KB) | Rcvd: 4 (194B)

Advantages of the IP Protocol Scan
The IP protocol scan locates uncommon IP protocols that may be in use on a system. These are often found on routers and switches that are configured with additional IP protocol support, such as EGP or IGP. Locating these additional protocols can help determine if the destination device is a workstation, a printer, or a router.

Disadvantages of the IP Protocol Scan
When looking at a packet trace, an IP protocol scan looks fairly obvious. Since most networking protocols are based on TCP or UDP, any deviation from those two protocol types is conspicuous. This scan will certainly appear on any network monitoring application that identifies the IP protocol types in use.


When to use the IP Protocol Scan
The IP protocol scan is useful when looking for "other" protocols that might be in use. If a device is suspected to be a router, the IP protocol scan can locate router protocols that would assist with the identification process.
 

  2.15 RPC scan


# nmap -v -sR 192.168.0.7

A remote program call (RPC) scan is used to locate and identify RPC applications. After open ports are identified with another scan type, the RPC scan sends each open port an RPC null to provoke a response from any RPC application that might be running. The RPC scan runs automatically during a version scan (-sV).

The RPC scan is referenced as an RPCGrind scan in the nmap output.

# nmap -v -sR 192.168.0.7
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-22 23:12 EDT
Initiating SYN Stealth Scan against 192.168.0.7 [1663 ports] at 23:12
Discovered open port 22/tcp on 192.168.0.7
Increasing send delay for 192.168.0.7 from 0 to 5 due to max_successful_tryno increase to 4
Discovered open port 2049/tcp on 192.168.0.7
Discovered open port 111/tcp on 192.168.0.7
Discovered open port 886/tcp on 192.168.0.7
The SYN Stealth Scan took 10.26s to scan 1663 total ports.
Initiating RPCGrind Scan against 192.168.0.7 at 23:12
The RPCGrind Scan took 1.11s to scan 4 ports on 192.168.0.7.
Host 192.168.0.7 appears to be up ... good.
Interesting ports on 192.168.0.7:
(The 1659 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE                VERSION
22/tcp   open  ssh
111/tcp  open  rpcbind (rpcbind V2-4) 2-4 (rpc #100000)
886/tcp  open  unknown
2049/tcp open  nfs (nfs V2-3)         2-3 (rpc #100003)
MAC Address: 00:03:47:6D:28:D7 (Intel)
Nmap finished: 1 IP address (1 host up) scanned in 12.228 seconds
               Raw packets sent: 1900 (76KB) | Rcvd: 1664 (76.5KB)

Advantages of the RPC Scan
The RPC scan provides detailed RPC application and version information. If the remote device is running an RPC-based application, nmap will reveal everything!

Disadvantages of the RPC Scan
The RPC scan opens application sessions, so there will be transaction events in the application logs. Once the application is opened, the size of the conversation will vary. Some open ports will transfer data, but no RPC information. Other RPC applications will send a number of frames as nmap queries for the application name and version number.

When to use the RPC Scan
If RPC applications are of interest, the RPC scan will efficiently and effectively locate all RPC applications and identify the RPC application name and version. The RPC scan automatically runs during a version scan, combining valuable version information with detailed RPC data.

 2.16 TCP ACK Ping Operation


# nmap –v –sS 10.0.0.4 –PA23,110

Instead of using the default option of both an ICMP echo request and a TCP ACK, the –PA option sends a TCP ACK and forgoes any ICMP echo requests. This is a good alternative when the use of ICMP is not applicable because of packet filtering or firewalls.

The TCP ACK ping consists of a random TCP ACK sent to a remote device. If the device is active, a RST will be received in return. If the device is not active or the port is filtered, there will be no response to the ACK. It's interesting to note that these results are identical to the results found with the TCP ACK scan (-sA).

The [portlist] option allows the user to specify a series of ports for the ACK ping to use. The specification of this port list isn't as flexible as specifying IP addresses, but this is a pre-scan ping process and not an actual scan. For the ACK ping, the ports are listed individually with each port separated with a comma.


# nmap –v –sS 10.0.0.4 –PA23,110
 
will attempt a TCP ACK ping to host 10.0.0.4 over ports 23 and 110. If neither of these ports replies to the ACK ping, the SYN scan will not run and the scan attempt will stop with this message:

Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
If a port is not specified, port 80 is used by default.


 
 

Advantages of the TCP ACK Ping
The TCP ACK ping uses little network traffic. In most cases, the common ACK query to a device is relatively undetectable. The TCP ACK ping also allows different port numbers to be probed, providing nmap with additional options when negotiating a scan through a firewall.

The TCP ACK ping identifies a filtered connection or a non-filtered connection.


When to use the TCP ACK Ping
Because of its low profile and flexible configuration options, the TCP ACK ping can be used in almost any circumstance. The ACK ping's port values can be modified, and multiple ports can be included on the command line.
 

 2.17 FTP Bounce Attack

# nmap -v -b anonymous:anon@192.168.0.7 192.168.0.5

The FTP bounce attack is infamous in the network security world. The modern threat associated with this attack methodology has been nullified by the retooling of most FTP services, rendering this particular attack more interesting for its technical process than for its potential maliciousness. Like idlescan, the FTP bounce attack uses a third workstation to act as a proxy between the nmap host and the destination station.

The FTP bounce attack wouldn't be possible if it weren't for passive mode FTP. With passive mode FTP, the command connections are completely separate from the data connections. This allows the FTP server to work well with firewalls because the FTP server is responsible for building the outbound data connection with the remote host.

 
 

The nmap output shows the results of the FTP bounce scan. Since the bounce scan is often performed through firewalls, nmap adds a reminder to include the "don't ping" option (-P0) on the command line.

# nmap -v -b anonymous:anon@192.168.0.7 192.168.0.5
Hint: if your bounce scan target hosts aren't reachable from here, remember to
use -P0 so we don't try and ping them prior to the scan

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-04-23 20:37 EDT
Resolved ftp bounce attack proxy to 192.168.0.7 (192.168.0.7).
Attempting connection to ftp://anonymous:anon@192.168.0.7:21
Connected:Login credentials accepted by ftp server!
Initiating TCP ftp bounce scan against 192.168.0.5 at 20:37
Discovered open port 6969/tcp on 192.168.0.5
Discovered open port 135/tcp on 192.168.0.5
Discovered open port 139/tcp on 192.168.0.5
Discovered open port 445/tcp on 192.168.0.5
Scanned 1663 ports in 9 seconds via the Bounce scan.
Host 192.168.0.5 appears to be up ... good.
Interesting ports on 192.168.0.5:
(The 1659 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
6969/tcp open  acmsoda
MAC Address: 00:11:43:43:A8:34 (Dell   (WW Pcba Test))

Nmap finished: 1 IP address (1 host up) scanned in 20.602 seconds
               Raw packets sent: 2 (68B) | Rcvd: 1 (46B)
 
 
 2.18 NMAP'S PING OPTIONS

 Understanding nmap's myriad scan types is only the beginning of harnessing its power. Nmap's additional options provide over fifty different choices of packet timings, ping options, output formats, and other customizable features! Although this considerable quantity of options seems overwhelming, it's this abundance of choices that provides nmap with incredible flexibility in nearly any networking environment.

Nmap always "pings" a remote station before initiating the scanning process. The default nmap ping consists of an ICMP echo request followed by a TCP ACK on port 80. If a station does not respond to either ping method, nmap will continue to the next target. If the scan does not have any additional targets, the scan will end.
Networking purists consider the term "ping" as a reference to an ICMP echo request and the corresponding ICMP echo reply. However, nmap's use of the word "ping" is more generic. In the nmap world, a ping is any request that would prompt a remote station's response. Throughout this text, a ping will refer to nmap's more relaxed definition.

The purpose of an nmap ping is to provoke any kind of response from a remote station. Once a response is received from a remote device, nmap identifies that device as active on the network and begins scanning it for detailed port information. Most of these ping options can be combined together to maximize the possibility of locating a device through firewalls or packet filters.

If an IP subnet is selected as a destination, nmap will also send ping requests to the subnet's broadcast addresses. For example, an nmap destination of 192.168.0.2/24 will prompt an nmap ping of all hosts between 192.168.0.1 and 192.168.0.254. Additionally, nmap will include 192.168.0.0 and 192.168.0.255 as destination addresses.

Many systems will respond to an "all-zeros" or "all-ones" broadcast, even though an individual IP address has not been specified. Some operating systems have been configured to ignore these types of broadcasts, but many stations will unknowingly respond to at least one of these broadcast types.

No comments:

Post a Comment