From 2be2722f2642554eb2942c6e0a94e76bd6488020 Mon Sep 17 00:00:00 2001 From: fyodor Date: Wed, 22 Sep 2010 00:03:42 +0000 Subject: [PATCH] changes from chat w/David --- todo/nmap.txt | 77 ++++++++++++++++++++++++++------------------------- 1 file changed, 39 insertions(+), 38 deletions(-) diff --git a/todo/nmap.txt b/todo/nmap.txt index f4b8ff7d5..0827b577a 100644 --- a/todo/nmap.txt +++ b/todo/nmap.txt @@ -1,27 +1,20 @@ TODO $Id: TODO 11866 2009-01-24 23:10:05Z fyodor $ -*-text-*- -o [NSE] Maybe we should create a script which checks once a day - whether similar tools (Metasploit, Nessus, OpenVAS, etc.) have any - new modules, and then mails out a list of them with the description - fields. The mail could go to just interested parties, or maybe - nmap-dev. This may help prevent important vulnerabilities from - falling through the cracks. Perhaps we would include new NSEs in - there too, especially if we open it up as a public list. - o [NSE] Review scripts: o Hostmap (Ange Gutek) - http://seclists.org/nmap-dev/2010/q3/60 o [Zenmap] Add a button to select script files from the filesystem. -o [Zenmap] Show help for individual script arguments in the Help pane, - not for all arguments at once. - o Process Nmap survey and send out results [Fyodor] o [Web] Add a page with the Nmap related videos we do have already o Post BH/Defcon Nmap videos +o Do new Nmap release with the stuff merged from SoC students and + other new developments. + - Need to have our SoC successes writeup for 2010 posted first. + o Write and post 2010 SoC Successes writeup [Fyodor] o Make new SecTools.Org site with the 2010 survey results. @@ -48,26 +41,6 @@ o Revive the Nmap Public Source License project (need to find an open o Also take close look at Mozilla's license modernization project: http://mpl.mozilla.org/scope/ -o [Zenmap] Consider a memory usage audit. This thread includes a claim - that a 4,094 host scan can take up 800MB+ of memory in Zenmap: - http://seclists.org/nmap-dev/2010/q1/1127 - The reporter mentioned Guppy/Heapy to debug memory use: - http://guppy-pe.sourceforge.net/ - http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst. Many - Nmap survey respondants complained about this too. - Note: Fyodor has a 50MB scan log file named ms-vscan.xml which - demonstrates this problem. When trying to load the file, Zenmap - grows to 1150MB of RAM, pegs the CPU usage at 100% for many - minutes or maybe hours (I forgot about it, but woke up the next day - to find that it had started, was then using 2.4GB of RAM. The - hosts/services functionality seemed to work, although it would take - a minute or so to switch from say "ftp" port to view "ssh" ports. - - -o Do new Nmap release with the stuff merged from SoC students and - other new developments. - - Need to have our SoC successes writeup for 2010 posted first. - o [NSE] We should probably enable broadcast scripts to work better by (initial thoughts): 1) Change NSE to always set nsp_setbroadcast() on new sockets @@ -79,13 +52,6 @@ o [NSE] We should probably enable broadcast scripts to work better by o [NSE] Our http-brute should probably support form POST method rather than just GET because some forms require that. -o Since Libdnet files (such as ltmain.sh) are apparently only used by - libdnet (they used to be used by shared library NSE C scripts), we - should move them to the libdnet directory. - -o Upgrade our Windows OpenSSL binaries from version 0.9.8j to the - newest version (1.0.0a as of Aug 12, 2010). - o Add raw packet IPv6 support, initially for SYN scan o After that can add UDP scan, and sometime OS detection (David did some research on what IPv6 OS detection might require). @@ -730,6 +696,41 @@ o random tip database DONE: +o [Zenmap] Show help for individual script arguments in the Help pane, + not for all arguments at once. + +o Upgrade our Windows OpenSSL binaries from version 0.9.8j to the + newest version (1.0.0a as of Aug 12, 2010). + +o Since Libdnet files (such as ltmain.sh) are apparently only used by + libdnet (they used to be used by shared library NSE C scripts), we + should move them to the libdnet directory. + o Turned out to be a pain. See + http://seclists.org/nmap-dev/2010/q3/733 + +o [Zenmap] Consider a memory usage audit. This thread includes a claim + that a 4,094 host scan can take up 800MB+ of memory in Zenmap: + http://seclists.org/nmap-dev/2010/q1/1127 + The reporter mentioned Guppy/Heapy to debug memory use: + http://guppy-pe.sourceforge.net/ + http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst. Many + Nmap survey respondants complained about this too. + Note: Fyodor has a 50MB scan log file named ms-vscan.xml which + demonstrates this problem. When trying to load the file, Zenmap + grows to 1150MB of RAM, pegs the CPU usage at 100% for many + minutes or maybe hours (I forgot about it, but woke up the next day + to find that it had started, was then using 2.4GB of RAM. The + hosts/services functionality seemed to work, although it would take + a minute or so to switch from say "ftp" port to view "ssh" ports. + +o [NSE] Maybe we should create a script which checks once a day + whether similar tools (Metasploit, Nessus, OpenVAS, etc.) have any + new modules, and then mails out a list of them with the description + fields. The mail could go to just interested parties, or maybe + nmap-dev. This may help prevent important vulnerabilities from + falling through the cracks. Perhaps we would include new NSEs in + there too, especially if we open it up as a public list. + o Now that NSE has more script phases (prerule, postrule, hostrule, portrule, and versionrule soon to come), the NSEDoc should specify which phases a script belongs to.