Uses for Nlog and Nmap

nlog

Uses for Nlog and Nmap

So now you can port scan with Nmap and sort and analyze the results with Nlog. what can you do with these programs? There are, indeed, some interesting applications for port scanners. Here are some examples for you to try on your network:

      1. Scan for the least common services: if you have a service or port number that is only showing up on one or two machines, chances are that it is not something that is standard for your network. It could be a Trojan horse or a banned service (e.g. a file-sharing application). It could also be a misconfigured machine running an FTP server or other type of public server. You can set Nlog to show the number of occurrences of each and sort them by the least often occurring. This will generate a list for you to check. You probably won’t want to include your company’s servers in this scan as the will have lots of one-of-a-kind services running. However, it would not hurt to scan these servers separately either to fine-tune or eliminate extraneous services.
      2. Hunt for illicit/unknown web servers: Chances are that if you run one or more web servers for your company, you will see the HTTP services showing up a few times on your network. However, it is also likely that you will see it on machines where you don’t expect it. Some manufacturers of desktop computers are now loading small web servers by default on their systems for use by their technical support personnel. Unfortunately, these web servers are often barebones programs with security holes in them. You will also find web servers running on printers, routers, firewalls, and even switches and other dedicated hardware. You may need these servers to configure the hardware, but if you aren’t using these servers, you should shut them off. These mini-servers are often configured with no password protection by default and can offer a hacker a foothold onto that machine. They can also offer access to the files on the machines if an intruder knows how to manipulate them. Scan for these hidden web servers, and either turn them off or properly protect them. you should also search for ports other than 80 that are commonly used for HTTP. At the end of this article, there is a table listing some of those ports.
      3. Scan for servers running on desktops: Going a step further with the last exercise, restrict the IP range to only those that are nonserver machines and set a port range from 1 to 1024. This will find desktop machines running services that are normally done by servers, such as mail, web and FTP. Unless there is a good reason for this (e.g. PCAnywhere), your desktop machines should not be running these types of services.
      4. Hunt for Trojan horses: To hunt for Trojan horses on your network, run a scan of your network and translate it into the Nlog database format. Open the Nlog search page, select the ports, and set the range from 30,000 and 65,400. This is the favored range for Trojan horses because it is out of the range of normal services and so they usually will go unnoticed – that is, unless you are port scanning your network. However, just because there are some services running on high-level ports doesn’t always mean you have Trojan horses, but it is worth paying attention to services running on these high port numbers. Once you’ve narrowed it down to the machine and port numbers, you can rule them out by checking the services running on those machines or by SSHing to those port numbers and seeing if you get a service banner.
      5. Check your external network exposure: Put your Nmap box outside your network, either on a dial-up or home broadband connection, and try scanning your company’s public IP addresses. By doing this you will see what services are accessible from the Internet (and thereby to any port scanner-wielding person). This is the most vulnerable part of your network, and you should take extra care to secure any services that are public-facing by using a vulnerability scanner, such as the one described in the next chapter. It will also show if your firewall is properly filtering ports that it is forwarding to internal LAN addresses.
        So you’ve seen all the cool things you can do with a port scanner like Nmap. These programs are useful for finding out what you have running and where your exposures might be. But how do you know if those exposed points might be vulnerable? Or if services that are supposed to be open are safe and secure? That goes beyond the function of a port scanner and into the realm of a vulnerability scanner.


Web Ports

Common Port Number Protocol
81 Alternate web
88 Web
443 HTTPS, secure web
8000-8002 Web
8080 Web
8888 Web

External Links:

Download Nlog at packetstormsecurity.com

2003 archive of secureaustin.com (the former official site of H.D. Moore, creator of Nlog)

Nlog Add-Ons and Extensions

NlogIn the previous article, we discussed installing and using Nlog. In this article, we will discuss using add-ons and writing your own Nlog extensions.

Nlog Add-Ons

As mentioned earlier, Nlog is easily extensible and you can write add-ons to do other tests or functions on any protocols or ports found. In fact, there are several included with the program. If there is an add-on available, there will be a hypertext line next to the port and you can click on it to run the subprogram.

Nlog Built-in Extensions

Extensions Descriptions
Nlog-rpc.pl This add-on takes any RPC services that are found and attemps to find out if there are any current RPC attachments and exports for that service
Nlog-smb.pl For any nodes running NetBIOS, this script tries to retrieve shares, user lists, and any other domain information it can get. It uses the user name and login specified in the nlog-config.ph file.
Nlog-dns.pl This script runs a standard nslookup command on the IP address.
Nlog-finger.pl This runs a query against any finger service found running to see what information is sent.

If you examine these add-on scripts, you will observe that they are all just basic Perl programs. If you are experienced with Perl, you can write your own extensions to execute just about any function against your scanned hosts. For example, you can retrieve and display the HTTP header for any web servers found so you can more easily idenfiy it. You don’t need to go overboard with this, because programs like Nessus can do much more comprehensive testing, but if you just need a banner or some small bit of information, then using Nlog is a good solution.


