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

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)

Open Source Tools: Part Three (Even more nmap options)

nmap optionsWhen you specify your targets for scanning, nmap will accept specific IP addresses, address ranges in CIDR format, and octet format (i.e. x.x.x.x). If you have a host file, which may have been generated from your ping sweep earlier, you can specify it as well using the -iL flag. There are other, more formal nmap parsing programs out there, but awk can be used to create a quick and dirty hosts file from an nmap ping sweep. Scripting can be a very powerful addition to any tool, but remember to check all the available output options to avoid doing too much work.

nmap allows the user to specify the speed of the scan, or the amount of time from probe sent to replay received, and therefore how fast packets are sent. On a fast LAN, you can optimize your scanning by setting the -T option to 4, or Aggressive, usually without dropping any packets during send. If you find that a normal scan is taking very long due to ingress filtering or a firewall device, you may want to enable Aggressive scanning. If you know that an IDS sits between you and the target, and you want to be as stealthy as possible, the using -T0 or Paranoid should do what you want; however, it will take a long time to finish a scan, perhaps several hours, depending on your scan parameters.

By default, nmap 6.40 with Auditor scans 1000 ports for common services, which will catch most open TCP ports out there. However, sneaky sysadmins may run ports on uncommon ports, practicing security through obscurity. Without scanning those uncommon ports, you may be missing these services. If you have time, or suspect that a system may be running other services, run nmap with the -p1-65535 parameter, which will scan all 65k TCP ports. Even on a LAN with responsive systems, this will take anywhere from 30 minutes to a few hours. Performing a test like this over the Internet may take even longer, which will allow more time for the system owners, or watchers, to note the excessive traffic and shut you down.

Ping Sweeping with netenum

Finally, if you have a need for a very simple ICMP ping sweep program that you can use for scriptable applications, netenum might be useful. It performs a basic ICMP ping and then replies with only the reachable targets. One quirt about netenum is that it requires a timeout to be specified for the entire test. If no timeout is specified, it outputs a CR-delimited dump of the inputted addresses. If you have tools that will not accept a CIDR formatted range of addresses, you might use netenum to simply expand that into a listing of individual IP addresses. netenum is part of the Internetwork Routing Protocol Attack Suite, which also includes such utilities as cdp (for sending Cisco router Discovery protocol messages), and ass (Automated System Scanner).

External Links:

The official nmap site

Official site for the Internetwork Routing Protocol Attack Suite (IRPAS) – netenum is part of IRPAS

Port Scanning with nmap

port scanningThe list of potential targets from the footprinting phase of penetration testing can be expansive. To streamline the port scanning process, it makes sense to first determine if the systems are up and responsive. Several methods can be used to test a TCP/IP-connected system’s availability, but the most common technique uses Internet Control Message Protocol (ICMP) packets.

Of course, if you’ve done any type of network troubleshooting and/or are a reader of this blog, you probably recognize this as the protocol that ping uses. The ICMP echo request packet is a basic one that, according to RFC 1122, every host needs to implement and respond to. In reality, many networks, internally and externally, block ICMP echo requests to defend against one of the earliest DoS attacks, the ping flood. They may also block it to prevent scanning from the outside.

If ICMP packets are blocked, TCP ACK packets can also be used for port scanning. This is often referred to as a TCP ping. RFC 1122 states that unsolicited ACK packets should return a TCP RST. Therefore, sending this type of packet to a port that is allowed through a firewall (e.g. port 80), the target should respond with an RST indicating that the target is active. When you combine either ICMP or TCP ping methods to check for active targets in a range, you are performing a “ping sweep”. Such a sweep should be done and captured to a log file that specifies active machines that you can later input into a scanner. Most scanner tools will accept a cariage return delimited file of IP addresses.

Although there are many different port scanners, they all operate in pretty much the same way. Port scanning software, in its most basic state, simply sends out a request to connect to the target computer on each port sequentially and makes a note of which ports responded or seem open to more in-depth probing. There are a few basic types of TCP port scans, the most common of which is a SYN scan (also called a SYN stealth scan), named for the TCP SYN flag, which appears in the TCP connection sequence (the handshake). This type of scan begins by sending a SYN packet, responding with a SYN/ACK response if the port is open, or an RST if the port is closed. This is what happens with most scans: a packet is sent, the return is analyzed, and a determination is made about the state of the system or port. SYN scans are relatively fast, and relatively stealthy, since a full handshake does not occur. Since the TCP handshake did not complete, the service on the target does not see a connection, and does not get a chance to log.

Port Scanning Methods

Other types of port scans that may be used for specific situations include port scanning with various TCP flags set, such as FIN, PUSH, and URG. Different systems respond differently to these packets, so there is an element of OS detection when using these flags, but the primary purpose is to bypass access controls that specifically key on connections initiated with specific TCP flags set.

One of the more interesting port scanning options for nmap is the FTP bounce scan. RFC 959 specifies that FTP servers should support “proxy” FTP connections. In other words, you should be able to connect to an FTP server’s protocol interpreter (PI) to establish the control communication connection. Then you should be able to request that the server-PI initiate an active server data transfer process (DTP) to send a file anywhere on the Internet. This protocol flaw can be used to post virtually untraceable mail and news, hammer on servers at various sites, fill up disks, and try to hop firewalls. The FTP bounce scan can be done with nmap using the -b flag.

Here is a summary of a few nmap options:

nmap Switch Type of Packet Sent Response if Open Response if Open Response if Closed
-sT OS-based connect() Connection Made Connection Refused or Timeout Basic nonprivileged scan type
-sS TCP SYN packet SYN/ACK RST Default scan type with root privileges
-sN Bare TCP packet (no flags) Connection Timeout RST Designed to bypass non-stateful firewalls
-sW TCP packet with ACK flag RST RST Uses value of TCP Window (positive or zero) in header to determine if filtered port is open or close
-b OS-based connect() Connection Made Connection Refused or Timeout FTP bounce scan used to hide originating scan source

External Links:

RFC 1122 at

The Art of Port Scanning at

nmap documentation (in 16 different languages) at

© 2013 David Zientara. All rights reserved. Privacy Policy