Re: salt in version probes

[Toni Ruottu <toni.ruottu () iki fi>]

I am not sure what optimal probes would look like. The ones I posted
earlier are pretty much by the book.

I've been trying to write an info script for stun, but I really have
not been able to decide what would be an optimal script either. The
problem is that lots of different field types have been defined in
different rfcs, but I am really not sure how far the script should go.
I could go with a simple script that sends only one probe, or I could
go with a far more complex script that does the full stun resolving.

I started with the simple case and got that working. I am able to do
the most straight forward exchange and get a response messages with
some interesting fields describing the network environment between the
hosts. However, if I had the time to read all rfcs about turn, and ice
and others that extend stun I could probably find out a lot more. Then
again someone could use a regular stun implementation rather than nmap
for doing more complex things.

Thus I decided to start with version probes, but I am not sure I have
good answers for all or any of these questions. I think I am having a
slightly longer coffee break on this, and maybe returning to it at
some point if I can find the time.

On Mon, Jan 31, 2011 at 1:15 PM, David Fifield <david () bamsoftware com> wrote:
> On Mon, Jan 17, 2011 at 04:12:08PM +0200, Toni Ruottu wrote:
> > If it seems inconvenient to do this kind of changes at this point in
> > the release process, I am perfectly okay with leaving the probes out.
> > I am not even sure, if it is a good idea anyway. It is probably
> > possible to write some kind of matchlines based on RFCs. Do we prefer
> > this over gathering data through experimentation?
>
> Generally the probes are based on RFCs, but the match lines are based on
> experiment. The important thing is to start with a probe that will get
> lots of different answers from different servers so that the match lines
> aren't all the same. Sometimes this requires creativity and not just
> sending what the most typical first packet for the protocol is.
> Sometimes error messages can be better than success messages. What other
> possible probes are there for Teredo and STUN? Which do you think will
> be the most effective? Is there a chance of combining the probe more
> generically with another protocol?
>
> David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/