Re: probes vs payloads?

[Daniel Miller <bonsaiviking () gmail com>]

Mike,

As a general rule, the more frequently or easily a probe will be sent, the
more careful we must be that it doesn't have side effects. DHCP probes in
particular are tricky because many or most of them have the side effect of
requesting an address lease from the server. A script may follow up with a
subsequent message releasing that lease, but UDP payloads and service
probes don't have that ability. So to summarize:

* UDP payloads are only required to get *some* sort of response from the
target service (even a simple error response). They should be very
generic-looking since they get sent for all UDP scans that don't include
--data-length 0. We have some commented out because they set off default
SNORT rules.

* Service probes should be crafted to get a wide variety of responses from
different implementations of a protocol. They can be a little more unusual
(some contain the string "Nmap", for instance) since a version scan is not
stealthy by any means. They should not have side effects and should not
intentionally try to crash a target service.

* Scripts have the most freedom, because they can be categorized
"intrusive" or "dos", though the most useful scripts are more careful than
that. They can introduce state changes on the target, since they can send
follow-up messages to reverse the changes in many cases.

Dan

On Fri, Dec 18, 2015 at 8:48 AM, Mike . <dmciscobgp () hotmail com> wrote:

> hello all
>
>
> please stop my confusion on this subject. i see a list of payloads nmap
> uses for valid responses. after using the DHCP discover script, i am keen
> to ask, why is this not included as a payload for udp/dhcp? the packet is a
> proper packet which, one would assume, would garnish some type of response
> from a dhcp server out there. so can someone tell me when do we decide
> scripts can become payloads for service probes? (esp if they just dump
> simple info (upnp/ntp/rip/etc) and not interact or try anything malicious)
> thank you
>
>
> Mike
>
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/