Re: salt in version probes

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

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?

On Sun, Jan 16, 2011 at 11:17 AM, Toni Ruottu <toni.ruottu () iki fi> wrote:
> Here are two version probes I have created for NAT traversal services
> STUN and Teredo. I am not sure what would be good rarity values. The
> ports are standardized so I assume it is very common to have the
> services on those ports. I have not written any match lines yet, and I
> am not sure how to write really good ones.
>
> Could we include these in the release, recommend people to try
> scanning STUN and Teredo services, and get some match data posted to
> the database? How does the database work? Who has access to it? Does
> it have some automatic support for creating regular expressions?
>
> Please try running something like...
> nmap -sU -sV -p 3544,3478 teredo-debian.remlab.net
> teredo.ipv6.microsoft.com stun.xten.com stun1.noc.ams-ix.net
> stun.fwd.org stun.voipbuster.com stun01.sipphone.com
> stun.voxgratia.org -PN
> ...after including the probes to check that they work. Preferably,
> check with Wireshark that the sent probes seem sensible.
>
> The STUN specification mentions TCP based STUN servers, but I am not
> aware of any. Also I am not sure about the ssl ports thing. STUN
> specification discusses them. Does ssl work over udp?
>
> ##############################NEXT PROBE##############################
> # Teredo (rfc4380.txt), Router Solicitation Message
> #
> # Contains the Teredo auth-header with nonce (7cc3883d8d187299), IPv6
> header, and an ICMPv6 Router Solicitation packet
>
> Probe UDP teredo-rs
> q|\x00\x01\x00\x00\x7c\xc3\x88\x3d\x8d\x18\x72\x99\x00\x60\x00\x00\x00\x00\x08\x3a\xff\xfe\x80\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x85\x00\x7d\x37\x00\x00\x00\x00|
> rarity 2
> ports 3544
>
> ##############################NEXT PROBE##############################
> # Session Traversal Utilities for NAT (rfc5389), Binding Request
> #
> # Contains the transcation id d08cad2223e6ca425de64cd2
>
> Probe UDP stun-br
> q|\x00\x01\x00\x08\x21\x12\xa4\x42\xd0\x8c\xad\x22\x23\xe6\xca\x42\x5d\xe6\x4c\xd2\x00\x03\x00\x04\x00\x00\x00\x00|
> rarity 2
> ports 3478
> sslports 3478,5349
>
>
>
>
>
> On Sun, Jan 16, 2011 at 7:12 AM, David Fifield <david () bamsoftware com> wrote:
> > On Fri, Jan 14, 2011 at 09:07:31PM +0200, Toni Ruottu wrote:
> > > Some protocols require client to send a random number that is echoed
> > > back by the server. What kind of version probe should I write for such
> > > protocols? Is it okay to just create a random number and hard code
> > > that into the probe if the server seems to be okay with that?
> >
> > If a static value works, just use a static value. (And document it so
> > people don't look for meaning in it.) Anything more complicated needs a
> > script.
> >
> > David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/