Re: suggestion to update ripeQuery.nse to not bother if the IP address is a private IP address

[Stoiko Ivanov <stoiko () xover htu tuwien ac at>]

Hi,
On Mon, Jun 11, 2007 at 02:43:30PM +0100, Eddie Bell wrote:
> It would be useful to write a general function that can check this, as
> other scripts will probably need the same feature.  Perhaps one of the
> NSE soc'ers could take a look at it? The code could look something
> like this:
>
> function isPrivateAddress(addr)
>   local a, b = addr:match( ("([^"..'.'.."]*)"..'.'):rep(2))
>
>   if(a == '10' or
>       (a == '172' and b == '16') or
>       (a == '192' and b == '168')) then
>         return true
>   end
>   return false
> end
>
> Although I'm not sure where in the nse code it would go.

great question! - I implemented a small patch which sets the path lua
searches for modules to the default value prepended by "NMAPDATADIR/nselib"

This will contain modules with code used in nse-scripts. 
At the moment only modules written in lua are supported (although I'll add
support for C-modules this week). 
I'll set up the make-system to install the nselib directory with the script
files today and commit it (I'll need to do some reading for the windows 
installer though). 
At the moment the only module is shortport.lua (containing some tests
commonly found in portrules) 
I'll add your code (with the small fix for the 172.* range) to another 
module (maybe ipOps.lua) in addition to a function converting an ip-address to 
its d-word value.

So should anybody have ideas for functions which may be needed inside
nse-scripts write a suggestion and I'll try to come up with a solution or -
even better - write a module to be added to the nse 
(http://www.lua.org/manual/5.1/manual.html#5.3) ;)

At the moment the path relies on the modules to have a .lua extension - I
decided to use the standard-lua extension, since the modules are plain lua
code (as compared to nse-scripts, which require the presence of certain
fields (id, description, portrule/hostrule, action)).

Comments (especially concerning the directory-name and file-extensions)
would be appreciated

cheers
stoiko

> - eddie
>
> On 10/06/07, DePriest, Jason R. <jrdepriest () gmail com> wrote:
> > Most of the systems I scan are on an internal network.  The RIPE Query
> > always fails because this traffic is not allowed to leave the network.
> >
> > My suggestion is to take the IP address that the script is using and
> > compare it against private ranges.  If it is in one of those ranges,
> > skip it.
> >
> > I realize that this would be extremely cumbersome to try to fit the
> > ranges around full regular expressions.
> >
> > So, I looked at converting the ranges to their dword values and then
> > using those for comparison instead.
> >
> > So 10.0.0.0 to 10.255.255.255 becomes 167772160 to 184549375,
> > 172.16.0.0 to 172.31.255.255 becomes 2886729728 to 2887778303, and
> > 192.168.0.0 to 192.168.255.255 becomes 2886729728 to 2887778303.
> >
> > To convert the IP address of the host to dword in LUA would probably
> > need to be done like this (Perl example since I don't know LUA):
> > <code>
> > my $host_ip = <some IP address>;
> > my ($w, $x, $y, $z) = split(/\./,$host_ip);
> > my $host_dword = ( ( $w * 256 + $x ) * 256 + $y ) * 256 + $z;
> > </code>
> >
> > Then just see if $host_dword is in any of the private ranges by doing
> > simple < and > comparisons.  If it is inside those ranges, don't try
> > to look it up.
> >
> > What do you think?
> >
> > It had been my intention originally to provide a patched script on my
> > own, but the way regular expressions are handled is different enough
> > so that I cannot easily grasp the concept without more examples.
> >
> > -Jason
> >
> > --
> > NOTICE:  This email is being sent in clear-text across the public
> > Internet.  Therefore, any attempts to include unenforceable legalese
> > restrictions are ridiculous and pointless.  If you can read this,
> > consider yourself authorized (whether I like it or not).
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org

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