Vulnerability Scanning: What It Won’t Fix


Vulnerability scanningSecurity Issues That Won’t Be Fixed By Vulnerability Scanning

While vulnerability testing is a valuable tool in your security arsenal, you should not think of it as a silver bullet. There are still situations and areas that a vulnerability testing program won’t help you with. You have to develop additional systems and procedures to lessen your exposure in these areas. The following include security issues that won’t be found by vulnerability testing.

Logic errors are security holes that involve faulty programming logic inside a program. these are generally undiscovered or unpatched bugs where the program does not perform as it was supposed to. An example would be a web login page that does not authenticate properly or one that allows users to get more privileges than they should have. Well-known logic errors in major programs might be included in the Nessus vulnerability tests, but most of them are too obscure to be noticed except by a dedicated hacker.

Vulnerability testers rely on published reports of vulnerabilities. Usually, once a vulnerability is announced, an add-on or plug-on for the system is written. With open source programs, this may only take a few days. However, during that time there may be a window of vulnerability because your scanner won’t be finding that security hole if it exists. Of course, you could quickly write your own tests using NASL while you wait for the official one to come out.

Vulnerability testing programs typically only address published commercial and open source programs. If you have a program that was developed for internal use only, a vulnerability tester probably won’t test anything on it. If it uses standard protocols or subprograms such as HTTP, FTP, or SQL, then some of the tests may apply. There are additional programs specially designed to test code for its security that you should run on these applications. The good news is that with an open source vulnerability tester like Nessus, you can write tests custom designed for your in-house application.

All the testing in the world won’t help you if you have poor or nonexistent security policies for your employees. Hackers denied technical means to gain access to your network can revert to social engineering – in other words, trying to talk someone into giving them access. This can be surprisingly easy, because the hacker takes advantage of the basic human nature of people generally wanting to help others, especially people perceived as fellow employees. There is only one way to combat this kind of hacking, and it does not involve any technical systems. Having good security policies, educating employees about them, and enforcing them will lessen your exposure to these kinds of attacks.

Vulnerability testing only shows you potential security holes in your system; it won’t tell if those holes have been exploited or alert you if an attack is taking place. Programs like Nessus are purely preventative in nature, and they are effective only if you take action to fix problems when they are found. Vulnerability scanners won’t fix them for you, although Nessus is very helpful in giving you detailed information on how to fix any issues found.

External Links:

Vulnerability scanner on Wikipedia

Vulnerability Scanning Tips

vulnerability scanning tipsBefore you start vulnerability scanning, you should take into consideration some issues. Port scanning is a fairly innocuous activity, althouh it is annoying when you see the activity showing up in your logs. Vulnerability testing, however, can be quite a bit more disruptive, crashing servers, taking down Internet connections, or even deleting data. Many of the Nessus tests, for example, are specifically designed to cause a denial-of-service attack. Even with the safe checks option turned on, the tests can cause problems with some systems. With this in mind, here are some guidelines.

Scan Only with Permission

You should never scan a network that is not under your direct control or if you do not have explicit permission from the owner. Some of the activity initiated by Nessus could be legally considered hacking (especially with the DoS checks turned on). Unless you want to take the chance of being criminally and civilly charged, or having a complaint lodged against you by your ISP, you should always scan with permission. Non-company outsiders such as consultants should make sure to obtain written permission with all the legal disclaimers necessary. Internal personnel should make sure they have authority to scan all the machines in the range they are scanning. Coordinate with other departmental personnel as necessary, such as firewall administrators and security staff.

Modern vulnerability scanners are easy to install and use, but they are generally installed with generic settings. Using such settings may not be a good idea if you have legacy hardware. Approaching legacy hardware with a scan calls for caution, as a scan may cause problems with the legacy machine’s approaches to port management and binding. In such cases, port scanning can cause connection hang-ups and even system crashes. As a result, if your network includes such hardware, you want to be aware of the potential issues of running an untested scan and plan accordingly. Segmenting your risk by testing only a few servers at a time may be the way to go.

You should always make sure your backups are current anyway, but it is doubly important when vulnerability scanning, just in case the scan causes a problem with a server. Doing a Nessus scan right after you run backups will ensure that you can restore the most current version. But also make sure you aren’t running your scan during a backup. Not only could you cause a corruption of your backup data, but both processes will slow to a crawl.

