Re: Major SIPOptions probe reorganisation

[doug () hcsw org]

Brandon:
> If SIPOptions now has GetRequest as a fallback can't we just drop 5060
> from GetRequest and SIP will be applied first before Get?

The problem is that the SIP probe will be applied before the GetRequest.
If all HTTP servers replied the same to the SIP probe as the GetRequest,
the fallback would solve this issue. Unfortunately, most httpds will
probably send 400 bad request or method not supported. In other words,
the match lines in the GetRequest rely on the exact data sent by
the GetRequest probe.

Matt:
> 5060 is the IANA-registered SIP port.  Shouldn't we always look for SIP
> first on that port and then other protocols?

Ideally yes but the design of the vd engine makes this case slightly
problematic. There are 2 ways I can think of to do this:

* Change the rarity of SIP to 8 or 9 and leave it above GetRequest.
  This means that SIPOptions will not be applied to non-5060 ports
  with the default scan.
* Move the sip match lines in GetRequest to the SIPOptions probe and
  remove 5060 from the GetRequest ports. This is not ideal because
  we have fingerprints for SIP services that were submitted before
  SIPOptions was added so we don't know what their responses to this
  probe look like.

Fyodor:
> Is SIP ever found on ports 5060?  In other words, is it a service like
> SMTP which is almost always found on the same port for the protocol to
> work properly, or more like http which you find all over the place?

Exactly, that is the really important question. I would guess that is
the case but don't know enough about the protocol to be sure. I'll just
move it back down below unless anybody has other suggestions.

Thanks for your comments all.

Best,

Doug

Attachment: signature.asc
Description: Digital signature

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