Re: [NSE] Local IP geolocation script

[Philipp Emanuel Weidmann <philipp.weidmann () gmx de>]

> Hi Philipp
>
> This is a nice script and probably caters well for the seriously
> paranoid!  I think it should also be in the "safe" category, but not so
> sure about being in the default one given that it requires a file which
> is unlikely (?) to be shipped with Nmap and thus not present in many
> installations.
> Having said that, it occurred to me that nmap.fetchfile() could be
> called from the scripts hostrule to check whether the file is present
> and to store a value in the registry so that this check would not need
> to be repeated for any further targets in that hostgroup.  This would
> have the effect of reducing some of the time wasted on calling the
> script if the required file is not present.
>
> The speed of lookup is OK for a single target, but for a large number of
> targets these small timescales would add-up to be quite lengthy.  This
> is because the geo file would be read for each target consecutively as,
> with no network activity, each instance of the script would complete
> before the next one begins.  Parsing the geo file once and storing the
> data for access by other instances of the script would slow down the
> execution for a single target by a small amount, but subsequent
> instances of the script would finish much more quickly and this would
> have a big impact when scanning lots of targets.
>
> Some other little points: ipOps.todword() could be used to convert
> host.ip into a number.  The script should be prevented from running
> against IPv6 targets where it would fail.  The script "id" field is
> being deprecated and the script filename is instead printed in the
> script results - so a more descriptive filename such as
> ip-geolocation.nse might be better.  You might also like to have a look
> at http://nmap.org/book/nsedoc.html for guidance on documenting the script.
>
> I've attached ip-geolocation.nse which calls datafiles.parse_file()
> inside the hostrule - combining the check for existence of the file and
> the one-time parsing and storage in the registry.  The hostrule also
> checks for IPv6 addresses (host.ip contains a colon).
>
> Regards,
>
> jah
>
>
>   

Hi jah!

Wow... you made an incredible number of improvements on the script. I 
wholeheartedly support all of them! Your changes also painfully reminded 
me of my lua deficiencies, especially where it parses the data... The 
datafiles.parsefile function I was unaware of, and it is certainly 
perfect here.

You also surprised me by saying that the "id" tag is going to be 
deprecated and only the file name will be output in the future... I do 
not want to appear ignorant given that I (sadly) have not been involved 
in the development of NSE at all, but this strikes me as a step in the 
wrong direction since it even *lowers* the amount of control the script 
has over how its output appears. The first thing I ever missed from the 
otherwise fantastic NSE was how little control the script had over its 
output! I was considering trying to add several features for that, like 
a very simple markup language that when used in the returned string 
would modify the behavior of Nmap when placing the string in the output:
In some instances the script might want to add information to the line 
"Interesting ports on..." where the host IP is given - for example those 
scripts dealing directly with the IP address (in which case the 
information should be close together). Also, a lot of time you do not 
want the "[scriptname]:" part of the output currently forced by NSE to 
appear at all which sometimes clutters up the output unneccessarily. 
Ideally, the script should be able to append (or possibly even modify) 
text freely in every section of the output. It might also be very nice 
to add some kind of simple markup by which the script can control 
bold/italic/color of its output when rendered in Zenmap, highlighting 
important information.

However, as I said I am not familiar with the dev history of NSE and 
therefore do not know what caused the decision to deprecate the "id" tag 
(I am sure that there are several good reasons for it). I would be glad 
if someone could tell me.

Best regards,
Philipp

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