[prads-devel] PRADS 0.3 DHCP

[Kacper Wysocki]

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
<edwardfjellskaal at gmail.com> 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
>> <edwardfjellskaal at gmail.com> 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.