Open Source Tools: Part One (nmap)

open source toolsNow that we’ve described the concepts of port scanning, enumeration and fingerprinting, it is time to discuss implementing them with open source tools. This article will cover two categories of tools: scanning tools and enumeration tools.

Port scanners accept a target or a range as input, send a query to specified ports, and then create a list of the responses for each port. The most popular scanner is nmap, written by Fyodor, and which is available from There are several open source tools for scanning, but Fyodor’s multipurpose tool has become a standard item among penetration testers and network auditors.

Open Source Tools: Using nmap

Before scanning active targets, consider using the ping sweep functionality of nmap with the -sP option. This option will not port scan a target, but will simply report which targets are up. When invoked as root with nmap -sP ip_address, nmap will send both ICMP echo packets and TCP SYN packets to determine if a host is up. However, if you know that ICMP is blocked, and don’t want to send those unnecessary ICMP packets, you can simply modify nmap’s ping type with the -P option. For example, -P0 -PS enables a TCP ping sweet, with -P0 indicating “no ICMP ping” and -PS indicating “use TCP SYN method.” By isolating the scanning method to just one variant, you increase the speed as well, which may not be a major issue when scanning only a handful of systems, but when scanning multiple Class C networks, or even a Class B network, you may need the extra time for other testing.

If nmap can’t see the target, it won’t scan unless the -P0 (do not ping) option is used. Using the -P0 option can create problems, since nmap will scan each of the target’s ports, even if the target isn’t up, which can waste time. To strike a good balance, consider using the -P option to select another type of ping behavior. For example, the -PP option will use ICMP timestamp requests, and the -PM option will use ICMP netmask requests. Before you perform a full sweep of a network range, it might be useful to do a few limited tests on known IP addresses, such as web servers, DNS, and so on, so you can streamline your ping sweeps and reduce the number of total packets sent and the time taken for the scan.

Capturing the results of the scan is extremely important, as you will be referring to the this information later in the testing process. The easiest way to capture all the needed information is to use the -oA flag, which outputs scan results in three different formats simultaneously: plain text (file extension .nmap), greppable test (.gnmap), and XML (.xml). The gnmap format is especially important to note, because if you need to stop a scan and resume it later, nmap will require this file to continue by using the –resume switch.

In the next article, we will continue our look at open source tools by covering some of nmap’s various options.

External Links:

nmap official site – features nmap news and several open source tools, including security tools

Port Enumeration and Fingerprinting

port enumerationPort Enumeration

Port enumeration is based on the ability to gather information from an open port, by either straightforward banner grabbing when connecting to an open port, or by inference from the construction of a returned packet. There is not much true magic here, as services are supposed to respond in a predictable manner.

Once the open ports are captured, by running a port scanner such as nmap, you need to be able to verify what is running on said ports and thus move one step closer to completing port enumeration. For example, you might assume SMTP is running on TCP port 25, but perhaps the system administrator is trying to obfuscate the service, and is running telnet on that port instead. The easiest way to check the status of a port is a banner grab. Upon connecting to a service, the target’s response is captured and compared to a list of known services, such as the response when connecting to an OpenSSH server.

Some services are wrapped in other frameworks, such as Remote Procedure Call (RPC). On UNIX-like systems, an open TCP port 111 indicates this. UNIX-style RPC can be queried with the rpcinfo command, or a scanner can send NULL commands on the various RPC-bound ports to enumerate what functions a particular RPC service performs.


The next step after port enumeration is system fingerprinting. The goal of system fingerprinting is to determine the operating system version and type. There are two common methods of performing system fingerprinting: active and passive scanning. The more common active methods use responses sent to TCP or ICMP packets. The TCP fingerprinting process involves setting flags in the header that different operating systems and versions respond to differently. Usually, several different TCP packets are sent and the responses are compared to known baselines to determine the remote operating system (OS). Typically, ICMP-based methods use fewer packets than TCP-based methods, so when you need to be more stealthy and can afford a less-specific fingerprint, ICMP is a viable alternative. Higher degrees of accuracy can often be achieved by combining TCP/UDP and ICMP methods, assuming that no device between you and the target is reshaping packets and mismatching the signatures.

Passive fingerprinting provides the ultimate in stealthy detection. Similar to the active method, this style of fingerprinting does not send any packets, but depends on sniffing techniques to analyze the information sent in normal network traffic. If your target is running publicly available services, passive fingerprinting may be a good way to start your fingerprinting. A drawback of passive fingerprinting is that it is less accurate than a targeted active fingerprinting session and relies on an existing traffic stream.

External Links:

Defining Footprinting, Fingerprinting, Enumeration and SNMP Enumeration?? at the World of Information Technology and Security blog

