Monday, April 20, 2009

Using the dhcp.xml file

Instead of telling you how to use the dhcp.xml file, I'll explain how Satori is using it, from there you can start using it like I originally intended, or branch out in ways I didn't anticipate and hopefully utilize it to its full potential! Most of this information was originally presented in a document by Jean-Fabien, who is one of 2 others that helped solidify the current xml format. I've taken it and extended it out a bit in places and removed other parts.

fingerprint name="Sweex LW050 WAP" os_name="VxWorks 5.5" os_class="VxWorks" os_vendor="Wind River" os_url="" device_type="Wireless Router" device_vendor="Sweex" device_url="" comments="" author="" last_updated="2009-04-13"
test weight="5" matchtype="exact" dhcptype="Offer" dhcpoptions="53,54,1,51,52,3,6,31"/
test weight="1" matchtype="exact" dhcptype="Offer" ipttl="32"

Header Info:
'name' - [required] this is the description of the device. In some cases it may be the name of the OS or device, othertimes it will be more generic like Linux 2.6.x, it is the description of the device that Satori shows upon a match.

'os_name' - [optional] The name of the actual OS that runs on this device. In some cases this may be redundant with the 'fingerprint name', at least when it something like Windows XP that we have identified, but in cases of SOHO routers, etc these are separate names.

'os_class' - [optional] The overall class that this device falls under when running this os. In the case of Windows XP, we'd have 'Windows'

'os_vendor' - [optional] Just that, the vendor who supports/supplies the OS

'os_url' - [optional] in a generic sense, the companies url, in a specific sense, say again of Windows XP, a direct link to that OS. Depends on what is being fingerprinted.

'device_type' - [optional] If it is a "hardware box", then what is it: Wireless Router, Switch, Wireless Access Point, etc

'device_vendor' - [optional] Who produces the device

'device_url' - [optional] URL directly to the device at the vendors page if applicable, otherwise a link to the vendors main page

'comments' - [optional] Any extended comments that may need to be know about the device or how the fingerprint was obtained

'author' - [preferred] Who the first person was to provide this fingerprint, not the last one to update it

'last_updated' - [required] Lets us know when the last time this fingerprint was updated

Clarification (from original doc by Jeff, with minor corrections):
Note the difference between “os” and “device” and related attributes. The “os” describes the operating system (the software) while the “device” describes the device itself (the hardware). Some fingerprints are “os” centric, some are “device” centric and some are both. When no “os” data is available then all “os_” attributes will be empty. Likewise, when no “device” data is available then all “device_” attributes will be empty.

Now we get into the actual tests for this device. It is surrounded by ...

'test weight' - [required] Values run from 1-10, 1 being the lowest, normal value being 5. Values less than 5 are reserved for "generic" things. TTL, MSFT, etc. Values that help, but only help to put in in a group of say "Windows" devices

'matchtype' - [required] Values are either "exact" or "partial". With DHCP fingerprinting, this is typically left at "exact", which would mean just that an exact match. "partial" is typically only used in vendor code, such as "Linux 2.6" when we have something like "Linux build 8756"

'dhcptype' - [required] Offer, Request, Discover, Inform, Release, etc. What type of DHCP packet was it.

'dhcpoptions' - [optional] all dhcp options together. One big list. Typical weight of 5. For ore information see:

'dhcpoption55' - [optional] just option 55 data. Typical weight of 5. For more information see:

'dhcpvendorcode' - [optional] vendor code. This 'weight' varies that most since this value is sometimes very unique, and others very generic.

'ipttl' - [optional] - The TTL of the IP packet. Weight on this should always be 1 due to the genericness of this value.

OS Classes (this is ever expanding, but here is the list as of today):
iPhone OS
Mac OS
Network Boot Loader
OS/2 Warp

There are breakdowns of each OS, for Windows, there are fingerprints for 95, 95B, 98, 98SE, ME, CE, NT4, 2000, XP, 2003, 2008, Vista, 7, etc.

Device Types (again, this is an ever expanding list):
Game Console
Miscellaneous (catch all that devices may eventually be removed from)
Mobile Phone
Mobile Phone
Network Diagnostics
Thin Client
Video Conferencing
Video Phone
VoIP Gateway
VoIP Phone
Wireless Access Point
Wireless Controller
Wireless Router

How Scoring works:
When we pick up a DHCP packet it may have up to 4 different values.
1. ipttl [1]
2. dhcpoptions [10]
3. dhcpoption55 [10]
4. dhcpvendorcode [10]

For a total possible score of 31 per DHCP packet. Typically this never happens since there may not be all 4 values to pull in the packet and more realistically because most of the tests above never have a value of 10, but a value of 5 instead. Also, Satori (but not some of the other products using the dhcp.xml file) does not use ipttl. So for Satori, the max possible fingerprint score would be 30.

We may get a chance to score a DHCP Request and Discover packet, in which case a max score of 60 is possible, then again we may also get a Inform packet, etc. Ultimately, the way Satori is setup, there is no MAX score that a device can have, it could continue to send out different request/discover/inform packets and continue to get its score for each fingerprint incremented.

Anyway, I add up the scores for each test, if it is actually a Windows Vista box, odds are it will end up with a score of 12. It will actually show 12 for Vista and 12 for Windows 2008, since they use the same TCP/IP stack. Nothing we can do about that!

Hopefully that gives a general overview of how I'm using this file in Satori.

No comments:

Post a Comment