Re: dhcp script (version 2)

[Ron <ron () skullsecurity net>]

On 09/09/2009 06:33 PM, Fyodor wrote:
> On Tue, Sep 08, 2009 at 09:19:25PM -0500, Ron wrote:
> Hi Ron.  This script is great.  It works well for me, and I support
> checking it in.  Here are some notes and suggestions:
>
> o Against the DHCP server on my home network (ISC DHCP server 4.1.0),
>    I get no response to DHCPINFORM, but both DHCPDISCOVER and
>    DHCPREQUEST give me (basically the same) detailed responses.
Good to know.
> o I don't know much about DHCP, but if DHCPINFORM is significantly
>    less intrusive than DISCOVER or REQUEST, it might be worth trying
>    that first and falling back to DHCPDISCOVER otherwise (and maybe
>    even REQUEST if that fails, though we don't want the script to take
>    too long).  I like the ideas people have suggested about making this
>    less intrusive by reducing the lease time requested or any other
>    techniques you can think of.
While it's significantly less intrusive, we do have to wait for a 
timeout before we know it isn't working (currently 5 seconds, 3 seconds 
was missing responses). Therefore, if we send a second check after the 
first times out, we're talking about a 10-second delay on everything 
except the router, which I'd like to avoid.

I'll definitely add the lower lease time before I check it in, though.

> o This is very valuable information and making this script run by
>    default is worth consideration, IMHO.
Agreed. It's pretty rare somebody would be scanning udp/67, though -- 
should we consider running it when OS discovery indicates a router? Or 
when port 80 is open (possibly with a specific service)? Are either of 
those possible from inside a script? (I'm not sure if we have access to 
that type of data, though I assume we do)

> o I'd suggest making the script less verbose by printing only the most
>    important fields by default.  With verbose mode (which should kick
>    in automatically now if the script is specified directly), it could
>    continue printing all the fields.  From the example output below,
>    I've put a star by the fields which look most important to me:
>    67/udp open dhcps script-set
>    |  dhcp-discover:
>    |   DHCP Message Type: DHCPOFFER
>    |*   Server Identifier: 192.168.0.100
>    |   IP Address Lease Time (client): 3232235520
>    |*   Subnet Mask: 255.255.0.0
>    |*   Router: 192.168.0.6
>    |*   Domain Name Server: 192.168.0.100
>    |*   Broadcast Address: 192.168.255.255
>    |   Renewal Time Value: 1616117760
>    |_  Rebinding Time Value: 2828206080
>
>    If the Server Identifier is almost always just the target IP (I have
>    no idea), then we can probably omit that by default too.  There may
>    be other important fields which I just don't see in my responses.
>    Perhaps a list of fields to ignore by default would be better than a
>    list of interesting fields.
Sure!

At work, the 'Server Identifier' is the core of the network, and the 
routers at .1 just forward the request back and forth. So while I may be 
scanning 10.100.100.1 (on a /24 network), the 'Server Identifier' would 
point to 10.0.0.1. So for that reason, I'd keep it.

There are roughly 55 - 60 different fields that we're requesting. I'll 
go through the list and mark any of them that contain valuable 
information. I can probably clean up the 'time' values more, too, making 
them minutes/hours/days/etc

> o Perhaps the script could have an option for using raw packets to
>    send a broadcast request on the network?
That can be done, but it doesn't really fit with Nmap's paradigm of 
scanning one server at a time. If we do a broadcast every time the 
script is run, we're going to get 256 responses. If we only do it once, 
we're going to end up with a result for one random host and no others.

Conceptually, it's like an "aux" module in Metasploit. Has anybody 
considered having a new type of script that runs once/scan without a 
specific host/port? I think that'd be something useful, and I can think 
of other ideas for broadcast scripts, too (nbscan comes to mind).

> o It is a trivial thing, but this part of the docs still needs to be
>    updated for your recent changes:
>    --@args dhcptype The type of DHCP request to make. By default, DHCPDISCOVER is sent, but this argument
>    --can change it to DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPDECLINE, DHCPACK, DHCPNAK,
>    --or DHCPRELEASE. Not all types will evoke a response from all servers.
Good find!

> Cheers,
> Fyodor
Ron

--
Ron Bowes
http://www.skullsecurity.org/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org