Remove todo directory as it hasn't really been used in more than 10 years and we keep these in issues DB now

This commit is contained in:
fyodor 2026-04-13 20:09:30 +00:00
parent 4a870aac73
commit 51a3d3de22
12 changed files with 0 additions and 5735 deletions

View file

@ -1,42 +0,0 @@
* Make improvements to the irc-unrealircd-backdoor script.
* Brandon says: "Sometime -sV goes just a little too fast and gets a connect
error. It should back off and try again a few times before giving up trying
to fingerprint the service." It looks like
Got nsock CONNECT response with status ERROR - aborting this service
Add a delay of 500 ms?
Summer of coder:
* Add a library function to test the randomness of a string. Use it to make
version scripts for services that send random or encrypted data, for example
cccam on port 12000 which sends 16 bytes.
Zenmap:
* Do a memory audit of loading a large scan file.
* Figure out what licensing notices are required in the Mac package for GTK+,
Glib, Python, and anything else we use.
Summer of Coder:
* Merge a scan aggregation into one XML file.
* Synthesize text Nmap output from an XML file.
Ncat:
* Make Ncat send one line at a time when --delay is in effect. This is
cumbersome to do until Nsock supports buffered reading.
* Make the HTTP proxy support the chunked transfer encoding, then change it to
be HTTP/1.1 and support pipelining.
* See if we can make Ncat drop privileges on startup.
Nsock:
* Add a buffer to each iod, so that you can ask for a certain number of bytes
or lines and get exactly that many, no more. Venkat wrote a proposal at
http://seclists.org/nmap-dev/2009/q3/0600.html.
Web site:
* Look for a good online respository viewer.
Done:
* Handle multiple targets with the same address.
* Check necessity of mswin32 pcap includes.
* Try removing the call to PacketSetReadTimeout in readip_pcap, so that Windows
uses the short 2 ms timeout like some other platforms without selectable pcap
fds do. Measure difference in time and CPU time.
* Do JavaScript magic to expand/contract NSEDoc sidebar.
* Check out compression options for the NSIS installer.

View file

@ -1,146 +0,0 @@
==
GSoC 2011 TASKS:
o Work on my GSoC vulnerability and exploitation script ideas:
https://secwiki.org/w/Nmap/Script_Ideas#Djalal_Harouni
o Review all the "Improve NSE HTTP architecture" proposal suggetions
and comments, and try to include them and update the proposal.
http://seclists.org/nmap-dev/2011/q2/967
o Start a thread on Nmap-dev about users favorite Nmap and NSE commands,
and create a special page for it in the secwiki.org site.
This will also let us to create more scan profiles for Zenmap.
==
1) Nmap Scripting Engine Infrastructure:
o [High priority]
Take a look at Dan's NSE XML output patch and try to commit it.
http://seclists.org/nmap-dev/2011/q2/1230
o NSE Version Numbering.
http://seclists.org/nmap-dev/2010/q4/693
[Other tasks]
o Propose a better duplicate scanned IPs filtering engine.
2) NSE Scripts:
[Priorities tasks]
o NFS/RPC features:
- add NFS READLINK support to let nfs-ls show symbolic files.
o Review NSE scripts and libs, and fixing bugs:
- Document all the new NFS procedures.
[Other tasks]
o NFS/RPC features:
- Add more authentication support: Unix authentication.
- NFSv4 support.
- Add recursion support to nfs-ls.nse
==
MAYBE:
o Create a new rule "versionrule" which will be used by version
category scripts.
http://seclists.org/nmap-dev/2010/q3/551
o NSE debugger.
o Add more NSE control for long running scripts: one option will be a
boolean expression filter (like: tcpdump) which will change NSE scripts
arguments or behaviour according to previous results, this will be
really useful for big networks. Another option will be a generic NSE
(Lua) script with an easy and readable code that includes expressions or
filters selection to let us change NSE arguments according to previous
results.
Note: this option will be useful on big networks. however for the moment
this is a simple idea and it needs further discussion on the nmap-dev.
o Privileges dropping for NSE scripts [nmap TODO list].
o NSE security review [nmap TODO list].
o Fixing bugs.
- NSE not honoring the source port flag when doing version scan.
http://seclists.org/nmap-dev/2010/q2/576
David said that it will not be easy to support setting the source port
http://seclists.org/nmap-dev/2010/q3/331
==
DONE:
1) Nmap Scripting Engine Infrastructure:
o Submitted the "Improve NSE HTTP architecture" proposal
http://seclists.org/nmap-dev/2011/q2/967
o Make NSE scripts able to retrieve the interface network
information.
o LuaFileSystem directory iterator [1] port.
[1] http://keplerproject.github.com/luafilesystem/
o New class of scripts which use two new script rules:
- Script Pre-scanning and Script Post-scanning rules: "prerule" and
"postrule". Documented these new phases.
- Update scripts to use these new rules:
dns-zone-transfer now uses "prerule" and "portrule".
o Update other parts of Nmap book to show the new Script scan phases.
o Fixing bugs:
- NSE not honoring the Exclude directive bug fixed and committed
as r18467.
o Let NSE "prerule", "portrule" and "hostrule" scripts to add new
discoverd targets to Nmap.
o Update scripting.xml to show the new script scan phases.
2) NSE Scripts:
o smtp-vuln-cve2011-1764 script to check Exim DKIM Format String
vulnerability (CVE-2011-1764).
o Updated and Improved ftp-vsftpd-backdoor to detect the vsFTPd backdoor
(CVE-2011-2523).
o ftp-vuln-cve2010-4221.nse script to check the ProFTPD Telnet IAC stack
overflow (CVE-2010-4221).
o smtp-vuln-cve2010-4344 script to check and exploit Exim SMTP Server:
heap overflow (CVE-2010-4344) and privileges escalation (CVE-2010-4345)
o SMTP library.
o Rewritten SMTP scripts to use the smtp library:
- smtp-commands
- smtp-open-relay
- smtp-enum-users
o smtp-vuln-cve2011-1720 script to check for CVE-2011-1720
o broadcast-avahi-dos script to check for CVE-2011-1002
o NFS/RPC features:
- New script: nfs-ls which combines nfs-dirlist and nfs-acls and try to
emulates some features of the old "ls" unix tool. The script support
NFSv2 and NFSv3.
- Readapted the RPC and NFS library code with a new re-design with new
high level functions.
- Added NFS procedures support:
NFSv2: LOOKUP
NFSv3: FSSTAT, FSINFO, READDIRPLUS, PATHCONF, ACCESS, LOOKUP

