Nmap Development mailing list archives
features/work to be considered/ideas
From: Okan Demirmen <okan () demirmen com>
Date: Sun, 19 Jun 2005 17:23:16 -0400
Hi all. 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 larger. 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 re-considered/re-worked. - 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 OpenSSH's ssh_config(5): addr 10.1.1/24 osfingerprint debugging ports T:20-25,80,U9999 xml addr 10.2.1/24 packet_trace ports T:1-10 Insame nmapformat min_hostgroup 10 addr 10.99.1.5 P0 sS sV sX grepable addr 10.50.1.88-200 Paranoid addr * verbose host_timeout 1000 decoy XXXX -n min_hostgroup 4 exclude-file <file> (* 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. Cheers, Okan -- Okan Demirmen <okan () demirmen com> PGP-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB3670934 PGP-Fingerprint: 226D B4AE 78A9 7F4E CD2B 1B44 C281 AF18 B367 0934 _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev
Current thread:
- features/work to be considered/ideas Okan Demirmen (Jun 19)
- Re: features/work to be considered/ideas Arturo 'Buanzo' Busleiman (Jun 19)
- Re: features/work to be considered/ideas Arturo 'Buanzo' Busleiman (Jun 19)
- Re: features/work to be considered/ideas Okan Demirmen (Jun 19)
- Re: features/work to be considered/ideas Arturo 'Buanzo' Busleiman (Jun 19)
- Re: features/work to be considered/ideas Arturo 'Buanzo' Busleiman (Jun 19)
- Re: features/work to be considered/ideas Arturo 'Buanzo' Busleiman (Jun 19)