During a penetration test we were confronted with rather unique requirements:

The requests should be performed as efficiently as possible without triggering an alarm in the system.

Because the target’s infrastructure was not maintained by our client (also our target) but by one of their external partners, we were not to involve the third party in our security testing. At that point, we didn’t know about the ideal timing behaviour of our requests. But this would play a crucial role in our mission in order to perform automated requests during an early phase of the testing. So we found ourselves at crossroads.

Efficiency vs. Camouflage

Research

In order to best gauge our possibilities of access we gathered information relating to the detection of many requests (typically during a portscan or a flooding). We defined the threshold using two values:

1. Number of accesses
2. per time unit (in our case, seconds)

To find this data for commonly used products, we used the following sources:

• Documentation (online help, manuals, screenshots)
• Testing (download and installation)
• Source code (if available, i.e. Snort)
• Discussion (forums, rather unreliable)

Results

In the following table, the number of requests (Req) per second (Sec). in order to get a unified number that can be compared, we complied the value nr/1S, the number of requests (nR) per second (1S). The arithmetic average of this number is 85.928.

Some factors stood out. All of them didn’t make our work easier:

• Many a product offers port scan detection, but only permit to activate or deactivate this feature. There are no details or options for granulated settings (requests/second).
• Some vendors that are known for buying other companies and products offer very inconsistent basic settings across their products. Examples include Juniper. Contrary to that behaviour is Checkpoint with a rather unified set of values (30 requests / 20 seconds).
• Vendors tend to use different units of time for testing. Short backlogs deliver high performance and long backlogs deliver a high rate of detection of long scans. Ranging from 0.3 seconds in Sophos to 10 minutes in Inmon Traffic Sentinel, we found a plethora of values. Products with extremely long units of time ranging in the area of hours have been excluded on purpose.

Summary

A reliable guideline for the threshold of port scan detection is the standard value of Checkpoint products. Thirty requests over twenty seconds is a maximum average of 1.5 packets per second, which is the median of the values in this article.

If you are confronted with the same paradoxical requirements as we were then you should go for approximately 1.3 packets per second in order to remain undetected. The offset of 0.2 was chosen as a buffer in order to be absolutely safe and undetected. Using nmap we enabled the switch —max-rate 1.3 in order to maintain that rate.

However, this view is only capable of dealing with standard settings of any product. The further recommendations by vendors, clients and experts as well as the settings that end up being used have to be looked at on an individual basis.

About the Authors

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Oliver Kunz has been in information security since 2010. Mainly, he deals with incident response, forensics and the security of mobile devices.

Links

• http://nmap.org/book/man-performance.html