[RFC] hosted nmap scanner (GSoC)

[alexandru <alex () hackd net>]

Hello world,

I know others have expressed interest in tackling the 'hosted scanner' idea for this year's GSoC, but I figure 
competition is a good thing. Here are some of my thoughts and ideas regarding this; I'm looking to tap the list's 
combined wisdom for help on how I can refine this proposal. Thanks in advance for all the awesome feedback and for 
taking the time to read this.

=== Backend === 

The scanner will be in Python, based on Django. This affords user accounts and ACLs 'on the cheap' (development-wise) 
and takes away a lot of the pain of doing from scratch. Security issues in Django are likely to be well-mediatized; 
using Django is a better bet than going at it from scratch. This doesn't mean that proper security-testing of the 
application won't be done (using many of the great tools[1] available) but that there will be less to test, and more 
time to test it.

Django handles the DB, so there's no limitations there. Initial development will happen on PostgreSQL, but the actual 
DB is, more or less, at the user's discretion.

The system runs wherever Django and nmap run. My own development will be done on OS X with side-by-side testing on arch 
Linux. Once there's something seriously usable, I'll start testing on CentOS as well. A dumb (nmap-disabled) interface 
will be made available for the community to see, test, and provide feedback on.

Scans, as created within the app, are validated both on the server/web side and by the daemon that's going to be 
running them. Things like hostnames/IP-ranges get treated differently in the form input, complete with all the 
appropriate validation checks. Hostnames will always be put into a file passed to nmap with -iL

With these checks in place, something as simple as a chroot jail might be sufficient to run the daemon inside of. 
Policy-based access controls would be even better (the daemon should only ever run nmap-related things, and everything 
else should be flagged). It's important that users don't:

    + compromise the system by crafting scans with side effects outside of nmap
    + elevate their scanning privileges
    + gain access to other users' scan results
    + own the system

=== Functionality ===

For starters, only two types of user accounts will exist: regular and super. The differences will be the same as the 
regular vs. sudo execution of nmap. Time-permitting, arbitrarily many user classes can be defined by admins, each with 
different capability sets. There will also be an administrative account (only functionality related to the web app, no 
ability to run scans etc)

The user account allows for:

    + creating/running new scans, based on account capabilities
        + scan creation limits free input as much as possible
        + only show features user has privileges for (don't just make the others show up disabled)
        + try to filter out mutually-exclusive scan options
    + view/download scan results
    + scan result diffs
    + cronjob editor for automated scans (with automated emailing feature for when things change unexpectedly)
    + 'scan packs' where multiple scans for a certain host/range can be defined, and always run together.

The admin account allows for:

    + user auditing and CRUD
    + user classes (editing, defining, assigning users to)
    + scan statistics (hosts, usage, users) *tentative*


=== Interface ===

There will be iPhone and iPad stylesheets, though I doubt there will be enough time to turn this into a full-blown web 
app (complete with persistence on the iPhone etc). Maybe for the next GSoC?

Some mockups of the interface are available[2]. Adherence to user experience common sense is going to be at the centre 
of the project, alongside security, and many low-cost usability practices are going to be used throughout the lifetime 
of the project[3]. That said, simple and clean is preferred over UI exuberance.

The interface must be usable on all of the latest generation browsers. Most of the elements will be plain CSS and 
almost no graphics. JavaScript will only be considered as a last solution to most problems, but it may be useful in 
making the scan options page more usable (because there will be a lot of options and the possibility that many should 
be filtered out). Theming support won't be considered beyond swapping CSS files.


=== Me ===

I'm a Computer Science student looking forward to starting my Master's degree in the fall. I've dabbled in security 
from the sidelines for quite some time now, and I'm hoping I'll do most of my research in the field. However, academia 
and industry are very different at (most) times, and I enjoy the high of working on tools that people use Now (as 
opposed to 30 years from now, maybe). So I'm hoping I'll get to work on nmap and make this project happen over the 
summer, and immerse myself in the community (to which I intend to keep contributing post-GSoC, naturally)



[1]: http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy
[2]: http://hackd.net/soc/nmap/
[3]: http://www.useit.com/papers/heuristic/inspection_summary.html

—
@

Attachment: PGP.sig
Description:

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