Re: Draft for hosted cgi

[KarMax <karmax () gmail com>]

> All ideas are detailed in a file[2]. Comments are welcome. I will put more
> ideas as soon as possible.

Great doc.
It will be good if the client and the daemon communicate each other using XML
Doing this the client will be really independent. ( a perl/Gtk client
running on my *nix or a Java app, etc.)
So we have:
GUI --XML--> "Parser" --> DAEMON

The Function of the parser is:
- Get the XML request
- Write to the database (the one who stores, users, scans, etc) data
that could (and it will) be requested from the GUI client.
- The parser must give the scan request in some way to the DAEMON scanner.
  * The parser can pass the scan request directly (in an nmap fancy
daemon way) when writes the database.
 * Can write it in a database (the one that the DAEMON reads to do the scans).
  * Can write a .xml .txt .whatever file to be readed by the daemon.
 * etc.
- Finally Gives the result to the user.


The process looks like:

1) Start the scan from my "independent" client
2) Then the client send an XML request
3) The Parser got it
  - Write on the sql db
  - Pass the request to the Daemon scanner
4) Here comes your "several sort of scans"
5) The scan begins with the specified options.
6) "Can consult each scan that are done (history)"
 There will be two big types
  - "Live": The daemon parses right away the nmap output and write it
to the database
  - Normal: When the scan ends it write the result to the database.

* Both methods can show the results in the ways you write (mail, web
app, GUI, etc.)
* The result could be whatever nmap output we want.
* Maybe the daemon could directly pass the output to the parser.

7) The user finally get his nmap hosted scan result.



About How to store scans-data, there is a lot of ways, it will be good
if you can config that easily from some .cfg (or only three
"pre-made-options" like md5, date and users)
- Date
/data/(date-format)/scanid.xml
- Users
/home/user/nmap-hosted/data/(md5 or date mode)/scanid.xml



On 5/24/06, Arturo 'Buanzo' Busleiman <buanzo () buanzo com ar> wrote:
> 2) use scan types that no rely on root privileges

Not a valid option.

> 3) use linux capabilities, to grant an unprivileged user the required raw sockets capabilities.

Allow an unprivileged user to use raw sockets is a BAD idea.

I like the Daemon running as root (you can make it SECURE)




Also the daemon written on perl or C++ will be nice.
A big part of the comments are _MORE_ work (and maybe unnecessary)

Good Luck


-- 
Gonzalo Martinez
Jabber: KarMax () jabber org


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