Evasion-resistant network scan detection
© Harang and Mell; licensee Springer. 2015
Received: 26 January 2015
Accepted: 23 April 2015
Published: 9 May 2015
Popular network scan detection algorithms operate through evaluating external sources for unusual connection patterns and traffic rates. Research has revealed evasive tactics that enable full circumvention of existing approaches (specifically the widely cited Threshold Random Walk algorithm). To prevent use of these circumvention techniques, we propose a novel approach to network scan detection that evaluates the behavior of internal network nodes, and combine it with other established techniques of scan detection. By itself, our algorithm is an efficient, protocol-agnostic, completely unsupervised method that requires no a priori knowledge of the network being defended beyond which hosts are internal and which hosts are external to the network, and is capable of detecting network scanning attempts regardless of the rate of the scan (working even with connectionless protocols). We demonstrate the effectiveness of our method on both live data from an enterprise-scale network and on simulated scan data, finding a false positive rate of just 0.000034% with respect to the number of inbound flows. When combined with both Threshold Random Walk and simple rate-limiting detection, we achieve an overall detection rate of 94.44%.
KeywordsIntrusion detection systems Network scanning Algorithms Experimentation Measurement Security
Network scanning – an attempt to enumerate and/or fingerprint hosts and services on some victim network – is a common precursor to an attack, and often has utility in post-incident forensics. As discussed in , precisely quantifying what a ‘scan’ is can be difficult. This is particularly true when one considers parallelized scans (e.g. from a botnet), extremely slow scans attempting to evade detection, and the potential for non-hostile scans. We focus on detecting ‘horizontal’ scans from a single source that attempt to discover the active hosts on a network (e.g., “Ping scans”) or a particular service across a network (e.g., scans for SSH services on port 22). This approach may apply to detecting scanning botnets as each contributing source can be detected individually. We do not detect ‘vertical’ scans that attempt to enumerate the services on a single host.
A highly effective and widely cited method for detecting scanners is the Threshold Random Walk (TRW) algorithm . TRW can often detect single source scanning after only 4 or 5 connection attempts. Related approaches include  and . While effective, these approaches suffer from two limitations: they can be circumvented through mixing probe attempts with accesses to known active hosts, and they cannot handle scans using stateless protocols. Simpler thresholding methods, such as those in [6-9], count probe frequency within some time window and can be circumvented by an attacker slowing down the scan rate.
Thus, there is thus a need for a complementary scan detection method that 1) cannot be circumvented through knowledge of existing hosts, 2) does not require stateful connections or additional information about the internal structure of the defended network, and 3) cannot be evaded by simple rate-limiting approaches. In this paper, we develop such an approach and then show how it can be combined with TRW and simple rate limiting to form a highly effective ensemble approach.
Our method draws on a related insight to that developed with TRW in : since scanners do not know the internal structure of the network they are more likely to access inactive nodes. However, where TRW examines the number of legitimate and illegitimate targets with which each source communicates, we examine the number of sources communicating with each target. This conceptual inversion of the high-level TRW logic enables us to avoid many limitations of TRW (particularly the ability to evade TRW by connecting to operational servers), while retaining TRW’s advantages in terms of rate-insensitivity and rapid detection.
We proceed as follows. In section 2, we present related work and our differentiation from it. In section 3, we present details of our scan detection methodology. Section 4 analyzes the algorithmic execution and memory complexities. Section 5 describes our experimental data, and section 6 provides the empirical results. We conclude in section 7.
A wide variety of scan detection methods have been surveyed in . Perhaps the most influential and significant of those is that of , in which the TRW method is proposed. This approach is based on the observation that in the course of enumerating an unknown network, a scanner will generate a relatively large number of unsuccessful connections; legitimate traffic by contrast should generate unsuccessful traffic only rarely. By examining a ratio of successful to unsuccessful connections, robust and rapid identification of potential scanners can be achieved. A weakness of the algorithm is that a scanner can boost its successful connection count by accessing known good servers, enabling additional probing of unknown addresses prior to detection. If enough known good servers are probed first (e.g., 6 or 7 for the published TRW parameters), TRW will permanently classify the scanner as benign and will ignore any subsequent scanning activity . TRW can be modified to avoid such permanent labelling, but this causes a significant increase in the computation and memory requirements , while still leaving open the ability for an attacker to delay being categorized as malicious by seeding scan activity with accesses to known servers. Another weakness is that TRW only operates on stateful protocols like TCP that clearly define a “failed” connection. This limitation is due to TRW classifying stateless communication as scan activity in situations where there is a lack of bi-directional communication .
TRW has been used as a building block for other work. The work of  describes enhancing TRW with a severity metric to distinguish reconnaissance scanning from peer-to-peer scanning. A ranking metric for a TRW-based method is also applied in  to detect inter-domain scans. The work of  examines a different extension of the TRW method in which the target thresholds for the likelihood ratio are sequentially adapted according to some user-defined acceptable risk for a bounded sequence, thus allowing the TRW method to converge to a decision in (almost surely) finite time. The work of  modifies TRW to allow for scan detection in network backbones where there is asymmetric routing. It considers the ratio of distinct IPs contacted to distinct ports contacted within a time window, and labels IP addresses that show a pronounced asymmetry in either direction (i.e., an extremely high number of IPs contacted on just a few ports or an extremely large number of ports on a limited number of distinct IPs) as potential scanners.
The work of , similarly to TRW, uses a likelihood ratio test, however it focuses on comparing the empirical distribution of benign traffic with that of an assumed uniform distribution of scanning traffic. As noted in , an inaccurate empirical distribution may result in significant false positive results and an assumed uniform distribution of scanning traffic may present detection circumvention opportunities for attackers. Probabilistic methods are also used in  to construct a Bayesian belief network to detect anomalous packets that may be indicative of a scan and a correlation engine to attempt to collect these anomalous packets into sets that suggest scanning behavior. As in , the accuracy of this method depends in large part on the quality of the data used to build the statistical model that represents ‘normal’ traffic.
Other approaches include , in which the tools of social network analysis are applied to graphs constructed from netflow data to detect a wide range of intrusive behaviors, including scans. In , the RIPPER data mining tool is applied to a set of hand-crafted feature vectors in order to learn novel rules to classify network scans.
Simpler threshold based mechanisms (see, e.g., [12-15]), that simply tally connection attempts and alarm if the number of connections attempted by a single IP exceed some threshold within a certain period of time, have also been used. These can be effective for many types of scanning and were implemented in systems such as the Network Security Monitor  and Snort . Later systems such as Bro  elaborated on this initial concept by also tracking failed connections in a side count for particular ports. Such techniques are lightweight and sufficiently effective on unsophisticated scanning activity that they continue to be widely used. More recent developments in this vein examine TCP flags attempting to find unusual sequences of flags, such as FIN flags being sent or received when no already established connection is present , or construct more elaborate feature vectors based on distinct IP counts of successful and unsuccessful connections .
Several methods address detecting groups of collaborating scanners, such as those coordinated through a botnet or other covert distributed system [17-20]. While our approach can detect individual scanners making up such a coordinated effort, we do not attempt to group detected scanners into collaborating groups.
Where # |set| denotes the cardinality of set. The nodes with a high W are those that received communication attempts from a relatively low number of distinct hosts. The nodes with a high S are those that attempted to initiate connections to any such sparsely contacted hosts (the supremum of the edge connected W y scores). And the nodes with a high C made many connections (without reference to the connectivity of the target).
In Figure 1 we provide a simple worked example of the scoring method. We assume that the external IPs are the left partite component, and the internal IPs are the right partite component. The bottom-most external IP is a scanner, and the bottom-most internal IP is an inactive host. As the inactive host receives only a single connection from the scanner, it obtains a W score of 1; this is the largest across the W scores of the internal IPs connected to the scanner, so the scanner obtains an S score of 1. As the scanner contacts 5 internal IPs, it obtains a C score of 5.
Note that this method requires only directed flows from the L component to the R component in order to calculate the relevant scores. This feature allows the in-degree method to function in situations where asymmetric routing exists without any need for modification (c.f. , where the TRW approach required modification to function adequately under asymmetric routing conditions). We do not address this feature directly, but the experience of  suggests that direct deployment of the TRW method under asymmetric routing will be highly problematic.
Algorithm and execution complexity
This method can be implemented using a batch processing approach in time complexity O(mlogm) where m represents the number of flows but can achieve linear time with a slight variation. Most steps are O(m) while the calculations for α and β require O(mlogm) due to the requirement to sort two arrays containing S and C values respectively. If linear time complexity is needed, the calculations for α and β can be reused in subsequent batches provided that the time slices being evaluated are of the same length, or can be approximated through a number of on-line estimators . The memory footprint required is at most O(m) provided one uses an in-place style sorting algorithm (e.g., in-place heapsort).
Extract all flows whose source is in L and whose destination is in R in O(m) time.
Enumerate over all extracted flows to filter out those that do not connect distinct IP pairs. Use a hash table, LRHash, keyed by both IP addresses to determine if a flow connects distinct pairs. A single hash table lookup and insertion takes O(1). Since there are O(m) remaining flows, this operation takes O(m).
Enumerate over the set of flows with distinct IP pairs. For each flow, populate and update a hash table, RHash, by using the destination IP address as the key. For each processed flow, increment a count of source IPs communicating with the destination IP and update a variable containing the inverse of this value (the W metric). This uses O(m) time since there are O(m) flows and hash table lookups and updates are O(1).
Enumerate over the set of flows with distinct IP pairs. For each flow, populate and update a hash table, LHash, by using the source IP address as the key. For each processed flow, increment the count of destination IPs communicating with the source IP (this is the C metric) and append each destination IP to a list (one list for every hash key). This uses O(m) time since there are O(m) flows, hash table lookups and updates are O(1), and appending to a list is O(1).
Calculate the S metric for each source IP by accessing each key in LHash and traversing the local list to look up each destination IP in RHash. Assign S to be the largest W value found in the RHash lookups and store it in LHash. This takes O(m) to access each key, an amortized O(m) to traverse all destination IP lists, and O(1) for the RHash lookup. Overall this is O(m).
Calculate α in O(mlogm) by accessing each key in LHash, building a sorted array of the discovered S values, and extracting the value stored at the index (θ S * length(list)).
Calculate β in O(mlogm) by accessing each key in LHash, building a sorted array of discovered C values, and extracting the value stored at the index (θ C * length(list)).
Compare each source IP in LHash and its S and C values to α and β to identify the scanners in O(m) time.
This batch based algorithm can be executed with overlapping time windows since the linear execution option executes very quickly. The algorithm can then be run in small periodic increments (but still using large time windows), approximating an always-on online solution. A true online algorithm is more difficult to achieve because a single flow can change the S value in O(m) nodes in L. Even more problematic, a newly processed flow indicates that some amount of time has elapsed. Thus, previously process flows may need to drop out of the calculation for W, S, and C values for all nodes. Data structures to accommodate this are computationally expensive and so we suggest using linear complexity, continuously running, overlapping time window, batch jobs as a better solution.
Our data sets consist of network flows, both live and simulated. Each flow contains source and destination IP addresses, port numbers, connection times, and TCP flags (used for TRW analysis).
Our live data was collected for 24 hours from a single network intrusion detection sensor. A total of 5,897,187 flows were observed, involving 454,510 distinct pairs of IP addresses. This data was known a priori to contain one port scan across a substantial portion of a class C subnet.
Each distinct external class C subnet within the data has been replaced with a non-routable subnet selected uniformly at random from the set of non-routable subnets in 10.0.0.0/8.
Each distinct internal class C subnet within the data has been replaced with a non-routable subnet selected uniformly at random from 172.16.0.0/12.
Each final octet within each class C subnet (both internal and external) has been replaced with an octet selected uniformly at random from the range 1–255 (for the sake of simplicity we neglect the reduction in valid IP addresses caused by the assignment of gateway, network name, and broadcast addresses).
We do not report port information, other than noting whether source IP, destination IP, or both exhibit a fixed port during the reported scan.
To augment the live data, we simulate 3 scans by introducing appropriate flow records into the live data. We simulate an ICMP “ping” scan, a TCP SYN scan (with fixed source and destination ports), and a UDP scan (with fixed destination ports). Each simulated scan probes all 255 members of a class C subnet within the network perimeter from a spurious source IP address. Partial and rate-limited scans are simulated by subsampling some proportion of the full scans and distributing their event times uniformly over the duration of the flow being analyzed. Responses from active hosts to the simulated scanning packets were created as follows: ICMP packets generated no response; UDP packets generated either an ICMP Port Unreachable message, a mock UDP response packet, or no response (all with equal probability); TCP packets received an ACK for active hosts (followed by a final RST packet from the scanner). Inactive hosts created no response.
We note that our algorithm does not make use of subnetting information except at the presentation layer, and hence a very sparse scan across a class B subnet (for example, a single random IP within each class C subnet contained within the class B subnet) would yield the same results, however this renders the display of results less compact, and so is omitted for space.
We first used our in-degree algorithm as a guide to discover novel scans within the live network data, as well as the scan known a priori, while examining the impact of various parameter settings. We then explore an ensemble scan detection solution by combining our algorithm with TRW and rate-based scanning. We show how TRW complements our approach by both approaches detecting different sets of scanning IPs. We furthermore show how pre-filtering our in-degree method with a rate-based scanning method can substantially reduce the false positive rate. We then compare our findings against a manual analysis of the same data. For our last data set, we investigate in-degree and TRW detection of the simulated scans injected into the live data. We conclude this section with an analysis of the difficultly of an attacker simultaneously circumventing both our in-degree approach and TRW.
In-degree method results on live network traffic
Cumulative counts greater than or equal to joint values of C and S
Marginal distributions of S and C suggest that the bulk of the data (89.2%) has an S score of 0.333 or less, and 83.3% of the data has a C score of 1 or less. The joint distribution indicates that there is a slight dependence between S and C, with approximately 2.0% (10/509) of the data having both S > 0.333 and C > 1 versus 1.8% if the scores were independent. The data having these values are highlighted in bold in Table 1 (bold italics indicates the presence of scans that were not detected by any combination of methods examined, as discussed below). At the other extreme, approximately 86.4% of our joint data falls into the lower bins in both dimensions (versus an expected value of 74.3% assuming independence). A permutation test yields a one-tailed p-value of 0.0178, indicating slight but significant correlation.
Detailed examination of the 10 external IPs in the bold cells in Table 1 indicated that 2 were false positives. One was determined to be the result of a web-based advertising network rotating through a pool of IP addresses serving auto-refreshing content to 4 otherwise idle hosts. The second was the result of network time protocol (NTP) traffic delivered to 2 otherwise inactive hosts. There was thus a .000034% false positive rate with respect to the number of original flows and .00044% with respect to distinct pairs of IP addresses. By either measure, the false positive rate is extremely low.
Scan detected from live traffic
Value(s) – scan 1
Value(s) – scan 2
Value(s) – scan 3
6 minutes, 7 seconds
7 hours, 48 minutes
ICMP and TCP
SYN or SYN-ACK
SYN or SYN-ACK (TCP only)
Source IP (anonymized)
Varied between 4 values
Destination IPs (anonymized)
84 within 22.214.171.124/24
29 within 126.96.36.199/24
7 within 188.8.131.52/24
110 within 184.108.40.206/24
122 within 220.127.116.11/24
Constant (when TCP)
3 per contact
6 (ICMP) or 1 (TCP) per contact
1 or 3 per contact
Total bytes transmitted
186 per contact
420 (ICMP) or 62 (TCP) per contact
70 bytes per packet
Data bytes transmitted
24 per contact
48 (ICMP) or 8 (TCP) per contact
8 bytes per packet
Of perhaps greater interest are those scans that did attempt some degree of subtlety, presumably to evade traditional rate-based scan detection methods. Scan 3 in Table 2 shows a summary of one such scan detected in the live data by our method, in which just 7 IP addresses were scanned over the course of approximately 7.75 hours. Consultation with network analysts suggests that there is an extremely high likelihood that this traffic represents a deliberate attempt to evade rate-based portscan detection algorithms. Note that the ICMP protocol is not one that is supported by most stateful connection-based scanners , and hence this scan would not have been detected by those methods.
Detection counts by class of scan
Lateral port (TCP)
Lateral port (UDP)
Network enumeration (any)
Composition of methods on live data
We now explore how the in-degree method complements TRW detection and how rate-based detection methods can reduce in-degree false negatives.
TRW and in-degree method
Cross-tabulation of TRW and in-degree detections
Pre-filtering in-degree data with rate-based scanning
Cross-tabulation of TRW and filtered in-degree detections
Table 5 then represents our most important result. Of the 36 known scans in our dataset, the tri-algorithm approach detected 34 of them. 3 were detected solely by the rate limiting approach. 13 were detected solely by TRW. 12 were detected solely by the in-degree algorithm. 6 were detected by both TRW and the in-degree algorithm. The overall detection rate for the tri-algorithm approach was then 94.44%. This compares to individual detection rates of just 50.00% for in-degree, 52.78% for TRW, and 8.33% for rate-limiting. The dramatic increase in the overall detection rate highlights the complementary nature of these three algorithms.
We performed a manual analysis of the inbound traffic subset of the 5.9 million flow records identified above, using a variety of internal analysis and aggregation tools, as well as direct examination of the flows. This required significant analyst effort and thus is a completely infeasible method for routine scan detection. Our analysis revealed the 2 scans not detected by any automated detection method, both contained within the darker shaded cells in Table 1. These two appeared to be service enumeration scans, resulting in higher S scores for each scanned host as multiple services were requested. Note that as this was a manual analysis, we cannot rule out the possibility of additional false negatives. Reducing the threshold for S to 0.250 would have successfully detected both such scans at the cost of an additional 5 false positives (we also note that proposed modification to the TRW described in  would have enabled the TRW method to detect them). 25 external hosts also delivered a single contact to nodes which had not received any other traffic. While these cannot be ruled out as extremely slow scan attempts, they were determined to be most likely the result of misdirected traffic.
As successful connections are only defined for TCP connections, the TRW method was applied only to the simulated TCP scans. Results are given in Figure 4. While the TRW method did successfully identify the majority of simulated scans as the number of probes per IP address approached 10, the success rate was markedly less than that of the in-degree method. The TRW results for probes 1–5 were expected as the construction of TRW requires a sufficient history of failed probes in order to be able to alert on a scan. The deficiency of TRW when compared to in-degree for probes 6–10 reflects the fact that probes to active services (prevalent in this subnet) can camouflage scanning activity against TRW detection. Conversely, in the operational data in section 6.2, scans generally involved a large number of probes per scan, resulting in a much higher TRW performance.
While the in-degree method shows excellent performance when detecting random scans on the basis of low in-degree count, our false negative and rate-limited scan results point out a potential evasion technique: generating multiple connections to each host from distinct IP addresses in order to artificially decrease the S scores. Preliminary work has shown that under modest assumptions, it is not difficult to construct a ‘chaff’ set of connections from a set of scanning IP addresses that will reduce the S scores sufficiently to avoid detection under this method, while simultaneously maintaining a low enough rate to evade rate-based intrusion detection systems. As shown above, however, the TRW method of  forms an excellent complementary method to ours (for TCP based scans) such that it will be difficult for an adversary to avoid both detectors simultaneously. The TRW method and its variants can be evaded by maintaining a sufficiently high ratio of successful to unsuccessful connections [1,3] while our method ultimately forces a potential attacker to create numerous unsuccessful connections to evade detection. In order to simultaneously maintain both a non-alerting TRW score and a non-alerting S score, the total number of connections that the attacker must therefore create per inactive IP address probed to avoid detection increases significantly. However, note that there are no limits on the rate at which any feasible covert scanning may be accomplished. By reintroducing rate-based detection methods, which limit the total rate of connections regardless of status, the combination of these three methods places limits on the total rate at which new IPs can be scanned without detection. In future work, we will investigate the synthesis of the three methods and theoretical limits on the potential for covert attacker scanning rates.
We have presented a novel approach to scan detection that operates in a complementary fashion to the Threshold Random Walk (TRW) method of . Instead of just providing another scan detection methodology, our approach detects previously unmitigated TRW circumvention activity as well as activity that operates using connectionless protocols. Our novel method has a low time complexity, and has been applied to real-world network data both alone and in conjunction with the TRW and rate-limiting scan detection methods. The in-degree method is shown to detect scans not identified by the TRW method, and to do so with increased accuracy when the data is pre-processed to remove scans detected by a simple rate-limiting method. Further application to randomly generated scans have shown that – under the assumption that target IPs are picked at random from the available addresses in the subnet, and the subnet in question is not completely allocated – the in-degree method is extremely effective at picking out novel scans. While doing this, the in-degree method maintains a very low false positive rate.
We combined in-degree method with TRW and simple rate limiting to form a highly effective ensemble algorithm. Since TRW and in-degree work using distinct data sets (internal node behavior versus external node behavior), the combination makes it extremely difficult for scanners to operate without detection and mitigates known circumvention approaches. Deliberately connecting to know active hosts prior to probing unknown addresses to circumvent TRW is likely to be detected by in-degree and ‘chaff’ connections designed to circumvent in-degree are likely to be detected by TRW.
Internet Control Message Protocol
Transmission Control Protocol
Threshold Random Walk
User Datagram Protocol
This research was sponsored by the U.S. Army Research Labs and the National Institute of Standards and Technology (NIST). It was partially accomplished under Army Contract Number W911QX-07-F-0023. The views and conclusions contained in this document are those of the authors, and should not be interpreted as representing the official policies, either expressed or implied, of the Army Research Laboratory, NIST, or the U.S. Government. The U.S. Government is authorized to reproduce and distribute reprints for Government purposes, notwithstanding any copyright notation hereon. The authors would like to thank Harold Booth of NIST for assisting with the initial formulation of the in-degree concept.
- J Jung, V Paxson, AW Berger, H Balakrishnan, “Fast portscan detection using sequential hypothesis testing,”. IEEE Symposium on Security and Privacy, 2004, pp. 211–225Google Scholar
- M Bhuyan, DK Bhattacharyya, JK Kalita, “Surveying Port Scans and Their Detection Methodologies”. Comput J 54(10), 1565–1581 (2011)View ArticleGoogle Scholar
- P Mell, R Harang, “Limitations to Threshold Random Walk and Mitigating Enhancements,”, in First IEEE Conference on Communications and Network Security (submitted), 2013Google Scholar
- V Falletta, F Ricciato, “Detecting scanners: empirical assessment on a 3G network”. Int J Network Secur 9(2), 143–155 (2009)Google Scholar
- L. Aniello, G. Lodi and R. Baldoni, “Inter-domain stealthy port scan detection through complex event processing.,” Proceedings of the 13th European Workshop on Dependable Computing. (ACM, Pisa Italy, 2011)
- X Chen, “New Sequential Methods for Detecting Portscanners,” arXiv preprint, 1204(1935), 2012Google Scholar
- A Sridharan, T Ye, S Bhattacharyya, Connectionless port scan detection on the backbone. Performance, Computing, and Communications Conference, 2006View ArticleGoogle Scholar
- C Leckie, R Kotagiri, A probabilistic approach to detecting network scans. Network Operations and Management Symposium, 2002, pp. 359–372Google Scholar
- S Staniford, JA Hoagland, JM McAlerney, Practical automated detection of stealthy portscans. J Comput Secur 10(1/2), 105–136 (2002)Google Scholar
- Q Ding, N Katenka, P Barford, E Kolaczyk, M Crovella, Intrusion as (anti) social communication: characterization and detection. Proceedings of the 18th ACM SIGKDD international conference on Knowledge discovery and data mining, 2012, pp. 886–894Google Scholar
- GJ Simon, H Xiong, E Eilertson, V Kumar, Scan detection: A data mining approach. Proceedings of the Sixth SIAM International Conference on Data Mining, 2006, pp. 118–129Google Scholar
- LT Heberlein, GV Dias, KN Levitt, B Mukherjee, J Wood, D Wolber, A network security monitor. IEEE Computer Society Symposium on Research in Security and Privacy, 1990, pp. 296–304Google Scholar
- M Roesch, Snort -- lightweight intrusion detection for networks. Proceedings of the 13th USENIX conference on System administration, 1999, pp. 229–238Google Scholar
- V Paxson, Bro: a system for detecting network intruders in real-time. Comput Netw 31(23), 2435–2463 (1999)View ArticleGoogle Scholar
- M Dabbagh, AJ Ghandour, K Fawaz, WE Hajj, H Hajj, Slow port scanning detection. 7th International Conference on Information Assurance and Security, 2011, pp. 228–233Google Scholar
- M Alsaleh, PCV Oorschot, “Network scan detection with LQS: a lightweight, quick and stateful algorithm”. Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security, 2011View ArticleGoogle Scholar
- C Gates, “Coordinated scan detection”. Proceedings of the 16th Annual Network and Distributed System Security Symposium, 2009Google Scholar
- R Baldoni, GAD Luna, L Querzoni, “Collaborative Detection of Coordinated Port Scans”. Midlab Technical Report, 2012Google Scholar
- M Kang, J Caballero, D Song, “Distributed evasive scan techniques and countermeasures,”. Detection of Intrusions and Malware, and Vulnerability Assessment, 2007, pp. 157–174Google Scholar
- Y Zhang, B Bhargava, Allocation Schemes, Architectures, and Policies for Collaborative Port Scanning Attacks. J Emerg Technol Web Intell 3(2), 154–167 (2011)Google Scholar
- M Greenwald, S Khanna, Space-efficient online computation of quantile summaries. ACM SIGMOD Record 30(2), 58–66 (2001)View ArticleGoogle Scholar
This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/4.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly credited.