xprobe2 is an active operating system fingerprinting tool with a different approach to operating system fingerprinting. xprobe2 relies on fuzzy signature matching, probabilistic guesses, multiple matches simultaneously, and a signature database.
As xprobe2 uses raw sockets to send probes, you must have root privileges in order for xprobe2 to be able to use them. Some of its logic has been absorbed into Nmap and it’s basically an active OS fingerprinting tool meaning it sends actual data to the machine it’s fingerprinting rather than a passive tool like p0f which just listens.
Xprobe2 Active OS Fingerprinting Tool Features
- Port scanning is now available through the usage of the -T (TCP) and -U (UDP) command line option
- Added the -B command line option (‘blind port guess’) used for searching an open TCP port among the following ports: 80,21, 25, 22, 139
- Include XSD schema with distribution and make our XML comply with that XSD
- loopback (lo) is supported
If you want to understand more in depth you can check out the paper: xprobe2 – A ‘Fuzzy’ Approach to Remote Active Operating System Fingerprinting
How to use Xprobe2 For OS Fingerprinting
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
xprobe2 [ -v ] [ -r ] [ -p proto:portnum:state ] [ -c configfile ] [ -o logfile ] [ -p port ] [ -t receive_timeout ] [ -m numberofmatches ] [ -D modnum ] [ -F ] [ -X ] [ -B ] [ -A ] [ -T port spec ] [ -U port spec ] host -v be verbose. -r display route to target (traceroute-like output). -c use configfile to read the configuration file, xprobe2.conf, from a non-default location. -D disable module number modnum. -m set number of results to display to numofmatches. -o use logfile to log everything (default output is stderr). -p specify port number (portnum), protocol (proto) and it's state for xprobe2 to use during rechability/fingerprinting tests of remote host. Possible values for proto are tcp or udp, portnum can only take values from 1 to 65535, state can be either closed (for tcp that means that remote host replies with RST packet, for udp that means that remote host replies with ICMP Port Unreachable packet) or open (for tcp that means that remote host replies with SYN ACK packet and for udp that means that remote host doesn't send any packet back). -t set receive timeout to receive_timeout in seconds (the default is set to 10 seconds). -F generate signature for specified target (use -o to save fingerprint into file) -X write XML output to logfile specified with -o -B causes xprobe2 to be a bit more noisy, as -B makes TCP handshake module to try and blindly guess an open TCP port on the target, by sending sequential probes to the following well-known ports: 80, 443, 23, 21, 25, 22, 139, 445 and 6000 hoping to get SYN ACK reply. If xprobe2 receives RST|ACK or SYN|ACK packets for a port in the list above, it will be saved in the target port database to be later used by other modules (i.e. RST module). -T, -U enable built-in portscanning module, which will attempt to scan TCP and/or UDP ports respectively, which were specified in port spec -A enable experimental support for detection of transparent proxies and firewalls/NIDSs spoofing RST packets in portscanning module. Option should be used in conjunction with -T. All responses from target gathered during portscanning process are divided in two classes (SYN|ACK and RST) and saved for analysis. During analysis module will search for different packets, based on some of the fields of TCP and IP headers, withing the same class and if such packets are found, message will be displayed showing different packets withing the same class. |
Xprobe2 Download
Download Xprobe2 here:
Or read more here.
matt says
Sounds like a very useful tool. Would be nice to see all of these features combined with nmap. …maybe a new project for myself. Thanks for the article!
Jinesh says
Words are not enough to describe this tool.
Chris says
I must politely disagree with Matt here. Personally I don’t use nmap at all, but I very much agree with the unix philosophy of one tool for one type of purpose. nmap is already doing too much, it should in my opinion do less.
Let xprobe2 stay the way it is, and try and slim nmap down a bit. What they should do with nmap is improve their UDP-scanning. Integrate a payload system, like the one found in unicornscan. Also they should stop doing automatic flow-control. It just messes up badly on larger networks. You need to be able to calculate efficiency and time.
My two cents.
Darknet says
Chris: You kind of went against what you were saying there, for UDP scanning Unicornscan is better…for larger networks either Unicornscan, Scanrand or Advanced LAN Scanner. Or a paired down version of nmap with the right options. Different tools for different jobs.
Chris says
I did? I personally find that nmap just cannot do the job on large networks, i.e /18-. It takes too much time, and there is no way to control how it interacts with its environment.
If we’re talking about portscanning, I include UDP/TCP for that. unicornscan does just that, it does portscanning, nothing more. For that reason I prefer unicornscan over nmap. It’s not however to say I think nmap is bad, for certain things it performs very well. It all comes down to the job, purpose and the tester. The tester should be comfortable with all the tools he decide to use, they are never a replacement for good understanding of x.y.z.
If I contradicted myself, that was not my intention. (And I still fail to see how I did!)
– Chris
Darknet says
Chris: Well it depends how you look at it, it’s very subjective. For me nmap started out as a decent TCP connect scanner and evolved from there, the main featureset is on the TCP side – it’s definitely not a competent UDP like Unicornscan is. Yes Unicorn does TCP as well and it does it better for large networks but I still find nmap better for TCP investigation and trickery (idle scans, decoys, banner grabbing etc). For me saying it should be better at UDP scanning is the opposite of one tool for one purpose.
Erik says
The only things about active OS fingerprinting is that it can be done from any network as long as the fingerprinted host is reachable. Apart from that I really prefer doing passive OS fingerprinting.
Is there by the way any point in doing OS fingerprinting based on UDP packets? My feeling is that they don’t hold enough information in order to fingerprint a host properly. A much better fingerprinting method is to look at DHCP packets since they reveal a lot about the host. The good thing with DHCP is also that it is broadcast, so it’s perfect for doing passively. In fact the new version of NetworkMiner [ http://networkminer.wiki.sourceforge.net/NetworkMiner ] supports passive OS fingerprinting using both TCP and DHCP fingerprinting.
I haven’t tried unicornscan though, it also seems to have some passive OS fingerprinting functionality.
Darknet says
Erik: I agree, due to the nature of UDP packets they have very little overhead and therefore very little useful info. DHCP packets and anything broadcast by Windows machines is useful. NetworkMiner is a neat tool we have covered it here before, still the best for passive OS fingerprinting is p0f – I haven’t yet covered that here but will shortly. The active OS fingerprinting in nmap is pretty decent too, I haven’t tried any of those features in Unicornscan yet.
Xnih says
Darknet: I’ll jump on the bandwagon with Erik, but that is just because his programs uses the DHCP fingerprinting from my own program Satori [ http://myweb.cableone.net/xnih ]. p0f does a decent job of passive os fingerprinting in the area of syn and syn/ack packets, but does nothing with DHCP, ICMP, CDP, IPX/SAP, etc, nor has it been updated in years.
Sifmole says
One of my problems with xprobe2 is that the only fingerprinting database I can find is from 11 July 2005. Do any of you know where you can find updated databases?