diff options
Diffstat (limited to 'todo/nmap.txt')
| -rw-r--r-- | todo/nmap.txt | 638 |
1 files changed, 638 insertions, 0 deletions
diff --git a/todo/nmap.txt b/todo/nmap.txt new file mode 100644 index 0000000..76fe1ff --- /dev/null +++ b/todo/nmap.txt @@ -0,0 +1,638 @@ +TODO $Id: TODO 11866 2009-01-24 23:10:05Z fyodor $ -*-text-*- + +o Work on Nmap on Mobile devices, particularly Android. Would be + great to get it in Google Play store, for example. An official + version with a workable GUI. For now, people have to do manual work + and it isn't as well tested either: + https://secwiki.org/w/Nmap/Android . If this is successful, we could + consider iOS. + +o Nmap performance work. Particularly with --min-rate. + +o Consider re-architecting Nmap to have more of a scanning pipeline +approach rather than fixed sets of hosts which start and finish one +phase and then move into the next in parallel. This could potentially +allow us to add hosts one by one to a phase as other hosts finish that +phase and, ideally, the phases could run in parallel too. + +o Nmap Network Scanning, 2nd Edition work [placeholder] + +o Organize nselib into a hierarchy. A library "dirname/filename.lua" can be + required as "dirname.filename". We would need to ensure the installers + (Makefile, OS X, Windows, RPM) can handle this. See + http://seclists.org/nmap-dev/2014/q3/364 + +o We should work to reduce Zenmap's memory consumption. We used to + commonly get error reports from people who load so many systems that + Zenmap gives an out of memory error and crashes. For example, see + this thread: http://seclists.org/nmap-dev/2014/q2/46 + After committing patch at http://seclists.org/nmap-dev/2014/q2/429, + we no longer get the error report but the problem still exists. + The problem seems to lie in a very large Nmap Output being stored + in memory and a possible fix seems to be to use a file based paging + system. + +o Consider making a version of Nmap for Apple's official Mac App + Store. A particular concern with the downloadable Mac version of + Nmap is that Apple's new "Mountain Lion" release may require users + to jump through hoops to install unsigned non-app-store content per + their "Gatekeeper" "feature". Though maybe signing the app will be + enough. There may also be an issue with the "Sandboxing" + requirement for App Store apps starting June 2012. Will Nmap be + able to request all the permissions it needs? Ignoring the + technical challenges for the moment, what will users prefer? + +o Do a roll up on (state, TTL) pair instead of just state so that TTL + info is not lost when doing roll up on port states. + See thread at http://seclists.org/nmap-dev/2014/q3/93 + +o Consider looking into differring TTL values during OS detection + phase and choose a port that is (hopefully) not firewalled to get + a better chance at correct result. See thread at + http://seclists.org/nmap-dev/2014/q3/33 + +o [Zenmap] Look into and refactor code which uses the (very slow) += operation + on strings. http://seclists.org/nmap-dev/2014/q2/432 helped improve speeds + for opening files (from hours to seconds) and it seems like more speedups + can be done in other places. + +o Look into moving our Mac building/testing system into a virtual + machine or leased server sort of environment so that multiple Nmap + developers can access it and nobody has to keep a stack of Mac Minis + in their closet. + +o INFRASTRUCTURE: Upgrade seclists to use Mailman 3, which apparently + has many improvements. + +o We should fix nsedoc generation so it doesn't fail when blocks like + @usage, @output, etc. are followed by a local declaration. See + http://seclists.org/nmap-dev/2014/q2/331. If for some reason this + just can't be fixed, we will have to document the heck out of it, I + suppose. + +o When scanning your own IP from Windows, Nmap currently recognizes + the problem (can't do a raw scan like that on Windows) and skips the + SYN scan, leading to Nmap printing a bunch of ports in "unknown" + state at the end. Nmap should probably act like unprivileged mode + in this case (e.g. do a connect scan, etc.). See + http://seclists.org/nmap-dev/2013/q3/519 + +o Investigate Checkmarx static analysis report of Nmap source tree + that someone sent us on Feb 12. It looks like mostly false positives, + but we should go through to check for any real bugs or even possible + security issues. Fyodor has the report. + +o INFRASTRUCTURE: Consider updating our svn-mailer.py (and conf file) + to the latest official version. First check whether there is a + later official version and whether it has material changes. We're + currently using one from + subversion-1.4.2/tools/hook-scripts/mailer/mailer.py. + +o Consider a two-stage model for IPv6 subnet/pattern support + o Right now you can try to scan a /64, for example, and Nmap will try + to iterate through them all (and of course never complete). So + perhaps Nmap should first look at a specification and decide if it + should use other techniques like multicast discovery instead. + +o Move advanced IPv6 host discovery features from NSE into core Nmap. + We'll probably add the functionality of + targets-ipv6-multicast-invalid-dst, targets-ipv6-multicast-echo, and + maybe targets-ipv6-multicast-slaac. + - The idea is that Nmap does them automatically if it gets a large + target specification and sees that it is local so can be multicast + pinged. + +o We should figure out why (at least with Nping) raw ethernet frame + sends seem to be taking significantly longer than raw socket sends + (e.g. using --send-ip or the OS-provided ping utility). This has + been reproduced on Linux and Windows. Here's a thread: + http://seclists.org/nmap-dev/2012/q4/424 + o Note that David and I tried to reproduce this on his machine and + on 'web' and 'research' machines and could not reproduce. Still + happens with Fyodor's machine connected with WiFi. Fyodor should + test on the same machine using wired and see if that changes anything. + +o Implement some improvements to dns-ip6-arpa.nse, as describe at + http://seclists.org/nmap-dev/2012/q2/45. + - Also consider a move to "fire and forget" logic. Just blast out + the queries that we know we have to make, and then read any replies + that may happen to come back. (but still try not to introduce + inaccuracy (missed hosts) by flooding the network. + +o Treat the input to the escape function in xml.cc as UTF-8, not just + ASCII. Good UTF-8 should survive into the output; i.e., "\xe2\x98\xbb" + should become "\xe2\x98\xbb" in the output, not "☻". + If the input happens not to be UTF-8, (like the file name in + http://seclists.org/nmap-dev/2013/q1/180), I suppose we can + individually encode each byte of each invalid sequence: "\xba\xda\xbf" + becomes "ºÚ¿". Can probably do this with simple + byte->rune and rune->byte functions as in + http://plan9.bell-labs.com/sys/doc/utf.html. + +o We should probably redo the Nmap header (e.g. on https://nmap.org) to + make it more attractive. Or, at a minimum we should update the + screenshots and think about which links we really need (some of those + pages aren't really updated any more). + +o Test a hierarchical classifier for IPv6 OS detection. Our classifier + currently treats, for example, some localhost Linux fingerprints as + separate classes from remote Linux fingerprints, simply because we + lose precision if we lump them together (for example TCP window size + differs across certain Linux versions when measured remotely, but + not on localhost). This leads to the linear classifier having to use + narrow margins between fingerprints that are really very similar. I + want to try a tree of classification where each non-leaf node is a + separately trained classifier and each leaf node is a final + classification. The first layer of the hierarchy would be something + like + (linux windows solaris aix ... other) + where "linux" would contain *all* the Linux fingerprints in a single + class. Lower levels would be like + (linux-2.4 linux-2.6) + (windows-xp windows-vista windows-7) + Lower levels will include only those fingerprints in their parent + class, so we don't even think about Windows when classifying + Linux. Probably three or four levels will be sufficient. There may + be a principled or automatic way to build this hierarchy, but I + suspect playing it by ear will be sufficient. Talk to David for more + of his thinking on this topic. + +o Maybe we should rename dns-brute to dns-brute-enum since it is so different + from our traditional brute force authentication cracking -brute scripts? + +o NSE WORK (note that this is mostly infrastructure because script + ideas are generally put on the script ideas page instead: + https://secwiki.org/w/Nmap_Script_Ideas) + o Review NSE-based port scanning and RST idle scan. + http://seclists.org/nmap-dev/2011/q2/307. [Henri and Hani?] + +o Maybe we should add an analysis or reporting or intelligence (or + different name) for our NSE scripts which don't send any packets, but + simply analyze Nmap's existing data and report when useful. + +o Install some sort of svnview webapp for svn.nmap.org which is + wrapped in Insecure chrome, allows people to click link for direct + file download, probably shows revision history and allows users to + see older versions, etc. + +o Process Nmap survey and send out results [Fyodor] + +o Nping (we think) will stop after 2^32 rounds even when "-c 0" is + given. We should probably make this a 64-bit integrer so that "-c + 0" will go essentially forever and so that users can give values + higher than 4 billion. + +o Nscan work [placeholder] + - Hosted Nmap system + +o Add CPE entries to OS fingerpting DB entries which still lack them. + This is a gradual process since almost all of the missing ones + aren't in the official CPE dictionary either and it can take a lot + of research to decide on an appropriate entry. Milestones so far: + - 3/21/12: We have entries for 2,601 of 3,572 fingerprints (971 + missing; 73% coverage) + - 11/5/12: We have entries for 3,285 of 3,907 fingerpritns (622 + missing; 84% coverage) + - 11/12/12: We have entries for 3,558 of 3,946 fingerprints (388 + missing; 90% coverage). + +o [Zenmap] should actually parse and use script results. See + http://seclists.org/nmap-dev/2010/q1/1108 + - We have an initial prototype, but probably need to redo because it + doesn't present the results in the way we'd like yet due to + problems implementing such a presentation with GTK, etc. + +o Make Zenmap settings get upgraded when the Zenmap executable is + upgraded. The per-user configuration files such as scan_profile.usp + and zenmap.conf are never overwritten once installed by Zenmap, so + changes and fixes to those files don't reach anyone who has + installed Zenmap already. This is most noticeable with changes to + profiles and highlight definitions are notably affected. This fix + may involve hard-coding settings that are not normally configured by + users (like highlighting) or updating the per-user files at startup + (only those parts that haven't been changed by the user). + +o We should offer partial results when a host timeouts. I (Fyodor) + have been against this in the past, but maybe the value is + sufficient to be worth the maintenance headaches. Many users have + asked for this. If we do implement this, we may want to only print + results for the COMPLETED phases (e.g. host discovery, port + scanning, version detection, traceroute, NSE, etc.) Trying to print + partial results of a port scan or NSE or the like might be a pain. + And if we print some results for a host which timeouts, we should + give a very clear warning that the results for that host are + incomplete. As an example, here is someone who hacked Nmap source + code to achieve this: http://seclists.org/pen-test/2010/Mar/108. + o Another benefit would be that it would allow us to clean + up/regularize the host output code. Right now there are I think + three places where a host's final output can be printed. If, + instead, that code just looked at what information was available and + printed that out only, we could potentially isolate it in just one + place. + o This also might let us provide a feature for skipping the rest of + an Nmap phase which is going too slowly (I think that has its own + Nmap TODO item). + +o [Nsock] Some SSL connections that used to work now fail; find out + why. http://seclists.org/nmap-dev/2010/q4/788. Narrowed down to + r19801 in http://seclists.org/nmap-dev/2011/q1/12. + +o [NSE] Consider a system where scripts can tell if any other scripts + depend on them. They could then use that to determine whether they + should bother storing information in the registry. For example, + snmp-interfaces could store the discovered table if another script + (such as a mac address geolocator script) depends on it. + +o [NSE] Consider whether we need script.db for performance reasons at + all or should just read through all the scripts and parse on the fly. + See: [http://seclists.org/nmap-dev/2009/q2/0221.html] + +o A couple minor nsedoc issues (see + http://seclists.org/nmap-dev/2011/q1/1095): + o After the ssh-hostkey portrule was added, nsedoc seems to be + generating a blank "Script types" filed for the script: + http://localhost:8082/nsedoc/scripts/ssh-hostkey.html + o This is happening because "portrule" and "hostrule" appear later in + the script, and NSEDoc thinks it is their definition, and there is + no NSEDoc there. + local ActionsTable = { + -- portrule: retrieve ssh hostkey + portrule = portaction, + -- postrule: look for duplicate hosts (same hostkey) + postrule = postaction + } + o ssh-hostkey and rmi-dumpregistry each have two @output sections, + and NSEDoc is only showing the second one. We should probably just + combine them into one @output section, and maybe make nsedoc give a + warning in this case. Or we could make nsedoc handle multiple + @outputs. + +o Add general regression unit testing system to Nmap + o David has created a system for Ncat which could serve as a + model. + +o Make version detection and NSE timing system more dynamic so that + the concurrency can change based on network conditions/ability. + After all, beefy systems on fast connections should be able to handle + far more parallel connections than slower systems. + o At a minimum, this at least warrants more benchmark testing. + +o We should run at least one SCTP service on scanme. Daniel + Roethlisberger has made available dummy services which support IPv4 + and IPv6 (see http://seclists.org/nmap-dev/2011/q2/450). + Alternatively, we could run some sort of "real" SCTP application(s) + (preferably one which is relatively simple, easy to install, secure, + and supports IPv6). + +o Create new default username list: + http://seclists.org/nmap-dev/2010/q1/798 + o Could be a SoC Ncrack task, though should prove useful for Nmap + too + o We probably want to support several lists. Like an admin/default + list like "root", "admin", "administrator", "web", "user", "test", + and also a general list which we obtain from spidering from + emails, etc. + +o Improve Nsock proxies system + - Add SSL support + - Add proxy authentication + - Switch Ncat to using Nsock proxy system rather than it's own + built-in support. + - Move the code which is shared with ncat to nbase (URL parsing code, + for instance). + - Add socks4a/socks5 support. This requires to figure out how to + enter the nsock proxy code w/o having the target IP address. No huge + technical blocker there though, only design choices to make. + - Nping could potentially use it as well (could be useful for + measuring latency and reliability of a given proxy chain, for + example). + - Add proxy support to connect() scan. This would mean moving + connect scan to nsock. + +o [NCAT] Send one line at a time when --delay is in effect. This is + cumbersome to do until Nsock supports buffered reading. + +o [NCAT] Make the HTTP proxy support the chunked transfer encoding, + then change it to be HTTP/1.1 and support pipelining. + +o [NCAT] Drop privileges once it has started up, bound the ports it + needs to, etc. + +o [NCAT] Work as a SOCKS4a/SOCKSv5 proxy. + +o [NCAT] Resolve names through the proxy when possible. + http://seclists.org/nmap-dev/2012/q2/768 + +o [NSE] Script writing contest (something to think about) + +o We should document an official way to compile/test refguide.xml so + people can more easily test their changes to it. This will probably + involve moving legal-notices.xml into /nmap/docs, among other + things. + o Note that nping has its own /nmap/nping/docs/genmanpage.sh - we + could look at how that could apply to Nmap. + +o Move Zenmap man page from nmap/docs/ to nmap/zenmap/docs to match + the man page location for ncat and ndiff. + o Don't break packaging/build system + o Don't break the system for posting html to web site. + o Consider standardizing names for nping and ncrack man pages as well. + [Fyodor] + +o [NSE] MSRPC - Improve domain support all around -- in particular, + let the user give the domain in the format DOMAIN\username or + username@DOMAIN anywhere that usernames are accepted. Suggested + at http://seclists.org/nmap-dev/2010/q2/389 + +o [NSE] Combine similar MSRPC scripts, especially the "get info" + stuff. See this thread on combining + (http://seclists.org/nmap-dev/2010/q1/1023). This was suggested by + Ron at http://seclists.org/nmap-dev/2010/q2/389. + +o [Zenmap] Investigate getting new OS icon art. See + http://seclists.org/nmap-dev/2010/q1/1090 + +o We should probably enhance scan stats--maybe we can add a full-scan + completion time estimate? Some ideas here: + http://seclists.org/nmap-dev/2010/q1/1007 + +o [NSE] Do some benchmarking of our brute.nse. We should check the + performance with different levels of thread parallelism. Our + initial results show that it isn't helping much for vnc-brute or for + drda-brute (which is currently using the multi-thread feature + directly rather than through brute.nse library). We should figure + out why the threads aren't helping more, and whether there is + something we can do to fix it. It would also be interesting to + compare speed with Ncrack for services we have in common. + +o Start project to make Nmap a Featured Article on Wikipedia. + - See http://seclists.org/nmap-dev/2010/q1/614 + +o Add Nmap web board/forum + - First step is looking at the available software for this. + - Nmap subreddit exists: https://www.reddit.com/r/nmap + +o [Zenmap] Consider a couple ideas from Norris Carden + (http://seclists.org/nmap-dev/2010/q2/228): + - remember last save and/or open location for new saves and/or opens + - default save location option + +o [Nsock] Consider adding server support to Nsock so it can accept + multiple connections and multiplex the SD's, like it does for + clients. This could potentially be used by Ncat and Nping echo + mode. Currently Ncat server doesn't use Nsock at all, while Nping + echo mode basically polls, repeating a loop of 1s in nsock_loop + followed by a nonblocking accept(). Then Nping gives the SD's to + Nsock to manage. + +o Consider implementing both global and per-host congestion control in + the IPv6 OS detection engine. Currently it handles congestion globally + (one CWND and SSTHRESH shared by all hosts). This works fine but it + may not be the most efficient approach: if the congestion is not + in our network segment but in a target's and we are os-scanning + hosts in different networks, then all hosts get "penalized" because + there is congestion in another network, not in theirs. + +o [Nsock] Consider implementing a nsock_pcap_close() function or making + nsp_delete() call pcap_close() when pcap IODs are used. Currently valgrind + warns about a socket descriptor left opened (at least in Nping). + ==10526== at 0x62F77A7: socket (syscall-template.S:82) + ==10526== by 0x4E348A5: ??? (in /usr/lib/libpcap.so.1.0.0) + ==10526== by 0x4E36819: pcap_activate (in /usr/lib/libpcap.so.1.0.0) + ==10526== by 0x4E375FC: pcap_open_live (in /usr/lib/libpcap.so.1.0.0) + ==10526== by 0x4311A9: nsock_pcap_open (nsock_pcap.c:64) + ==10526== by 0x428078: ProbeMode::start() (ProbeMode.cc:329) + +o Consider rethinking Nmap's -s* syntax for specifing scan types + o Current problems with this -s syntax: + o We already use like 20 of the 26 letters, so we end up with + things like SCTP scan using -sY + o Can make Nmap command lines hard to read, particularly given + that we often need to improvise to find a letter which isn't + taken. + o Problematic for scan types -sI and -b which require arguments + o Inconsistencies. For example, -sC and -sV do script scan and + version detection, respectively, and yet for OS detection we use + -O. Also, control flow (-sP, -sL) is used with -s, which further + overloads the options. + o Possible solution: + o We are enabling -Pn and -sn as preferred notations for -PN and + -sP which mean "no ping" and "no port scan". Those match the + already existing -n for "no DNS". The problem with -sP is that it + implies "ping only", when what it really should mean is "disable + port scan" because you may want to do NSE, OS detection, + traceroute, etc. still. + o We might want to just give them normal option strings, so you + could do --maimon instead of -sM, for example. For extremely + common options such as SYN scan, UDP scan, version detection, we + could perhaps find good single letter options as an alias to the + longer one. + o Another idea is to use something like --scantype syn,udp,sctp, + which is a lot longer for single-type scans, but shorter when + you're combining mulitiple ones. Doesn't allow for individual + scan arguments easily. I (Fyodor) think I prefer the idea above + of just givem them top level arguments. + o If we keep -s*, we could just give it one defined function, such + as selecting port scan type, or control flow. + o Obviously this will take some discussion/brainstorming on nmap-dev. + +o Do -p- Internet UDP scans. + +o Scanning through proxies + o Nmap should be able to scan through proxy servers, particularly now + that we have an NSE script for detectiong open proxies and now that + Ncat can act as proxy client or server. + o Requirements: + o Would be nice to be able to chain through multiple proxy servers of + different types. + o Would be nice to be able to spread the load amongst multiple + proxies. + o Should support port scanning, version detection, and NSE. In + other words, nsock should support proxies. + o Support IPv4 and v6 + o Need to figure out how to get good performance. Pool of + connections to proxy or proxies for concurrency? HTTP pipelining? + o Support the different varieties of proxies: socks4, socks4a, + socks5, HTTP GET (if possible), HTTP CONNECT. Note that GET + proxies present some challenges since the error messages may not + be standard, etc. + o Maybe auto-detect the proxy type so that Nmap can try the most + efficient scanning method first? + o I've been asked to support basic, ntlm, and digest authentication + if possible. + o Implementation ideas: + o There is a patch by Zoltan Panczel (http://nmap-dev.fw.hu) and it + has been improved by Jacob Appelbaum in nmap-exp/ioerror/ . This + patch doesn't handle things like parallelization, but it may be a + good proof of concept. + o This might not be appropriate for ultra_scan ... perhaps would be + better to write a general scanning engine for abusing + applications for port scanning purposes. This could handle + scanning through proxies and the existing FTP bounce scan would + also be ported to this engine (or, frankly, we could probably get + away with removing FTP bounce). rembrandt at jpberlin.de tells me + that you can also do this with the "forwarding" commands on IMAP + servers. Whoever does this should probably start by reading the + code for the main port scanning engine (ultra_scan()) and also + the version detection code (service_scan()). And the version + detection paper at https://nmap.org/book/vscan.html. If you + understand all that, you may be ready for this project :). This + is important, because it is easy to do poorly. The tough part is + high performance and clean code which is general enough that all + these different applications can be scanned through using the + same basic engine. You should run your ideas by nmap-dev in as + much detail as possible before starting. + o David: I'm starting to think about building proxy support into + Nsock and then implementing -sT with Nsock instead of ultra_scan. + +o [Web] Consider adding training/introduction videos to the Nmap site + o Would be great to have a (5 minute or less) promotional video + introduction to each tool (Nmap, Zenmap, Ncat, Ndiff) on its web + page. + o They need to be good to be useful--the sort of the quality you see + in Laura Chappell's Wireshark videos or James Messer's Nmap videos + or Irongeek's videos (http://www.irongeek.com). + o Besides the promotional videos, users would probably enjoy more + in-depth video instructions (e.g. covering the Nmap Network + Scanning topics). + o Here's an example product page with lots of videos (we may not go + that far): http://www.splunk.com/product + +o The Zenmap translation system + (https://nmap.org/book/zenmap-lang.html) has been pretty successful + so far. We should consider doing the same for Nmap. After all, we + already have the reference guide in 16 languages at + https://nmap.org/docs.html. We should definitely try to use the same + translation methods for Zenmap as we do for Nmap. In fact, maybe we + can create a combined PO file Nmap, Zenmap, Ncat, and Ndiff so that + they can all be translated and maintained together. Something to + consider: calling setlocale can change the behavior of functions like + isalpha. Locale-dependent functions need to be checked for security + risks. + +o [NSE] Consider whether we should include some sort of NSE debugger. Or we + could include something simpler. For example, Nmap now provides a + traceback (with sufficient debugging/verbosity) when a script ends + in error. For some inspiration/ideas, look at Diman's NSE + debugger (http://seclists.org/nmap-dev/2008/q1/0228.html). + +o [NSE] Support routing http requests through proxies. + +o [NSE] Would be great if NSE scripts could be made to NOT + run as root if they don't have to. + +o [NSE] Security Review + o Consider what, if any, vulnerabilities or security risks NSE has + with respect to buffer overflows, format string bugs, any other + maliciously formatted responses from target systems, etc. Maybe + address the known risk of malicious scripts too. + o Consider that NSE runs scripts as root + +o More security auditing of Nmap code (it never hurts to do more proactive + security auditing). + +o Figure out and document (in at least the Ncat user's guide) the best + way to use Ncat for chaining through proxies. One option is this + sort of thing: + ncat -l localhost 1234 --sh-exec "ncat --proxy A.A.A.A B.B.B.B" + ncat --proxy localhost:1234 C.C.C.C + If you had two proxies A.A.A.A and B.B.B.B, connecting to C.C.C.C. + With another listener/--sh-exec pair for each additional proxy. + But perhaps we can make it easier by adding it to the syntax. + +o Look into whether we should loosen/change the global congestion + control system to address possible cases of one target host with many + dropped packets slowing down the whole group. See + http://seclists.org/nmap-dev/2008/q1/0096.html . + * Related possibility: Fix --nogcc to gracefully handle ping scans. + Right now it seems to go WAY TOO FAST (e.g. several thousand + packets per second on my DSL line). + * [12/22/09] David says: It still is in one case that I've + documented on my wiki. I had an idea to fix it, but on testing it + it didn't work. The idea was to treat the global congestion limit + differently. Instead of dropping it down to the minimum level on a + drop as is done currently, I thought about only dropping it by the + amount that the individual host limit drops. For example, if a + host had a drop and its limit fell from 25 to 1, then the global + limit would change (if it was at 100 to begin with) to 76, not all + the way down to 2 or whatever it is. The idea being that the + global limit is most important at the beginning of a scan, when + there's no information to set host limits, and every host wants to + send all its first probes at once. See + http://www.bamsoftware.com/wiki/Nmap/PerformanceNotesArchive2#global-cc. I + am convinced, though, that some sort of global control is + necessary. There's a reason that a web browser limits the number + of connections it will make, and doesn't try to download every + image file at once and count on the fairness of TCP to sort it + out. + +o libnmap organization for UNIX and Windows + o Then change Nmap and Zenmap to simply call this library + o It is interesting to look at: http://www.gnupg.org/gpgme.html + +o Deal with UDP retransmission for version detection (I think I + should just do a second run of all probes for UDP if it fails to + match anything). The advantage there is that no retransmissions are + neccessary if the service is found. Then again, per-probe + retransmission would let us redo the most likely probes (the one(s) + that match the port number) quickly. Lost packets should probably + affect ideal_parallelism. + +o Make RPM relocatable (requires somehow avoiding storing paths in the + binary) + - That may be easier now that David has made some big improvements + in detecting where the binary is cross-platform and then looking for + data files based on that location. + +o Nmaprc-related - Create a system to store Nmap defaults/preferences + in an nmaprc file. + o nmaprc should be in ~/.nmap on UNIX + o On Windows, we may need a registry key to find the .nmaprc + o Perhaps Lua could be used as the format? + o .nmaprc for keeping defaults, etc. + o Nmaprc infrastructure, hook to new timing variables + o Nmaprc man page + o Default timing mode + o Default NSE arguments, such as user agent + o Maybe Default source IP (-S) argument + o should be a way to specify your own .nmaprc + o Maybe lets you add a directory and template for saving all + scans. + o Maybe let you define "scan profiles" like is done with Zenmap. + There would then be a command-line option to select the profile used. + +o Get new Zenmap logo + o consider putting back on top-right of command constructor wizard + (there used to be umit logo there). + o Maybe that can be done after the release by soliciting ideas. + +o Create or collect some great ./configure ascii art. + +o Look at all the pcap functions, there are some like + pcap_findalldevs() which could be quite useful. There are mails to + the Nmap list relating to suggested improvements -- + http://seclists.org/lists/nmap-dev/2004/Apr-Jun/0024.html . + Actually I do indirectly use that for Windows. I wonder if they work + for UNIX? + +o perhaps each 'match' line in nmap-service-probes should have a + maximum lines, bytes, and/or time by which a response should be + available. Once that much time (or many bytes or lines) have passed, + that match can be considered 'failed' and ignored in subsequent runs. + Once all matches are considered failed, that probe is done. This + could be a useful optimization and is arguably better than the less + granular 'totalwaitms'. Or I could just have a simple function that + looks at whether a given regex could possibly match something + starting with the received data (not too hard since almost all of + the current regexes are anchored). But before doing this, I should + look long and hard at how many of the probes have every match + capable of doing this. In particular, many of the softmatch lines + don't offer many chars anchored at the front. + +o Separate nbase into its own Windows library in the same way as Andy did + with iphlpapi . + +o Nmap / Nmap-hackers FAQ + +o random tip database + |