lunes, 29 de junio de 2015


NMAP la navaja suiza
Nmap 6.01 ( )

Usage: nmap [Scan Type(s)] [Options] {target specification}


  Can pass hostnames, IP addresses, networks, etc.

  Ex:,; 10.0.0-255.1-254

  -iL <inputfilename>: Input from list of hosts/networks

  -iR <num hosts>: Choose random targets
  --exclude <host1[,host2][,host3],...>: Exclude hosts/networks
  --excludefile <exclude_file>: Exclude list from file
  -sL: List Scan - simply list targets to scan
  -sn: Ping Scan - disable port scan
  -Pn: Treat all hosts as online -- skip host discovery
  -PS/PA/PU/PY[portlist]: TCP SYN/ACK, UDP or SCTP discovery to given ports
  -PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes
  -PO[protocol list]: IP Protocol Ping
  -n/-R: Never do DNS resolution/Always resolve [default: sometimes]
  --dns-servers <serv1[,serv2],...>: Specify custom DNS servers
  --system-dns: Use OS's DNS resolver
  --traceroute: Trace hop path to each host
  -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
  -sU: UDP Scan
  -sN/sF/sX: TCP Null, FIN, and Xmas scans
  --scanflags <flags>: Customize TCP scan flags
  -sI <zombie host[:probeport]>: Idle scan
  -sO: IP protocol scan
  -b <FTP relay host>: FTP bounce scan
  -p <port ranges>: Only scan specified ports
    Ex: -p22; -p1-65535; -p U:53,111,137,T:21-25,80,139,8080,S:9
  -F: Fast mode - Scan fewer ports than the default scan
  -r: Scan ports consecutively - don't randomize
  --top-ports <number>: Scan <number> most common ports
  --port-ratio <ratio>: Scan ports more common than <ratio>
  -sV: Probe open ports to determine service/version info
  --version-intensity <level>: Set from 0 (light) to 9 (try all probes)
  --version-light: Limit to most likely probes (intensity 2)
  --version-all: Try every single probe (intensity 9)
  --version-trace: Show detailed version scan activity (for debugging)
  -sC: equivalent to --script=default
  --script=<Lua scripts>: <Lua scripts> is a comma separated list of
           directories, script-files or script-categories
  --script-args=<n1=v1,[n2=v2,...]>: provide arguments to scripts
  --script-args-file=filename: provide NSE script args in a file
  --script-trace: Show all data sent and received
  --script-updatedb: Update the script database.
  --script-help=<Lua scripts>: Show help about scripts.
           <Lua scripts> is a comma separted list of script-files or
  -O: Enable OS detection
  --osscan-limit: Limit OS detection to promising targets
  --osscan-guess: Guess OS more aggressively
  Options which take <time> are in seconds, or append 'ms' (milliseconds),
  's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
  -T<0-5>: Set timing template (higher is faster)
  --min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes
  --min-parallelism/max-parallelism <numprobes>: Probe parallelization
  --min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies
      probe round trip time.
  --max-retries <tries>: Caps number of port scan probe retransmissions.
  --host-timeout <time>: Give up on target after this long
  --scan-delay/--max-scan-delay <time>: Adjust delay between probes
  --min-rate <number>: Send packets no slower than <number> per second
  --max-rate <number>: Send packets no faster than <number> per second
  -f; --mtu <val>: fragment packets (optionally w/given MTU)
  -D <decoy1,decoy2[,ME],...>: Cloak a scan with decoys
  -S <IP_Address>: Spoof source address
  -e <iface>: Use specified interface
  -g/--source-port <portnum>: Use given port number
  --data-length <num>: Append random data to sent packets
  --ip-options <options>: Send packets with specified ip options
  --ttl <val>: Set IP time-to-live field
  --spoof-mac <mac address/prefix/vendor name>: Spoof your MAC address
  --badsum: Send packets with a bogus TCP/UDP/SCTP checksum
  -oN/-oX/-oS/-oG <file>: Output scan in normal, XML, s|<rIpt kIddi3,
     and Grepable format, respectively, to the given filename.
  -oA <basename>: Output in the three major formats at once
  -v: Increase verbosity level (use -vv or more for greater effect)
  -d: Increase debugging level (use -dd or more for greater effect)
  --reason: Display the reason a port is in a particular state
  --open: Only show open (or possibly open) ports
  --packet-trace: Show all packets sent and received
  --iflist: Print host interfaces and routes (for debugging)
  --log-errors: Log errors/warnings to the normal-format output file
  --append-output: Append to rather than clobber specified output files
  --resume <filename>: Resume an aborted scan
  --stylesheet <path/URL>: XSL stylesheet to transform XML output to HTML
  --webxml: Reference stylesheet from Nmap.Org for more portable XML
  --no-stylesheet: Prevent associating of XSL stylesheet w/XML output
  -6: Enable IPv6 scanning
  -A: Enable OS detection, version detection, script scanning, and traceroute
  --datadir <dirname>: Specify custom Nmap data file location
  --send-eth/--send-ip: Send using raw ethernet frames or IP packets
  --privileged: Assume that the user is fully privileged
  --unprivileged: Assume the user lacks raw socket privileges
  -V: Print version number
  -h: Print this help summary page.
  nmap -v -A
  nmap -v -sn
  nmap -v -iR 10000 -Pn -p 80


root@bt:~# nmap -v -A

Starting Nmap 6.01 ( ) at 2015-06-29 12:20 CDT

NSE: Loaded 93 scripts for scanning.

NSE: Script Pre-scanning.

Initiating Parallel DNS resolution of 1 host. at 12:20

Completed Parallel DNS resolution of 1 host. at 12:20, 0.11s elapsed

Initiating SYN Stealth Scan at 12:20
Scanning [1000 ports]
Completed SYN Stealth Scan at 12:20, 0.21s elapsed (1000 total ports)
Initiating Service scan at 12:20
Initiating OS detection (try #1) against
Retrying OS detection (try #2) against
NSE: Script scanning
Initiating NSE at 12:20
Completed NSE at 12:20, 0.00s elapsed
Nmap scan report for
Host is up (0.000051s latency).
All 1000 scanned ports on are closed
Too many fingerprints match this host to give specific OS details
Network Distance: 0 hops

NSE: Script Post-scanning.

Read data files from: /usr/local/bin/../share/nmap

OS and Service detection performed. Please report any incorrect

results at .

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


TCP/IP stack fingerprinting

Passive OS Fingerprinting method and diagram.
TCP/IP stack fingerprinting is the passive collection of configuration attributes from a remote device during standard layer 4 network communications. The combination of parameters may then be used to infer the remote machine's operating system (aka, OS fingerprinting), or incorporated into a device fingerprint.

TCP/IP Fingerprint Specifics[edit]

Certain parameters within the TCP protocol definition are left up to the implementation. Different operating systems, and different versions of the same operating system, set different defaults for these values. By collecting and examining these values, one may differentiate among various operating systems, and implementations of TCP/IP.[1] The TCP/IP fields that may vary include the following:
  • Initial packet size (16 bits)
  • Initial TTL (8 bits)
  • Window size (16 bits)
  • Max segment size (16 bits)
  • Window scaling value (8 bits)
  • "don't fragment" flag (1 bit)
  • "sackOK" flag (1 bit)
  • "nop" flag (1 bit)
These values may be combined to form a 67-bit signature, or fingerprint, for the target machine.[2] Just inspecting the Initial TTL and window size fields is often enough in order to successfully identify an operating system, which eases the task of performing manual OS fingerprinting.[3]

p0f v3 (version 3.08b)

Yeah, it's back!

1. What's this?

P0f is a tool that utilizes an array of sophisticated, purely passive traffic fingerprinting mechanisms to identify the players behind any incidental TCP/IP communications (often as little as a single normal SYN) without interfering in any way. Version 3 is a complete rewrite of the original codebase, incorporating a significant number of improvements to network-level fingerprinting, and introducing the ability to reason about application-level payloads (e.g., HTTP).
Some of p0f's capabilities include:
  • Highly scalable and extremely fast identification of the operating system and software on both endpoints of a vanilla TCP connection - especially in settings where NMap probes are blocked, too slow, unreliable, or would simply set off alarms.
  • Measurement of system uptime and network hookup, distance (including topology behind NAT or packet filters), user language preferences, and so on.
  • Automated detection of connection sharing / NAT, load balancing, and application-level proxying setups.
  • Detection of clients and servers that forge declarative statements such as X-Mailer or User-Agent.
The tool can be operated in the foreground or as a daemon, and offers a simple real-time API for third-party components that wish to obtain additional information about the actors they are talking to.
Common uses for p0f include reconnaissance during penetration tests; routine network monitoring; detection of unauthorized network interconnects in corporate environments; providing signals for abuse-prevention tools; and miscellanous forensics.
You can read more about its design and operation in this document. In one form or another, earlier versions of p0f are used in a wide variety of projects, including pfsenseEttercapPRADSamavisdmilterpostgreyfwknopSatori, the OpenBSD firewall, and an assortment of commercial tools.
Fun fact: The idea for p0f dates back to June 10, 2000. Today, almost all applications that do passive OS fingerprinting either simply reuse p0f for TCP-level checks (Ettercap, Disco, PRADS, Satori), or use inferior approaches that, for example, pay no attention to the intricate relationship between host's window size and MTU (SinFP).

2. What's the output?

A snippet of typical p0f output may look like this:

.-[ -&gt; (syn) ]- | | client = | os = Windows XP | dist = 8 | params = none | raw_sig = 4:120+8:0:1452:65535,0:mss,nop,nop,sok:df,id+:0 | `---- .-[ -&gt; (mtu) ]- | | client = | link = DSL | raw_mtu = 1492 | `---- .-[ -&gt; (uptime) ]- | | client = | uptime = 0 days 11 hrs 16 min (modulo 198 days) | raw_freq = 250.00 Hz | | `---- .-[ -&gt; (http request) ]- | | client = | app = Firefox 5.x or newer | lang = English | params = none | raw_sig = 1:Host,User-Agent,Accept=[text/html,application/xhtml+xml... | `----

3. Can I have it?

Yup: click here to download the current release (3.08b), or here to browse older releases, including 2.0.x and 1.8.x.
Please keep in mind that p0f v3 is a complete rewrite of the original tool, including a brand new database of signatures. We are starting from scratch, so especially for the first few releases, please be sure to submit new signatures and report bugs with special zeal! I am particularly interested in:
  • TCP SYN ("who is connecting to me?") signatures for a variety of systems - especially from some of the older, more exotic, or more specialized platforms, such as Windows 9x, NetBSD, IRIX, Playstation, Cisco IOS, etc. To do this, you simply need to attempt establishing a connection to a box running p0f. The connection does not need to succeed.
  • TCP SYN+ACK signatures ("who am I connecting to?"). The current database is minimal, so all contributions are welcome. To collect these signatures, you need to compile the supplied p0f-sendsyn tool, and then use it to initiate a connection to an open port on a remote host; see README for more.
  • HTTP request signatures - especially for older or more exotic browsers (e.g. MSIE5, mobile devices, gaming consoles), crawlers, command-line tools, and libraries. To collect a signature, you can run p0f on the client system itself, or on the web server it talks to.
  • HTTP response signatures. P0f ships with a minimal database here (only Apache 2.x has any real coverage). Signatures are best collected for three separate cases: several minutes of casual browsing with a modern browser; a request with curl; and another one with wget.


Developer(s)Michal Zalewski
Stable release3.08b / 2014-11-08
Written inC
Operating systemLinux, Macintosh, Windows
TypeOS fingerprinting
p0f is a versatile passive OS fingerprinting tool. p0f can identify the system on machines that connect to your box, machines you connect to, and even machines that merely go through or near your box even if the device is behind a packet firewall.
p0f will also detect what the remote system is hooked up to (be it EthernetDSLOC3), how far it is located, what's its uptime. The latest beta can also detect masquerade or illegal network hook-ups (useful for ISPs andcorporate networks). p0f can detect certain types of packet filters and NAT setups, and sometimes can determine the name of the other guy's ISP. It's still passive. It does not generate any network traffic. No name lookups, no traffic to the victim, no ARIN queries, no trace route.


p0f can identify the system on:
  • machines that connect to your box (SYN mode)
  • machines you connect to (SYN+ACK mode)
  • machines you cannot connect to (RST+ mode)
  • machines that talk through or near your box
But checking the system is not all p0f can do, p0f will also check the following:
  • masquerading and firewall presence (useful for policy enforcement)
  • the distance to the remote system and its uptime
  • other guys' network hookup (DSL, OC3, avian carriers) and his ISP

Advantage over other fingerprinting tools[edit]

The passive nature of p0f is what sets it apart from the other fingerprinting tools. p0f passively listens to the network traffic without creating any extra packets. It determines the operating system of the remote host by analyzing certain fields in the captured packets. Due to this passive analysis, the remote system will not be able to detect the packet capture.

How it works[edit]

As mentioned above, p0f captures packets, and analyses them on the basis of certain fields. Time to live (TTL), Win, Don't Fragment and TOS are some of the fields used for OS fingerprinting by p0f. Values of these fields are compared with the signatures in a fingerprint file, which is stored in /etc/p0f/p0f.fp in most implementations of p0f. The user is allowed to use a different fingerprinting file by running p0f with the -f command line option.


p0f does not have a graphical user interface. It can be run from the command line prompt. A comprehensive list of p0f options for version 3 is given below.
Usage: p0f [ -f file ] [ -i iface ] [ -L ] [ -r file ] [ -o file ]
       [ -s file ] [ -d ] [ -u user ] [ -p ] [ -S num ] [ -m c,h ] [ -t c,h ]
  -f file  - reads fingerprint database (p0f.fp) from file
  -i iface - listen on specific network interface
  -L       - list all available network interfaces
  -r file  - read pcap packet file instead of listening to an interface
  -o file  - append output to file in grep-friendly format
  -s file  - output to a socket
  -d       - go into daemon mode
  -u user  - switch to specified user and drop privileges, use with -d
  -p       - put the selected interface into promiscuous mode
  -S num   - set maximum number of API client connections, default is 20
  -m c,h   - set maximum number of clients and hosts to be tracked
  -t c,h   - set timeouts for any connection(c) and for purging idle hosts (h)


amap - a powerful application mapper


License And User Bewares


amap [Mode] [Options] <target> <port/portrange> [<port> ...]


Amap is a scanning tool that allows you to identify the applications that are running on a specific port or ports. This is achieved by connecting to the port(s) and sending trigger packets. These trigger packets will typically be an application protocol handshake. Many network daemons will only respond to the correct handshake (i.e. SSL). Amap then looks up the response in a list and prints out any match it finds. Amap supports tcp and udp protocols, regular and SSL-enabled ASCII and binary protocols and a variety of options are at your disposal to control the behaviour of the tool. It can take an nmap machine readable output file as its input file and can log to a file and screen.
Why use our tool? Well, when portscanning a host, you will be presented with a list of open ports. In many cases, the port number tells you what application is running. Port 25 is usually SMTP, port 80 mostly HTTP. However, this is not always the case, and especially when dealing with proprietary protocols running on non-standard ports you will not be able to determine what application is running. With amap, you will be able to identify that SSL server running on port 3445 and some oracle listener on port 23. Also, it will actually do an SSL connect if you want and then try to identify the SSL-enabled protocol!
Please also see amapcrap -h for an additional tool for ports who do not give any output.


amap can be run in three different modes:
-AMap applications: send triggers and analyse responses (default). All options can be used in this mode.
-BJust grab banners, do not send triggers. Only a few commandline options are used from the set when run this mode. They are maked below as "(Banner)"
-PNo banner, application, stuff - be a (full connect) port scanner! Only a few commandline options are used from the set when run this mode. They are maked below as "(Portscan)"
-WThis is the Web Online Update mode. When specifying this option, all other options except -D are ignored, and the application fingerprints and triggers are updated from the web site.


Options can also be seen by typing ’amap -h’. Here follows an explanation of all options.
HOSTS AND PORTS (all modes)
-i <file>
This makes amap read its hosts and ports from the specified file. The file must be
Generated by nmap, using the -oM <file> option of nmap. It doesn’t matter if you have multiple hosts and mixed tcp and udp ports in the file: amap reads them all.
lt;target> and <port/portlist>
Target can be an IP address or fully qualified host name. A port can be any number between 1 and 65535, ranges (e.g. 1-65535) are also supported. You can specify as many ports on the command line as you want. Ports are by default TCP (see -u option below).
None of these are required but some can be quite useful.
Note that all options can be used in amap’s default mode (-A), the banner grab (-B) and portscan modes (-\P) support only those options which are marked as such.
Ports specified on commandline are UDP (default is TCP). (Modes: Amap, Banner, Portscan)
-6Use IPv6, not IPv4
-1Only send triggers to a port until 1st identification. Speeeeed!
-vVerbose. Usually not used, but gives detailed info on the screen as to what connections are made to what ip’s/ports. Don’t use twice. You will be bored to death with even more stupid uninteresting information. (Modes: Amap, Banner, Portscan)
-qQuiet. Has got nothing to do with the "-v" option :-) If the -q option is applied, all closed and timed out ports are NOT marked as unidentified, and are not reported at all.
-dMake a hex dump of all received responses. The default is to only print unrecognised responses.
-UDo not dump unrecognized responses. (see option above)
-bPrint ACSII banners (if one is received).
-o <file>
Log the output of amap to <file>. (Modes: Amap, Banner, Portscan)
-m <file>
Make the log file output (-o option) machine readable (colon seperated). (Modes: Amap, Banner, Portscan)
-D <file>
Triggers and responses are read by default from appdefs.trig and appdefs.resp. By specifying for instance ’-D trojans’ it will read triggers and responses from trojans.trig and trojans.resp. It can be very usefull if you only want to scan for certain applications. Please take a look at the appdefs files to see what the format of these files is (it’s pretty simple, you shouldn’t have any trouble adding your own triggers and responses, which you are encouraged to do, btw).
These options influence the behaviour of amap when scanning.
-p <proto>
This specifies a single protocol trigger to send. The name of the protocol must match one of the first fields of the lines in the trigger file. For instance, ’-p SSL’ will scan only for SSL enabled port. However, if by chance other protocols are also indentified, they will be printed.
-SDo NOT NOT look behind an SSL port. Otherwise amap will reconnect later to identify the service running behind the ssl wrapper.
-RDo NOT identify RPC service. Otherwise amap will connect many times to identify the exact rpc service type and version. This can be time consuming.
-c nOpen ’n’ parallel tasks (connections). The default is 32, the maximum 256. (Modes: Amap, Banner, Portscan)
-C nIf a TCP connect timed out (did not finnish in "-T n" time), how often should be retried the connect? This is by default 3. (Modes: Amap, Banner, Portscan)
-T nCauses amap to wait upto ’n’ seconds for a successful TCP connect. Default is 5 seconds, but this can be too few sometimes when scanning over a slow link, and too long on a LAN. (Modes: Amap, Banner, Portscan)
-t nCauses amap to wait upto ’n’ seconds for a response. Default is 5 seconds, but this can be too few sometimes when scanning over a slow link, and too long on a LAN. (Modes: Amap, Banner)
-HSkip potentially harmful triggers. Some daemons and applications will crash when receiving long or unexpected binary input. -H skips triggers marked as potentially harmful. See appdefs.trig for information on how to mark a trigger as harmful.


amap is (C) 2003 by vanHauser and DJ.RevMoon (of THC - program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2. This guarantees your right to use, modify, and redistribute amap under certain conditions.
Source is provided to this software because we believe users have a right to know exactly what a program is going to do before they run it. This also allows you to audit the software for security holes.
Source code also allows you to port amap to new platforms, fix bugs, and add new features. You are highly encouraged to send your application triggers and responses to us. Please send triggers and responses (either as a tcpdump file or in our own format) to
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details (it is in the COPYING file of theamap distribution).
It should also be noted that amap has been known to crash certain poorly written applications, TCP/IP stacks, and even operating systems. Amap should never be run against mission critical systems unless you are prepared to suffer downtime. We acknowledge here that Amap may crash your systems or networks and we disclaim all liability for any damage or problems Amap could cause.


There are bound to be numerous bugs in amap. Please tell us if you find any. Please email to
Top of page | 


No hay comentarios:

Publicar un comentario

Blogger Widgets