Nlog comes with a sample custom add-on called nlog-bind.pl. This scrupt is designed to poll a DNS server and tell you what version of BIND (the Berkeley Internet Naming Domain) it is running. However, this script is not finished; it is provided as an exercise to create your own add-ons. The sample script is in /nlog*/extras/bind/. The following procedure guides you through finishing the script. You can use that format to create any custom script of your own.

  1. Compile the script using the Gcc compiler with the following command from that directory:
    gcc -o bindinfo binfo-wdp.c

    This creates a binary file called bindinfo in that directory.

  2. Copy this binary file to the directory where you are keeping your nlog scripts.
  3. Change the permissions on it to make it executable (remember that you have to be root to issue this command):
    chmod 700 bindinfo
  4. Open your nlog-config.ph file in a text editor.
  5. Add this line:
    $bindinfo = "/path/to/bindinfo";

    Replace path/to/bindinfo with the location where you put the binary file.

  6. Save this file.
  7. Now edit nlog-search.pl. This is te Perl script that creates your search results page.
  8. Find the section that looks like this:
    1: # here we place each cgi-handler into a temp var for readability.
    2: 
    3: $cgiSunRPC = "sunrpc+$cgidir/nlog-rpc.pl+SunRPc";
    4: $cgiSMB = "netbios-ssn+$cgidir/nlog-smb.pl+NetBIOS";
    5: $cgiFinger = "finger+$cgidir/nlog-finger.pl+Finger";
    6:
    7: $qcgilinks = "$cgiSunRPc $cgiSMB $cgifinger";
  9. Between lines 5 and 6, add a line that looks like:
    $cgiBIND = "domain+cgidir/nlog-bind.pl+BIND";
  10. Edit line 7 to look like this:
    $qcgilinks = "$cgiSunRPC $cgiSMB $cgiFinger $cgiBIND";

    Line 7 is also where you would add, in a similar fashion, links to any other scripts you had created.

  11. Copy the nlog-bind.pl file from this directory into your cgi-bin directory (/var/www/cgi on Mandriva), and change the permissions (chmod0 so the application can read it.

Now when your Nmap scans find port 53 open (which is generally a DNS server), you can click on the link that Nlog creates and find out what version of BIND is running. You can write additional scripts to extend Nlog by following the logic in this example.

External Links:

Download Nlog at packetstormsecurity.com

2003 archive of secureaustin.com (the former official site of H.D. Moore, creator of Nlog)

Nlog: A Utility for Analyzing Nmap Logs

nlogIn a previous article, we covered the Nmap utility. You can save Nmap logs in a number of formats, including plain text or machine-readable, and import them into another program. However, if these options aren’t enough for you, Nlog can help you make sense of your Nmap output. Running it on very large networks can be a lifesaver, because perusing hundreds of pages of Nmap output looking for nefarious activity can be tedious.

The Nlog program helps you organize and analyze your Nmap output. It presents them in a customizable web interface using CGI scripts. Nlog makes it easy to sort your Nmap data in a single searchable database. On larger networks, this kind of capability is vital to making Nmap useful. H.D. Moore put together these programs and made them available. You can find more information about Nlog at securiteam.com. You can download Nlog at packetstormsecurity.com.

Nlog is also extensible. You can add other scripts to provide more information and run additional tests on the open ports it finds. The author provides several of these add-ons and instructions on how to create your own. Nlog requires Perl and works on log files generated by Nmap 2.0 and higher.

Installing Nlog

Follow these steps to install and prepare Nlog:

  1. Download the files from the Nlog web site.
  2. Unpack the Nlog files using the tar-zxvf command. It will unzip and neatly organize all the files for Nlog in a directory called nlog-1.6.0 (or other numbers, depending on the version number).
  3. You can use the installer script provided to automatically install and prepare the program. Note that you need to edit the program before you run it. Go to the Nlog directory and, using a text editor program such as vi or emacs, open the file installer.sh and enter the variables where indicated for you system. Edit the following parameters with the correct values for your installation.
    CGIDIR=/var/www/cgi/
    HTMLDIR=/var/www/
    

    Put the path to your CGI directory. The above represents the correct values on a default Mandrake installation. Make sure you enter the correct ones for your system. For other Linux systems, find the path to this directory by using the locate command. This useful command will find any files with the text you insert after it.

  4. Save the file, then run it by typing:
    ./install.sh

    The installation script automatically copies the CGI files to your CGI directory and the main HTML file to your HTML directory. It also changes the permissions on those files so they can be executed by your web browser.

  5. For the final step, go into the /html directory and edit the nlog.html file. In the POST statement, change the reference to the cgi files to your cgi files, which should be the same one used above (/var/www/cgi/). Save the file and you are ready to go.


Running Nlog

Nlog can be used as follows:

  1. The first thing you must do is create a Nlog database file to view. You do this by converting an existing Nmap log file. Make sure you save your Nmap logs with the machine-readable option (-m on the command line) to be able to use them in Nlog. You can then use a script provided with Nlog to convert the Nmap log into the database format that Nlog uses. To convert a Nmap machine readable log, run the log2db.pl script using this command:
    Ip2db.pl logfile 
    

    Replace logfile with your log file name and location.

  2. To combine multiple log files into a single database, use the following commands:
    cat * > /PATH/temp.db
    cat * > /PATH/temp.db | sort -u > /PATH/final.db
    
  3. Replace /PATH with the path to your Nmap files and final.db with the name you want to use for the combined Nmap database. This sorts the files into alphabetical order and eliminates any duplicates.
  4. Start your web browser and go to the web directory (/var/www/ from the previous section).
  5. Select the Nmap database file you want to view and click Search.
  6. You can now open your Nmap database and sort it based on the following criteria:
    • Hosts by IP address
    • Ports by number
    • Protocols by name
    • State (open, closed, filtered)
    • OS match

    You can also use any combination of these criteria. For example, you could search for any web servers (http protocol) on Windows systems with a state of open.

In the next article, we will look at Nlog add-ons and creating Nlog extensions.

External Links:

Download Nlog at packetstormsecurity.com

2003 archive of secureaustin.com (the former official site of H.D. Moore, creator of Nlog)

© 2013 David Zientara. All rights reserved. Privacy Policy