From kacperw at gmail.com Thu Feb 16 22:39:23 2012 From: kacperw at gmail.com (Kacper Wysocki) Date: Thu, 16 Feb 2012 22:39:23 +0100 Subject: [prads-devel] PRADS 0.3 DHCP In-Reply-To: <4F396D73.1070403@gmail.com> References: <4ED9B40C.8090700@gmail.com> <4ED9B928.9070907@gmail.com> <4ED9BC51.6070106@gmail.com> <4EF08EE4.8020800@gmail.com> <4EF0C36C.40505@gmail.com> <4EF24628.8020603@gmail.com> <4EF386CC.9040101@gmail.com> <4EF73C47.2040206@gmail.com> <4F394811.3070404@gmail.com> <4F396D73.1070403@gmail.com> Message-ID: I think what we found out during our chat today was that it would be best if we made a dhcp[xid] = mac,os,reqip hash to store the fingerprinted requests in and linked this to the asset database as soon as we can match a dhcp reply to the same xid. You think that's doable? 0K PS hello prads-dev, let's try to be a little inclusive ;-) On Mon, Feb 13, 2012 at 9:07 PM, Edward Fjellsk?l wrote: > > That pretty much confirms my view and "solution" to the problem. > So it helps me confirm that Im not that far off :) > > Then I guess we will have to make a bucket[linked-list-mac] that > holds MACs+OS that are discovered via DHCP, and MAC+IP discovered > via regular prads asset detection... > > Example case for the mac-linked-list: > > * we see DHCP traffic > ** We get a MAC+OS+timestamp > ** We set the "printed" bit to 0 for that fingerprint > > * we see IP traffic > ** We get MAC+IP+timestamp > ** we print the asset in PRADS style: > ? 192.168.22.132,0,0,0,DHCP,[7:64:53,54,12,255:.:.:Linux:Ubuntu > 10.04],0,1291108260 > ** We set the "printed" bit to 1 so we dont print this info again > ? but if we see it again, and the timestamp is updated, we set > ? the bit to 0 again. > ** Should we add the MAC into the output ? > > * if we see new DHCP traffic > ?and we get a new fingerprint, add that to the mac-asset and > ?set the "printed" bit to 0 for that fingerprint. > > and so on.... > > Kacper - any thoughts ? > > E > > On 02/13/2012 07:15 PM, Eric Kollmann wrote: >> The way I handle it is I keep track of all MAC addresses and then >> update the IP address if it is 0.0.0.0 (more here in a sec), since >> prads is kicking info out immediately it is a little harder to do >> this. >> >> The other option, though not as good as the above one is to look at >> what IP address the client is looking for when it sends out the >> discover/request (sorry off the top of my head not sure which or if >> both types of packets). ?The problem with this approach is that they >> may have been on their home network and be requesting their previous >> 192.168.0.x or 10.0.0.x address instead of an address on the current >> network they are on. >> >> Satori does end up putting it out there as 0.0.0.0 with some MAC for a >> period of time and then when it sees the real IP address later it will >> have that IP and that MAC. ?I have a "job" that runs every 5 mins that >> scans through the list and if the IP is 0.0.0.0 it will combine with >> the real address on a match. ?Not perfect, but better than matching on >> MAC only as you'd have your routers MAC's IP keep changing as new >> external sites were browsed. ?And also better than matching on IP only >> like NetworkMiner does (or did haven't verified in awhile) and >> therefor all of the 0.0.0.0 addresses end up as one device! >> >> I have not implemented this "clean up" feature with IPv6 yet. ?That is >> on my list for one of these days, but not high priority! >> >> For less code, but also less reliability, you could just fingerprint >> when the client already has an IP address. ?Problem with this approach >> is one you miss a lot, but two these are normally unicast (not always, >> but normally as I recall) and so when it reaches 50% of its lease time >> it does send out a request again, but instead of broadcast to everyone >> it unicasts it back to the DHCP server (I'd have to go back and test >> to make sure on this uni vs broad, but that is my recollection). >> >> Hope some of that helps. >> >> On Mon, Feb 13, 2012 at 10:27 AM, Edward Fjellsk?l >> wrote: >>> On 02/13/2012 04:08 AM, Eric Kollmann wrote: >>>> So we're a few months later, make any headway on DHCP stuff? >>>> >>>> Getting ready to play with p0fv3 here and thought I'd look at prads again too. >>> >>> Hi Eric, >>> >>> I kinda stopped coding on DHCP in PRADS after my coding during Xmas. >>> I ran into something that my head has not solved yet, but its processing >>> in the background :) >>> >>> Right now I have the mac-address + the OS from the DHCP fingerprinting. >>> I could extract the IP from the answer that the server gives, if it >>> gives, but then I have to make some state into the tracking, which is >>> Ok, but some work. In DHCP renewal, its easier to map correctly into >>> PRADS core. >>> >>> Another way to solve it, would be to keep a mapping-table between >>> MACs and OSs associated with it (and timestamps etc) discovered by the >>> DHCP method. Then also have a table that linkes MACs and IPs from >>> our regular asset detection. >>> >>> Any suggestions and experience would be helpful here Eric :) >>> >>> BTW; http://www.gamelinux.org/?p=485 >>> (PRADS, and how it compares to pads and p0fv2 and p0fv3) >>> >>> If you find anything new to p0f3 thats not in the post, I would be >>> happy to know. I haven't played with it since the blogpost. >>> >>> E > -- http://comotion.delta9.pl http://u.delta9.pl http://kacper.doesntexist.org Too much order is its own chaos. Employ no technique to gain supreme enlightment.