Re: Draft for hosted cgi

[Fyodor <fyodor () insecure org>]

On Mon, May 29, 2006 at 10:39:07PM +0200, Julien Delange wrote:
> I make an update of the specifications[1]. More, I wish answer to some
> questions that were asked in the initial post.

Thanks, it looks pretty good.  My suggestions are below.

> - About language used in CGI
> I will probably use Perl. In my opinion, it's a good language and many know
> it.

Those are very good reasons.  Perl sounds good to me.

> On the other side, Ruby could be interesting, because rails can help to
> make a good cgi app.

If you are experienced with Ruby on Rails (or at least Ruby), that may
be a good option.  But if you have never used it, I'd stick with Perl.
This is a challenging project to do in 12 weeks as it is, so there is
no reason to add "learn a whole new langauge and web fraemwork" if we
don't need to.  I also know Perl, but not Ruby.

> week. But I already make many programs in Perl and think it will be more
> easy for me.

Good points.

> - About language used for Daemon
> I think it's probaly better to use the same langage of cgi-application. In
> fact, I plan to make a common API that could be used for that
> cgi-application and the daemon.

What sort of API calls would the Nmap execution daemon share with the CGIs?

> In fact, at this time, the daemon will store resulsts as XML files with -oX
> options. I don't plan to support others output options. I prefer to make a
> working solution, and after, I would add other functionnalities.

As long as you keep in mind the entire scope so that your simple
initial implementation can be cleanly expanded to support the extra
functionality, I agree that this is a super way to go.

I have a couple comments regarding the new doc:

> * Should be available in several language
>                                                        * Will use gettext()

I'm worried that this will add another layer of complexity to the
code.  And the user is going to have to deal with Nmap results in
English anyway.  So I would suggest doing the app and documentation in
English.  Then you (or others) can always write alternative docs in
other languages.  This is what Nmap itself does.  The binary only does
English, but I maintain the documentation in 12 languages here:

http://www.insecure.org/nmap/docs.html

I just added Italian a couple days ago (thanks to Lorenzo G. and
Simone Scarduzio for doing that translation).

> Rights:
> -------
> There is the list of each rights that admin can allow to a group
...
>        * OS detection : allow OS detection (-O)
>        * OS detecntion more agressive ( --osscan-guess )

No need to have the --osscan-guess privilege.  That doesn't change the
packets Nmap sends, just makes Nmap interpret the results differently.
So you can always allow --osscan-guess when you allow -O.

>        * deny scans to some domains, with willcard (ex: *.mil , *.gov, ...)

This would be hard to implement in an efficient way that users
couldn't easily bypass.  Specifying CIDR IP ranges to exclude is
better.  Then you can pass those to the Nmap --exclude option.

>       * define rtt timeouts ( --min-rtt-timeout , --max-rtt-timeout , --initial-rtt-timeout )

I'd just call it "aggressive timing options" or something.  Because
there are more options to limit.  And you don't have to worry about
things like --min-rtt-timeout which only SLOW down the scan.

> * allow source spoofing ( -S )

I'd say just don't allow that ever.

> * limit the number of scans per day/week/month
> * limit the number of unique-scans (scan to a specific host) per day/week/month

The limit should be by IP addresses, I think.  Because clearly a /16
scan is far more intrusive/dangerous than 100 single-target scans.

>        * define ttl : allow user to change the ttl (--ttl)

I don't see that option as particularly intrusive/dangerous, so I'd just allow it.

>        * set agressive or paranoid options ( -T{0,1,2,3,4,5} )

Those options are just -T4 and -T5

>        * set min/max parallelism ( --min-paralleslism, --max-parallelism )

Don't worry about --max-parallelism as that only slows scans down.
--min-parallelism belongs in "aggressive timing options".

> Admin-part:
> -----------

This all sounds good!

> oncrete example:
> -----------------
> I make a scan-request. It has the id 545
> All files related to this scan will be stored in the directory : /545/
>
> A make another scan, it has the id 565 890 : will be stored in the directory /565/890/
>
> Another scan has the id 1 -> /001/

If you store id 545 in /545 , where will you store id 545,007?  You
had a set number of levels in your previous proposal, which I liked.
With three levels, we can store a billion scans, which should be
enough for now.  Also, I suggest removing trailing zeros (unless the
whole value is 0) for a certain level (that is just a minor preference
I have).  So:

545 -> 0/0/545/
1 -> 0/0/1
565890 -> 0/565/890/
545007 -> 0/545/7/
204719806 -> 204/719/806/

> The daemon will fork() and execute a command like nmap ... -oX
> /data/545/545.xml ... hostname

Maybe call it scan.xml or something rather than id.xml.

Also, as an alternative to this approach, have you thought about
giving each user an ID and storing their UID in a directory structure
like this, then storing their scans in a subdir of their UID?  That
may make it easier to see all of the scans a user has made, delete
them when the user is deleted, etc.  But I'm sure you can get it to
work either way.

Cheers,
Fyodor






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