Re: Timing race cars with a sundial (-sV match performance)

[Fyodor <fyodor () insecure org>]

On Fri, May 08, 2009 at 10:07:03PM +0000, Brandon Enright wrote:
> A few weeks ago I embarked on a (mostly) futile attempt to measure the
> performance of applying a PCRE match expression in our

Thanks for sending the results, even if they weren't all you hoped.

> As for optimizing these matches, for the LPD match we really need to
> add an anchor.  I did some checking and all UCSD hosts that match the
> service can safely add '^' and still match.

Sounds like a good idea.

> The '^.*' usage in the ser2net match is counter-productive.  I don't
> have any matching services so I don't know what can be done to
> improve on '^.*' besides just removing it.

Removing the "^.*" sounds like the way to go, as it seems completely
pointless to me.

> The Xylan PizzaSwitch telnetd match is pretty zealous in its use
> of .* early in the match.  Telnet services often match the start and
> then print a large amount of data (banners, abuse warnings, etc).  '.*'
> is consuming all of that data on all telnet services and then
> backtracking a byte at a time.  We should make the '.*' lazy by changing
> it to ".*?". Even better would be to add a few more matching bytes to
> match the telnet control bytes before using '.*' but we may not have
> enough data to do this.

I'll forward you some Xylan PizzaSwitch signatures in a few minutes in
case it helps to have the extra data.

> The Cyrus Murder matches look like a '^' can be added.  The protocol
> looks like IMAP and it is safe to anchor the \* in IMAP with '^'.  UCSD
> doesn't have any Cyrus Murder installs for me to test.  I'd suggest we
> add the anchor and then wait for new submissions if it doesn't match.

Sounds reasonable.

> I'm happy to submit a patch that does all of the above if it sounds
> reasonable.

Yeah, please do create such a patch and check it in.

> We might also think about adding Nmap internal performance statistics
> logging to Nmap proper similar to my addition of
> log_write(LOG_STATS, ...) in this branch.  I feel like sometimes using
> - -d3 or more is too much data when all you want to do is measure
> performance stats.

Have written up anywhere how this feature works?  We do try to avoid
filling Nmap with too much debugging code, but sometimes it is
definitely worthwhile.

Cheers,
-F


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