Router Hacking Part 2 (Service Enumeration, Fingerprinting, And Default Accounts at

Fingerprinting at

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

ntop: An Introduction

ntopntop is a network probe that shows network usage. It displays a list of hosts that are currently using the network and reports information concerning the IP and non-IP traffic generated by each host. It is a simple, open source (GPL), portable traffic measurement and monitoring tool, which supports various management activities, including network optimization and planning, and detection of network security violations. In interactive mode, it displays the network status on the user’s terminal; in web mode, it acts as a web server, creating an HTML dump of the network status. ntop was developed by Luca Deri, a research scientist and network manager at the University of Pisa. It started development in 1997, and the first public release was in 1998 (v. 0.4). Version 2.0 was released in 2002 and added support for commercial protocols such as NetFlow v5 and sFlow v2, and version 3.0 was released in 2004 and added RRD support, as well as IPv6 and SCSI/FiberChannel support. Binaries for ntop are currently available for Ubuntu and Red Hat/CentOS.

Advantages of ntop

There are several advantages to using ntop. It is portable and platform neutral; you can deploy it wherever you want with the same look and feel. There are minimal requirements needed to leverage its use. Finally, it is suitable for monitoring both a LAN (by default) and a WAN (if ntop is configured properly).

We can classify the network activity measured by ntop into two categories: traffic measurement and traffic characterization and monitoring. Traffic measurement covers data sent and received, including volume and packets, classified according to network and IP protocol, as well as multicast traffic, TCP session history, bandwidth measurement and analysis, VLAN and AS traffic statistics, and VoIP monitoring. Traffic characterization and monitoring involves observing network flows as well as protocol utilization, ARP and ICMP monitoring, and detection of popular P2P protocols. Monitoring such traffic can be an aid in network optimization and planning which encompasses identification of routers and Internet servers, traffic distribution, service mapping, and mapping network traffic.

In the next article, I will cover integration of ntop into your network.

External Links:

The official ntop site

Traceroute Utility in pfSense

Traceroute Explained


The traceroute command in action under Windows.

In computer networking, traceroute is a computer network diagnostic tool for displaying the route and measuring transit delays of packets across an Internet Protocol network. The history of the route is recorded as the round-trip times of the packets received from each successive host in the route; the sum of the mean times in each hop indicates the total time spent to establish the connection. Ping, on the other hand, only computes the final round trip time to the destination, not the intermediate times. It is defined in RFC 1393.

Traceroute sends a sequence of three ICMP echo request packets addressed to a destination host. The time-to-live (TTL) value, also known as hop limit, is used in determining the intermediate routers being traversed towards the destination. Routers decrement packets’ TTL value by one and discard packets whose TTL value has reached zero. When a packet is discarded because its TTL value reached zero, the router sends an ICMP Time Exceeded message back to the source. Traceroute, on the other hand, sends packets with gradually increasing TTL value, starting with a value of 1. The first router receive the packet, decrements the TTL value and drops the packet. The router sends an ICMP Time Exceeded message back to the source. When the source receives this ICMP message, it sends out a new set of packets with a TTL value of 2. This way, traceroute is able to build a list of routers that the packets traverse, until the destination is reached and returns and ICMP Echo Reply message. The timestamp values returned for each router along the path are the latency values, typically measured in milliseconds.

While traceroute under Windows (invoked with the tracert command) uses ICMP and the original specification called for using ICMP, the command did not initially work well because of the interpretation of RFC 791 (the Internet Protocol RFC) by routing equipment vendors. Thus to fix this, Van Jacobson wrote a variant to traceroute that worked so well and reliably, it was ported to many systems and used as the default. The Van Jacobson version used outbound UDP datagrams from the host running traceroute instead of ICMP. This was the default on any system using the Van Jacobson version of the command, including most BSD and UNIX-type systems. Systems using the Van Jacobsen version also use destination port numbers ranging from 33434 to 33534. The utility under Unix usually has an option to instead use ICMP echo request. If a network has a firewall and operates both Windows and Unix systems, both protocols must be enabled inbound through the firewall for traceroute to work and receive replies. Some traceroute utilities use TCP packets (e.g. tcptraceroute or layer four traceroute).

Using Traceroute in pfSense


Using traceroute in the pfSense web interface.

To use traceroute from the pfSense web interface, first browse to Diagnostics -> Traceroute. At “Host”, set the host to the IP address or hostname of the machine you are trying to trace. At “Maximum number of hops”, set a maximum number of hops for the trace to traverse. At “Use ICMP”, you can check this check box (if not, traceroute will use UDP). Then press the “Traceroute” button to perform the function. The output of the traceroute function will appear below the button.

Note that traceroute can sometimes take a long time to complete. You can click the browser’s stop button at any time to cancel the traceroute and display the results. It should be noted that multi-WAN is not supported by this utility.

External Links:

Traceroute at Wikipedia

How Traceroute Works at

Why traceroute sends UDP packets and not ICMP ones? from Stack Overflow

Traceroute at

Ping Utility in pfSense

The Ping Utility Explained


Using the Ping utility in pfSense.

Ping is a computer network administration utility used to test the reachability of a host on an IP network and to measure the round-trip time for messages sent from the originating host to a destination host. It operates by sending Internet Control Message Protocol (ICMP) echo request packets to the target host and waiting for an ICMP response. In the process it measures the time from transmission to reception and records any packet loss.

RFC 1122, which defines communication layer requirements for Internet hosts, says the following about Echo Requests and Replies:

Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies. A host SHOULD also implement an application-layer interface for sending an Echo Request and receiving an Echo Reply, for diagnostic purposes.

An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded.


This neutral provision results from a passionate debate between those who feel that ICMP Echo to a broadcast address provides a valuable diagnostic capability and those who feel that misuse of this feature can too easily create packet storms.

The echo request (“ping”) is an ICMP message whose data is to be received back in an echo reply (“pong”). The host must respond to all echo requests with an echo reply containing the exact data received in the request message. The echo reply is an ICMP message generated in response to an echo request, and is mandatory for all hosts and routers.

Using the Ping Utility in pfSense

To use the pfSense ping utility, first navigate to Diagnostics -> Ping. Then at “Host”, set the host to the IP address or hostname of the host we are trying to ping. At “Interface”, choose the interface from which to initiate the ping (WAN for remote hosts, LAN for local hosts). At “Count”, use the dropdown set the number of ping requests (anywhere from 1 to 10; the default of 3 is usually sufficient). Then press the “Ping” button to invoke the utility. Sending out ICMP echo requests is often a useful diagnostic tool; however, multi-WAN is not supported with this utility.

External Links:

Ping at Wikipedia

RFC 1122 (which mandates that Internet hosts reply to ICMP echo requests)

Firewall Rules in pfSense: Part One

Firewall Rules: Part One

Firewall: Rules page in the pfSense web GUI.

In the previous article about NAT port forwarding, we used “Add associated filter rule” in order to generate the firewall rule for the Apache web server. We could, however, have chosen “None” for the “Filter Rule Association” and created the rule ourselves. This next article describes how to create firewall rules.

Adding Firewall Rules

In order to do this, first browse to Firewall -> Rules. There will be two pre-configured firewall rules by default: “Block private networks” (for blocking 10.x.x.x, 172.16.x.x, and 192.168.x.x addresses) and “Block bogon networks” (for blocking bogus addresses). There will be at least three tabs: “Floating“, “WAN” and “LAN“. Select “WAN” if it isn’t already selected. Press the “Plus” button to add a new firewall rule. Under “Action”, there are three options: “Pass“, “Block”, and “Reject“. The web GUI has the following explanation of the difference between “Block” and “Reject“:

Hint: the difference between block and reject is that with reject, a packet (TCP RST or ICMP port unreachable for UDP) is returned to the sender, whereas with block the packet is dropped silently. In either case, the original packet is discarded.

In this case, you can leave the default unchanged as “Pass“. Next is the option to “Disable this rule“; we don’t want to do this so leave this box unchecked. At “Interface”, you will again have a choice of “LAN“, “WAN” and whatever other interfaces were configured; choose “WAN“.

Firewall Rules: Part One

Adding a firewall rule in pfSense.

At “Protocol“, there are a number of options in addition to the four listed under NAT port forwarding. “ICMP” stands for Internet Control Message Protocol and is used to send error messages indicating, for example, that a requested service is not available or that a host or router could not be reached. ICMP can also be used to relay query messages. “AH” stands for Authentication Header, which is part of the IPsec suite and provides connectionless integrity and data origin authentication for IP datagrams and provides protection against replay attacks. “IGMP” stands for Internet Group Management Protocol and is a connectionless protocol used by hosts and adjacent routers on IP networks to establish multicast group memberships; it is used for one-to-many networking applications such as online streaming video and gaming, among other uses. “OSPF” stands for Open Shortest Path First, a link-state routing protocol for IP networks that uses a link state routing algorithm and falls into the group of interior routing protocols. “CARP” stands for Common Address Redundancy Protocol, a protocol which allows multiple hosts on the same local network to share a set of IP addresses. Its primary purpose is to provide failover redundancy. Finally, “pfsync” is a computer protocol used to synchronize firewall states between machines running Packet Filter (PF) for High Availability. If is used along with CARP to make sure a backup firewall has the same information as the main firewall. In this case, we should leave the default protocol “TCP” unchanged.

At “Source“, specify “any”, as the “Type” and at “Source Port Range“, also specify any. The “Type” options are the same as the options under “Source” and “Destination” for NAT port forwarding; therefore I will not go into detail on them here. In “Destination“, select “Single host or alias” as the type, and specify (our Apache server) for the “Address”. At “Destination Port Range“, specify “HTTP“. You can leave “Log packets that are handled by this rule” unchecked unless you have reason to log the packets. Specify a “Description” if you wish and press the “Save” button to save the changes.

Firewall Rules: The Source Port Range is Usually Unknown

It should be noted that when a firewall rule is created, the “Source Port Range” is almost always set to “any“. This is because the client decides which port to open on the client computer, which may or may not be the same as the port requested on the server. The source port is an an ever-changing port which the end user probably never knows about. So most of the time, we will not know the Source Port Range of the traffic being allowed in.

In the next article, I will go into some detail on rules governing firewall rules, and some of the advanced options for firewall rules under pfSense 2.0.

External Links:

Firewall Rule Basics at

© 2013 David Zientara. All rights reserved. Privacy Policy