Re: Draft for hosted cgi

[Fyodor <fyodor () insecure org>]

On Wed, May 24, 2006 at 12:24:54PM +0200, Julien Delange wrote:
> [2] :
> http://svnweb.tuxfamily.org/filedetails.php?repname=hostednmap+%28nmapcgi%29&path=%2Ftrunk%2Fdocs%2Fspecs-wip&rev=0&sc=0

Looks good.  Here are some comments:

* Can see a diff between two scan
     -> Will probably use the diff command

The diff command is insufficient, but may work as a placeholder.  One
of the feature-creepers (not determined who yet) is planning to write
a program to compare XML results and output english or XML, which
should do the trick.  Here is the task specifics:

o Write a program which compares two Nmap XML output files and
  outputs a 3rd file (in user's choice of XML or english text)
  describing the differences.  A number of SoC projects would likely
  find this useful (NmapFE++, Hosted Nmap).  You would write a DTD and
  otherwise document the third (difference file) format.
  o The first step is to design the system in a proposal for posting
    to nmap-dev

> * Supported options: *OS detection  *SYN scan

This is clearly not a comprehensive list :).

> * Can change the theme
>   * The web-interface could be tuned and have several themes (templates+css)

Sounds good.

> Admin-part:
> * Can edit statistics : the user who makes a large number of scans, ...

I'm not sure what you mean by "edit statistics".

> * Can forbid

Can forbid what?

> CGI-part:
> *********
> * Has severals themes

Two themes ought to be plenty at first, I think.  But if you make more
themes than that, more power to you!

> Daemon-part:
> ************
> * Run by root (MUST be secure)
> * Written in the same language than the CGI-part

I don't think there is any reason it has to be in the same language.
It might be better in C, for example.  It will only be doing the bare
minimum of stuff where you need to run with privileges (which mostly
means executing Nmap after determining that the command line is safe
(I think this is where we should do the checks that the command line
is reasonably sized and that only known-safe options are used) (to
exclude things like -o or --interactive or -iL).  Also, do some sanity
checks such as not letting a single option argument be 2K.

>                - Each scan as an id
>               - Take the 8 first caracters from the md5 of this id. Cut those caracters
>                 on group of two. You will have subdirectory.
>                 i.e : the number "1" has md5 c4ca4238a0b923820dcc509a6f75849b, so you will have
>                 c4/ca/42/38/
>               - Add the name of the file in this directory
>                 In our case, with the id "1", we will have the file c4/ca/42/38/1.xml

We may not need to hash the ID number into another number.  You could
have ID #1 stored in 0/0/1 for example, and ID #1,043,017 stored in 1/43/17 .
Obviously they won't be randomly distributed among the directory tree
this way, but I don't think that is necessary.

>        WITH DATABASE
>       =============

I think a DB will probably make many aspects of the projects easier for you.

> We simply have a field in the database and we put the XML output in this field.

Maybe you can store the ID in the DB and also some other important
aspects of the scan in their own fields, but the XML could be stored
on the filesystem as you discussed above.  Inserting a 100K Nmap XML
blob into the DB is kinda ugly and probably less convennient in
general than having it in a file.

I hoep this helps.

Cheers,
-F


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