|
The last four years of Google
Summer of Code projects were a tremendous success for
the Nmap Project and student
participants, as documented in
this Google
Open Source Blog article. So we are delighted to apply again for
2009! This innovative and extraordinarily generous program provides
$4,500 stipends to 1,000 (for 2009) university students to create or
enhance open source software during their summer break. Students get
paid, gain valuable experience and a great resume booster, and write
code which will be used by millions of people!
If you have the time and motivation, submit an application! It
doesn't even require a postage stamp. The big decision to make is
what project you wish to take on. There are many great
mentoring organizations, but our biased suggestion is the
Nmap Security Scanner. Several project ideas are suggested below, or
you can come up with your own clever project. Maybe there is a
feature that you have wanted for years, but nobody has yet stepped up
to the plate to implement it.
Applications are only accepted from March 23 through April
3. If you apply (or plan to), please join the
temporary Nmap
SoC mailing list. Also, we have
written some tips for preparing a great
application.
Note that there are some basic requirements which apply to all sponsored projects.
If you have any questions about your ideas, the best place to post them is the nmap-dev@insecure.org mailing list. You can also join the list or read the archives online. For Nmap SoC specific questions, you can mail them to the Nmap SoC list.
While we hope you apply for Nmap, you are allowed to apply to multiple organizations and doing so increases your odds (if you put enough time into each app). Many great security projects are participating in SoC this year:
Freenet (a crypto anonymity system),
Honeynet Project,
Nmap Security Scanner,
OpenSSH,
Tor (anonymizing proxy),
Umit Project,
and Xelerance (OpenSwan/DNSSec/OTR).
While you can submit a proposal for whatever cool idea your heart
desires, here are a few suggestions that would be extremely helpful to
the Nmap project and its users. These are in
no particular order.
Nmap Scripting Engine -- Infrastructure manager
In 2006, Diman Todorov worked as a GSoC student
with Fyodor to create
the Nmap Scripting Engine,
which was then integrated into Nmap. This is one of Nmap's most
powerful features, allowing users to write (and share) simple scripts
to automate a wide variety of networking tasks. For 2007 and 2008,
Diman came back as a GSoC mentor to further improve the systems,
adding features such as the NSE standard
library, Mutexes,
and the NSEDoc Reference Portal.
For 2009, we have even more ideas in mind. For example, we might want
to include NSE debugging facilities (perhaps a full-fledged debugger,
or maybe something simpler such as Patrick's traceback.nse which many
developers already use in their experimental trees). NSE could definitely benefit from some performance tuning, and we have various smaller items in the Nmap TODO list, such as adding boolean expression capabilities to the --script option. Also, we have some improvements in mind for the raw packet mode.
- NSE Debugger - We need to consider whether to include NSE
debugging facilities. For example, Diman has already written a proof
of concept debugger, or we could go with something simpler such as
Patrick's traceback.nse which many developers already use in their
experimental trees.
- Performance testing and optimization
- Bug fixing
- Boolean expression capabilities for the --script option - For example, you could specify that you want scripts in the discovery category, except those which are also in intrusive.
- Raw packet mode - We have various enhancements to this in mind.
We will probably not try to define all the tasks in advance--just the
initial tasks. That leaves us more room for spontaneity in taking
the project in new directions or coming up with and implementing great
features. For example, we will probably have at least one SoC student
spending the summer writing NSE scripts (see the next task), and he or
she might need infrastructure support to implement some of them.
Nmap Scripting Engine—Script Developer
See the previous project for a description of NSE. Now that we
have this extensible scripting system, it is time to really make use
of it! We need a talented, creative developer (we might even sponsor
several!) to help by identifying useful scripts (through research and
community input) and then implementing them. Future script developers
will surely review these scripts as examples, so this is a chance to
really set precedent and customs for readable, efficient, maintainable
scripts. The script developer(s) may identify some bugs in NSE and
likely have infrastructure suggestions for making script writing
easier or execution more efficient. Script developer will work with
the infrastructure guy (or gal!) to address these issues.
The script developer(s) will also likely write some new
libraries/modules that their scripts depend on. It is best to use
libraries for general task which many scripts might find useful,
rather than locking the code up in a single NSE script. Here are some example scripts to consider:
- Open proxy detection (we have http-open-proxy, but that currently only handles HTTP GET proxies, and does not check for SOCKS or HTTP CONNECT proxies).
- Bonjour service discovery
Zenmap (and some Ndiff) developer
While Nmap offered the NmapFE front end for many years, it was a
simple wrapper over the Nmap command-line executable and didn't
provide much extra value. In 2005 and continuing in 2006, Adriano
Monteiro Marques was sponsored by Nmap SoC to write a new,
cross-platform Nmap GUI and advanced results viewer. We eventually
incorporated it into Nmap as
the Zenmap frontend and have
been improving it ever since. The highlight of Zenmap development for
SoC 2008 was probably the
new network
topology
and scan
aggregation features.
For 2009, we have numerous new features in mind and are open to
more suggested by applicants. For example, we would like a better way
to handle Nmap Scripting
Engine script selection and argument passing. A graphical
selection dialogue would be great for people who don't have the dozens
of script names memorized! We also may want to allow people to export
topology graphs to image formats such as svg and/or png. Performance
is key too--topology graph building can be quite slow when there are
many nodes. We will probably not try to define all the tasks in
advance--just the initial tasks. That leaves us more room for
spontaneity in taking the project in new directions or coming up with
and implementing great features.
Applicants for this position must have strong Python experience.
The project may involve some work on
our Ndiff utility, which is also
written in Python. That will be a minority of the work, since Ndiff is
a much smaller and simpler program than Zenmap.
Slacker
Nmap developers are known as some of the most productive in the
open source world. In order to crank out more code, many eschew
luxuries like classes, social lives, sex, and sleep. To
counterbalance all of this planned productivity, we may need some
experienced slackers to spend the summer playing video games, watching
TV, reading Slashdot, and dating. You will report these activities in
a weekly status report so the rest of us can live our lives
vicariously through yours.
Since laziness is a virtue for this position, our normal application form is not required. Just
tell us your best time-wasting story or any other relevant credentials for this critical role.
Ncat Specialist
One of the tools we're most excited about
is Ncat, our feature-packed
reimplementation of the venerable Netcat (nc) tool. It was created by
Fyodor and SoC student Chris Gibson in 2005, then further enhanced by
Kris Katterjohn, David Fifield, and Mixter in subsequent years. It
was finally released in Nmap 4.85BETA1 in January 2009, and is
destined for the next stable Nmap release later this year. Ncat is
already working well and a big hit, but it can always use improvement.
The person taking this role will many enhancements during the
summer. Here are some examples from the current TODO list:
- When acting as an HTTP proxy, we should support GET mode as well
as CONNECT so that it works as a non-SSL proxy in browsers such as
Firefox.
- Ncat verbose mode (-v) should probably only give important
messages, such as perhaps a message once you connect successfully to a
port, or a message if the connection attempt times out. An Ncat
version banner (with URL) like Nmap has might be warranted (in verbose
mode). Currently, Ncat floods you with (mostly) useless debugging
information like this with a single -v
- Maybe we should create an SSL cert with no passphrase during Ncat
compilation or install process so that if someone specifies Ncat -l
and --ssl with no --ssl-cert and --ssl-key, we already have one for
them, and it is a slightly better one (since the private key isn't
known) than if we distributed a key. Obviously it is still subject to
MITM attacks since there is no domain validation going on. But people
who need that will have to buy a key from a certificate authority in
any case. We could create the key by using the "openssl" command line
tool as shown in
http://nmap.org/ncat/guide/ncat-advanced.html#ncat-ssl, or maybe
better to have a way for Ncat to do it using openssl calls.
Create a Better Hping
Nmap has expanded from a single tool (nmap itself), to a suite of
tools
including Nmap, Zenmap, Ncat,
and Ndiff. But we're not done
yet! We'd also like Nping, a handy utility for constructing
and sending raw packets (and interpreting any responses). For
details, see the proposed requirements
doc, and ignore the Ncat portions since that is already done. If
you apply for this one, be sure and describe your ideas in full. We
want someone who is really inspired to create a great new tool from
scratch (except that it will be utilizing Nmap's networking
libraries).
Feature Creepers and Bug Wranglers
There are many small Nmap bugs and desired features which are quite
valuable but may take only a couple days to handle rather than a whole
summer. Others may take weeks or even a month. The feature creeper
and bug wranglers handle many such tasks during the summer. This lets
them explore and contribute to a wide variety of the Nmap code base
rather than spending the whole summer working on just one subsystem.
The exact tasks won't all be itemized in advance, but here are the
sorts of things these people might be doing. You should state in the
application which of these might be a good fit for your interests and
skillset.
- Write a general scanning engine for abusing applications for port
scanning purposes. This would handle scanning through SOCKS and HTTP
proxies, and the existing FTP bounce scan would also be ported to this
engine. Proxy chaining must be supported.
- Raw IPv6 Scan Support (we currently only offer the connect()-style
TCP port scan under IPv6. Supporting the raw scans (such as SYN scan
and UDP scan) would be great.
- When high-priority bugs are discovered, bug wranglers get on the case and solve them.
- Reorganize Nmap into a C/C++ library, and then change Nmap and
Zenmap to interact with Nmap through that library. Of course Zenmap
would need some sort of Python bindings to do so.
Rather than take a specific role (bug wrangler or feature creeper),
the individual(s) sponsored for this position will do some of each.
But if you have ideas for small feature-creeping/bug-wrangling tasks,
we'd love to hear about them in your application. You can also take a look at /nmap/docs/TODO in our SVN repository for many more tasks.
Your Own Creative Idea!
Don't feel constrained to the ideas we have suggested here. If you
are very familiar with Nmap and have your own great idea for
improvement, propose it! There will be dozens of applicants for each
position listed on this page, but your suggestions have less
competition. Before writing a whole proposal, we recommend that you send
a paragraph or two describing your idea to the nmap-dev list for feedback.
Ready to apply? Great! Please visit our SoC Application Notes page for instructions.
|
