Re: [NSE] httprecon 1.0nse Release

[Marc Ruef <marc.ruef () computec ch>]

Hello Rob,

Thank you for your feedback.

> Hi Marc, I gave the NSE version a try (you might want to update the tar.gz
> file so the get and head folders are already within an httprecon folder, as
> that's where the script expects them) and it was excellent against IIS

Good input. I will consider that in release 1.1.

> (correctly detecting 5, 6 and 7 - the latter in a slightly non-default
> configuration), but I wasn't quite as happy with the minor versions of
> Apache. The win32 version seemed to be more accurate against the same
> Apache 1.3.37 server (putting it in joint 1st place, rather than joint
> 3rd), although this may be down to performing additional checks:

Unfortunately your observation is correct. This has two reasons:

1. It is very hard to find differences between (minor) releases of Apache.

2. I was not updating the fingerprint database for the last few months. 
The accuracy might be very limited when it comes to the latest releases 
of http daemons. An updated db is on the way ;)

> I guess the weighting might need a little bit of fine tuning. In general
> the script seems very good, and httprecon (both the NSE script and win32
> versions) seems like a decent alternative to similar tools I'm already
> using.

Thank you for your kind words :)

> I would, however, consider marking the script as "intrusive" as it
> intentionally makes non-standard requests (e.g. get_long) that might upset
> some devices. To me it seems marginally more intrusive than some existing

Good feedback.

However, you might be able to disable checks by using the following 
command line arguments:

httprecontestgetexisting=0
httprecontestgetnonexisting=0
httprecontestgetlong=0
httprecontestheadexisting=0

> "intrusive" scripts like ssl-enum-ciphers (which is classed as intrusive
> due to the number of requests, even though none of them are malicious),
> dns-zone-transfer and dns-resursion. Or perhaps we need to take another
> look at the classifications in general (looking at the contents of
> script.db, the intrusive category seems to be the exact opposite of safe,
> which might make intrusive somewhat redundant).

I would appreciate it if others might backup this suggestion. My 
familiarity with nse standards is a bit limited. What is the best strategy?

Regards,

Marc

--
Marc Ruef | marc.ruef () computec ch | http://www.computec.ch/mruef/
_________________________________________________________________
Meine letzte Publikation: "Nmap NSE  Hacking, Teil 5: 
HTTP-Kommunikationen" http://www.scip.ch/?labs.20100511
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/