Scheduling Your Scans

Along the lines of the last comment, make sure you coordinate your scan to get the results you want with minimal impact on other employees. Scanning the mail server at 8:00 AM when everyone is getting their e-mail will probably not make you very popular with the staff. Schedule scans on always-up servers for off-hours, and be sure to avoid overlapping with other system administration and general activity levels. If you are scanning internal machines, you will probably want to do it during the day unless you can arrange for everyone to leave their machines on at the end of the day. The best time to do it during business hours is generally around the lunch hour, as a minimal number of people will be using the network.

Schedule your scans as often as you feel is necessary, but don’t automatically assume that nightly scans are going to make your network more secure. If you cannot interpret and respond to scan reports on a daily basis, then don’t do the scan; all it will do is put additional traffic on your network. Base your frequency on the capability of your staff to deal with the results. You should do it at least once a month, but if you have a particularly busy network, you may want to do it weekly. Similarly, if you have a very small external network, you may feel comfortable with quarterly scans. Daily scans are probably excessive unless you have dedicated staff to handle the remediation work. If you have that much need for up-to-the minute protection, then use an intrusion detection system to supplement your vulnerability testing.

If you want a true of your external vulnerability (for the Internet), you should make sure your Nessus server is located outside your firewall. This can be on a home Internet connection, at a data center that is outside your company network, or at another company (perhaps you can negotiate a trade to use another company’s facilities for scanning and let them user yours for the same). Remember, because of the Nessus client-server architecture, you can still control your scans from inside your firewall. Just make sure you enable the SSL support so communications between your client and the server are encrypted.

If you are scanning your internal network, your internal network, your server will have to be located inside your firewall. Loading Nessus on a laptop can facilitate doing scans from both inside and outside your network without requiring multiple machines.

External Links:

Vulnerability Scanning Do’s And Don’ts at

Nessus Configuration: Part Two

Nessus configurationThe Nessus GUI configuration menu contains several configurable options. For example, this is where the maximum number of checks and hosts being scanned at one time, the resource you want nessusd to use and the speed at which data should be read are all specified, as well as many other options. These settings should be reviewed and modified appropriately based on your scanning environment.

Nessus Configuration: max_hosts and max_checks

In particular, the max_hosts and max_checks values can have a great impact on your Nessus system’s ability to perform scans, as well as those systems being scanned for vulnerabilities on your network. Pay particular attention to these two settings.

Default Values for max_hosts/max_checks

Option Value
max_hosts 40
max_checks 5

Note that these settings will be overridden on a per-scan basis if you are using Tenable’s SecurityCenter or write a custom policy in the Nessus user interface. To view or modify these options for a scan template in SecurityCenter, edit a Scan Template’s “Scan Options”. in the Nessus user interface, edit the scan policy and then click on the “Options” tab.

It should be noted that the max_checks parameter has a hardcoded limit of 15. Any value over 5 will frequently lead to adverse effects as most servers cannot handle that many intrusive requests at once.

As the name implies, max_hosts is the maximum number of target systems that will be scanned at any one time. The greater the number of simultaneously scanned systems by an individual Nessus scanner, the more taxing it is on that scanner system’s RAM, processor, and network bandwidth. Take into consideration the hardware configuration of the scanner system and other applications running on it when setting the max_hosts value.

As a number of other factors that are unique to your scanning environment will also affect your Nessus scans, experimentation will provide you with the optimal setting for max_hosts.

max_checks is the number of simultaneous checks or plugins that will run against a single target host during a scan. Note that setting this number too high can potentially overwhelm the systems you are scanning sepending on which plugins you are using in the scan.

Multiply max_checks by max_hosts to find the number of concurrent checks that can potentially be running at any given time during a scan. Because max_checks and max_hosts are used in concert, setting max_checks too high can also cause resource constraints on a Nessus scanner. As with max_hosts, experimentation will provide you with the optimal setting for max_checks, but it is recommended that this always be set relatively low.

Here is a selective list of some other Nessus configuration options:

