Port Scanning Test Configuration for IPv4 and IPv6

CDRouter includes port scanning test cases in the firewall.tcl module which will probe the WAN interface of the DUT for open TCP and UDP ports over IPv4. These open ports provide services either by the DUT or forwarded to internal LAN clients. Users of the CDRouter IPv6 expansion will find they can also perform similar tests over IPv6.

Although there are certainly legitimate uses of port scanning, the vast majority of it occurs on the public Internet and is directed toward the WAN ports of random CPEs. The traffic is usually unsolicited from an unidentified source. This source could be as malicious as a human attacking a specific institution, or as mundane as a network inventory probe with a typo. Regardless of intent, we will simply refer to this source as the Remote Party.

When the Remote Party attempts to port scan a CPE, they will typically chose a TCP or UDP port, use an appropriate technique to scan the port, and then increment to the next highest port. After some time, a profile has been built for the Remote Party to examine. This profile is essentially a list of open, closed, and stealth ports. Combined with a list of well-known ports, the Remote Party can then articulate which services the CPE is offering, either directly or by forwarding to a private LAN client.

Unfortunately, since CPEs reply to packets in slightly different ways, they effectively create a fingerprint of sorts. After enough traffic has been sampled, it is possible to determine which operating system the CPE is running. The Remote Party can then simply look up any exploitable software bugs for that fingerprint.

An open port is a port that replies to a probe. A TCP probe can construct a stateful connection with an open TCP port. Since UDP probes do not construct a state, it is impossible to send the expected data payload in a UDP probe to an unknown service. An open port might send a UDP response indicating an error, or may simply not reply at all. Closed TCP ports will send a RST packet, and closed UDP ports will send an ICMP Port Unreachable packet. Stealth ports are the most difficult to determine, as the CPE is configured to silently discard the probe with no response to the Remote Party. It remains unknown whether the probe was lost on the way to the CPE, ignored, or replied to but lost on the way back to the Remote Party. Some port scanners retry the same probe multiple times, to reduce the likelihood of lost packets. Since stealth configuration is the most common for a CPE, CDRouter treats it is the default behavior for a port.

Port Scanning in CDRouter

To configure CDRouter’s port scanner, there is a pair of testvars that signify the start and end ranges for port scanning tests. These testvars affect the behavior of both the IPv4 and IPv6 port scanning tests, included in firewall.tcl and firewall-v6.tcl, respectively.

    testvar portScanStart         0
    testvar portScanStop          2048

This example configuration will configure CDRouter to begin its port scanning at port 0, and to finish at port 2048. Note that port 0 is a special port reserved for use by the operating system, and sending probes on this port can yield interesting behavior.

    testvar portScanDelay         1

The portScanDelay testvar indicates how long to wait between subsequent port probing. Measured in milliseconds, a value of 1000 will wait for a full second. Increasing this value may allow some CPEs to recover from what is effectively a denial of service attack, as they cannot cope with providing so many resources in such a short duration.

Because CDRouter expects that all ports are in a stealth state by default, there is a testvar that allows TCP and UDP ports to be defined in the open or closed state. For IPv4 transport:

    testvar firewallTcpOpenPorts  "22 443 70-72"
    testvar firewallTcpClosedPorts "2323"

This example configures TCP over IPv4 ports 22 and 443 as open, which are typically SSH and HTTP/SSL services. Ports 70, 71, and 72 are open since they have been listed in range format. Port 2323 has been marked as closed, so CDRouter will expect an active reset of the probe sent to that port. To specify ports 6000 and 6010 as closed, as well as 7000 through 7999:

    testvar firewallTcpClosedPorts  "6000 6010 7000-7999"

UDP ports are configured in an almost identical manner.

    testvar firewallUdpOpenPorts  "1234"
    testvar firewallUdpClosedPorts "113"

If you have CDRouter IPv6 available, you can perform port scanning over IPv6 using the following testvars:

    testvar ipv6FirewallTcpOpenPorts "22 80 443 8080 300-349"
    testvar ipv6FirewallTcpClosedPorts "25 110 143"

    testvar ipv6FirewallUdpOpenPorts "50000 51000"
    testvar ipv6FirewallUdpClosedPorts "4080 600-700"

The IPv4 and IPv6 firewall testvars ipv6FirewallTcpClosedPorts, ipv6FirewallUdpClosedPorts, firewallTcpClosedPorts and firewallUdpClosedPorts support the special keyword all to indicate that all the ports not explicitly open will instead send reset packets. This is intended for devices that do not silently discard connection requests to blocked ports.

Differences between IPv4 and IPv6 in CDRouter

There is a significant model change to port scanning when the network layer protocol changes from IPv4 to IPv6. The canonical modern-day IPv4 network employs Network Address Translation of some variety at the network gateway. Clients with private addresses (RFC 1918) have NAT applied to their packets. The NAT gateway records a table of related connections to determine which is the correct internal client for response packets. Because of this, the NAT device is the final routable address for these response packets. The last step of delivering the packet to the LAN client is a special case and is simply the NAT gateway manually delivering the packet using implicit knowledge it gathered. The entire association of the NAT gateway and all of its internal clients is effectively one Internet entity.

Since the LAN client doesn’t have a routable IP address, new sessions from the Internet cannot directly send packets to the client. All sessions must be originated by the client, which creates the temporary association in the NAT gateway, allowing return packets. New sessions from the Internet can target only the WAN address of the NAT gateway. This is true of all port scanning software. In the case of CDRouter, all of the port scanning activity will probe the WAN address of the CPE. The port might be in stealth mode, or closed. It might be open. The CPE might run an application service locally on a port, or it might forward the port to a specific LAN client. If a CPE forwards every unconfigured port to a default LAN client, this client can be said to exist in the DMZ, or Demilitarized Zone (this standard name is a visual metaphor of a hostile area).

In the case of IPv6, the LAN clients have global, routable addresses. This is identical to the pre-NAT IPv4 model. New sessions are able to directly address LAN clients, and so the implicit security by obfuscation that NAT provides is no longer realized. CDRouter uses this model and sends packets directly to the LAN client in all the IPv6 Port Scanning tests. The firewall tests therefore are not port scanning the firewall itself, even though it is the firewall that denies or allows the port scan to continue on to the LAN client.

In general, it can be described that the IPv4 port scan tests are sent to the CPE, but the IPv6 port scan tests are forwarded through the CPE.