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.
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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org