Subject: Patch - Nmap Dev - msg#00100

Previous Message by Date: click to view message preview

Re: Another important feature

digmet wrote: > Hello, Vipe. > > Saturday, June 11, 2005, 7:49:12 PM, you wrote: > VF> I can support Russian and Ukrainian translations > > I can support Russian too. > I'll do Swedish. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Lead Developer _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev

Next Message by Date: click to view message preview

New Nmap GUI and Results Browser Requirements Doc

The Google Summer of Code application deadline (Tuesday) is fast approaching, so I decided to write up this requirements/suggestions document specifying what I think the new GUI should offer. Of course there are other SoC projects which will probably be sponsored, but the GUI attracted the most interest and is the most open ended. And it is still not too late to apply if you are a university student (see http://www.insecure.org/nmap/GoogleGrants.html ). This is a huge list to accomplish in 10 weeks. But some of the applicants seem quite skilled and motivated. Still, it will be a major challenge and huge accomplishment. If applicants think it is too hard, let me know and we may be able to pare it down for your application. If you think it is too easy, that is no problem as there is always room for you to do more or add finishing touches. Or if you somehow create a great GUI meeting all these requirements in 7 weeks, then you deserve to sit on your butt with a Playstation 2 for the remaining 3 :). We will also probably sponsor 2 or 3 developers to work on independent GUIs (Google doesn't allow teams to work together). At the project end (Sept. 1), perhaps the best features of each could be combined. Or maybe one will be vastly superior to the others and can be used as the default Nmap GUI. Or, maybe they will both be useful to different sets of people, serving different niches. The development will be done in the open on a site such as Sourceforge, and nmap-dev people are allowed (and encouraged) to help them test, contribute patches, etc. A new GUI would be a great boost to the project. This GUI will do a lot more than simply execute Nmap and show the unparsed results in a Window -- that only helps newbies. Read the specs below and you'll see a lot of features designed for advanced users scanning huge networks. Probably 80% of work will be in the results viewer/parser, making the "nmap execution" part relatively easy. I do want to emphasize that this is NOT intended as a replacement for the beloved command-line version of Nmap. So no need to get defensive about it, as some recent nmap-dev mails were :). Heck, the app will work by executing the command-line version. Even if the app turns out to be everything I want it to be, I'll still use the command-line version for most of my scanning. But it is nice that other people have the option to use the GUI for executing Nmap. And the results viewer aspect (which, again, is most of the work), could be very useful even for the command line gearheads. If you guys think of other important features/requirements for this document, of feel it should be changed in other ways, let me know. Labels such as "should" or "would be nice" denote optional features, while "musts" have to be met. Here are the proposed features and infrastructure requirements for the new Nmap GUI and results viewer: REQUIRED FEATURES: o Must be able to execute Nmap and read the XML output, and also be able to parse existing XML files. Must be able to save Nmap results to an XML file, even after Nmap runs. Would be nice to save in other formats as well, such as normal output and HTML. Maybe an option to store in a DB. Input from Nmap "normal output" would be nice as well. o Must support all significant Nmap options, and in a well-organized way (probably multiple tabs or panels) o Must show Nmap command line as it is being built through options dialogues. o Must support interactive display of results which easily allow any of the following after scan is run (or after previous-scan XML file loaded): o Show details (open ports, os, etc.) for a certain host by typing in IP or hostname, or by browsing to it in results window. o Show all machines with a certain port number or service name listening. If a service name is selected o Show all found instances of a certain application, via version detection results. must allow a regular expression match of the version, product, and extrainfo fields. Nmap already includes libpcre for portable perl-style regexp support. o Sort results by open port number or service name (this would just be a big table of open (or, perhaps open|filtered) ports, with columns for IP address, port number, service, maybe the host OS, etc. Obviously sorted by port number or service name, as requested. o Sort all results by IP address o After you load an XML (say from the "recent scans" menu item or just from file browsing), or even when you are viewing results from a just-done scan, there should be a "repeat this scan" option to let you run the same scan again. Maybe the best way to do this is to check the relevant options for the command used when the user loads an XML (or keep them when the user performs a scan). Then repeating the scan is just a matter of pressing "scan" again. For example, you might want to scan your new server, disable some stupid services in an ssh window, then repeat the scan to ensure that the ports are now closed. This should be easy. The solution of setting/preserving options when XML is loaded or Nmap is run may solve the "named profile" item below as well. o Might be nice if you can create and store named profiles, such as "full scan of chicago division", "ipv6 check", "arp scan of local net", etc. o Must have a graphical paperclip or other mascott which provides advice and suggestions as you plan your scan. Like this one: http://www.counterhack.net/base_clippy_image.html . OK, maybe not :). o Must be able to show small icons for operating systems and/or device type and known services. These must be stored in such a way that they are easy to change, and there must be a default for unknown services/systems. o Must be able to store persistant state (probably in a file for portability reasons). This could hold stuff such as preferences, recent scan information (XML file location, options used, etc.) o Must support all of the major Nmap output information (port states, os detection, version detection, uptime, mac address, etc.) o Must support Nmap timing estimates for progress bars and such. This will probably require adding that support to the XML output (I don't think it is there yet), or parsing Nmap "normal" output. Or maybe you could just show normal output while the scan proceeds, then switch to parsed mode when it completes. o Must be able to compare 2 scans (show the new/removed/changed hosts/ports) o Would be nice to be able to load multiple files into the results view, e.g. if you have one scan file for each subnet. The results would be merged, and it would be OK to have rules like only showing the 1st results of a given host (if that is found in subsequent files, you could ignore those instances of it). o Should have a big red "hack this server" button which uses AI and a cache of 0-day exploits to identify weaknesses, create and launch exploit code, then deface the web site with a poorly spelled self-aggrandizing rant about how lazy and stupid the syadamin must be and how 'l33t the Nmap user is. It should automatically report the defacement to Zone-H and the other archives :). o Must be fully documented in a man page and HTML. One good option is to write the docs in Docbook XML and then use automated conversion to get man page (nroff) and html. Or you could write the nroff directly and convert to html. Or write separate HTML and man pages. HTML generated from a non-text source (Word, Dreamweaver, Frongpage, etc.) is unacceptable unless you have a rare tool that produces readable and concise HTML. Interactive help in the application may be nice too. At the bare minimum, it should at least have a help button/menu that points users to the help web page or man page. o Must allow annotations (text strings) to be made to hosts and ports. These are saved in the XML (and/or other formats like HTML if offered) file when the user does a save option. User is prompted to save if NmapFE is closed when annotations have been added/changed since last save. User can search for these annotations in the GUI, or have the displayed in the relevant port tables, etc. o Must provide overall stats for loaded results, such as number of hosts scanned, number of hosts online, number of ports in each state (open, closed, filtered, etc.) o Should have a non-proprietary installer for Windows which handles file installation, windows registry changes, uninstall, etc. o Generally intuitive, aesthetically pleasing, well organized, stable, fast, etc. Of course, these are mostly subjective goals, but they are still important. INFRASTRUCTURE REQUIREMENTS: o Must support and be tested under Linux, Mac OS X, and Windows. There should be no barrier towards supporting other systems such as Free/Net/OpenBSD and Solaris, though no need to test on all of those initially. That is what users are for :). o Must be done in Python, C/C++, or Perl. Tcl/Tk is probably OK too. No Java or .Net. This may be the most controversial policy, but there are two important reasons for it: o I really believe the project will have trouble catching on if a java interpretor or .net infrastructure are required. Python/Perl/Tcl are small enough that the interpreter can basically be shipped with the binary. o A great front end deserves to be maintained long after the Summer of Code project ends. While it is great if the author steps forward to continue maintance, they may be unable/unwilling to do so at some point. Many Nmap front ends have been abandoned for these reasons, and sometimes I end up maintaining them (e.g. my maintenance of NmapFE and long-time hosting of Nmapwin). I am unwilling to maintain a Java or .Net project. o Must not be done with Glade, QTDesigner, or similar GUI code creation tool. The code they produce is just too ugly, and often inflexible. o Must limit the number of external libraries/programs it depends on. Anything that ships with Nmap is OK, and you'll probably need a graphical widget library such as GTK or QT and an XML parser, but don't go overboard in adding a bunch of new dependencies. It must not require DB libraries or installation of a database (though that is OK as an option). o Development must be done in the open, hosted on a project server such as Sourceforge. Test versions and such should be sent to the nmap-dev list (just send links, not the binaries themselves). That is a good list for bouncing ideas around too. Cheers, Fyodor _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev

Previous Message by Thread: click to view message preview

Re: Raw sockets, MS05-019 and Windows Firewall -- Summary

Thanks for all the valuable information that you posted. I remember I was able to use nmap before in Windows but after a few updates by Microsoft now it doesn't work anymore. After reading your post I uninstalled the MS05-019 patch, rebooted, and tried running nmap again. However it still did not work. The personal firewall is turned off. I was wondering did any of the other patches also cause nmap to break? I have only microsoft service pack 1 installed, not sp2. However some of the hotfixes that I received from the microsoft update were also called sp2 hotfixes even though sp2 isn't installed. Any help to get nmap working would be appreciated. Thanks again for all the hard work! Aeris __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev

Next Message by Thread: click to view message preview

New Nmap GUI and Results Browser Requirements Doc

The Google Summer of Code application deadline (Tuesday) is fast approaching, so I decided to write up this requirements/suggestions document specifying what I think the new GUI should offer. Of course there are other SoC projects which will probably be sponsored, but the GUI attracted the most interest and is the most open ended. And it is still not too late to apply if you are a university student (see http://www.insecure.org/nmap/GoogleGrants.html ). This is a huge list to accomplish in 10 weeks. But some of the applicants seem quite skilled and motivated. Still, it will be a major challenge and huge accomplishment. If applicants think it is too hard, let me know and we may be able to pare it down for your application. If you think it is too easy, that is no problem as there is always room for you to do more or add finishing touches. Or if you somehow create a great GUI meeting all these requirements in 7 weeks, then you deserve to sit on your butt with a Playstation 2 for the remaining 3 :). We will also probably sponsor 2 or 3 developers to work on independent GUIs (Google doesn't allow teams to work together). At the project end (Sept. 1), perhaps the best features of each could be combined. Or maybe one will be vastly superior to the others and can be used as the default Nmap GUI. Or, maybe they will both be useful to different sets of people, serving different niches. The development will be done in the open on a site such as Sourceforge, and nmap-dev people are allowed (and encouraged) to help them test, contribute patches, etc. A new GUI would be a great boost to the project. This GUI will do a lot more than simply execute Nmap and show the unparsed results in a Window -- that only helps newbies. Read the specs below and you'll see a lot of features designed for advanced users scanning huge networks. Probably 80% of work will be in the results viewer/parser, making the "nmap execution" part relatively easy. I do want to emphasize that this is NOT intended as a replacement for the beloved command-line version of Nmap. So no need to get defensive about it, as some recent nmap-dev mails were :). Heck, the app will work by executing the command-line version. Even if the app turns out to be everything I want it to be, I'll still use the command-line version for most of my scanning. But it is nice that other people have the option to use the GUI for executing Nmap. And the results viewer aspect (which, again, is most of the work), could be very useful even for the command line gearheads. If you guys think of other important features/requirements for this document, of feel it should be changed in other ways, let me know. Labels such as "should" or "would be nice" denote optional features, while "musts" have to be met. Here are the proposed features and infrastructure requirements for the new Nmap GUI and results viewer: REQUIRED FEATURES: o Must be able to execute Nmap and read the XML output, and also be able to parse existing XML files. Must be able to save Nmap results to an XML file, even after Nmap runs. Would be nice to save in other formats as well, such as normal output and HTML. Maybe an option to store in a DB. Input from Nmap "normal output" would be nice as well. o Must support all significant Nmap options, and in a well-organized way (probably multiple tabs or panels) o Must show Nmap command line as it is being built through options dialogues. o Must support interactive display of results which easily allow any of the following after scan is run (or after previous-scan XML file loaded): o Show details (open ports, os, etc.) for a certain host by typing in IP or hostname, or by browsing to it in results window. o Show all machines with a certain port number or service name listening. If a service name is selected o Show all found instances of a certain application, via version detection results. must allow a regular expression match of the version, product, and extrainfo fields. Nmap already includes libpcre for portable perl-style regexp support. o Sort results by open port number or service name (this would just be a big table of open (or, perhaps open|filtered) ports, with columns for IP address, port number, service, maybe the host OS, etc. Obviously sorted by port number or service name, as requested. o Sort all results by IP address o After you load an XML (say from the "recent scans" menu item or just from file browsing), or even when you are viewing results from a just-done scan, there should be a "repeat this scan" option to let you run the same scan again. Maybe the best way to do this is to check the relevant options for the command used when the user loads an XML (or keep them when the user performs a scan). Then repeating the scan is just a matter of pressing "scan" again. For example, you might want to scan your new server, disable some stupid services in an ssh window, then repeat the scan to ensure that the ports are now closed. This should be easy. The solution of setting/preserving options when XML is loaded or Nmap is run may solve the "named profile" item below as well. o Might be nice if you can create and store named profiles, such as "full scan of chicago division", "ipv6 check", "arp scan of local net", etc. o Must have a graphical paperclip or other mascott which provides advice and suggestions as you plan your scan. Like this one: http://www.counterhack.net/base_clippy_image.html . OK, maybe not :). o Must be able to show small icons for operating systems and/or device type and known services. These must be stored in such a way that they are easy to change, and there must be a default for unknown services/systems. o Must be able to store persistant state (probably in a file for portability reasons). This could hold stuff such as preferences, recent scan information (XML file location, options used, etc.) o Must support all of the major Nmap output information (port states, os detection, version detection, uptime, mac address, etc.) o Must support Nmap timing estimates for progress bars and such. This will probably require adding that support to the XML output (I don't think it is there yet), or parsing Nmap "normal" output. Or maybe you could just show normal output while the scan proceeds, then switch to parsed mode when it completes. o Must be able to compare 2 scans (show the new/removed/changed hosts/ports) o Would be nice to be able to load multiple files into the results view, e.g. if you have one scan file for each subnet. The results would be merged, and it would be OK to have rules like only showing the 1st results of a given host (if that is found in subsequent files, you could ignore those instances of it). o Should have a big red "hack this server" button which uses AI and a cache of 0-day exploits to identify weaknesses, create and launch exploit code, then deface the web site with a poorly spelled self-aggrandizing rant about how lazy and stupid the syadamin must be and how 'l33t the Nmap user is. It should automatically report the defacement to Zone-H and the other archives :). o Must be fully documented in a man page and HTML. One good option is to write the docs in Docbook XML and then use automated conversion to get man page (nroff) and html. Or you could write the nroff directly and convert to html. Or write separate HTML and man pages. HTML generated from a non-text source (Word, Dreamweaver, Frongpage, etc.) is unacceptable unless you have a rare tool that produces readable and concise HTML. Interactive help in the application may be nice too. At the bare minimum, it should at least have a help button/menu that points users to the help web page or man page. o Must allow annotations (text strings) to be made to hosts and ports. These are saved in the XML (and/or other formats like HTML if offered) file when the user does a save option. User is prompted to save if NmapFE is closed when annotations have been added/changed since last save. User can search for these annotations in the GUI, or have the displayed in the relevant port tables, etc. o Must provide overall stats for loaded results, such as number of hosts scanned, number of hosts online, number of ports in each state (open, closed, filtered, etc.) o Should have a non-proprietary installer for Windows which handles file installation, windows registry changes, uninstall, etc. o Generally intuitive, aesthetically pleasing, well organized, stable, fast, etc. Of course, these are mostly subjective goals, but they are still important. INFRASTRUCTURE REQUIREMENTS: o Must support and be tested under Linux, Mac OS X, and Windows. There should be no barrier towards supporting other systems such as Free/Net/OpenBSD and Solaris, though no need to test on all of those initially. That is what users are for :). o Must be done in Python, C/C++, or Perl. Tcl/Tk is probably OK too. No Java or .Net. This may be the most controversial policy, but there are two important reasons for it: o I really believe the project will have trouble catching on if a java interpretor or .net infrastructure are required. Python/Perl/Tcl are small enough that the interpreter can basically be shipped with the binary. o A great front end deserves to be maintained long after the Summer of Code project ends. While it is great if the author steps forward to continue maintance, they may be unable/unwilling to do so at some point. Many Nmap front ends have been abandoned for these reasons, and sometimes I end up maintaining them (e.g. my maintenance of NmapFE and long-time hosting of Nmapwin). I am unwilling to maintain a Java or .Net project. o Must not be done with Glade, QTDesigner, or similar GUI code creation tool. The code they produce is just too ugly, and often inflexible. o Must limit the number of external libraries/programs it depends on. Anything that ships with Nmap is OK, and you'll probably need a graphical widget library such as GTK or QT and an XML parser, but don't go overboard in adding a bunch of new dependencies. It must not require DB libraries or installation of a database (though that is OK as an option). o Development must be done in the open, hosted on a project server such as Sourceforge. Test versions and such should be sent to the nmap-dev list (just send links, not the binaries themselves). That is a good list for bouncing ideas around too. Cheers, Fyodor _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev