mailing list archives
features/work to be considered/ideas
From: Okan Demirmen <okan () demirmen com>
Date: Sun, 19 Jun 2005 17:23:16 -0400
So since everyone's got an opinion, I might as well voice a few of mine.
I wanted to wait until all the GUI and language discussions wore down
just a bit. I got a few ideas, some general and some specific which
may deem appropriate for a summer of code project and some smaller and
I personally think that a new GUI may be of some help, but that's
exactly what it will be, a *new* GUI. Sure the current one is merely a
GUI to all the options and not too much else. I feel if a *new* type of
GUI is to be developed, some underlying functions of nmap may need to be
- Abstract the scanning and processing "engines". Go so far as having a
core function actually do the scanning and have a DE (decision engine)
go through all the results. One may go as far as having nmap generate
the traffic and store the results in some pcap-like file, then have the
DE process the results. Yes, there are many things that nmap needs
results on before continuing, but that is the general idea. One place
where this type of split may help is OS fingerprinting. Imagine having
nmap do the work, store the fingerprint somewhere, then have another
piece, the DE, match against the fingerprint DB. Here the GUI makes out,
for it could then parse "raw" nmap results. One could have a private
database of fingerprints to their environment, or use the default one,
or one could pluggin a new fingerprinting method (just by telling nmap's
scanning engine to do(tm) more stuff, and have the result processing
engine map against a new db). I mentioned the GUI, but of course one
could pipe the nmap "raw" data through nmap to get the same results.
There are other places where having the "raw" data available and having
processing occur outside of active scans. Would this speed up nmap?
Maybe, if nmap's scanning engine just collects and stores, then the
processing engine/decision engine does the harder work. Same binary? Who
knows. I don't have the details in my head yet - just spewing for now.
- As I've seen some ideas about kicking off scans from web interfaces
and whatnot, think taking my idea above a bit further and creating nmapd
- an nmap daemon. Think about distributed scanning engines... and say
nmapctl/nmapd status/etc...what would this do for parallelism? - still
not completely clear in my head, but possibilities can get endless here.
- While this idea is very important to a daemon idea, I believe it nmap
may benefit from this as it is today. Have nmap privsep. We all know
what privsep is, for we all use OpenSSH today, but a better comparison
maybe be OpenBSD's privsep'd tcpdump(8).
- I've seen this comment elsewhere on the list - config files for nmap.
Kinda trivial to do today with a shell script, but maybe worth it -
especially with nmapd ;) However, a nice feature of actually creating
config files may allow for something such as the following - ala
P0 sS sV
(* implies all defaults, unless specified - see ssh_config(5) for
details on how it works for OpenSSH)
(minor: standardize a source style - 80 char width/tab vs space/etc ;)
Just a few ideas. Yes, some of them not completely clear in my own head,
but if anyone things they are important, then we'll all think about it.
Okan Demirmen <okan () demirmen com>
PGP-Fingerprint: 226D B4AE 78A9 7F4E CD2B 1B44 C281 AF18 B367 0934
Sent through the nmap-dev mailing list
- features/work to be considered/ideas Okan Demirmen (Jun 19)