View file

@ -1,12 +0,0 @@
* Make Zenmap unit tests work. Guessing lots don't, since r32569 fixed real code
that matched some unit tests, too.
* Make sure Ndiff, Zenmap are 2to3 compatible with python -3
* Script to check for updated versions of included libs. Have shell for libpcap,
but should convert to python.
* NSE stuff
* broadcast-srvloc-info - test
* broadcast-rpcbind - write, test
* Consolidate utility functions

File diff suppressed because it is too large Load diff

View file

@ -1,66 +0,0 @@
=====
GSoC 2011 participation: Discovery and miscelaneous script specialist
=====
Work in progress:
* bgpmon-info analyze
* bittorrent-dht-nodes
* lldp - write script proposal
http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
* disjunctive-traceroute analyze feasibility
http://ccr.sigcomm.org/online/?q=node/398
=====
ToDo:
* snmp-brute port to brute framework
There are a couple of default passwords that snmp-brute uses atm which should be
considered even when it's the brute.lua is used
=====
Maybe (the ones with ** aren't on the Script_Ideas Page yet)
* Bonjour / mdns / llmnr etc.
(DNS protocols support) + backscatter into dns scripts where applicable?
* targets-asn
John Bond is working on this. It's called asn-to-prefixes. Perhaps I could
review it, asist so it makes its way to the library faster? On the other hand
there already are a couple of people assisting.
* targets-dhcp
dhcp-discover as a prerule, so it doesn't run by default. But it doesn't run by
default. It's discovery, intrusive, but not default. Maybe just add the prerule
there, and some way of forcibly initiating the prerule (like an argument).
* hnap-info
* hnap-auth-bypass
A nice hnap library would be fitting, that will make these scripts a breeze.
I'd need testing equipment, or some :S implementation.
* vuze-dht-version
* Nbstat.nse -> change to using a broadcast prerule
* SSL renegotiation
* soap.lua
* xmlrpc.lua
=====
Completed:
* broadcast-ping
* nmap lib: get_ttl() and get_payload_info()
* ip-geolocation scripts
* snmp-interfaces patch related to mac-geolocation
* mac-geolocation
* stdnse.lua: in_port_range()
* backorifice-brute
* backorifice-info
=====

View file

@ -1,41 +0,0 @@
o Proper SSL support in proxy mode.
- A naive implementation relying on the current code would probably look
horrible (at least my own attempts did). I believe that nsock should
internally be able to SSLify a plain TCP connection. It doesn't have to be
exported but it should be implemented just like the other operations. Then
it would be trivial (and clean) for the library to SSLify the channel
established by the proxy hooks.
- When redesigning nsock SSL code, keep in mind the ability to establish a SSL
session and still expose the raw TCP. That can be convenient when auditing
the SSL/TLS layer.
o Don't drop pending writes when deleting the corresponding IOD. For nsock to
behave a bit like standard BSD sockets we should flush writes on close. (OTOH
anything which isn't ack'ed has no meaning, caller can still cancel it
typically...)
o Give IODs their own methods to streamline the code and get rid of all
the special cases in nsock_core.c. This would also make it easier to
hook operations (typically: override the default iod_connect() method
to establish a proxy chain).
o Fix the read API (!)
o Profile the pcap code. It needs cleanup (for sure) and optimizations (maybe).
o Proxy authentication
o Handle socks4a
- This requires to figure out how to trigger proxy code without
resolving target hostname first. The problem is that the proxy code
is supposed to be a transparent hook of connect()... Extending the
exported API will probably be needed :(
- Async hostname resolution available from within nsock would let us
try clever tricks... I'm not sure whether nsock should provide it
or if it should simply provide an API to plug an external system.
o Socks5 support
o Some code is copied from ncat. I should move it to nbase.
o Replace event lists by more efficient data structures. Consider using
a radix tree to map event IDs to pointers. Another solution would
be to put them all into a single RB-tree (TODO: validate BSD_HACK_MODE
& stuff). Encoding the event type in the ID's MSB would let us do inorder
traversal with connect events first, then read, then write...
{NOTE: It'd be cool for the beauty of it, but my tests reveal that as of Oct.
2013 there's no big bottleneck there.}
o Rework the filespace code to avoid unneeded data copy. Scatter/gather
I/O might be useful there. Same task can also be expressed as: "profile and
optimize the usual nmap nsock I/O patterns."

View file

@ -1,638 +0,0 @@
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

View file

@ -1,799 +0,0 @@
/*****************************************************************************
* *
* o *
* o *
* o *
* o o *
* o o *
* o o *
* o o o *
* o o o *
* 888b 888 o o o *
* 8888b 888 o o o *
* 888Y88 888 o o o *
* 888Y88b 888 o *
* 888 Y88b888 o *
* 888 Y88888 *
* 888 Y8888 *
* 888 Y888 *
* *
* --[NPING TO-DO LIST]-- *
* *
*****************************************************************************/
This file contains Nping's to-do list. Items are listed in order of priority
(high priority items are listed first). Feel free to work on any of the items
on the list. However, if you'd like to work on something that is not trivial
to implement you may want to send a message to the nmap-dev list before you
start so other developers can see what you are planning to do. Make sure you
explain exactly what you are trying to fix/implement and how you are planning
to do it. It's always better to discuss bugfixes and new feature additions in
advance because they may actually have bigger implications than you think and
you may not get your patch accepted.
Please keep in mind that contributed code must:
* Be written in C++.
* Include comments so anyone can understand immediately what it does.
* Work on Linux, Mac OS and MS Windows. It's OK if you have not tested
the code in all those platforms, but at least keep portability in mind when
you write it and include a list of systems you've tested it on along with
your patch.
Questions, comments and patches should be sent to the Nmap development
mailing list (nmap-dev). To suscribe:
<https://nmap.org/mailman/listinfo/dev>
/*****************************************************************************
* Things that have NOT been done yet *
*****************************************************************************/
* Improve IPv6 support. Currently it doesn't work well. The situation should be
analyzed in detail because right now Nping has code to send packets at raw
transport level (letting the OS craft the IPv6 header), and at raw ethernet
level. None of them seems to work well, though.
* Investigate an IPv6-related core dump reported by Vasiliy Kulikov.
More info: http://seclists.org/nmap-dev/2011/q3/567
* Consider using Nmap's proto-dependant payloads for UDP packets. According
to David's tests, better results are obtained when sending UDP probes with a
payload specific to the protocol.
* Consider adding the possibility to see the RTT in the RECV line. Something
similar to the way the traditional ping tool prints the RTT (time=XXX ms)
$ ping nmap.org
PING nmap.org (173.255.243.189) 56(84) bytes of data.
64 bytes from nmap.org (173.255.243.189): icmp_req=1 ttl=48 time=169 ms
64 bytes from nmap.org (173.255.243.189): icmp_req=2 ttl=48 time=177 ms
64 bytes from nmap.org (173.255.243.189): icmp_req=3 ttl=48 time=179 ms
^C
--- nmap.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 169.097/175.137/179.152/4.347 ms
This was requested by Jacek Wielemborek. More info:
http://seclists.org/nmap-dev/2013/q3/533
* Currently, Nping determines the maximum number of open descriptors
(in TCP connect and UDP unprivileged modes), from the value returned
by libnetutil::get_max_open_descriptors(). However, it is often the
case that such function returns a value higher than FD_SETSIZE, which
is the maximum number of descriptors that select(2) can handle.
Currently Nsock uses select(2) so we have to limit the number of
descriptor to FD_SETSIZE, and not to the value returned bu
get_max_open_descriptors(). However, Henri Doreau is working on a new
nsock-engines branch which will provide Nsock engines based on
better I/O syscalls like poll() and epoll(). I've asked Henri if he
could implement a function in Nsock that provides the maximum number
of descriptors that can be handled at the same time, based on the
nsock engine being used. So, if that function gets implemented and
his nsock-engines branch merged into trunk, we should consider
updating Nping's code to use it.
More info here:
http://seclists.org/nmap-dev/2011/q4/550
* A few ideas for the Echo protocol:
- Add an authenticated NEP_BYE message, so session termination is explicit
and both ends can determine if the session was ended because the other end
requested it or if it was due to some error at the network or transport
layer. Suggested by David.
- Add examples for encryption and hmac to the RFC. This would help in
debugging implementations. Suggested by Toni Ruottu.
- RFC. Improve description of how the IVs work. Suggested by Toni Ruottu.
- RFC. Improve description of encryptionless sessions. Suggested by Toni
Ruottu.
- Currently, the echo server zeroes any application layer data before
transmission in a NEP_ECHO message. This minimizes the impact of
errors in the server's packet matching engine or malicious attacks that
attempt to trick the server into echoing packets that do not belong to
a particular user. This works well but in the future, if one day we
create a NEPv2 specification, we may want to consider extending NEP_ECHO
packets to allow stripped-packet transport. This is, to allow echo servers
to remove application layer data before transmission, and include
additional information in the NEP_ECHO message so clients can determine
that the payload part was stripped and how long was it.
- Consider making the echo server bind to all IPv4 AND IPv6 interfaces.
- Add a description of the security implications of running a public echo
server (failures in the packet matching algorithm, etc), to either the
RFC or the man page. Suggested by Toni Ruottu.
- Test the new --safe-payloads option with a packet fuzzer to make sure
the packet parser behaves correctly.
* When running Nping echo client with the --no-capture parameter, the last
packet's CAPT line is not displayed.
nping --ec public echo.nmap.org -p90 --tcp --count 1 --no-capture
luis@Aberdeen:~$ sudo nping --ec public echo.nmap.org -p90-92 --tcp --count 1 --no-capture
Starting Nping 0.5.52.IPv6.Beta2 ( https://nmap.org/nping ) at 2011-07-05 12:53 CEST
SENT (7.3302s) TCP 163.117.203.253:18554 > 74.207.244.221:90 S ttl=64
CAPT (7.4625s) TCP 163.117.203.253:18554 > 74.207.244.221:90 S ttl=54
SENT (8.3309s) TCP 163.117.203.253:18554 > 74.207.244.221:91 S ttl=64
CAPT (8.4429s) TCP 163.117.203.253:18554 > 74.207.244.221:91 S ttl=54
SENT (9.3310s) TCP 163.117.203.253:18554 > 74.207.244.221:92 S ttl=64
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (120B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)| Echoed: 2 (80B)
Tx time: 2.00181s | Tx bytes/s: 59.95 | Tx pkts/s: 1.50
Rx time: 2.00193s | Rx bytes/s: 0.00 | Rx pkts/s: 0.00
Nping done: 1 IP address pinged in 9.33 seconds
* Sometimes Nping displays a couple of error messages (related to cleanup of
Nsock events), even though everything went fine.
luis@Aberdeen:~$ sudo nping --ec public echo.nmap.org -p90 --tcp --count 1
Starting Nping 0.5.52.IPv6.Beta2 ( https://nmap.org/nping ) at 2011-07-05 12:51 CEST
SENT (1.8965s) TCP 163.117.203.253:64288 > 74.207.244.221:90 S ttl=64
CAPT (2.0293s) TCP 163.117.203.253:64288 > 74.207.244.221:90 S ttl=54
RCVD (2.1233s) TCP 74.207.244.221:90 > 163.117.203.253:64288 RA ttl=51
nping_event_handler(): READ-PCAP killed: Resource temporarily unavailable
nping_event_handler(): TIMER killed: Resource temporarily unavailable
Max rtt: 226.762ms | Min rtt: 226.762ms | Avg rtt: 226.762ms
Raw packets sent: 1 (40B) | Rcvd: 1 (40B) | Lost: 0 (0.00%)| Echoed: 1 (40B)
Tx time: 0.00136s | Tx bytes/s: 29411.76 | Tx pkts/s: 735.29
Rx time: 1.00082s | Rx bytes/s: 39.97 | Rx pkts/s: 1.00
Nping done: 1 IP address pinged in 2.93 seconds
* Investigate about warning on old version of gcc like g++ 4.1.2 20080704
(Red Hat 4.1.2-48). No warnings are shown on newer version but it would be
nice to get rid of them if possible. There are some of them:
ARPHeader.h:169: warning: class ARPHeader has virtual functions but
non-virtual destructor
RawData.h:99: warning: class RawData has virtual functions but
non-virtual destructor
* Decide more on rDNS
- Do we want to rDNS resolve all target IPs? If so, where should we
show the name? At the final report (even when just one host
scanned, which omits that line now)? In the individual packet
trace lines? When a CNAME (or a name which forward resolves but
does the IP doesn't reverse resolve) is specified on the command
line, should we use that version, or the official rDNS, if any?
- Some more discussion on this topic on nmap-dev may be warranted.
* Improve output for negative verbosity levels. Currently, one can't
even tell how many hosts replied, just how many responses were
received, which could be all from the same host. If there is only
one target, then the current behavior is fine. However, when pinging
more targets, we should be able to provide a better output; at least
how many hosts were alive. This was suggested by Dan Farmer.
* Consider adding more examples of setting fields/payloads to the man
page. This was suggested by Dan Farmer.
* Consider adding support for XML output.
* From: David Lam <david@thedavid.net>, "Some general questions about
Nping/Ncat"
In TCP traceroute mode, would it be possible to ask Nping to
stop once it gets an SYN-ACK response back from the destination host rather
than continuously hitting the host until the max TTL?
* Make broadcast ping work. Currently the following command does not
show any captured packets:
nping 192.168.0.255 --dest-mac ff:ff:ff:ff:ff:ff -c 1
The cause is probably the BPF filter, which only allows replies from
192.168.0.255.
Also, look into official multicast addresses like 224.0.0.1. Can we
received replies to that probe?
* Do some performance testing.
Fyodor:
<<Nping should be able to send packets quickly, at least comparable to
"ping -f" and hping. If it can't send as many packets per second as those,
then it warrants looking into whym figuring out what the bottlenecks are.
It would be good to compare nping with other tools such as hping in
terms of how high the values of packets per second can get and still
work reliably.>>
* Stats for ARP packets.
* Do more testing on Mac
* Support pre defined probe rates: --fast, --faster, --flood, --slow,
--slower, --paranoid...
* Think about --establish feature, which uses raw packets to establish
a connection and can then send data on the connected stream (Luis
already has a proof-of-concept implementation).
* Make privileged and unprivileged TCP/UDP mode specification consistent.
> - User is unprivileged and did not supply mode: --> Use TCP-Connect
> - User is unprivileged and supplied --tcp --> Use TCP-Connect
> - User is unprivileged and supplied --upd --> User UDP unprivileged
> - User is root and did not supply mode --> Use ICMP Echo
> - User is root and supplied --tcp --> Use raw sockets TCP
> - User is root and supplied --udp --> User raw sockets UDP
> - User is root and wants to use TCP-Connect --> User needs to either
> pass --tcp-connect or --unprivileged
> - User is root and want unprivileged UDP --> User needs to pass
> --unprivileged or --udp-XXXXX (any suggestions?. --udp-sendto() may not
> be the best idea because when we use raw sockets we also use sendto() to
> transmit the data).
* Support reverse DNS resolution in --traceroute
* Implement TCP options
* Implement hping-like ability to change the port/ttl using the keyboard
during a scan.
* Disable ARP resolution when --source-mac is specified.
* Implement --data-file option. What should we do if file is big? Read the
first X bytes? Send consecutive chunks?
* Implement ICMP address mask
* Implement entire ICMP Traceroute message opts.
* Research on default IP Identification value. Kernel does not seem to like
value 0 because when set to zero, kernel changes it to some other value. When
we set it to something !=0, the kernel leaves our value untouched.
* At some point in the future, implement weird ICMP Types. I think this would
let us make a difference to the rest of pings and packet creation tools
because anyone wanting to send weirds packes would have to download our
Nping ;-)
( http://www.iana.org/assignments/icmp-parameters )
6 Alternate Host Address [JBP]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [David Johnson]
33 IPv6 Where-Are-You [Bill Simpson]
34 IPv6 I-Am-Here [Bill Simpson]
35 Mobile Registration Request [Bill Simpson]
36 Mobile Registration Reply [Bill Simpson]
39 SKIP [Markson]
40 Photuris [RFC2521]
* Implement checks in function that handles received packets:
Fyodor:
<<You can't assume that the filter always works right, so you do need to
validate the information anyway. For example, on windows in some cases
we have to change the filter to "" because it doesn't work otherwise
so, in actuality, I often end up with rather broad pcap filters and then
do the checking by hand, but tightening the pcap filter can improve
performance a bit.>>
* Implement "-iL inputfilename (Input from list) " and the case where "-" is
supplied and target specs need to be read from stdin.
* Consider adding option to allow sending NO packets but act as a
simple sniffer. Users could use --bpf-filter to specify a
tcpdump-like filter and get every receive packet printed to
stdout. Maybe with "-c 0"? "-c none"? We need to have some flag in
NpingOps so we don't terminate Nping but wait undefinitely.
* At some point we should support nmap-like MAC specification.
* When implementing IPv6, check MAX_TCP_PAYLOAD_LEN constant and method
TCPHeader::setSum(). Because with IPv6 the max payload length should be 20
bytes less than with the IPv4 header.
* When using payloads, take into account that the IP and TCP headers may
contain options and therefore, the maximum payload len should be
65535 - 20(ip header) - 40 (ip options) -20(tcp header) -20(tcp options);
* Make sure randomnly generated checksums in IPv6-TCP/UDP are in fact invalid
and don't match the correct checksum.
* Fyodor:
<<in some cases it might be nice to have an option which sends all
probes (all ports to all hosts) at the same time.>>
* ARP mode does not support payload specification. However, users may
want to do things like appending null bytes at the end of an ARP
packet to test some device behaviour, etc. Adding support for
payload to this mode is really trivial, would make the payload spec
more consistent with the rest of the modes, and may be a nice to have
feature.
* [EM] For CAPT packets, decide if we want to print the full info or
just the fields that have changed in transit (or both). Note that
printing differences would be complicated by the fact that nping
doesn't currently associate captured packets with the original send.
* Decide if we want to allow things like "1074628148" or "0x400d8634" to
be treated as valid IP addresses.
* Check out if --ip-options "RTUS 1.1.1.1 2.2.2.2" makes sense. It now
fails.
* It may be nice to let users set the IP header lenght field. Maybe they
want to stress tcp/stacks with this.
* Investigate on ICMP preference levels. It's not clear whether there is
a standard encoding or not. The logic that parses this in Nping needs
to be reviewed.
* Split up libnetutil.cc into different source files.
* Investigate on nping's version of devname2ipaddr. Think about side
effects on using that in Nmap.
* Consider adding multi-packet support.
o Example: tell nping to send 4 tcp packets, 5 icmp packets and 3 udp packets
* Consider adding RFC-style output for send/recv packets.
* Consider adding more detailed stats for the Echo Mode.
* [EM] Handle DLT types. Currently the server always sets the null DLT value
that indicates that no data link header is included.
/*****************************************************************************
* Things that have been solved already *
*****************************************************************************/
[DONE] Add default target port for TCP-Connect and TCP modes :: Port 80
[DONE] Add default target port for UDP mode :: Port 40125
[DONE] Add default UDP Source port: 53
JUSTIFICATION: From David's EffectivenessOfPingProbes
http://www.bamsoftware.com/wiki/Nmap/EffectivenessOfPingProbes
"The best individual UDP probes are still those to a random high port,
with a source port of 53 and a non-empty payload. Even without the source
port and payload, the ports 40125 and 40126 that I picked out of the air
are better choices than the current default of 31338, finding around 400
additional hosts."
[DONE] Change resolution for the inter-ping delay. (Fyodor: btw, usleep() will
probably do the trick for you as it let's you sleep with microsecond
precision)
[DONE] Use int send_ip_packet(int sd, struct eth_nfo *eth, u8 *packet, unsigned int
packetlen) instead of ip_open();
[DONE] Add protocol to BPF filterstring because It is possible that when in TCP mode
a UDP packet destined to the TCP source, arrives to the net iface and gets
printed.
[DONE] Implement multiple port specification.
[DONE] Implement ICMP router advertisement entries
[DONE] Default probe mode: ICMP echo
[DONE] Test ICMPv4Header::addRouterAdEntry() and check entries are being added
correctly.
[DONE] Determine source IP address automatically
[DONE] Determine network interface to be used for packet capture automatically
[DONE] Add support for cached DNS requests
[DONE] Start user documentation (mainly man page)
[DONE] Change output to include timing information
[DONE] Implement controls in payload options parsing to prevent specifying lengths
that cannot be carried by a single TCP/UDP packet.
[DONE] Start implementing unprivileged UDP pings.
[DONE] When sending ICMP packets, checksum is not being computed correcly if
--data-length, and options like that, are specified.
[DONE] Find a bug that under some circumstances produces a segfault. It is probably
related to the way option -e is being handled.
[DONE] Fix a bug in option "-e iface" that results on IP 2.0.0.0 being used as a
source address.
[DONE] Update --help display to include new ICMP flags. Check also commandline syntax
docs.
[DONE] Use nsock approach instead of threads.
[DONE] Finish ARP/RARP support.
[DONE] Change doc for option --count. We don't stop after N probes, we stop after
N rounds.
[DONE] Ask Fyodor what tool is used to convert from nmap-man.xml to nmap.1
[DONE] Check all outPrint()s and outError()s to ensure they specify the correct
verbosity/debug level.
[DONE] Document format specified in ArgParser::atoICMPType().
[DONE] Document format specified in ArgParser::atoICMPCode().
[DONE] Finish implementing unprivileged UDP pings.
[DONE] Finish Ethernet frame creation.
[DONE] Find a way to convert the nping.xml into man page.
[DONE] Check what happens if payload is specified and we are not sending TCP/UDP
but ICMP or other proto packets. [Sometimes it may not make sense to include
payloads (e.g. ARP) but we still allow it just in case users want to play
around].
[DONE] Ask Fyodor whether we want to display elapsed time (like nmap) or we prefer to
display rtt time as other ping utilities do. [This is probably fine for now]
[DONE] Fix the warnings produced by Fyodor's gcc.
+---------------+
NpingTargets.cc: In member function int NpingTargets::processSpecs():
NpingTargets.cc:315: warning: comparison between signed and unsigned integer expressions
NpingTargets.cc: In member function NpingTarget* NpingTargets::getNextTarget():
NpingTargets.cc:333: warning: comparison between signed and unsigned integer expressions
+---------------+
In file included from /usr/include/string.h:640,
from nbase/nbase.h:158,
from nping.h:107,
from utils.cc:95:
In function void* memset(void*, int, size_t),
inlined from int getNetworkInterfaceName(sockaddr_storage*, char*) at utils.cc:689:
/usr/include/bits/string3.h:85: warning: call to void* __builtin___memset_chk(void*, int, long unsigned int, long unsigned int) will always overflow destination buffer
+---------------+
[DONE] Redesign verbosity levels:
* Put verbosity levels 2 into level 1
* Use level 2 for error.
* Use level 3 to print everything but not sent/rcv packets.
* Level 4 the usual
[DONE] Add stats at the end of nping execution.
[DONE] Add options to disable viewing of sent packets.
[DONE] Add option to to disable packet capture.
[DONE] Add a section to the man page explaining how we iterate over targets,
ports, etc.
[DONE] Beta-testing email to the list.
[DONE] Change default round count to 5.
[DONE] Fix a segfault detected by Fyodor in trg=o.targets.findTarget(...).
[DONE] Send an email to the list telling about the nping.exe file.
[DONE] Support CTRL-C statistics.
[DONE] Change "solution" file in mswin32/nmap.sln to nping.sln
[DONE] In man page and -h: move Ethernet section so it appears after network
layer info.
[DONE] Make rx time more accurate taking into account that we wait for a bit after
the last probe is sent.
[DONE] Fix bug: add ICMP dest unreachable, etc to the BPF filter so we can get
icmp error messages when TTLs expire, etc.
[DONE] Disable all ethernet related code when sendEth is false.
[DONE] Finish porting Nping to Windows.
[DONE] Find an OS X box to test Nping.
[DONE] Reorganize verbosity levels (again ;-) [-3, +3].
[DONE] Finish documentation for options --source-mac and --dest-mac
[DONE] Make sure --ether-type supports specifying types in hex.
[DONE] Implement verbosity level 3: in this level, sent and recv packets are
hexdumped to stdout.
[DONE] Write and check in nping/index.html web site
- Include SVN checkout/install instructions
- include tarballs when available
[DONE] Create Windows installer (maybe can copy a lot of stuff from what
Ithilgore has done with Ncrack)
[DONE] Create Nping release tarball for UNIX systems
[DONE] Release Nping 0.1BETA2
[DONE] Man page should say Nping is currently in Alpha stage.
[DONE] Support -vvv, -qqq and -ddd syntax. [Requested by Dirk Loss]
[DONE] Create Mac OS X installer (also can probably copy a lot of stuff
from what Ithilgore has done with Ncrack. David can usually help
with installer building).
[DONE] Move nping to /nping in SVN rather than being in nmap-exp
[DONE] Set up automatic conversion from nping XML man page to HTML for
https://nmap.org/nping/man.html [Fyodor working on this]
[DONE] Include signature files in new releases. [Requested by Henri Salo]
[DONE] It would be nice to have Bzip2 packages. [Requested by Henri Salo]
(These last two don't make sense anymore as Nping is now distributed
with Nmap).
[DONE] Do small fix in nmap's send_ip_packet_sd()
- res = Sendto("send_ip_packet", sd, packet, packetlen, 0,
+ res = Sendto("send_ip_packet_sd", sd, packet, packetlen, 0,
[DONE] Correct BPF filter specs, to make the condition about the source
address apply everywhere.
[DONE] Fix possible bug in BPF filter specification. More details in
http://seclists.org/nmap-dev/2010/q2/252
[DONE] Work on nping&nmap code merge.
[DONE] For options that take numbers we need to allow users to specify them
also in hex with the format 0xNNNN...
[DONE] Replace this pattern:
if ( isNumber_u32(optarg) ){
u32 aux32 = strtoul( optarg, NULL, 10);
...
}
with a function that checks for syntax and returns the value (i.e., a wrapper
around strtoul). There is nowhere that isNumber_u* is called without it being
immediately followed by a strtoul, outside of utils.cc.
[DONE] Bug in --icmp-advert-entry. Specified IPs are being set in host byte
order instead if in network byte order.
[DONE] Investigate why ARP replies are not being received. Wireshark shows
replies but they don't get captured by Nping. The bpf filter looks
ok: "arp and arp[6]==0x00 and arp[7]==0x02"
[DONE] Investigate into this:
sudo nping --icmp scanme.nmap.org -vvv -d1 --icmp-type ra --icmp-advert-entry 256.257.258.259,222
Invalid Router Advertising Entry specification: Unable to resolve 6628128
Apparently the call to outFatal() is specifying %d instead of %s, but
that's not being detected properly by the compiler, because we don't
get a warning. We have to do something like this:
void fatal(const char *fmt, ...)
__attribute__ ((noreturn))
__attribute__ ((format (printf, 1, 2)));
TODO: Look at the documentation to see what the numbers mean.
Probably one of the is the index of the format argument, and the
other is where the varargs start.
[DONE] Fix division by zero exception:
sudo nping --icmp scanme.nmap.org -vvv -d1 --icmp-type echo --rate 0
./test_nping.sh: line 83: 11690 Floating point exception"$@"
[DONE] Fix little problem in TIMING_5. We need to detect the bogus time
before we actually pass the value to NpingOps. Nping is giving an
error but the bogus input is getting to far.
[DONE] Document that badsum-ip may not always work because the kernel may
correct the sum.
[DONE] Change overloaded functions in libnetutil that were refactored to
make them compile in C. Go back to the overloaded version if possible.
[DONE] Move grab_next_host_spec() and pals to netutil.
[DONE] Control the case when user passes "--mtu 0". An assertion fails but
Nping should print a nicer message.
[DONE] Improve error message for --mtu. We should probably allow mtu's bigger
than 2^16 but take that as a "dont fragment" request. Also, make
"rand" produce only valid MTUs (multiple of 8, etc).
[DONE] When passing "--tcp-flags 0x100" the error is not very accurate.
This is because parser_u8() fails and then Nping tries to resolve the
value letter by letter. Maybe we can parse_u32() it, and then check
if n<255 and print a better error message.
[DONE] Document what happens with the IP header length when user wants to
add uneven bytes of IP options. We are truncating the result, because
the header length is expressed in 32 bit words.
[DONE] Check if there is any problem with -e "". Maybe we shouldn't let users
supply a NULL name, but make them use the "any" specifier. Add doc
about this and update the test description (MISC_12).
[DONE] Update documentation for option --delay, including that now, time
specification as float numbers is supported (eg: --delay 0.1 meaning 100ms)
[DONE] Change info about TODO file in https://nmap.org/nping web page.
- If you wish to contribute code to Nping there is a TO-DO list you can have
- a look at (file "TODO" in the source package).
+ If you wish to contribute code to Nping there is a TO-DO list you can have
+ a look at (file "todo/nping.txt" in nmap's source package).
[DONE] Make sure randomnly generated checksums are in fact invalid and don't match
the correct checksum. There is a 1/65535 chance of this happening.
[DONE] After merging nmap-dedup, change send_frag_ip_packet() to take "u32 mtu"
and fix the printf below to use "%u" instead of "%i".
[DONE] [EM] Update EchoProtoRFC.txt and any of the other design files as
appropriate and send to nmap-dev for comments
[DONE] [EM] Pick a default port number
[DONE] [EM] Make a mockup of the desired standard output in a regular echo mode
execution, like nping -c 2 --tcp --flags SYN -p 80 scanme.nmap.org (let's
assume there are some differences found, like a NAT is in place)
o A key aspect of this task is determining what diffs are going
to look like.
[DONE] [EM] Things to decide on:
o Decide on packet specifiers that can be passed to the server so it
can recognize packets sent by the client even if a number of headers
have changed and pass them back. (see Fyodor/Luis IM discussion logs
from 6/28/10).
[DONE] [EM] Improve client error handling. Currently it doesn't behave well when
the server crashes.
[DONE] [EM] Make the client timeout if the server does not send data during
handshake. Currently the client waits forever.
[DONE] [EM] Make the server detect when a client disconnects and delete its context
data.
[DONE] [EM] Get rid of some messages that are currently displayed in the client.
Print them only if debugging level is high enough.
[DONE] [EM] Make sure -h help screen includes info about the echo mode.
[DONE] [EM] Add echo mode to the man page.
[DONE] [EM] Add received echoed packet to the final statistics.
[DONE] [EM] Multi-client support
[DONE] [EM] Delay RECV message printing so the CAPT messages are shown in order.
[DONE] [EM] Use NEP_QUIT only if necessary, just close connection if possible.
[DONE] [EM] Implement crypto
[DONE] [EM] Consider whether the CAPT line should (or should have an
option to) display the time based on capture time from the server.
Obviously this can be problematic because not all machines run
ntpd. One option is to just make it an option so that people should
only use it if both the client and server are running ntpd. Luis is
adding a precision timestamp to NEP_ECHO packets so we could easily
add it in the future. Another approach would be to do NTP-style
handshaking to compute time offsets between the two machines during
the echo side-channel handshaking. Then the client could remember
how far off it is. A third approach is to guess about the CAPT time
that it was 1/2 the time between packet send and when we received
the NEP_ECHO back notifying us of receipt.
NOTE: We finally decided to take the third approach. CAPT_time=RTT/2.
[DONE] [EM] Consider whether we should delay RCVD packet printing
slightly so that CAPT packets received just slightly afterward could
be printed before the RCVD. This might make the most sense if we do
the previous feature where we show the time that a packet was
actually captured by echo server. If we did it in normal cases, it
might make it easier to compare SENT and CAPT packets, but would
also be a bit strange to see the timeline out-of-order.
[DONE] Fix Windows rtt values. Right now Nsock does not seem to be giving
the callback at the proper time, or something.
[DONE] Add --no-crypto to -h output.
[DONE] Make sure nping does not allow generating packets with tcp src port or
tcp dst port 9929 (or --echo-port N, if that is set), because 1) the
echo server does not capture those packets and 2) to avoid messing up the
established side-channel tcp connection.
[DONE] Add support for custom IP binding: if user supplies -S then
the echo side-channel connection and connections in TCP-Connect mode should be
established from that IP. This includes the echo server binding to that IP.
[DONE] Make nping issue a warning when user supplies a payload in TCP-Connect
mode.
[DONE] [EM] Echo server should print which interface is using to capture packets.
[DONE] In some cases, when using nping through a VPN connection, nsi_pcap_linktype()
returns something different to DLT_EN10MB, and Nping fatals. Investigate
why this happens to nping and is not a problem for Nmap. Also, determine
why this doesn't happen all the time. What does it change between these
two?: sudo nping --udp 1.1.1.1 -g 999 -p998
sudo nping --udp 1.1.1.1 -g 999 -p999
The first one works, and the other one fatals with the "Currently only
Ethernet is supported." (error message @ nping.cc:1717).
- Note this also happens when Fyodor uses Nping tethering through
his cell phone (ppp0)
[DONE] [EM] Make the server stop capturing packets when all connected clients
finish their session.
[DONE] [EM] Some things to keep in mind for the implementation and to update
our design docs accordingly:
o Implement different "modes" for the server: complete access,
one-time-access, and restricted.
[DONE] Do more testing on MS Windows.
[DONE] [EM] Investigate why the echo server does not send NEP_ECHO messages when the
client sends probes at a very high rate, like in :
./nping -c 1000 --rate 1000 --echo-client "pass" --icmp -v echo.nmap.org
[DONE] [EM] Add echo mode to the man page
[DONE] [EM] Do some extensive testing of the Echo mode once it is working
to try and flesh out any bugs before merging.
[DONE] Make Nping call nsi_delete() on pcap IODs, IODs in TCP-Connect mode and maybe
in IODs of other modes. See http://seclists.org/nmap-dev/2010/q3/587
[DONE] Fix bug that causes Nping to fail when sending UDP packets to a broadcast
address. More info: <http://seclists.org/nmap-dev/2010/q3/752>
[DONE] When doing ICMP echo traceroute (with --traceroute), unless the user
supplies a custom round count (-c/--count), Nping only sends 5 packets
(default round count). This is usually not enough to reach hosts
on the internet. What should be the default behaviour? Stick with the
default round count of 5 or increment it when --traceroute is set?
- We should probably set -c 32 when --traceroute is specified,
unless user specifies their own -c explicitly.
[DONE] Try to reduce the size of the internal buffer in the EchoHeader class.
Currenltly it allocates a big buffer that is able to hold the theoretical
maximum size of a NEP message (normal use does not require so much space).
When this is done, check if we still need to increase the stack size
in the project properties in Visual Studio.
[DONE] [Fixed by Vasiliy Kulikov] When running Nping in ARP mode, hexdump of
ARP replies is not shown with -vvv, only for requests. Here's the output:
sudo nping --arp 192.168.240.139 -vvv -d1
Starting Nping 0.5.59BETA1 ( https://nmap.org/nping ) at 2011-07-11 12:32 CEST
BPF-filter: arp and arp[6]==0x00 and arp[7]==0x02
SENT (0.0562s) ARP who has 192.168.240.139? Tell 192.168.240.1
0000 ff ff ff ff ff ff 00 50 56 c0 00 01 08 06 00 01 .......PV.......
0010 08 00 06 04 00 01 00 50 56 c0 00 01 c0 a8 f0 01 .......PV.......
0020 00 00 00 00 00 00 c0 a8 f0 8b ..........
RCVD (0.0568s) ARP reply 192.168.240.139 is at 00:0C:29:E4:90:CD
SENT (1.0580s) ARP who has 192.168.240.139? Tell 192.168.240.1
0000 ff ff ff ff ff ff 00 50 56 c0 00 01 08 06 00 01 .......PV.......
0010 08 00 06 04 00 01 00 50 56 c0 00 01 c0 a8 f0 01 .......PV.......
0020 00 00 00 00 00 00 c0 a8 f0 8b ..........

View file

@ -1,77 +0,0 @@
===
Currently working on:
-- LPEG in NSE.
-- HTTP Library in LPeg.
===
Maybe:
-- NSE Debugger. Look at Diman's implementation:
http://seclists.org/nmap-dev/2008/q1/0228.html
http://www.keplerproject.org/remdebug/
-- Review NSE Nsock Socket Allocation:
o Dynamically increase socket slots if nothing has been done
in the last ~5 seconds. Also decrease once traffic is working again.
This resolves any sort of socket deadlock.
-- Deadlock identification and correction:
o Add detection for deadlocks and print which threads are involved.
o use above results to make a strategy for automatic deadlock resolution.
-- Look into moving Packet Module to C.
===
Done:
-- Review and Improve NSE Nsock Library.
o Move away from C pointer references and allocation over to Lua.
If a function ends in error, all the userdata will be collected.
We would otherwise need to use pcalls everywhere to clean up
and free malloc()'d memory.
o Use thread calling nsock_loop (or currently running thread)
for restoring waiting threads to the running queue.
Making a function call on a yielded thread is a hack and
could cause problems in the future.
o Get rid of the static nsock_pool and use a dynamically allocated
structure on a per-host-group basis.
o Prepare for Lua 5.2 --> Change to real errors.
-- Update NSE Book Implementation Section.
-- Added boolean operator patch.
-- Update NSE --script section (book) to include Boolean operators.
-- Fix ceil for runlevels.
-- Solve Brandon's Segfault for thread's sockets and close them when
the thread ends.
-- Change the error on finding the name of a nonexistent file in script.db
into a non-fatal warning.
-- Correct nsock_connect to unlock the socket slot if the connection fails.
-- Remove packet.hextobin and packet.bintohex. Fix scripts that used them
to instead use bin.(un)pack.
-- Commit --script-args patch and update the relevant section in the book.
-- Deadlock identification and correction:
o Release mutexes upon script death.
-- Review NSE Nsock Socket Allocation:
o Release socket locks on connection failure or timeout.
o Track active sockets in the nsock library and don't rely on
garbage collection for reallocation.
-- HTTP Caching:
o Add ability to use a proxy to http.lua.
o Test http.lua performance using local caching proxy.
o Implement a cache in http.lua.

View file

@ -1,4 +0,0 @@
TODO:
-Update wiki page.
-Fix: http-enum does not work on windows. UNIX paths are hardcoded into the script. It also fails when running from a directory with spaces in the name.

View file

@ -1,49 +0,0 @@
TODO.sctp $Id$ -*-text-*-
o Further investigate SCTP functionality, as some people reported
problems (see this thread:
http://seclists.org/nmap-dev/2009/q2/0669.html)
o Add support for UDP encapsulated SCTP (9899/udp).
Basically just wrap the SCTP packets into a UDP packet.
Think about how to add support for this to libdnet first.
See this Internet Draft by Michael Tuexen for the specs:
http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps
This is actually quite a challenging task due to the
current architecture of the scan engine. How to best
differentiate a UDP packet related to a UDP scan from a
UDP wrapped SCTP packet? How to unpack the UDP wrapped
SCTP packet in order not to duplicate a lot of code?
A good solution will be non-trivial.
o Verify ICMP response handling for SCTP. Make sure all
ICMP types are handled in an optimal way (esp. destination
unreachable: protocol unreachable).
o Consider removing 9899/sctp from the default port list.
9899/udp is used for UDP encapsulated SCTP. One reason
to keep 9899/sctp is likely misconfigurations.
o Investigate whether it makes sense to store scan state in
the itag/itsn fields for INIT scans.
o Investigate the suitability of other SCTP chunks for port
scanning and implement more scan types if they turn out to
be worthwhile. One unverified idea is to experiment with
undefined chunk types and their first two magic bits to
provoke ERROR responses.
o Add SCTP based service probing.
o [Ncat] Consider implementing SCTP broker mode.
o [NSE] Add SCTP support to NSE.
o Investigate on differences between SCTP stacks and
implement SCTP based OS detection probes based on the
results. For example, BSD systems send the ASCII string
KAME-BSD in INIT-ACK chunks.
o SCTP-enable scanme.nmap.org in order to make scanme.roe.ch
obsolete.

View file

@ -1,150 +0,0 @@
In progress:
============
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).
Hanging(waiting for further input, etc..):
==========================================
o Nmap *poor's man* test suite by expanding on what I already have in
/nmap-exp/shinnok/nmap-test-script.
o NMAP reports different service results every so often with the same port.
http://seclists.org/nmap-dev/2011/q2/815
o Review latest revision of Marek's ncat_proxy.patch - DONE
http://seclists.org/nmap-dev/2011/q2/573
o Commit approval pending
Pending:
========
Pending (low priority):
=======================
o E-mail nmap-dev with GProfiles /ncrack
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.
Potential:
==========
COMPLETED:
==========
o Add a --append-output option to ncat. [DONE - r25737]
o libpcre/pcre.h - is cleared upon make distclean thus leaving the SVN
working directory dirty
http://seclists.org/nmap-dev/2011/q2/708
o De-duplicate code by unifying ncat_broker.c and ncat_listen.c code paths,
either as a single file in ncat_listen.c or merge duplicate code in
ncat_listen.c and keep only broker specific code in ncat_broker.c(it it's a
lot of code, otherwise ncat_listen.c would do just fine).
o Nmap should defer address parsing in arguments until it has read
through all the args. Otherwise you get an error if you use like -S
with an IPv6 address before you put -6 in the command line. You
get a similar problem (on David's IPv6 branch) if you do "-A -6"
(but "-6 -A works properly).
o Delve into Lua and NSE and try to write some scripts to get the hang
of it and gain a better understanding of the NSE engine in Nmap.
o Written two NSE scripts, http-reverse-ip and http-google-email that
can be found in /nmap-exp/shinnok/nse.
o E-mail nmap-dev with QtCreator usage steps for Nmap
--
o Ncat hangs on ssl -> REFACTORING
some refactoring left to be done to reduce code duplication
http://seclists.org/nmap-dev/2011/q2/842
o Commit current switch/ifdef refactoring patch.
o Research code deduplication even further.
o Ncat chat (at least in ssl mode) no longer gives the banner greeting
when I connect. This worked in r23918, but not in r24185, which is
the one running on chat.nmap.org as of 6/20/11. Verify by running
"ncat --ssl -v chat.nmap.org"
o Pending uncompleted SSL handshakes when in --exec* listening mode make
Ncat consume 100% cpu(core/thread).
Possible solutions:
o Listen on the union of the two sets in ncat_listen.c composed of the
current set and a secondary one, ssl_pending which should include the
pending ssl hanshake sockets.
o Timeout ssl handshakes.
o Delay adding the exec output pipes to fselect/WaitForMultipleObjects
until the ssl handshake has been completed.
http://seclists.org/nmap-dev/2011/q2/988
---
o Fix ncat.xml(the input for the man page) examples section. - David came up
with the final right fix on this one.
o Ncat should close its socket and refuse further connections after the first
one, if invoked without --keep-open. That's what traditional netcat does
too. - DONE [r24197]
http://seclists.org/nmap-dev/2011/q2/944
o Add TEST in ncat-test.pl - DONE [r24373]
o Closing Zenmap without stopping the scan first will leave nmap running in
the process list on Windows. [r24308]
[Actually, Zenmap was unable to kill the nmap scan processes at all on
Windows]
o Zenmap should wait for the return exit code of the nmap scanning subprocess
upon killing it(canceled scan), otherwise the subprocesses will enter a
defunct(zombie) state.[r24235]
o Fix build_icmp_raw and build_igmp_raw filling the packet data payload
with zeroes instead of the supplied random data, when nmap is invoked
with --data-length.[r24127]
o Investigate and document how easy it is to drop Ncat.exe by itself
on other systems and have it work. [r24242]
http://seclists.org/nmap-dev/2011/q2/1090
o We should also look into the dependencies of Nmap and Zenmap.
It may be instructive to look at "Portable Firefox"
(http://portableapps.com/apps/internet/firefox_portable) which is
built using open source technology from portableapps.com, or look at
"The Network Toolkit" by Cace
(http://www.cacetech.com/products/network_toolkit.html).
o --max-conns is broken in latest svn -> fixed in r24130, other two
bugs discovered:
o --max-conns 0 kills ncat with a glibc assertion error on calloc with
zero as nmemb(??) at:
init_fdlist(&broadcast_fdlist, o.conn_limit);
o When killing the first initiated connection on --max-conns > 1 Ncat:
Ncat: Program bug: fd (5) not on list. QUITTING.
[DONE]The previous two bugs were introduced in r24130, they are now fixed
in r24193.