Re: Nmap script ideas wiki

[Nick Nikolaou <nikolasnikolaou1 () gmail com>]

I think this is a great idea which will make a great starting point for
people that want to contribute.

On 11 March 2011 17:48, David Fifield <david () bamsoftware com> wrote:

> We can also put notes next to entries to show which ones are being worked
> on.


Is everyone free to start working on a script and edit the page to reflect
that?

On 11 March 2011 17:48, David Fifield <david () bamsoftware com> wrote:

> On Fri, Mar 11, 2011 at 07:13:14PM +0200, Toni Ruottu wrote:
> > What kind of suggestions are welcome? I wrote a few, but I am not sure
> > if I should spam the wiki with all the scripts I've been thinking
> > about. On the other hand some of the topics may be useful. Even if
> > they just provide new comers a list of things they can choose from.
> > There are some info script categories which may easily get long, and
> > may not need exact descriptions, as the purpose of an info script is
> > always just to extract some information semitrivially available
> > through chatting the protocol. Some types I have been looking at
> > include:
> >
> > game servers (quake3-info, wesnoth-info)
> > These reveal information about the game world, but also technical
> > information about the server configuration. They are often simple to
> > write, but may require parsing all kinds of formats that may or may
> > not be trivial. quake3 style servers require talking a binary
> > protocol, while wesnoth uses gzip and xml.
> >
> > network diagnostic services (teredo-info, stun-info)
> > These may reveal lots of information about the targets, but also some
> > information about the network environment between the scanner and the
> > target. These scripts have lots of potential, but may be hard to write
> > as there is a lot one could do. Also writing these requires lots of
> > rfc reading, as the specifications may be long (teredo) or scattered
> > in multiple rfcs (stun, turn, ice, ...)
> >
> > system monitoring services (gkrellm-info, mbmon-info)
> > These are really good targets for script writing, as the services are
> > designed to reveal lots of interesting information about the system.
> > The produced scripts are also really useful for administrators, as
> > they can then use nmap for gathering statistics of multiple machines
> > with nmap scans. The problem with these is that available information
> > may be overwhelming. For example gkrellm reports the cpu load with an
> > interval of a few seconds. What should the script show to the user? A
> > graph? Average value? First value? Min and max values? Ofcourse there
> > is lots of simple information available as well, but deciding what to
> > show and how may be hard.
> >
> > remote administration tools (backorifice-info, subseven-info,
> > netbus2000-info, backorifice2000-info)
> > These are important because insecure remote administration tools may
> > reveal lots of information about the system. It is critical to
> > acknowledge any such services as soon as possible. Most of the ones I
> > listed above are used by malicious users to gain access of
> > unsuspecting victims, so highlighting these systems to the admin is
> > really useful for improving security. Most of these are old, but some
> > of them still work with up to date systems. The problem with these is
> > that the protocols may not be clearly documented, so one needs to do
> > research with wireshark, and google to find out how they work.
> > Grepping open source reimplementations is also useful.
> >
> > peer-to-peer nodes (gnutella-info, tor-info, freenet-info)
> > Peer-to-peer nodes often publish technical information to co-operate
> > with other nodes. Having convenient access to this information is
> > useful for researching the system, but also to give users some idea
> > what kind of data they are giving out to the world. The problems
> > involved with these are that there may be lots of information
> > available, so one needs to decide what to show to the user. Some
> > information may also be relative to your position in the network. Some
> > of these services reveal a connection table, which makes it possible
> > to draw graphs about the systems, or crawl the network to scan other
> > nodes involved in the protocol.
> >
> > discovery services (udp-bittorrenttracker-info,
> > http-bittorrenttracker-info, gnutella-nodecache-info)
> > These scripts are useful for getting some nodes to scan while
> > exploring a peer-to-peer system. They can provide a starting point for
> > crawling the network. The discovery services may also provide other
> > interesting information. Also, getting a list of IP addresses when
> > ever the scan hits a discovery server makes it clear to the user what
> > the services is used for. There are two types of discovery scripts.
> > Some have a pre rule and are mainly used to choose scan targets for a
> > scan, but some other are used by scanning the discovery service to
> > extract information out of it. Also the latter ones may be used to get
> > scanning targets, but this typically leads to scanning the discovered
> > servers for discovery services, which is a bit odd.
> >
> > These examples are from the top of my head. I just thought I'd post
> > them here rather than spam the wiki directly. We can always move some
> > of these to the wiki, if that is useful.
>
> I think these are fine examples of what we want on the page. I would
> copy all of them there. One of the motivations behind putting ideas on
> the wiki is make discussion more permanent, and to make it easier for
> other people to contribute (who may see joining a mailing list as too
> high a barrier). We can also put notes next to entries to show which
> ones are being worked on.
>
> In general, I'd say use the Wikipedia philosphy and Be Bold in editing.
>
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/