Option Description
auto_update Automatic plugin updates. If enabled and Nessus is registered, then fetch the newest plugins from automatically. Disable if the scanner is on an isolated network not able to reach the Internet.
dumpfile Location of a dump file for debugging output if generated.
enable_listen_ipv4 Directs Nessus to listen on IPv4.
enable_listen_ipv6 Directs Nessus to listen on IPv6 if the system supports IPv6 addressing.
logfile Where the Nessus log file is stored.
optimize_test Optimize the test procedure. Changing this to “no” will cause scans to take longer and typically generate more false positives.
port_range Range of the ports the port scanners will scan. Can use keywords “defaut” or “all”, as well as a comma-delimited list of ports or ranges of ports.
xmlrpc_listen_port Port for the Nessus web server to listen to (XMLRPC protocol).

External Links:

Nessus Documentation at

Nessus Configuration: Part One

Nessus Configuration

Advanced settings in the Nessus web GUI.

Nessus Configuration: Proxy and Advanced Settings

The first thing you will see when you access Nessus is the login page. You must first enter the login name and password you created when you set up Nessus. Since Nessus uses a web-based front end, you can access the Nessus server from any computer on the local network that has a web browser, making Nessus configuration much easier. This increases the scalability of Nessus for larger organizations. You can configure scan options and make other changes, all from the web interface.

Once you are logged in, there are several settings you can change. If you click on your username (in this example, “nessusadmin”) on the right side of the page, there is a drop-down menu with several options; select “Settings”. On the left sidebar, there is an option called “Proxy”. If you did not set up a proxy during the setup process and need to do so now (for example, if your organization requires that all web traffic be directed through a corporate proxy), you can input the settings here.

Proxy Setting Options

Option Description
Host The host or IP of the proxy
Port The port of the proxy
Username Optional: if a username is required for proxy usage
Password Optional: If a password is required for proxy usage
User-Agent Optional: If the proxy you are using filters specific HTTP user agents, a custom user-agent string can be supplied
Custom Update Host Optional: This can be used to force Nessus to update plugins from a specific host. For example, if plugins must be updated from a site residing in the U.S., you can specify “”

Different Nessus configuration options can be set by clicking on the “Advanced” link in the Settings menu. Each option can be configured by editing the corresponding field and clicking the “Save” button at the bottom of the screen. In addition, the option can be removed completely by clicking on the “X” button.

By default, the Nessus GUI operates on port 8834. To change this port, edit the xmlrpc_listen_port to the desired port. The Nessus server will process the change within a few minutes.

If additional preferences are required, click on the “New Setting” button, input the name and the value, and press “Save”. Once a preference has been updated and saved, Nessus will process the changes within a couple of minutes.

Nessus Configuration

Adding a new user in Nessus.

Nessus Configuration: Adding/Editing Users

During the initial setup, one administrative user is created. Using the credentials specified during the setup, you can log into the Nessus GUI. Once authenticated, click on the “Users” heading at the top. To create a new user, click “New User” on the upper right. This will open a dialog box asking for required details. Input the username and password, verify the password, and determine if the user should have administrator privileges. If a user account needs to be modified, double-click on the user.

You cannot rename a user. If you want to change the name of a user, delete the user and create a new user with the appropriate login name. To remove a user, select the check box next to the account on the list, select “Options” on the upper right, and then click “Delete User” and confirm.

A non-admin user cannot upload plugins to Nessus, cannot restart it remotely, and cannot override the max_hosts/max_checks setting in the configuration section. If the user is intended to be used by SecurityCenter, it must be an admin user. SecurityCenter maintains its own user list and sets permissions for its users.

In the next article, we will cover more Nessus configuration options.

External Links:

Nessus home page on

Nessus on Wikipedia

Nessus Installation: A Guide

Nessus Installation

Installing Nessus using the Debian package manager in Mint Linux.

Nessus Installation and Setup

In the previous article, we discussed some of the features and capabilities of Nessus 5. Here we will discuss downloading and installing the program.

There are two prerequisites you must have before you begin Nessus installation, and two others that are nice to have installed beforehand to take full advantage of the add-on capabilities.

  1. The two prerequisites are the Gimp Tool Kit (GTK) and libpcap. If you installed Nmap, you should already have these programs installed. If not you can download GTK from:

    and libpcap from:
  2. The two programs that are optional for Nessus installation but recommended are OpenSSL and Nmap. Nessus can use Nmap as its port scanner and OpenSSL for secure communications between the server and client.
