mailing list archives
Re: salt in version probes
From: Toni Ruottu <toni.ruottu () iki fi>
Date: Mon, 7 Feb 2011 03:20:32 +0200
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?
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/