CERBERUS/nmap
1
0
Fork 0
mirror of https://github.com/nmap/nmap.git synced 2026-10-21 19:32:18 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

changes from chat w/David

Browse source
This commit is contained in:
fyodor 2010-09-22 00:03:42 +00:00
parent 31fbab7eba
commit 2be2722f26
1 changed files with 39 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

77
todo/nmap.txt
View file

@ -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.