Nessus Installation

Entering the registration code during the Nessus installation process.

It is fairly easy to download and install Nessus from Tenable’s official site at Nessus is available for several operating systems, including:

  • Windows (XP, 2003 Server, Vista, 7 and 8)
  • Mac OS X
  • Linux
  • FreeBSD
  • Solaris

In Mint Linux, I began Nessus installation by downloading Nessus 5.2.6 from the Tenable web site (I downloaded the version for Ubuntu 9.10). When you download Nessus, you will be asked to register by providing your name and an e-mail address. Once I downloaded Nessus, I chdir-ed to the downloads directory, and at the command line, I typed:

sudo dkpg -i Nessus-5.2.6-ubuntu910_i386.deb

Within moments, the Debian package installer had unpacked and installed Nessus. Once it was done, I typed

sudo /etc/init.d/nessusd start

to start Nessus. Now the Nessus installation process can be completed by accessing the web interface via port 8834 on a web browser (using the HTTPS protocol). The first screen you’ll see upon accessing the web interface for the first time is the “Welcome to Nessus 5” screen. Click on the “Get Started” button to continue.

Next is the “Initial Account Setup” screen, where you will be asked to created an admin user and password. Fill in the relevant fields and click on the “Next” button.

The next screen is “Plugin Feed Registration”. Here, you need to enter the activation code that was e-mailed to you when you first registered. There is also a section at the bottom for “Optional Proxy Settings”. Here you can enter the proxy hostname, proxy username, and proxy password if you want to configure a proxy. Enter the activation code, configure the proxy settings (if desired), and click on the “Next” button to register your scanner.

After registration, Nessus must download the plugins from Tenable. This process may take several minutes. The plugin setup process involves transferring a considerable amount of data to the machine, verifying file integrity, and compiling them into an internal database. Once the plugins have been downloaded and compiled, the Nessus GUI will initialize and the Nessus server will start. Nessus installation is complete and you are now ready to use Nessus.

In the next article, we will go through the process of using Nessus to secure your network.

External Links:

<a href=””>Nessus home page on</a>

<a href=””>Nessus on Wikipedia</a>

Nessus Features and Capabilties

Nessus featuresIn the previous article, we introduced the Nessus vulnerability scanner. In this article, we will discuss some of the additional Nessus features.

Nessus Features: Scripting Language, Integration with Other Tools, Smart Testing

To supplement the plug-in architecture, Nessus has its own scripting language called Nessus Attack Scripting Language (NASL), one of the more important Nessus features. This easy-to-learn utility language allows you to quickly and easily write your own custom security plug-ins without having to know C or all of the internal workings of the main program.

Nessus can be used by itself or with several other open source security tools. You can use Nmap, the best port scanner in the world, or the port scanning part of the job, rather than the built-in one. the Nesseus port scanner is faster and a little more efficient with memory, but Nmap allows for a lot more options and settings. Almost all the Nmap settings are configurable from within the Nessus client. Nessus also works with Nikto and Whisker, tools that run more complex tests on web servers; CGI programs; and Hydra, a tool for running brute-force password attacks against common services. The functionality of these tools is written right into Nessus, so you can make configuration changes from a single interface.

Another ability which you may find is one of the more useful Nessus features is that it can be set up so that it does not automatically run all of the vulnerability tests on every host. Based on the results of a port’s scan or other input such as past vulnerability tests, Nessus will run only tests appropriate to that machine. So if the server is not running a web server, it won’t run web server-related tests. Nessus is also smart in that it does not automatically assume that web servers will run on port 80, but rather checks all the possible ports for signs of a web server. Nessus will even find multiple instances of services running on different ports. This is especially important if you are inadvertently running a web server or other public service on an unusual port.

Nessus Features: Knowledge Base and Reporting

Another one of the more useful Nessus features is that it can save all scan results in a database called the Knowledge Base. This allows it to use the results of past scans to intelligently figure out what tests to run. You can use this to avoid doing a port scan every time you run Nessus, because it will remember what ports it found open last time on each host and test only those. It can also remember what hosts it saw last time and test only new hosts. You probably shouldn’t do this every time, because you may miss new ports that open up on machines or new vulnerabilities that show up on previously scanned boxes. However, it can allow you to run scans more often with less bandwidth and processor power as long as you do a complete scan on a regular basis.

