mailing list archives
Re: regarding rpc based protocols and rpcinfo script
From: Toni Ruottu <toni.ruottu () iki fi>
Date: Sun, 20 Mar 2011 14:11:03 +0200
I almost wrote my own rpcinfo because I could not imagine that it
might not be in the default category. I think every script that is not
enabled by default should have a comment which explains why. Maybe we
could form a convention while there are not yet thousands of scripts.
When the explanation is explicit it is falsifiable and can be
We could have exceptions for cases where the script belongs to version
category or intrusive category. Writing a comment "non-default reason:
intrusive" might be useful in cases where the script is later moved
out from intrusive category, and someone forgets to add it to default.
At the moment there are two intrusive scripts that are run by default.
Is this an error? I though a script could only belong to one. Also, I
think we agreed earlier that netbus-auth-bypass should be in default,
but it is not.
On Sat, Mar 19, 2011 at 10:57 AM, Fyodor <fyodor () insecure org> wrote:
On Fri, Mar 18, 2011 at 01:37:21AM +0200, Toni Ruottu wrote:
I am looking at the rpcinfo nse script. Why is it not in the default category?
Good question. It is already in the "safe" category (not intrusive)
and it produces very useful information. It is also very fast--taking
well under 1/20 of a second when I scan localhost. So I just moved it
to "default" as you suggest. If anyone doesn't think it should be
default, just speak up!
I also updated the NSEDoc to better describe what fields it prints
out. Users unfamiliar with the rpcinfo program may not understand the
current output very well. Actually, I think a header line will help
even more than the documentation update, so I just added one. After
all, my rpcinfo program includes one:
rpcinfo -p localhost
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 41952 status
100024 1 tcp 40652 status
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/