Re: Updated DHCP scripts

[David Fifield <david () bamsoftware com>]

On Sat, Aug 28, 2010 at 07:48:19PM -0500, Ron wrote:
> All right, these changes are committed. I'd like to put more work into the DHCP scripts, though. What do you think of 
> this idea?
>
> Right now, by default, a DHCP_DISCOVER is sent directly to the host (when broadcasting is enabled, we'll do that as a 
> prerule). The response is parsed and displayed. There are script-args for randomizing the MAC address, sending 
> multiple requests, etc (all of which are designed to exhaust the DHCP addresses). 
>
> I'm thinking of splitting up the script a bit (the names are just the first things I thought of):
> - - dhcp-discover -- Send a DHCP_DISCOVER broadcast once we get broadcast sorted out (will find all DHCP servers on 
> the network segment)
> - - dhcp-info -- Send a DHCP_INFORM to the particular target. This doesn't always work, but is safe enough to be in 
> the default/safe group. 
> - - dhcp-exhaust -- Send a series of DHCP DISCOVER messages with random MAC addresses, designed to exhaust the DHCP 
> server. This would be in 'dos'. 
>
> None of those would be a significant amount of code, thanks to the DHCP library I wrote, but that's the cleanest way 
> of splitting it that I can think of. 

This sounds good to me. It would mean three scripts where we now have
one. I guess the question is whether someone would want to run more than
one of these scripts at a time, and whether the different modes of
operation are sufficiently different that they should have different
categories. dhcp-exhaust is fairly clearly separable. dhcp-discover and
dhcp-info are less clear. dhcp-discover can already send many more types
of packets, like DHCPOFFER, DHCPREQUEST, etc. DHCPDISCOVER and
DHCPINFORM are just two of these.

You can go ahead and separate out dhcp-exhaust. As for dhcp-discover and
dhcp-inform, does it make sense to just do both by default in one
script, and all the script argument controlling which packet types to
send to take an array of types?

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