Nessus has some of the best reporting capabilities in the open source field. Although it is not perfect, it can output your scan data in just about any format. Basic HTML and HTML with pie charts and graphs are two of the more popular formats. These reports include summary data and are suitable for posting to an internal web site with little or no editing. Other report formats supported include XML, LaTeX, and plain text. The Windows client offers additional report formats. There are additional tools available that allow you to do further manipulation of the data.

Mailing Lists

Nessus has an extensive support network for getting help, both on basic installation and use as well as more complex programming and customization. there are no fewer than five Nessus mailing lists, each dedicated to a different area. There is an archive of all the past posts so you can check to see if your question has ever been answered. The following are the main Nessus mailing lists:

  • nessus: A general discussion list about Nessus.
  • nessus-devel: Talks about the development of the upcoming versions.
  • nessus-cvs: Shows the CVS commits made on the Nessus tree.
  • nessus-announce: A low-traffic moderated list that is dedicated to the announcements of the availability of new releases.
  • plug-ins-writers: A list dedicated to the writing of new Nessus plug-ins. If you want to write your own security checks, you should subscribe to it.

Of the discussion lists, nessus is the most active, broadest in scope, and probably most useful to the average reader. Much of the traffic consists, of questions and answers rather than actual discussions, and topics include Nessus and NessusWX, the plugins, vulnerabilities themselves, third-party add-ons, and so forth. Nessus-devel tends to be more discussion oriented, with the focus on revisions to Nessus and the NASL language. Plugins-writers leans more toward questions and answers, generally how to accomplish something in NASL or whether plugins are properly testing for vulnerabilties. None of these lists has an actual charter, though, and in practice there’s a fair amount of overlap among them.

To subscribe to any of the above lists, send an e-mail to with the following text in the body of the e-mail:

Subscribe listname

Replace listname with the name of the list to which you want to subscribe. To unsubscribe, do the name but write Unsubscribe listname in the body.

Nessus has quite a bit of documentation on its web site, including detailed instructions on installation, basic operation and use of Nessus features, and tutorials on how to write your own security checks in NASL.

Now the we have covered some of the more important Nessus features, in the next article, we will cover installing Nessus in Linux.

External Links:

Nessus home page on – Additional information on Nessus features can be found here

Nessus on Wikipedia

Nessus Vulnerability Scanner: An Introduction


Introducing the Nessus Vulnerability Scanner

Modern computer networks have multiple potential areas of insecurity. How do you protect all these avenues of attack? You might feel that protecting your network is an impossible situation. You could spend all day, every day, just checking for these security holes manually. Even if you tried to automate it with scripts, would would seem to take dozens of programs. Fortunately, there are packages out there called vulnerability scanners that will automatically check all these areas and more.

Nessus is an excellent program. It is a great example of how well open source projects can work, although the project has been since been changed to a proprietary (closed source) license. [The Nessus 3 engine is still free of charge, though Tenable Network Security, the company founded by Nessus creator Renaud Deraison, charges $100/month per scanner for the ability to perform configuration audits for PCI, CIS, FDCC and other configuration standards, technical support, SCADA vulnerability audits, the latest network checks and patch audits, the ability to audit anti-virus configurations and the ability for Nessus to perform sensitive data searches to look for credit card, social security number and many other types of corporate data.] It is robust, well documented, well maintained, and the premiere vulnerability scanner. Nessus has consistently rated at the top of all vulnerability scanners, commercial or noncommercial. This is amazing when you consider its competitors cost thousands of dollars and are created by large companies. It continues to impress and improve, and most importantly, to protect thousands of companies’ networks. There are some design features that make Nessus unique and superior to other vulnerability scanners.

Even as Nessus 3 and subsequent versions went closed source, the Nessus 2 engine and a minority of the plugins are still GPL, leading to forked open source projects based on Nessus. Tenable Network Security has still maintained the Nessus 2 engine and has updated it several times since the release of Nessus 3. The current stable version of Nessus is 5.2.1 (released May 7, 2013).

Nessus currently offers over 2000 individual vulnerability tests that cover practically every area of potential weakness in systems. Very few scanners out there can compete with this level of testing, and new tests are being added daily by a worldwide network of developers. The speed of release of new tests for emerging vulnerabilities is usually measured in days if not hours. Its plug-in based architecture allows new tests to be added easily.

