Re: [RFC] hosted nmap scanner (GSoC)

[David Fifield <david () bamsoftware com>]

On Sun, Apr 04, 2010 at 07:30:43PM -0700, alexandru wrote:
> 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.

This is a good proposal, with lots of specific ideas. I also like that
you have provided mockups at http://hackd.net/soc/nmap/.

I'm afraid I'm not familiar with any web frameworks, so I can't comment
yet on the specific choice of Django. Avoiding the reimplementation of
user accounts and all that strikes me as a good idea.

I recently used the scanner service at http://nmap-online.com/. You can
compare your proposed service with that one and others, explaining what
you like and what you would change about the exiting options.

When you submit your proposal, be sure to use the template at
http://socghop.appspot.com/gsoc/org/home/google/gsoc2010/nmap. Also we
will want to know what different steps there are in the project, and how
long you estimate they will take.
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/