Re: Script force - Named probes

[Djalal Harouni <tixxdz () opendz org>]

On Thu, Dec 15, 2011 at 11:34:49PM -0500, Patrick Donnelly wrote:
> Hi Djalal,
>
> On Sun, Dec 4, 2011 at 6:50 AM, Djalal Harouni <tixxdz () opendz org> wrote:
> > The rules should not be skipped (and they are not), we just ignore the
> > returned results if the force flag is set. I assume when you force a
> > script to run you know what you are doing!
>
> Skipped was the wrong word. I meant that NSE ignores the return value.
I can understand this, using this quick bash command:

for script in $(echo scripts/*.nse); \
do sed -rn -e \
'/^(pre|post|port|host)rule\s=\sfunction\s*\(.*\)[:blank:]*$/,/^end/p' \
$script | wc -l | xargs -- echo $script":"; \
done | grep -v ": 0" | sort -r -k2 -t : -n

We can see how many Lua lines are used in the rule functions, this is the
result (some rules will have blank lines):

Script                         Number of Lua lines in rules
scripts/dns-zone-transfer.nse: 52
scripts/qscan.nse: 37
scripts/firewalk.nse: 31
scripts/path-mtu.nse: 24
scripts/nbstat.nse: 24
scripts/ipidseq.nse: 20
scripts/ip-geolocation-ipinfodb.nse: 18
scripts/targets-traceroute.nse: 17
scripts/ms-sql-info.nse: 17
scripts/lltd-discovery.nse: 17
scripts/broadcast-ping.nse: 17
scripts/backorifice-brute.nse: 17
scripts/sniffer-detect.nse: 16
scripts/http-title.nse: 14
scripts/ftp-vsftpd-backdoor.nse: 13
scripts/ftp-proftpd-backdoor.nse: 13
scripts/dns-brute.nse: 12
scripts/whois.nse: 11
scripts/p2p-conficker.nse: 11
scripts/snmp-interfaces.nse: 10
...

Rules with 4 and 5 lines of code can be ignored.

Actually from the current 294 scripts we have between 25 and 30 scripts
which perform some logical operations in their rules (we count multiple rule
functions per script), and most of this Lua code is checking arguments
and permissions, so we can move it outside rules, when scripts are loaded.

The '--script' allows complex boolean operations so why not add this '+' ?


> > But yes from another point of view ignoring the returned results is not
> > really optimal.
>
> "Not optimal" is not how I'd describe it. We are deliberately breaking
> our own design. Scripts logically assume some code is run inside the
> portrule/hostrule when this is not the case. Forcing scripts to have
As you have noted we can move some of the script argument checks outside
rules, but it will not work for broadcast and prerule scripts.

> logic accounting for external forces complicates their design
> considerably. This patch may seem innocuous by itself but it opens the
> floodgates for similar extensions.
Yes, but do we have another option ?

(After this long discussion, nobody will propose something like this :p)


I also have another suggestion to adapt it to our current design:
1) Portrule/hostrule scripts should try to check their arguments outside
   rules.

2) prerule (broadcast) scripts are a special case: They need their
   arguments.

3) postrule scripts are also a special case: they need to check if there
   are some saved results.

> From these points, perhaps  we should just allow portrule/hostrule
scripts to be forced, and they will check their arguments outside rules,
and let rules only for port/host rule checks.

With this, the prerule/postrule logic will be preserved.


Really sorry for this noise I know that the patch has been committed but ...
(missing time ...)

What do you think ?


> ...
> > I think this is connected to Patrik suggestion about named probes [1]
> > or a replacement for it where --script-args "services.*" will set the
> > service manually.
> >
> > (1) Patrik's named probe example:
> > ./nmap -sV -p 1433-1500,1521-1600 1.2.3.4 --probes ms-sql-s,oracle-tns --script oracle-brute,ms-sql-brute
> >
> > (2) Patrick's --script-args example:
> > --script-args "services.ms-sql-s = {1433,1434}"
>
> Patrik's solution (1) looks good too. Thanks for making me aware of it.
We can add it later, and it will work with this force stuff.

Thanks Patrick.

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