You can turn off whole categories of tests if they do not apply or if you are worried they could be dangerous to your systems, or you can deactivate individual tests if you have it concern about a specific one. For example, you may prefer to disable the untested category, which contains tests that haven’t been fully tested yet.

Nessus uses a client-server architecture to run its security checks. The server runs the tests and the client configures and controls the sessions. The fact that the client and server can be separated offers some unique advantages. This means that you can have your scanning server outside your network, yet access it from inside your network via the client. this also allows other operating systems to be supported via different clients. There are currently UNIX and Window clients available, with projects to create additional ones ongoing. These is also now a web client interface available, which makes Nessus truly platform independent (at least on the client end).

In the next article, we will continue our discussion of Nessus and its features.

External Links:

Nessus home page on

Nessus on Wikipedia

Useless Services

Useless services

Useless Services

Like a vestigial tail, there are often applications running on our machines that no longer serve any useful purpose. These services may be part of an earlier set of libraries that the programmers built on and never bothered to take out. This is one of the downsides of ever-increasing processing power and memory capacity. Programmers used to carefully ration every byte they used and would never allow unnecessary lines in their code. However, in this age of bloatware and gigabyte-sized operating systems, it is often easier to leave legacy services in rather than risk breaking some other program that depends on them. The incredible thing is that these services are often turned on by default. Here is a list of some of those services:

Useless Services in Linux

Services Common Port Numbers Functions
chargen 19 Sends a stream of standard characters when polled. Not only isn’t this service used anymore, but it can be used to generate a denial of service (DoS) attack by having it continually spit out character streams.
daytime 13 Returns the time of day. Not really needed of any modern system functions.
discard 9 Discards whatever is sent to it silently. Mainly used for testing purposes.
echo 7 Replies back with whatever was sent to it. Like chargen, echo can be used in DoS attacks by sending it a steady stream of data to echo.
finger 79 Much has been said about this service. [Consider, for example, the original Internet worm, released by Robert Morris in 1988, which exploited a buffer overflow bug in the finger program and propagated itself from one machine to another.] Very useful to hackers.
qotd (quote of the day) 17 Sends out a little quote or phrase that the system administrator sets up when you log in.

If you are running Windows, there are other services you will probably want to disable. Here is a partial listing of those useless services:

Useless Windows in Windows

Service Description
Remote Registry Enables viewing and changing Windows Registry from a remote computer (including hackers’ computers).
ClipBook (Windows XP only) Shares Clipboard contents over a network
Function Discovery Resource Publication (Windows Vista, 7, 8, 8.1) Publishes shared resources (printers, libraries, etc.) on this computer over a network.
Offline Files (Windows Professional/Business/Ultimate) Caches selected folders and files from file servers so that the items are always available.
SSDP Discovery Detects and publishes Simple Services, such as UPnP devices (home entertainment systems, media streaming, printers, some WiFi routers, etc).
Telnet (Windows XP only) Enables remote access to a command-line interface over a network.
WebClient Enables creating, accessing and modifying files on the Internet using Windows-based programs. This does not affect FTP, SSH, SCP or browser-based access.
Windows Media Player Network Sharing Service Enables streaming music and video to home entertainment systems and other computers/devices over a network.

If you disable at least some of these services, your system should be harder for hackers and bots to attack, and your system will be more secure.

External Links:

Remove useless services/apps at

Useless services in CentOS VDS/VPS at

Turn off Unnecessary Windows Services at

Disable Unneeded Services in Windows at

Uses for Nlog and Nmap


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

2003 archive of (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 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 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 file. This script runs a standard nslookup command on the IP address. 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 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 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 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.
    3: $cgiSunRPC = "sunrpc+$cgidir/";
    4: $cgiSMB = "netbios-ssn+$cgidir/";
    5: $cgiFinger = "finger+$cgidir/";
    7: $qcgilinks = "$cgiSunRPc $cgiSMB $cgifinger";
  9. Between lines 5 and 6, add a line that looks like:
    $cgiBIND = "domain+cgidir/";
  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 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

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

© 2013 David Zientara. All rights reserved. Privacy Policy