Last updated at Sat, 19 Aug 2017 16:36:05 GMT

In the challenge of network security there are many great tools at your disposal. Some of these tools are the IDS/IPS and Firewall. An IDS will detect an attack, relay the info to the IPS which will help prevent it. Firewalls generally block stuff (IP or port related), and also tend to have some basic IDS/IPS functionality.

What is a Tarpit?

A Tarpit is a service generally found on IDS/IPS and Firewalls as well as servers, that delay or shroud incoming connections. Basically when port scanning, the scanner gets stuck for hours, days, or even months trying to get past it with any sort of meaningful data.

Tarpits are actually a really good network security device, and their ability to shroud targets by responding to all connections requests on behalf of the downrange device can be a scanner killer (this is generally a good thing). It also means that if scanned by Nexpose which in turn uses Nmap, and it scans for say 65,000 TCP ports to see which is open, it is going to get back 65,000 tcp ports as open. This in itself is just shrouding the ports that are truly open, the big challenge is when it comes to fingerprinting all of those ports. I.e. 65,535 fingerprints, most of which fail and/or time out, which translates to a scan that seems to hang or go on for days, weeks, months.

Even if it takes a second per port to fail on a fingerprint, that would be 65,535 seconds.  That is over 18 hours, and if there are more devices in scope it could take much longer.

As we can see from the above, Tarpits can be ‘A Nexpose Killer. Now what? How do we solve this issue, yet still maintain the security? We want to improve our security not make it worse just so we can scan?

Fortunately, there is hope. The following are solutions, in order, starting with the Best, ending with the least:

  1. Attempt scanning using Full connect in the scan template
    1. The TCP three way handshake may confuse Tarpits as most are only smart enough to respond to SYN requests (most).
  2. Whitelisting the scan engine from the IDS/IPS/Tarpit Server/Firewall ***
  3. Placing a Nexpose scan engine on the other side of the Tarpit (within the same network as the devices being scanned)
  4. Implement Custom Nexpose fingprinting timeouts based on time or subsequent failures.
    1. I am not a fan of using a timeout as a solution as  they will decrease the accuracy for devices behind tarpits, however they will cut out the massive scan time increases.
      1. When you don't know which devices are behind the Tarpit when initially scanning say a Class B, it is usually nice when the scan actually finishes so you can then implement one of the above prevention steps.
      2. This would be a good scenario to use a Custom timeout solutions.
      3. Below are two solutions we can use if you are running into this issue, and just want to get through the scan:
echo "com.rapid7.nexpose.fingerprinter.port.exceptionWhenConnectionResetByPeer=true" >> /opt/rapid7/nexpose/nse/CustomEnvironment.properties
echo "com.rapid7.nexpose.fingerprinter.protocol.device.timeout=900">> /opt/rapid7/nexpose/nse/CustomEnvironment.properties

*** The one challenge with most IDS/IPS/Tarpit's and even some Firewalls is that the security admin or sometimes even the network team may not know they are there. It might be a special device that only the CSO knows about, or a tarpit that was implemented by an employee that left the company 5 years back. The best way to help find these devices when you think they might be there but are just not sure is a traceroute. I am not a big fan of traditional traceroute tools, however the traceroute built into Nmap has been very effective.

On a Nexpose Linux install one could use the built in Nmap to use traceroute to determine a traffic path within a network using the following:

/opt/rapid7/nexpose/nse/nmap/nmap --traceroute <IP ADDRESS>

Hopefully all of the above info helps when running into Tarpits. Let me know if there are any thoughts or discussion points.