Beyond the Horizon: Uncovering Hosts and Services Behind Misconfigured Firewalls

Qing Deng Juefei Pu Zhaowei Tan

University of California, Riverside University of California, Riverside University of California, Riverside
qdeng010@[Link] jpu007@[Link] ztan@[Link]

Zhiyun Qian Srikanth V. Krishnamurthy

University of California, Riverside University of California, Riverside
zhiyunq@[Link] krish@[Link]

Abstract—Public IP addresses can expose devices and services connections1 (with a few exceptions if the end device is a
to risks such as port scanning and subsequent cyberattacks. server). They may also restrict outbound traffic to a few
Therefore, firewalls are extensively deployed and play a critical essential protocols, e.g., HTTP and DNS. Such a firewall is
role in enforcing security policies and preventing unauthorized supposed to minimize the attack surfaces of the end devices.
access. However, vulnerabilities can allow firewalls to be by- However, this belief is not always true, as misconfigured
passed, effectively nullifying the protection. firewalls can fail silently in response to simple yet carefully
In this paper, we present the first comprehensive study of a crafted network traffic, exposing protected hosts and ser-
previously understudied attack surface: firewall misconfigura- vices to external attackers. For example, when configuring a
tions that inadvertently expose protected services to the public firewall to allow accessing HTTP websites, the administrator
Internet. Specifically, we demonstrate flawed firewall rules that may inadvertently allow any inbound traffic from TCP port
allow inbound connections from special source ports to bypass 80, creating a loophole that permits any inbound TCP con-
the firewall, and explore the prevalence and security implica- nection from port 80. Similarly, allowing DNS traffic might
tions thereof. To this end, we scan the IPv4 space for 15 com- unintentionally open up the firewall to any inbound UDP
monly high-risk TCP and UDP services from two special source datagrams from source port 53. Similar misconfigurations
ports. Our measurement reveals the widespread existence of have previously occurred in Windows 2000/XP/2003 [12]
such misconfigurations and identified over 2,000,000 otherwise and Mac OS X Tiger [13], which allowed connections from
unreachable services spread over 15,837 autonomous systems, certain ports to bypass their built-in firewalls. Although this
expanding the “observable Internet” for various protocols by vulnerability is documented in the Nmap manual [14], it has
up to 12.60%. More importantly, the affected services generally
been long forgotten and overlooked, and no comprehensive
study has been conducted. The prevalence, security implica-
exhibit higher security risks than the publicly accessible ones,
tions, and real-world exploitation of such misconfigurations
like outdated software versions and weak configurations. De-
in today’s Internet remain unknown.
spite the severity of this vulnerability, our honeypot experiment
Our Study. We conduct the first comprehensive study
provides little evidence of active exploitation in the wild.
of firewall misconfigurations of this type, which mistakenly
Our findings offer insights for better security posture and
allow undesired connections to bypass the firewalls. We aim
network administration, helping researchers and organizations
to quantify the prevalence and security implications of this
anticipate and mitigate potential cyber threats emanating from
understudied attack surface. To this end, we identify the
the Internet.
affected services in the IPv4 address space and analyze their
security risks.
1. Introduction Specifically, we scan the IPv4 space targeting 15 com-
monly high-risk services (e.g., SSH, HTTP, and MongoDB)
The public Internet is constantly being scanned [1], [2], and identify those that are only accessible from specific
[3], [4], [5], [6], often by malicious actors as a prelimi- unusual source ports. The result confirms the widespread
nary step in cyberattacks [1], [7]. Devices with public IP existence of firewall misconfigurations of this kind. By
addresses are subject to such probes, and attackers actively initiating connections from TCP port 80 and UDP port 53,
try to compromise reachable hosts by exploiting vulnera- we uncover over two million services that would otherwise
bilities like software defects, configuration flaws, and weak remain unreachable, including over 800 thousand manage-
passwords [8], [9]. Unsecured hosts may be compromised ment services (SSH, Telnet, RDP, SNMP, and IPMI). The
within minutes [10], [11]. As a result, firewalls are widely
deployed to protect devices and their services by blocking 1. For the sake of convenience, we refer to the sessions of connectionless
unwanted access. Typically, these firewalls block all inbound protocols like UDP also as connections.
affected hosts are distributed across 15,837 autonomous topology and connectivity across different regions [18], [19].
systems (ASes) and 221 countries and regions. With this By probing the accessible hosts and services, it maps the
firewall circumvention technique, we are able to reach up Internet and collects large-scale empirical data for analysis.
to 12.60% more services, with the ratio varying by protocol, Due to the importance of Internet-scale measurements,
expanding the observable Internet to a great extent. numerous techniques have been developed to facilitate In-
Notably, we find that the affected generally exhibit ternet scanning. ZMap [20] democratized fast Internet-wide
higher security risks than public services, such as outdated surveys. Masscan [21] is capable of scanning the IPv4 space
software versions and weak ciphers. Furthermore, we iden- in minutes with 10-gigabit Internet connections. While the
tified hundreds of unprotected SMB shares and MongoDB immense space of IPv6 precludes full scans, there have been
databases. This indicates that these misconfigured firewalls works utilizing heuristics and/or machine learning [22], [23],
provide a false sense of security. We also observe over ten [24] to pinpoint scannable subspaces.
thousand vulnerable home routers that may be compromised There are also platforms that spare researchers the bur-
from the public Internet and one public cloud that provisions den of managing their own scanners. Search engines like
flawed default firewall rules to virtual machines. Shodan [25], Censys [26], and FOFA [27] periodically probe
To investigate whether such misconfigurations are ac- the Internet, and users can search for hosts and services of
tively exploited in the wild, we carry out a honeypot exper- interest. RIPE Atlas [28] is a global network measurement
iment over four months. While our study shows no evidence platform where users can distribute measurement tasks to
of large-scale exploitation of this attack surface in the wild, tens of thousands of crowdsourced probes around the world.
its widespread presence should trigger an alarm for network Unfortunately, besides research purposes, Internet scan-
administrators and security researchers. We hope that the ning is largely abused by attackers for malicious activities.
insights in this paper can help improve security posture and In general, attackers scan ports where vulnerable services
benefit various sensitive applications. reside [7]. After identifying the hosts running the target
Disclosure. We perform responsible disclosure to the services, attackers try to exploit them by different means.
15,837 ASes with affected hosts and set up a website to They may try to compromise the hosts by exploiting soft-
explain this vulnerability and provide fix suggestions. In ware vulnerabilities or brute-forcing [8], [9] and use these
total, the website has been viewed by recipients from 1,436 machines to mine cryptocurrencies or expand botnets [29],
ASes, and we have received inquiries, updates, and letters [30]. Attackers may also exploit configuration flaws to
of thanks from 173 ASes. In the follow-up measurements, launch attacks, e.g., DNS and NTP reflection amplification
we see a noticeable decrease in affected hosts in the most attacks [31], [32], without fully compromising the hosts.
affected ASes. We also disclose this issue to involved parties
whose products are found to contain misconfigurations in 2.2. The Observable Internet
their host-level firewalls.
Contributions. We make the following contributions: The more services we can reach, the more empirical
• We perform the first comprehensive study of an under- data we can collect and analyze. It is also true for attackers
studied attack surface, firewall misconfigurations that in- – they need to reach a service before they can exploit it. In
advertently allow undesired connections, at the Internet this paper, we name the set of reachable Internet services
scale. the observable Internet. Only the services in the observable
Internet can be interacted with by actors on the Internet,
• We confirm the widespread existence of this issue and including performing measurements or launching attacks.
identify over two million affected services in the IPv4 However, despite the huge number of connected devices,
space, with a low false positive rate ensured by our hosts and services are sparse even for the relatively small
multi-pass workflow. IPv4 space. Bano et al. [33] pointed out that only ∼10%
• We analyze the security implications of the affected ser- of IPv4 addresses respond to ICMP pings. Klick et al. [34]
vices and find that they generally exhibit higher security found that only two-thirds of IPv4 addresses are announced
risks than public services. and that they can collect 90-99% of the desired responses by
• While we did not observe any large-scale exploitation scanning at most 75% of the announced IP addresses. The
in the wild in our honeypot experiment, we conduct majority of online devices and their services are concealed
responsible disclosure to the affected parties out of an behind firewalls or NAT gateways.
abundance of caution and receive positive feedback. Researchers have been working on expanding the ob-
servable Internet in different ways. Izhikevich et al. [35]
investigated services on non-standard ports and found that
2. Background and Related Work only 3% of HTTP and 6% of TLS services ran on ports 80
and 443, respectively. They further developed a framework
2.1. Internet Scanning to predict the ports of these misplaced services [36]. Song et
al. [37] also proposed a machine learning method to improve
Internet-wide scanning is crucial for various cybersecu- the hit rate and intrusiveness of uncovering such services.
rity applications, like vulnerability assessment and threat Wan et al. [38] demonstrated the importance of scanning
tracking [4], [15], [16], [17]. It also helps understand the from different geographic and topological locations.
 TCP 80 TCP 42000 TCP 42666 TCP 3389 TCP 80 TCP 3389

SYN SYN ✕ SYN

SYN-ACK SYN-ACK
ACK ACK

(a) Normal traffic is allowed. (b) Attacks from high ports are blocked. (c) Attacks from port 80 are overlooked.
Figure 1: Example of Bypassing Misconfigured Firewalls

There are also techniques leveraging vulnerabilities to packets that neither belong to any known flow nor create a
reach normally unreachable hosts and services. Rytilahti et new flow are discarded. The firewall deletes a flow record
al. [39] found that application-layer middlebox protocols when termination signals like FIN and RST segments are
might be used to bypass NAT gateways and reach internal found. For connectionless protocols like UDP and ICMP,
hosts. Feng et al. [40] utilized the shared-IPID side channel the record expires after a period of inactivity [47]. Most
to penetrate NAT devices. The SYN cookie implementation stateful firewalls, like iptables, also support stateless rules
in old Linux versions allowed attackers to bypass firewall to enhance performance and simplify configuration. With
rules by guessing cookies [41]. Some firewalls dynamically only stateless rules, a stateful firewall operates in the same
open ports for multichannel protocols like FTP and SIP, and way as stateless firewalls.
this feature can be exploited for tunneling any ports [42], Firewall Misconfiguration. As critical guardians of net-
[43]. Two vintage firewall flaws in Windows [12] and Mac works, firewalls mainly rely on manual configurations and
OS X [13] allowed any inbound traffic from certain remote a misconfigured one can be a single point of failure. Hence,
ports, effectively nullifying the system firewalls. firewall misconfiguration has been studied from various
In conclusion, expanding the observable Internet is criti- perspectives, such as automatically modeling and examining
cal to network research and can help anticipate and mitigate firewall rules [48], [49], [50], [51]. Bringhenti et al. [52]
potential cyber threats. Our work contributes a new perspec- proposed an approach to automate firewall configuration.
tive by demonstrating the prevalence and significant impacts The misconfiguration which unintentionally allows inbound
of firewall misconfigurations. connections from specific source ports has been mentioned
in the Nmap manual [53] and some articles available on-
2.3. Firewall line [13], [54]. However, there has been no comprehensive
study on this topic and the security implications thereof in
Firewalls inspect inbound and outbound traffic based on today’s Internet remain unknown. Our work demonstrates
predefined rules, establishing a barrier between the trusted that such misconfigurations are still widespread and have
network and the untrusted network (usually the Internet). alarming prevalence and far-reaching impacts.
Firewalls come in different forms and implementations. In
the context of this paper, the key lies in whether the firewall 3. A Firewall’s Achilles Heel
is able to, or configured to, track network flows, such as
TCP connections and UDP sessions. Based on whether they A single flawed rule can compromise the effectiveness
have this capability, we can categorize firewalls into stateless of the entire firewall. In this section, we demonstrate the
firewalls and stateful firewalls [44]. mechanism, threat model, and behavior patterns regarding
Stateless Firewalls. Stateless firewalls inspect network such flawed rules.
traffic on a per-packet basis, unaware of network flows.
Stateless firewalls only support stateless rules, which permit
or discard packets with specified properties, such as specific 3.1. Mechanism
source/destination addresses and ports. A stateless firewall
matches each packet against the rules and makes the de- Configuring firewalls may seem intuitive. However, sub-
cision solely based on that packet. Consequently, stateless tle intricacies can render it prone to errors.
firewalls are generally incapable of distinguishing between Using stateless rules, it takes two rules to permit access
inbound and outbound connections. While many advanced to external HTTP services: one for user packets to go out
models can filter TCP segments by their flags [45], enabling and another for server packets to come back. In a simplified
them to block inbound TCP connections, it does not extend scenario where only access to HTTP services is allowed, a
to UDP and is absent in the access control lists (ACLs) of network administrator may set up the following rules:
some switches [46]. Stateless firewalls are widely deployed 1) Permit TCP segments from internal hosts to port 80 of
in environments with heavy network traffic, as they offer external hosts.
superior performance and desirable simplicity. 2) Permit TCP segments from port 80 of external hosts to
Stateful Firewalls. Stateful firewalls are capable of internal hosts.
tracking network flows and filtering the packets based on 3) Discard all other IP packets.
their corresponding flows. Stateful firewalls support stateful These rules usually work well as operating systems typically
rules, which permit or forbid network flows with specific use random high ports as source ports by default [55], and
properties. The permitted flows are recorded, and orphan connections to internal hosts are supposed to be rejected by
Rule 3, as shown in Figure 1b. However, suppose an attacker It is worth noting that theoretically, port X may be a high
initiates TCP connections to the protected hosts from port port itself, as the flawed rule may allow any port depending
80. In that case, the initial SYN segment will be permitted by on the exact configuration. There may also be multiple ports
Rule 2, as the firewall is unable to distinguish the connection from which the inbound traffic can bypass the firewall, as
direction. Subsequently, the malicious traffic consistently there may be multiple flawed rules.
adheres to the first two rules, evading the intention of
blocking inbound connections, as illustrated in Figure 1c. 4. Measurement Framework
Similar misconfigurations can happen when allowing UDP
protocols like DNS and NTP, causing a loophole that allows While examining a single service is straightforward, it
any inbound UDP datagrams from source ports 53 or 123. becomes challenging when scaling the scope to the whole
It is unlikely for stateful firewalls with stateful rules IPv4 space. In this section, we discuss how we address the
to undergo the same misconfigurations, as they operate on challenges relating to the Internet-scale measurement.
network flows and do not require a complementary rule Goals. We aim to study (i) the prevalence and (ii) the
to permit returning packets. Still, human errors may lead security implications of the aforementioned firewall miscon-
to flawed rules being added. For example, when allowing figurations at the Internet scale. To this end, we need to:
inbound connections to TCP port 80 of a web server, the 1) Identify the affected services in the IPv4 space.
network administrator might misspell the destination port as 2) Extract the characteristics of the affected services, e.g.,
the source port, allowing any inbound connection from TCP software versions and supported cipher suites.
port 80. In such cases, the examples in Figure 1 still hold. 3) Analyze the security implications of exposure.
Challenges. Networks are dynamic and volatile, and the
3.2. Threat Model Internet exemplifies these characteristics. Packet loss and
region-based filtering rules are commonplace. A host can
We assume an attacker who actively scans the Internet to run any service, and the flawed rule may allow any source
find and exploit vulnerable services. The attacker is remote port to bypass the firewall inadvertently. To address these
and does not have special network capabilities. complexities, we need a robust workflow complemented by
Leveraging flawed firewall rules, the attacker can bypass diverse vantage points, carefully selected scope, and proper
the misconfigured firewalls and reach protected services by tools to ensure both accuracy and efficiency.
simply manipulating the source port of their connections.
The attacker can specify a common port like TCP 80 or 4.1. Workflow
UDP 53 as the source port for all their scanning activities.
The services reached in this manner should be a superset of The core of the workflow is an iterative method to ensure
the result of regular scanning, as scanning from a designated both broad coverage and a low false positive rate (below
port should not obscure the services reachable from random 1%). We denote the chosen source port as the designated
ports. The attacker can also scan from multiple special ports port and the port of the target service as the target port.
to circumvent even more misconfigured firewalls.
Consequently, the attacker can expand their observable Scan IPv4 space Candidate list Response list
desig. port → target port
Internet and obtain more potential targets for their attacks, ►host list

posing a greater threat to the Internet overall.

Probe candidates Scan responsive hosts
Scan hosts in list desig. port → target port high ports → target port
►responses ►irrelevant hosts
high ports → target port
3.3. Behavior Pattern ►irrelevant hosts

Exclude responsive hosts Remove responses

While it is infeasible to inspect the rules of firewalls on Remove irrelevant hosts from further probing from irrelevant hosts
from host list
the Internet directly, we can distinguish an affected service
by initiating multiple connections from different ports and Responsive Responsive
Responsive
observing the responses. No < 1%? No < 1%? No < 1%?

Assume that the affected service is on port P . Normally, Yes Yes Yes

the firewall blocks all inbound connections; however, it erro- Candidate list Response list Validated Responses
neously allows inbound traffic from port X . When initiating
connections from a random high port R and from port X , (a) Identification (b) Probe (c) Validation
we should notice the following differences in responses:
Figure 2: Three-Phase Workflow
• Port P is irresponsive or responds with errors, e.g.,
RST segments or ICMP unreachable messages when the Phase 1: Identify the Affected Hosts. In this phase,
connection is initiated from source port R. we unearth the hosts whose target ports are responsive only
• Port P becomes responsive, establishing the connection when we connect from the designated port. The steps are:
and responding at the application layer, when the con- 1) Scan the IPv4 space targeting the target port from
nection is initiated from source port X . the designated port. The responsive hosts constitute
 the initial host list, including both affected hosts and The process is shown in Figure 2c. The iteration often
irrelevant hosts. finishes in three to five rounds. The validated responses have
2) Scan the host list targeting the target port from random the desired false positive rate below 1%.
high ports. The responsive hosts are the irrelevant hosts After these phases, we parse the validated responses to
because they are reachable from high ports2 . extract the characteristics of the services, such as software
3) Remove the irrelevant hosts from the current host list. versions and supported cryptographic algorithms. We further
4) Repeat Steps 2 & 3 until the response rate is below analyze the characteristics to conclude security risks.
1%, ensuring a low false positive rate. The remaining
hosts form the candidate list. 4.2. Scope Selection
The process is shown in Figure 2a. We adopt the iterative While the IPv4 address space has a relatively manage-
design to circumvent packet loss and other dynamic be- able size, there are numerous (i) possible services and (ii)
haviors. Step 1 incurs most of the cost, which requires a unexpectedly allowed source ports. Given the scale, we have
full scan of the IPv4 space. The following steps converge to restrict our scope to a small number of target services and
rapidly, typically after three to five rounds of scanning a designated ports due to feasibility considerations.
small number of addresses. We believe that the candidate Target Service. To illustrate the prevalence and security
list is a reliable set of affected hosts. implications of firewall misconfigurations of this kind, we
We note that an open port does not necessarily serve the choose 15 common services that are often vulnerable. We
target service, and hosts may go offline at Step 2, causing list the services in Table 1. For services supporting both TCP
false positives. We handle these cases in the next phase. and UDP, we choose the more commonly used protocol, like
Phase 2: Probe the Affected Services. In this phase, UDP for DNS. We divide the services into four categories.
we send application-layer probes and collect the responses Management services are for device management; file shar-
for characteristic extraction. The steps are: ing and database services store user and application data;
1) Send probes (e.g., HTTP or DNS requests) to the target general services include other often exploitable services.
port of the candidate hosts from the designated port. Compromise of these services may lead to device takeover,
2) Record the responses and exclude the responding hosts information leakage, etc. These services have various attack
from further probing. surfaces, such as weak passwords in SSH, Telnet, RDP, etc.,
3) Repeat Steps 1 & 2 until the response rate is below and lack of authentication in FTP, SMB, MongoDB, etc. We
1%, ensuring high coverage. The aggregated responses introduce the attack surfaces of the services in detail in the
constitute the response list. corresponding sections in §6.
The process is shown in Figure 2b. The iteration usually Category Service Port
finishes in three rounds. The responses come from a subset
SSH TCP 22
of the candidates which truly serve the target service and Telnet TCP 23
have not gone offline during the measurement. RDP TCP 3389
We recognize that, despite ensuring a low false positive Management IPMI UDP 623
SNMPv1
rate in Phase 1, a significant number of affected hosts may SNMPv2c UDP 161
either fail to respond to our application-layer probes or SNMPv3
respond with an unexpected protocol due to various factors.
FTP TCP 21
Consequently, the subset of the hosts responding with valid File sharing
SMB TCP 445
responses in Phase 2 may be substantially smaller than
MySQL TCP 3306
the candidate list generated in Phase 1, necessitating an Database
MongoDB TCP 27017
additional verification of the false positive rate. We handle
HTTP TCP 80
this in the next phase. HTTPS TCP 443
Phase 3: Validate the False Positive Rate. In this phase, General
DNS UDP 53
we confirm the desired false positive rate by scanning the NTP UDP 123
affected services from high ports again. The steps are:
TABLE 1: Target Services for Measurement
1) Scan the services in the response list from random high
ports. The responsive hosts are new irrelevant hosts as Designated Ports. Technically, a firewall flaw may mis-
their services turn out to be reachable from high ports. takenly allow traffic from any source port, depending on
2) Remove the responses previously collected from the the specific erroneous rule. However, it is impractical to
irrelevant hosts. enumerate and scan from all 65,535 ports, and we hope to
3) Repeat Steps 1 & 2 until the response rate is below 1%, maintain a balance between coverage and footprint as dis-
ensuring a desired false positive rate. The remaining cussed in §11. We select port 80 for TCP-based services and
responses are the validated responses. port 53 for UDP-based services because their corresponding
protocols (HTTP and DNS) are among the most popular
2. Here we ignore the negligible possibility that the random high port is services on the Internet. According to recent studies on Inter-
the very port that can bypass the firewall. net traffic [56], [57], the HTTP family of protocols (HTTP,
HTTPS, and QUIC) account for the largest share. HTTP is We also develop our own tools in Python to analyze the
the fundamental member of this family. DNS accounts for output of ZMap and ZGrab. We store the data in MongoDB
the majority of UDP traffic besides QUIC and is necessary and ElasticSearch for indexing and querying.
for domain name resolution. Therefore, we presume that
TCP port 80 and UDP port 53 are the ports most likely to 4.4. Threats to Validity
be allowed by the firewalls, and the results should establish
a reliable prevalence. This presumption is also confirmed in We put in our best effort to get reliable and accurate
small-scale preflight measurements with other popular ports results in our Internet-wide measurement. We employ the
(TCP port 22/443 and UDP port 123/443). iterative and multi-pass approach in §4.1 to increase cover-
age and constrain false positives. However, the results may
4.3. Experiment Setup still be affected by the following factors:
Network Volatility. Despite measuring from five vantage
Vantage Points. We employ multiple geographical re- points iteratively, we cannot fully eliminate the impact of
gions to increase the coverage and mitigate packet loss and packet loss. An affected host may be offline for part or all
region-based filtering. This is important because it has been of our measurement period, which is out of our control.
shown that an individual vantage point may miss up to Firewall Strategies. Our probes may suffer from region-
18.2% of the target service [38]. Specifically, we deploy five based filtering rules despite multiple geographical locations.
vantage points in the United States, Germany, Singapore, Limited Scope. Most services do not run on their default
India, and Brazil, respectively. Each vantage point executes ports [35], and firewalls may be misconfigured to allow
every step of the workflow in §4.1, and we merge the results, packets from ports other than the designated ports we select
e.g., responsive hosts, into a union set after each step. The as discussed in §4.2.
vantage points run Debian 12 with kernel 6.1 and are capable Special Networks. Certain networks may route packets
of scanning the entire IPv4 space in about two hours. via multiple paths (e.g., ECMP routing), which may affect
Control Group from Public Services. We hypothesize the observation of middleboxes [60], [61]. Port forwarding
that the affected services face higher security risks because may also introduce a bias on the number of observed hosts.
administrators may be misled by the false sense of security It is hard to quantify the exact impact of these factors as
provided by firewalls, leading to less stringent maintenance their effects are intertwined. Nevertheless, we try our best to
practices. To verify this, we set up control groups for the ser- keep the observed false positive rate below 1% as discussed
vices for which we can safely measure specific weaknesses in §4.1, and give a reliable set of affected services.
(e.g., software versions and weak cipher suites); we do not
set up control groups for services that only have general 5. Overview of Measurement Results
weaknesses (e.g., weak passwords) that require aggressive
detection due to ethical considerations. The control groups We performed our primary Internet-wide measurement
consist of public services (unprotected by firewalls), whose in August 2024. In this section, we showcase the prevalence
hosts are randomly picked from the irrelevant hosts in Step and distributions of the aforementioned firewall misconfig-
2 of Phase 1 in §4.1. Their sizes are comparable to or larger urations. We also highlight the security implications of the
than the sizes of the affected services. We probe these public affected services.
services following Phase 2 of the workflow, except that we
Service Port Count Public Services %
initiate connections from random high ports.3 Finally, we
parse the responses and compare the security risks of the SSH TCP 22 234,984 25,307,484 0.93%
Telnet TCP 23 50,820 2,504,330 2.03%
affected services and public services. RDP TCP 3389 7,931 3,504,675 0.23%
Tools. We leverage two open-source tools for scanning IPMI UDP 623 4,242 59,565 7.12%
the Internet and sending probes to the target services. SNMPv1 42,894
SNMPv2c UDP 161 36,753 19,360,968 2.51%5
• ZMap [20], [58]: ZMap is a fast network scanner for SNMPv3 465,033
Internet-wide surveys. It is capable of specifying the
FTP TCP 21 32,172 7,713,688 0.42%
source port4 . We use it to detect the status of TCP SMB TCP 445 19,419 1,174,742 1.65%
ports and send probes to UDP services.
MySQL TCP 3306 19,456 3,853,048 0.50%
• ZGrab 2.0 [59]: ZGrab is a fast application-layer net-
MongoDB TCP 27017 338 198,470 0.17%
work scanner. It supports interacting with various pro-
tocols, and we enhance it to allow specifying the source HTTP TCP 80 222,539 163,503,752 0.14%
HTTPS TCP 443 193,630 158,488,284 0.12%
port and support additional protocols like RDP. We use DNS UDP 53 334,358 5,287,835 6.32%
it to send probes to TCP services. NTP UDP 123 824,389 6,545,301 12.60%

3. Not all picked hosts respond, possibly due to factors like network TABLE 2: Number of Affected Services
volatility. Hence, the final control group sizes vary (and thus, may appear
random).
4. When no source port is provided, ZMap uses random source ports 5. Calculated based on unique IP addresses as Shodan has no SNMP
from 32768 to 61000, the default ephemeral port range of Linux. version filter.
 Country Count ASN Country Type Count any authentication. We will describe the details relating
Italy 303,446 1267 Italy ISP 231,316 to each service in §6. Note that we did not perform any
USA 290,848 8447 Austria ISP 125,994 aggressive measurements (e.g., guessing weak passwords)
China 216,647 5483 Hungary ISP 121,853 due to ethical considerations.
Austria 130,331 4837 China ISP 79,811
Hungary 123,294 29256 Syria ISP 75,124 Service Security Risks
Poland 108,134 16509 USA Cloud 75,050
Japan 104,464 12741 Poland ISP 54,586 SSH 70,739 (30.10%) with weak cryptographic algorithms;
Brazil 85,869 1680 Israel ISP 47,127 2,695 known to be vulnerable to CVE-2024-6387 [62].
Syria 74,144 4134 China ISP 39,303 Telnet 31 directly present shells without any authentication.
Israel 69,440 15802 UAE ISP 34,514 RDP 2,324 (29.31%) run end-of-life Windows versions.
IPMI 1,264 (29.8%) can lead to full control of servers; 2,772
TABLE 3: Top Countries TABLE 4: Top ASes (65.35%) support insecure authentication.
SNMP 47,117 devices may leak configurations, including
servers, routers, switches, printers, VoIP devices, etc.;
465,033 devices may be fingerprinted or brute-forced.
Prevalence. We found a total of 2,488,958 services on
2,147,229 unique IP addresses affected by the previously FTP 1,833 known to run outdated software; two known to
allow anonymous login.
discussed firewall misconfigurations. We display the detailed SMB 202 unprotected file shares; 642 (63.44% of Windows
numbers relating to each service in Table 2. In addition, we hosts) run end-of-life Windows versions; 10,890 Linux
queried Shodan [25] for the numbers of the corresponding hosts are vulnerable routers.
publicly accessible services6 . We list the figures and the MySQL 10,522 (54.08%) run end-of-life versions.
ratios of the affected services to the public services. It turns MongoDB 790 unprotected databases with sizes up to 1 terabyte.
out that by initiating connections from only two designated HTTP(S) 20,681 (53.54% of those on mainstream web servers)
ports, we can reach up to 12.60% more services. run end-of-life software; 172,622 (89.15%) HTTPS
According to the statistics, the ratios of affected services services serve internal websites; 189,334 (97.78%)
HTTPS services use insecure certificates.
to public services are higher for UDP services than for TCP DNS 212,886 (63.67%) allow ANY queries, possibly ex-
services, especially for the more popular protocols like DNS ploited for reflection amplification attacks.
and NTP. The reason for this phenomenon may be due to NTP 22,244 (2.70%) allow monlist, possibly exploited for
the prevalence of insecure firewall rules for UDP services reflection amplification attacks.
on the Internet, which we discuss in §10.
TABLE 5: Security Risks of Affected Services
Distributions. We identified the locations and ASes of
the affected hosts by their IP WHOIS information. The
affected hosts are located in 221 countries and regions and
belong to 15,837 different ASes. We also list the ten most 6. Analyzing Security Risks by Service
affected countries in Table 3 and the ten most affected ASes
in Table 4. The results suggest that ISPs are most prone to In this section, we present the detailed results from our
such firewall misconfigurations. The complete geographic primary measurements, focusing on the security implications
distribution is shown in Appendix A.1. of firewall misconfigurations on various services.
Besides ISPs and clouds, we also find that many well-
known enterprises have thousands of affected hosts in their 6.1. SSH Services
ASes, such as Apple, Google, Starlink, Alibaba, and Yandex.
This further demonstrates the prevalence of firewall miscon- SSH provides secure remote access over insecure net-
figurations of this type. We list these noteworthy ASes in works. We uncovered 234,984 SSH services behind mis-
Appendix A.2. configured firewalls and picked 753,769 publicly accessible
We also notice a significant long tail in the distribution SSH services as the control group.
of the affected hosts in the ASes. Among the 15,837 ASes, Measurement. We record the banners and handshakes
only 202 (1.3%) have more than 1,000 hosts, accounting for of the SSH services. We determine their software versions
83.07% of affected hosts; only 960 (6.1%) have more than by parsing banners. We also extract the supported crypto-
100 hosts, accounting for 94.27% of affected hosts. graphic algorithms in the handshakes, as weak cryptographic
Security implications. After we extract the characteris- algorithms can compromise the confidentiality and integrity
tics as described in §4.1, such as software versions and sup- of SSH channels as found in the Terrapin Attack [63].
ported cryptographic algorithms, we analyze the potential Analysis. We list the most common vendors of the af-
security risks. We find the affected services are susceptible fected services in Table 6. The result shows that OpenSSH is
to various kinds of attack vectors. We highlight the key secu- predominant (94.8%) while some indicate embedded or net-
rity risks in Table 5. For example, we find that about 30% work devices like dropbear, ROSSSH, Cisco, HUAWEI,
of the affected SSH services employ weak cryptographic and DOPRA. OpenSSH accounts for 76.0% of the control
algorithms and that 31 Telnet services present shells without group services.
Given its dominant usage share, we compare the distri-
6. We specified the port number and filters like -hash:0 to exclude butions of OpenSSH versions between the affected services
invalid results. and public services as in Table 7. Overall, the affected
 Software Count % Version Affected Public considerations, these affected services may be brute-forced
OpenSSH 222,878 94.85% 2.x 0.11‰ 0.02‰ and taken over if the firewalls are circumvented.
AWS_SFTP 4,955 2.11% 3.x 0.16% 0.08%
dropbear 1,545 0.66% 4.x 0.34% 0.52%
ROSSSH 1,264 0.54% 5.x 2.81% 3.20%
6.2. Telnet Services
Cisco 1,095 0.47% 6.x 3.77% 2.58%
HUAWEI 564 0.24% 7.x 54.07% 34.84% Telnet allows users to access remote systems. We uncov-
DOPRA 232 0.10% 8.x 32.25% 45.31% ered 50,820 Telnet services behind misconfigured firewalls
WeOnlyDo 92 0.04% 9.x 6.55% 13.28%
Others 2,451 1.04% Others 0.03% 0.20%
and fetched their banners.
Measurement. We record the banners of Telnet services.
TABLE 6: SSH Software TABLE 7: OpenSSH Versions Telnet usually prompts login when connected, and insecure
systems may directly prompt shells without authentication.
Analysis. Upon connection, 98.06% (50,192) of affected
services tend to run older versions, suggesting a higher services prompt login. While most of the other affected
chance of older operating systems and other outdated and services return error messages or unidentifiable data, 31
vulnerable software. directly present shells without any authentication.
We then check the patch progress of CVE-2024-6387, Telnet does not support encryption and transmits all data
which is a recently discovered remote code execution (RCE) in plaintext. However, it is still widely used for manag-
vulnerability in OpenSSH. We select the services within ing network devices and IoT devices [15], [67]. Conse-
the affected version range and examine whether they are quently, attackers actively exploit Telnet to spread malware
patched based on the patch level in the version. We list by leveraging brute-forcing or software vulnerabilities [68],
the results in Table 8, where unidentified means that the [69]. While we did not verify these attack vectors due to
patch level is missing or there are no release notes. We ethical considerations, the compromise of network devices
note that a smaller portion of the affected services are like routers and switches can constitute severe threats to
known to be patched, and 47.92% are unidentified. Since infrastructures.
OpenSSH in many distros like Debian [64], Ubuntu [65],
and FreeBSD [66] provides patch levels and has explicit 6.3. RDP Services
release notes, unidentified services might be customized
versions and less secure. RDP allows users to manage Windows hosts via a
Vulnerable Patched Unidentified graphical interface. We uncovered 7,931 RDP services be-
hind misconfigured firewalls and picked 222,200 publicly
Affected 4.71% (2,695) 47.36% (27,085) 47.92% (27,405)
Public 16.34% (28,919) 62.23% (110,131) 21.43% (37,918)
accessible RDP services as the control group.
Measurement. We record the negotiation process of
TABLE 8: Patching Progress of CVE-2024-6387 RDP services. We identify the OS version by the build num-
ber in the NTLMSSP [70] response during negotiation [53].
We inspect the most vulnerable cryptographic algorithms If NTLMSSP is unavailable, often due to old versions, we
and list the results in Table 9. Compared with public SSH match the magic numbers in the responses [71].
services, a larger portion of affected services support weak Analysis. We list the OS distribution in Table 10. In
encryption or message authentication code algorithms. The total, 29.31% (2,324) of affected hosts run end-of-life (EOL)
usage share of weak key exchange algorithms is similar. Windows versions, while the percentage for the publicly
accessible hosts is only 9.70%.
Affected Public
OS Affected Public EOL
Encryption Algorithm
arcfour{,128,256} 6.82% (16,022) 4.15% (31,266) Windows 2000/XP 0.52% (41) 0.15% (344) ✓
aes{128,192,256}-cbc 28.25% (66,383) 24.73% (186,392) Windows 2003 9.51% (754) 3.17% (7,048) ✓
3des-cbc 26.94% (63,304) 21.04% (158,599) Windows 7/2008 19.28% (1,529) 6.38% (14,174) ✓
blowfish-cbc 22.16% (52,071) 17.19% (129,541) Windows 2012 10.68% (847) 30.13% (66,949)
cast128-cbc 21.62% (50,801) 16.02% (120,768) Windows 10/2016/2019 39.76% (3,153) 36.76% (81,688)
Windows 11/2022 15.77% (1,251) 21.19% (47,083)
Message Authentication Code Algorithm
Unidentified 4.49% (356) 2.21% (4,914)
hmac-md5 9.27% (21,780) 7.41% (55,870)
hmac-md5-96 8.28% (19,452) 4.31% (32,509)
TABLE 10: OS Distribution of RDP Services
Key Exchange Algorithm
dh-group1-sha1 25.20% (59,224) 25.32% (190,818)
dh-group-exchange-sha1 26.51% (62,289) 25.23% (190,162)
RDP has had a number of critical vulnerabilities [72],
[73], [74], [75], mainly in the old Windows versions. Out-
TABLE 9: Weak Cryptographic Algorithms in SSH dated Windows versions also have various vulnerabilities
beyond the RDP service and can be compromised in minutes
Besides these attack vectors we have measured, SSH is when connected to the Internet [10].
also vulnerable to weak passwords [9]. Although we did Furthermore, RDP is also prone to weak passwords, and
not verify the prevalence of weak passwords due to ethical compromise can lead to takeover, which we did not measure
due to ethical concerns. Still, exposure of RDP services can Analysis. We classify the affected devices based on their
constitute a threat to these devices. system descriptions and list the results in Table 12. “Net-
work device” includes switches, routers, firewalls, modems,
6.4. IPMI Services etc.; “Appliance” contains other connected devices including
printers, IP cameras, and VoIP gateways; “Empty Field”
IPMI is the industry standard protocol for out-of-band means that the system description field is empty; “Uniden-
remote management, mostly for servers. It enables users to tified” means that we cannot identify the exact type of the
control the power, view the screen, and use the keyboard and device. The result shows that the firewall misconfigurations
mouse over the network. We uncovered 4,242 IPMI services can affect a wide variety of devices.
behind misconfigured firewalls and picked 43,031 publicly
Type Count %
accessible IPMI services as the control group.
Measurement. We probe IPMI services by sending a Server 12,096 25.67%
“Get Channel Authentication Capabilities” command, which Network Device 20,044 42.54%
Appliance 2,175 4.62%
reveals the authentication configuration. Empty Field 11,260 23.90%
Analysis. We examine and list the prevalence of three Unidentified 1,542 3.27%
types of weak configurations [76], [77], [78] in Table 11. A
large portion of affected services allow NONE authentica- TABLE 12: SNMPv1 & SNMPv2 Device Type
tion, which enables anyone to gain full control of the servers
without any authentication. A relatively small but noticeable It is worth noting that SNMPv1 and SNMPv2 respond
percentage of affected services allow the anonymous user, only when the community string is accepted, and hence,
which is a low-privilege account without a password. Null anyone can use the community string public to read all
usernames may also lead to anonymous login. the variables of these affected devices. The variables may
contain sensitive information like the device passwords and
Type Affected Public logs [81], varying by specific model and implementation.
Due to ethical considerations, we did not use community
NONE Authentication 29.8% (1,264) 2.8% (1,185)
Anonymous Login 1.5% (64) 1.1% (469)
strings other than public.
Null Usernames 8.7% (369) 23.5% (10,091)
6.5.2. SNMPv3. We uncovered 465,033 SNMPv3 services
TABLE 11: IPMI Weak Configuration Prevalence behind misconfigured firewalls.
Measurement. SNMPv3 enhances security by support-
IPMI is not intended for public access. Many IPMI ing cryptographic authentication. We probe SNMPv3 ser-
implementations are flawed or shipped with fixed default vices by sending an empty “get request” without a pass-
passwords [79]. While we did not verify the vulnerabilities word. The response includes the device’s engine ID, which
due to ethical considerations, the exposure of IPMI services indicates the device manufacturer and contains additional
is a serious attack surface per se. data, often the media access control (MAC) address.
Analysis. The engine ID can be used to fingerprint the
6.5. SNMP Services device [82] and even brute force the password [83]. We
examine the responses and identify the device manufacturers
SNMP is widely used for telemetry and remote manage- by the enterprise ID in the engine ID. We list the results
ment, mainly for servers, routers, and switches. It exposes in Table 13. Furthermore, 163,827 devices give away their
the device status and configuration in the form of variables. MAC addresses without any authentication, enabling further
SNMP has three main versions: SNMPv1, SNMPv2c, fingerprinting and attacks.
and SNMPv3. The first two are similar and insecure, while
Manufacturer Category Count %
SNMPv3 has major improvements.
Cisco Network Device 199,304 42.86%
6.5.1. SNMPv1 and SNMPv2c. We uncovered 42,894 SN- Net-SNMP Server 99,623 21.42%
Juniper Network Device 51,346 11.04%
MPv1 services and 36,753 SNMPv2c services on 47,117 Nokia Network Device 45,330 9.75%
unique IP addresses behind misconfigured firewalls. We MikroTik Network Device 17,218 3.70%
discuss the two services together and regard each IP address Kyle Fox Unknown 14,303 3.08%
as a unique device. SNMP Research Server 10,691 2.30%
Others 27,218 5.85%
Measurement. SNMPv1 and SNMPv2c have a weak
security model, where the “community string” serves as TABLE 13: SNMPv3 Manufacturers
the password. Most vendors use public as the default
community string for read access, and private as the
default community string for read-write access [80]. We 6.6. FTP Services
probe SNMPv1 and SNMPv2c services by requesting the
system description field with the community string public, FTP is an ancient protocol for file transfer. We uncovered
which can reveal the device type and model. 32,172 FTP services behind misconfigured firewalls.
 Measurement. We record the banners of FTP services, OS Affected Public EOL
which may provide the software versions and the capability Windows 2000/XP 1.19% (12) 0.02% (1) ✓
of anonymous login. Windows 2003 4.74% (48) 0.06% (4) ✓
Analysis. The banners of FTP servers are obscured and Windows 7/2008 44.37% (449) 32.08% (1,992) ✓
Windows 8/8.1 13.14% (133) 12.24% (760) ✓
only 2,588 (8.04%) contain the software version. We list the Windows 2012 0 0.05% (3)
identifiable servers in Table 14. In total, 70.83% of these Windows 10/2016/2019 26.79% (271) 41.78% (2,594)
servers run software that is end-of-life or outdated7 , which Windows 11/2022 9.78% (99) 13.77% (855)
poses a high security risk. We also find that two affected
services explicitly state in their banners that anonymous TABLE 15: OS Distribution of SMB Services on Windows
login is allowed. Furthermore, the affected services may be
brute-forced if the firewalls are bypassed.
figure. After investigation, we find 10,890 services with
Software Supported EOL or Obsolete hostnames starting with LINKSYS, which appear to be
FileZilla 0 13.49% (349) Linksys routers. Further analysis reveals that these routers
MikroTik 17.39% (450) 10.36% (268) are customized and have an RCE vulnerability which can
ProFTPD 0 12.67% (328) be exploited from the Internet. We discuss this case in §8.1.
Serv-U FTP 0 1.31% (34)
vsFTPd 11.79% (305) 33.00% (854)

TABLE 14: Identifiable FTP Services 6.8. MySQL Services

MySQL is a widely used relational database manage-

6.7. SMB Services ment system. It has a highly compatible fork, MariaDB,
using the same protocol. We regard both as MySQL ser-
SMB is primarily used for file sharing on Windows. We vices. We uncovered 19,456 MySQL services behind mis-
uncovered 19,419 SMB services behind misconfigured fire- configured firewalls and picked 249,207 publicly accessible
walls and picked 41,483 publicly accessible SMB services MySQL services as the control group.
as the control group.
Measurement. We record the banners of the MySQL
Measurement. ZGrab supports SMB but only has lim-
services, which reveal the server software and versions. If a
ited functionalities. To study the SMB services better, we
server only allows access from trusted hosts, our connection
adopt smbmap [84]. We customize it to add support for
will be aborted with an error message without a banner.
specifying source ports and enhance its performance and
stability. We try to establish anonymous SMB sessions and Analysis. We examine the distribution of software ver-
enumerate the unprotected SMB shares. sions and list the results in Table 16. Overall, 54.08% of
Analysis. We find 13,220 (68.08%) of affected services the affected services run end-of-life MySQL or MariaDB
allowing anonymous sessions, while only 10,129 (24.42%) versions, whereas the percentage in public services is only
of the control group allow anonymous sessions. We discuss 35.60%. In addition, a lower portion of affected services
only the services allowing anonymous sessions below. deny our connections (“No Access” row in the table), which
In total, 96 of the affected services have 202 unprotected indicates more lax access control.
shares, allowing anonymous read. This poses a great threat
as the data is supposed to be protected by firewalls. We did Affected Public
not access any files in the shares due to ethical considera- MySQL
tions. End-of-Life Versions 27.17% (5,286) 28.62% (71,321)
We further analyze the affected hosts based on OS types. Supported Versions 2.81% (547) 14.92% (37,182)
Windows Hosts. We find that 1,012 (7.66%) of the af- MariaDB
fected services and 6,209 (61.30%) of the public services run End-of-Life Versions 26.91% (5,236) 6.98% (17,396)
Supported Versions 13.94% (2,712) 11.87% (29,575)
Windows. We list the OS distributions in Table 15. In total,
63.44% of affected hosts run end-of-life Windows versions, Total
while the percentage for the public services is only 44.40%. End-of-Life Versions 54.08% (10,522) 35.60% (88,717)
Supported Versions 16.75% (3,259) 26.79% (66,757)
This suggests that the affected hosts may be susceptible to No Access 29.17% (5,675) 37.61% (93,733)
various vulnerabilities like EternalBlue [85] which enables
zero-click RCE though we did not verify prevalence. TABLE 16: MySQL Version Distribution
Non-Windows Hosts. SMB is supported by third-party
software like Samba and can run on non-Windows plat-
forms. We find 12,208 (92.34%) affected hosts run non- Like any other database product, MySQL is vulnerable
Windows operating systems, which is an unexpectedly high to software flaws and weak passwords, and compromise
can lead to information leakage and even local privilege
7. We deem a software version “outdated” if it was released more than escalation [86]. Exposure and outdated software versions
three years ago and we see no sign of maintenance. significantly increase the risks.
6.9. MongoDB Services services, a significantly larger portion of affected services
use insecure certificates, such as self-signed certificates and
MongoDB is a widely adopted NoSQL database product. certificates valid for more than 397 days. While the affected
We uncovered 338 MongoDB services behind misconfigured services are less likely to use expired certificates, shorter
firewalls and picked 15,917 publicly accessible MongoDB keys, or weaker cryptographic algorithms, the exposure of
services as the control group. internal services already constitutes a serious security risk.
Measurement. We try to fetch the banner and database
list of the MongoDB services, which is common practice for Risk Factor Affected Public
search engines like Shodan. MongoDB disables authentica- Internal Names 89.15% (172,622) 15.46% (109,595)
tion by default and is a frequent target of ransomware [87]. Self-Signed Cert. 41.24% (79,856) 16.64% (117,979)
Analysis. We list the statistics in Table 17. The results Long Validity 73.25% (163,010) 21.00% (148,883)
Expired Cert. 10.22% (19,788) 11.33% (80,306)
show that a much higher percentage of affected MongoDB Short RSA Key Size 1.11% (2,158) 2.82% (19,993)
services have no protection at all. This indicates that the SHA-1 Signature 5.57% (10,794) 9.38% (66,485)
administrators might assume that the services are protected
by firewalls and do not properly secure them. Importantly, TABLE 18: Security Risks Based on Certificates
we note that most (76.33%) unsecured public MongoDB
services have been compromised by ransomware, with a We then identify the server software and versions via
database named READ__ME_TO_RECOVER_YOUR_DATA the Server header in the responses. We list the results in
or so as an indicator of compromise (IOC). However, the Table 19. Overall, the software is highly diverse. Compared
percentage for affected MongoDB services is only 2%, with the public services with regard to three mainstream web
whose firewalls may be set up after compromise. This servers, a higher percentage of affected services use end-
suggests that this firewall bypass technique has not been of-life versions; fewer affected services conceal their ver-
actively exploited against MongoDB services in the wild. sion information, potentially offering clues to attackers. A
significant portion (50.21%) of affected services run small-
No Authentication Compromised footprint servers such as lighttpd, thttpd, and mini_httpd.
Affected 29.59% (100) 2 (2.00% of the subset)
This high prevalence suggests that they are likely to be
Public 8.49% (1,352) 1,032 (76.33% of the subset) embedded devices, including network devices and industrial
control systems. The exposure of these services may impact
TABLE 17: MongoDB Service Statistics critical infrastructures.

We further analyze the 100 affected and unprotected Affected Public

MongoDB services. We find a total of 790 databases, among Apache 4.21% (17,512) 14.13% (220,366)
which four have over 1 TB of data, 37 have over 100 GB of End-of-Life Versions 50.69% (8,877) 7.47% (16,462)
data, and 98 have over 1 GB of data. The failure of firewalls Supported Versions 33.79% (5,918) 40.38% (88,984)
Unknown Versions 15.52% (2,717) 52.15% (114,920)
may impose disastrous impacts on these services.
With ethics in mind, we only list the names and sizes NGINX 4.82% (19,221) 21.17% (330,308)
of databases for analyzing IOCs and impacts. We did not End-of-Life Versions 59.69% (11,473) 34.87% (115,177)
Supported Versions 0.59% (113) 2.39% (7,889)
retrieve any data inside the databases. Unknown Versions 39.72% (7,635) 62.74% (207,242)
Microsoft IIS 0.45% (1,892) 3.09% (48,225)
6.10. HTTP(S) Services End-of-Life Versions 17.49% (331) 12.07% (5,820)
Supported Versions 82.51% (1,561) 87.90% (42,391)
HTTP(S) is the fundamental protocol to access websites. Unknown Versions 0 0.03% (14)
We uncovered 222,539 HTTP services and 193,630 HTTPS Squid 23.56% (98,042) 0.49% (7,597)
services behind misconfigured firewalls and picked 851,011 lighttpd 6.57% (27,353) 1.02% (15,923)
thttpd 22.73% (94,587) 0.13% (2,047)
public HTTP services and 708,968 public HTTPS services mini_httpd 20.91% (87,019) 0.09% (1,423)
as the control group. CDN Providers 0 18.65% (290,929)
Measurement. Since the protected websites may contain Other 16.95% (70,543) 41.23% (643,162)
sensitive information, due to ethical considerations, we send
HTTP HEAD requests to get the headers without web page TABLE 19: Server Software of HTTP(S) Services
content, which reveal the server software. In addition, we
record the TLS handshakes with the HTTPS services, which
include the certificates of the websites. 6.11. DNS Services
Analysis. We first analyze the TLS certificates used by
the HTTPS services and list the risk factors in Table 18. DNS provides domain name resolution. We uncovered
Most affected services appear to serve internal websites with 334,358 DNS services behind misconfigured firewalls. The
certificates containing internal names, e.g., private IP ad- number is as high as 6.32% of all public DNS servers.
dresses, illegal domain names, and private top-level domains We also picked 475,592 public DNS servers as the control
like .lan and .localdomain. Compared the public group.
 Measurement. We host a name server and set up a do- We also exclude their IP addresses from our measurements
main name for the measurement. We probe DNS services by to prevent data contamination. The experiment lasted four
sending A queries for our domain name, and the RA flag in months, from mid-June 2024 to mid-October 2024.
the responses shows whether they support recursive queries. Result and Analysis. During the four-month period, the
We also send ANY queries for our domain name to check honeypots received:
whether the servers respond because the ANY query may • 3 SNMPv1 requests at UDP port 161 from port 53.
be exploited to launch reflection amplification attacks [31]
• 65 DNS queries at UDP port 53 from port 53.
and was effectively deprecated by RFC8482 [88] in 2019.
Analysis. The results show that 87.40% (292,229) of • 104 NTP requests at UDP port 123, 6 from port 53, and
affected services support recursive queries, while the per- 98 from port 123.
centage for public services is only 27.99% (133,102). DNS The result shows very limited scanning activities. We
servers that support recursive queries have higher risks [89], further investigate the source of such scanning and find that
e.g., reflection amplification attacks and cache poisoning. most are likely benign and/or unintentional.
The result of ANY queries further proves this. 63.67% Datagrams from Port 53. We find that all of the 74
(212,886) of affected services respond to ANY queries, datagrams from port 53 are from cybersecurity companies or
whereas only 15.37% (73,119) public services respond. This researchers, judging by the source addresses, rDNS records,
suggests that a high percentage of DNS services behind and payloads. Besides, the choice of source port may be
misconfigured firewalls may be leveraged to launch attacks unintentional. For example, scapy is a popular Python library
if they are exposed to attackers. for creating network packets, and 53 is the default source
Various DNS servers are vulnerable to DNS cache poi- port for UDP datagrams [93].
soning [90], [91], [92], which can compromise the integrity Datagrams from Port 123. We find that 30 of the 98
of DNS responses. However, we did not verify these specific datagrams from port 123 are from cybersecurity companies,
vulnerabilities due to ethical considerations. judging by the source address and rDNS records. We inves-
tigate the remaining senders and find that they are all home
6.12. NTP Services IP addresses in East Asia and have been marked as NTP
scanners on AbuseIPDB, probably from a botnet.
NTP is used for time synchronization. We uncovered Summary. The honeypots received no TCP connections
824,389 NTP services behind misconfigured firewalls. The and only 172 UDP datagrams from cybersecurity companies,
number is as high as 12.60% of all public NTP servers. We researchers, and one botnet. We cannot verify the reason
also picked 978,751 publicly accessible NTP services as the for their source port choice, and the traffic is negligible
control group. compared to the everyday scanning activities on the Internet.
Measurement. We probe NTP services by sending time Hence, we conclude that there is no large-scale exploitation
requests. We also send monlist queries to check whether the in the wild and do not suspect any intentional exploitation.
servers respond because misconfigured NTP servers support-
ing monlist can be used for amplification attacks [32]. 8. Case Studies
Analysis. The result shows that 2.70% (22,244) of af-
fected NTP services respond to monlist queries, which is Besides the primary measurement at the Internet scale,
higher than the number in public NTP servers, i.e., 1.63% we find two products shipped with the firewall misconfigu-
(15,993). By bypassing the firewalls, attackers can expand rations studied in this paper. We elaborate these two cases
their arsenal considerably. and their security implications in this section.

7. Current Exploitation Status in the Wild 8.1. Linksys Home Router

The measurement reveals the widespread existence of In our measurement of SMB services, we find 10,890
firewall misconfigurations that mistakenly allow inbound affected services with hostnames starting with LINKSYS.
connections from certain ports. To investigate whether such Linksys is a popular network hardware manufacturer and
misconfigurations are actively exploited in the wild, we set many of its home routers support sharing external storage
up honeypots to capture connections from special ports. devices via SMB. This indicates that a large number of
Experiment Setup. We deploy honeypots in three lo- Linksys routers are affected by the firewall misconfiguration
cations: the United States, Japan, and Hong Kong. Each that allows inbound TCP connections initiated from port 80.
honeypot hosts a program listening on the ports of our se- Investigation. We check the IP addresses of the affected
lected services, as detailed in §4.2. This program records all Linksys routers and find that they all belong to an ISP
received connections and data. To simulate a misconfigured named Truespeed in the United Kingdom. According to the
firewall, we configure iptables with stateless rules that only official websites [94], [95], Truespeed partners with Linksys
allow inbound packets from specific TCP ports (22, 80, to provide its customers with customized Linksys routers
443) and UDP ports (53, 123), which correspond to popular based on Linksys Velop AX4200, which is a mesh router.
services and are likely to be exploited by potential attackers. Linksys mesh routers were known to contain an RCE
We verify that the honeypots work correctly with netcat. vulnerability in its inter-AP communication protocol [96].
While the firmware of the customized model is not publicly Recipient Selection. It is extremely difficult to deter-
available, we analyze the firmware of its original model, mine the actual owner of a host given only the IP address,
Linksys Velop AX4200, instead. To our surprise, the vulner- especially considering our avoidance of collecting sensitive
ability still exists in the latest firmware. We further confirm information. We choose to disclose the affected hosts and
that the port of the vulnerable service, TCP 6060, becomes services to the contact emails of their corresponding ASes
reachable when initiating connections from port 80. This and kindly request them to forward the message to the
suggests that this vulnerability may be remotely exploited. actual owners if they are not. We obtain the contact emails
We do not find any explanation for this firewall miscon- via WHOIS. For the few ASes without contact emails, we
figuration in the firmware of the original model. Considering choose the support or feedback emails on their websites.
the fact that we do not find other vulnerable Linksys devices Form of Disclosure. We send emails to the recipients,
outside of this ISP, it is likely that only the customized which include (i) a brief introduction of the vulnerability
model has this flawed rule, probably in iptables. and potential security implications, (ii) the list of affected
Disclosure. We disclosed the misconfiguration to hosts and services in the AS, and (iii) a link to our web-
Linksys with a detailed report in September 2024. However, site, providing technical details and possible fixes. We also
as of the time of writing, we have received no substantial explain the reason for scanning and provide methods to opt
response from Linksys, and the affected routers still show out of this study.
up in follow-up measurements. Feedback. We started the disclosure in mid-October and
Lessons Learned. Firewall misconfigurations in this finished in one month. As of the time of writing, the website
work may make local vulnerabilities remotely exploitable. has been viewed by recipients from 1,962 ASes. We have
Furthermore, embedded devices may be shipped with flawed received inquiries, updates, and letters of thanks from 290
firewall rules, which can be difficult to patch afterward. ASes, many of which report that they have successfully
patched the vulnerability or that they have forwarded the
8.2. Oracle Cloud Ubuntu Image message to their customers. Some indicate that they will
update their security tools to cover this attack surface. We
We research several mainstream public clouds for their received one bounty from a company for discovering their
built-in firewall rules. While most clouds provision services misconfiguration. Our disclosure also led to the discovery
with no firewall rule or secure firewall rules, the Ubuntu of a high-severity CVE [98] in Open Virtual Network, a
images on Oracle Cloud come with an insecure iptables rule network virtualization platform.
which allows any inbound UDP datagram from port 123. Some recipients share the root causes of their miscon-
Investigation. We find that the official Ubuntu images figurations, and the most common reason is flawed stateless
on Oracle Cloud forbid inbound connections by default but rules induced by carelessness. One special case is that the
contain a flawed iptables rule: -A INPUT -p udp -m recipient is aware of the misconfiguration but has to keep it
udp -sport 123 -j ACCEPT. It opens a loophole al- because of a firmware bug in their Cisco stateless firewall.
lowing any UDP datagram from port 123 and is preinstalled The bug prevents TCP flag filtering from working, and they
on all virtual machines using the official Ubuntu images. can only deploy flawed rules instead. They have submitted
Based on the port number, the rule in question should be a ticket to Cisco but have not heard back.
intended for NTP responses. The secure version should be We received and honored five opt-out requests in the
stateful, allowing inbound packets only if the host has ini- replies to our disclosure.
tiated a UDP session first: -A INPUT -p udp -sport Effectiveness of Disclosure for Top ASes. We perform
53 -m state -state ESTABLISHED -j ACCEPT. follow-up measurements before disclosure and every two
Oracle Cloud has hundreds of thousands of customers, weeks after disclosure. We scan the top 202 ASes with
including big companies and governments [97], and Ubuntu at least 1,000 affected hosts, which account for 83.07% of
is one of the most popular Linux distros. There may be a the total, from one vantage point in the United States. This
large number of hosts affected by this misconfiguration. reduced scope can decrease our scanning traffic by ∼93%
Disclosure. We disclosed the misconfiguration to Oracle but still accomplish very high coverage. We adopt the same
with a detailed report in October 2024. As of the time of workflow and target services in §4 and count the numbers of
writing, Oracle Cloud has removed the flawed rule in its affected hosts. The results are shown in Table 20. The first
Ubuntu images. row is the number of the affected hosts from the primary
Lessons Learned. Flawed firewall rules still may come measurement in §5 with only the data collected at the US
with operating systems, even in the cloud era. Preloading vantage point, serving as a benchmark. We also list the
firewalls with flawed rules may be more dangerous than no percentage changes compared to the previous measurement.
firewall at all, as it may create a false sense of security.
Primary (US) Week 0 Week 2 Week 4
9. Responsible Disclosure Total 1,718,659 1,706,378 1,626,073 1,617,107
Change (%) N/A -0.71% -4.71% -0.55%
In this section, we focus on disclosures relating to the
affected hosts and services. TABLE 20: Follow-up Measurements after Disclosure
 From the results, we see a small but noticeable drop in To minimize network pressure and avoid overwhelming
the number of affected hosts between Week 0 and Week Internet hosts, we focus on a small number of services
2. However, the number of Week 4 only has a negligible and source port numbers, and we use scanning tools that
decrease, probably due to network volatility. The measure- have been tested and repeatedly used by prior studies [20].
ment results show that only 11 of the 202 ASes have fixed Our scanners always follow protocol specifications, and we
the issue (having less than 10% of the original number of immediately close connections after a response is received
affected hosts). We hypothesize that the most affected ASes (both during port scanning and the application-layer prob-
have a lot of IP addresses and the corresponding devices are ing).
managed by their customers instead of the recipients. In addition, during our measurements, we collected min-
Summary. We perform responsible disclosure and re- imum data that allows us to analyze the services’ character-
ceive positive feedback. Our emails and website have helped istics and security risks. We avoid collecting any potentially
many ASes patch their firewalls. Some update their security sensitive data like web pages, files, or database content. We
tools accordingly. We also learn the causes of the miscon- did not perform any aggressive activities, such as cracking
figurations in some ASes, including carelessness and flawed passwords or exploiting vulnerabilities.
firmware. In the follow-up measurements, we see a small but Despite our efforts, our probe traffic may still be deemed
noticeable decrease in the number of affected hosts in the suspicious by automated systems like intrusion detection
most affected ASes. systems and honeypots. We received 25 complaints during
our measurement, mostly only because of sending packets to
10. Discussion their IP addresses. We confirmed that no harm was done and
properly handled all the complaints by immediately stopping
any measurement of the complaining IP addresses.
The IPv6 Space. With the growing adoption of IPv6,
We also ensure responsible disclosure. After our mea-
it is expected that every device gets a public IPv6 address.
surements, we notified all involved parties about the firewall
This shift will make the problem of firewall misconfiguration
misconfigurations in their networks or products. The proce-
even more important. We leave it to future research to
dure and feedback are detailed in §8 and §9.
conduct a comprehensive measurement in the IPv6 space.
Bad Advice on the Internet. Search engines and Q&A
platforms are common sources of information, including 12. Conclusion
firewall configurations. However, suggestions for insecure In this paper, we reveal the widespread existence of a
firewall rules are widespread and are often most upvoted. previously understudied attack surface, namely firewall mis-
This is particularly common with regard to allowing UDP configurations that inadvertently allow inbound connections
protocols like DNS [99] and NTP [100]. Stateless rules from certain ports. We further analyze the security implica-
are favored because of their simplicity, and stateful rules tions and exploitation status in the wild. We also perform
may appear obscured for UDP. While rare, flawed rules for responsible disclosure to the involved parties. Finally, we
TCP ports also exist [101]. Such information sources on the discuss future directions and best practices for mitigating
Internet may have contributed to the prevalence of firewall this attack surface.
misconfigurations and need remediation.
Mitigations and Best Practices. Stateful rules should be
used whenever circumstances permit, as stateless rules are
Acknowledgment
more prone to misconfigurations by nature. If stateless fire- The authors would like to thank the reviewers for their
walls/rules must be used, it is recommended to utilize TCP valuable feedback during the revision process. This research
flag filtering to block inbound connections (if the firewall was sponsored by the OUSD(R&E)/RT&L and was accom-
supports it) and whitelist only necessary UDP traffic to and plished under Cooperative Agreement Number W911NF-
from trusted servers. Another workaround is to specifically 20-2-0267. The views and conclusions contained in this
block the traffic to and from the ports of sensitive services. document are those of the authors and should not be inter-
However, these methods may produce side effects or have preted as representing the official policies, either expressed
omissions. Last but not least, it is important to regularly or implied, of the ARL and OUSD(R&E)/RT&L or the
review and update the firewall rules. U.S. Government. The U.S. Government is authorized to
reproduce and distribute reprints for government purposes,
11. Ethical Considerations notwithstanding any copyright notation herein.

We follow the best practices as in prior works [20], [38], References

including providing opt-out options and setting up a website
explaining the study. Anyone accessing the HTTP port of [1] Z. Durumeric, M. Bailey, and J. A. Halderman, “An
our scanners will be redirected to the website. We also attach Internet-Wide view of Internet-Wide scanning,” in 23rd
USENIX Security Symposium (USENIX Security 14). San
the opt-out instruction in our probes when the protocol Diego, CA: USENIX Association, Aug. 2014, pp. 65–
permits, like in the User-Agent header of HTTP. During 78. [Online]. Available: [Link]
our study, we received and honored 17 opt-out requests. usenixsecurity14/technical-sessions/presentation/durumeric
[2] H. Griffioen, G. Koursiounis, G. Smaragdakis, and C. Doerr, “Have [16] B. Zhao, S. Ji, W.-H. Lee, C. Lin, H. Weng, J. Wu, P. Zhou, L. Fang,
you syn me? characterizing ten years of internet scanning,” in and R. Beyah, “A large-scale empirical study on the vulnerability
Proceedings of the 2024 ACM on Internet Measurement Conference, of deployed iot devices,” IEEE Transactions on Dependable and
ser. IMC ’24, 2024, p. 149–164. Secure Computing, vol. 19, no. 3, pp. 1826–1840, 2022.
[3] J. Mazel, R. Fontugne, and K. Fukuda, “Profiling internet scanners: [17] M. Hastings, J. Fried, and N. Heninger, “Weak keys remain
Spatiotemporal structures and measurement ethics,” in 2017 Network widespread in network devices,” in Proceedings of the 2016
Traffic Measurement and Analysis Conference (TMA), 2017, pp. 1–9. Internet Measurement Conference, ser. IMC ’16. New York, NY,
USA: Association for Computing Machinery, 2016, p. 49–63.
[4] R. Hiesgen, M. Nawrocki, A. King, A. Dainotti, T. C. Schmidt, [Online]. Available: [Link]
and M. Wählisch, “Spoki: Unveiling a new wave of scanners
through a reactive network telescope,” in 31st USENIX Security [18] L. Quan, J. Heidemann, and Y. Pradkin, “Trinocular: understanding
Symposium (USENIX Security 22). Boston, MA: USENIX internet reliability through adaptive probing,” in Proceedings
Association, Aug. 2022, pp. 431–448. [Online]. Available: https: of the ACM SIGCOMM 2013 Conference on SIGCOMM,
//[Link]/conference/usenixsecurity22/presentation/hiesgen ser. SIGCOMM ’13. New York, NY, USA: Association for
Computing Machinery, 2013, p. 255–266. [Online]. Available:
[5] A. Anand, M. Kallitsis, J. Sippe, and A. Dainotti, “Aggressive [Link]
internet-wide scanners: Network impact and longitudinal charac-
terization,” in Companion of the 19th International Conference on [19] R. Fontugne, J. Mazel, and K. Fukuda, “An empirical mixture model
Emerging Networking EXperiments and Technologies, ser. CoNEXT for large-scale rtt measurements,” in 2015 IEEE Conference on
2023, 2023. Computer Communications (INFOCOM), 2015, pp. 2470–2478.
[6] W. K. Leong, A. Kulkarni, Y. Xu, and B. Leong, “Unveiling [20] Z. Durumeric, E. Wustrow, and J. A. Halderman, “ZMap:
the hidden dangers of public ip addresses in 4g/lte cellular Fast internet-wide scanning and its security applications,” in
data networks,” in Proceedings of the 15th Workshop on Mobile 22nd USENIX Security Symposium (USENIX Security 13).
Computing Systems and Applications, ser. HotMobile ’14. New Washington, D.C.: USENIX Association, Aug. 2013, pp.
York, NY, USA: Association for Computing Machinery, 2014. 605–620. [Online]. Available: [Link]
[Online]. Available: [Link] usenixsecurity13/technical-sessions/paper/durumeric
[7] P. Richter and A. Berger, “Scanning the scanners: Sensing [21] R. Graham, “robertdavidgraham/masscan: Tcp port scanner, spews
the internet from a massively distributed network telescope,” in syn packets asynchronously, scanning entire internet in under 5
Proceedings of the Internet Measurement Conference, ser. IMC minutes.” [Link] (Accessed
’19. New York, NY, USA: Association for Computing Machinery, on 09/05/2024).
2019, p. 144–157. [Online]. Available: [Link]
[22] B. Hou, Z. Cai, K. Wu, T. Yang, and T. Zhou, “6scan: A high-
3355369.3355595
efficiency dynamic internet-wide ipv6 scanner with regional encod-
[8] L. Bilge and T. Dumitraş, “Before we knew it: an empirical ing,” IEEE/ACM Transactions on Networking, vol. 31, no. 4, pp.
study of zero-day attacks in the real world,” in Proceedings of 1870–1885, 2023.
the 2012 ACM Conference on Computer and Communications
[23] G. Song, J. Yang, L. He, Z. Wang, G. Li, C. Duan,
Security, ser. CCS ’12. New York, NY, USA: Association for
Y. Liu, and Z. Sun, “AddrMiner: A comprehensive global
Computing Machinery, 2012, p. 833–844. [Online]. Available:
active IPv6 address discovery system,” in 2022 USENIX Annual
[Link]
Technical Conference (USENIX ATC 22). Carlsbad, CA: USENIX
[9] S. K. Singh, S. Gautam, C. Cartier, S. Patil, and R. Ricci, “Where Association, Jul. 2022, pp. 309–326. [Online]. Available: https:
the wild things are: Brute-Force SSH attacks in the wild and how //[Link]/conference/atc22/presentation/song
to stop them,” in 21st USENIX Symposium on Networked Systems
[24] G. Williams, M. Erdemir, A. Hsu, S. Bhat, A. Bhaskar, F. Li, and
Design and Implementation (NSDI 24). Santa Clara, CA: USENIX
P. Pearce, “6sense: Internet-Wide IPv6 scanning and its security
Association, Apr. 2024, pp. 1731–1750. [Online]. Available: https:
applications,” in 33rd USENIX Security Symposium (USENIX
//[Link]/conference/nsdi24/presentation/singh-sachin
Security 24). Philadelphia, PA: USENIX Association, Aug.
[10] E. Parker, “What happens if you connect windows xp to the inter- 2024, pp. 2281–2298. [Online]. Available: [Link]
net in 2024?” [Link] conference/usenixsecurity24/presentation/williams
may 2024, (Accessed on 09/03/2024).
[25] “Shodan search engine,” [Link] (Accessed on
[11] M. Boddy, “Exposed: Cyberattacks on cloud honeypots,” https: 09/06/2024).
//[Link]/X24WTUEQ/at/rgbjvgnx6qwwj7wvx764rmbn/
[26] “Censys search,” [Link] (Accessed on
[Link], arp
09/06/2024).
2019, (Accessed on 09/03/2024).
[27] “Fofa search engine,” [Link] (Accessed on
[12] Microsoft, “Ipsec default exemptions can be used to bypass
09/06/2024).
ipsec protection in some scenarios,” [Link]
web/20140530061933/[Link] [28] “Ripe atlas,” [Link] (Accessed on 09/06/2024).
(Accessed on 09/07/2024).
[29] T.-F. Tu, J.-W. Qin, H. Zhang, M. Chen, T. Xu,
[13] “Discovering mac os x weaknesses and fixing them with the and Y. Huang, “A comprehensive study of mozi botnet,”
new bastille os x port,” [Link] International Journal of Intelligent Systems, vol. 37,
[Link], (Accessed on 09/07/2024). no. 10, pp. 6877–6908, 2022. [Online]. Available:
[Link]
[14] G. Lyon, “Bypassing firewall rules,” [Link]
[Link], 2008, (Accessed on 09/08/2024). [30] C. Cimpanu, “A crypto-mining botnet has been hijacking mssql
servers for almost two years,” [Link]
[15] A. Cui and S. J. Stolfo, “A quantitative analysis of the insecurity a-crypto-mining-botnet-has-been-hijacking-mssql-servers-for-
of embedded network devices: results of a wide-area scan,” in almost-two-years/, arp 2020, (Accessed on 09/06/2024).
Proceedings of the 26th Annual Computer Security Applications
Conference, ser. ACSAC ’10. New York, NY, USA: Association [31] Cloudflare, “Dns amplification ddos attack,” https://
for Computing Machinery, 2010, p. 97–106. [Online]. Available: [Link]/learning/ddos/dns-amplification-ddos-attack/,
[Link] (Accessed on 09/06/2024).
[32] ——, “Ntp amplification ddos attack,” [Link] [47] Cisco, “Cli book 2: Cisco asa series firewall cli configuration
learning/ddos/ntp-amplification-ddos-attack/, (Accessed on guide, 9.12,” [Link]
09/06/2024). asa/asa912/configuration/firewall/asa-912-firewall-config/conns-
[Link], mar 2019, (Accessed on 09/10/2024).
[33] S. Bano, P. Richter, M. Javed, S. Sundaresan, Z. Durumeric,
S. J. Murdoch, R. Mortier, and V. Paxson, “Scanning the internet [48] L. Yuan, H. Chen, J. Mai, C.-N. Chuah, Z. Su, and P. Mohapatra,
for liveness,” SIGCOMM Comput. Commun. Rev., vol. 48, no. 2, “Fireman: a toolkit for firewall modeling and analysis,” in 2006
p. 2–9, may 2018. [Online]. Available: [Link] IEEE Symposium on Security and Privacy (SP’06), 2006, pp. 15
3213232.3213234 pp.–213.
[34] J. Klick, S. Lau, M. Wählisch, and V. Roth, “Towards better [49] T. E. Uribe and S. Cheung, “Automatic analysis of firewall and
internet citizenship: Reducing the footprint of internet-wide scans network intrusion detection system configurations,” in Proceedings
by topology aware prefix selection,” in Proceedings of the 2016 of the 2004 ACM Workshop on Formal Methods in Security
Internet Measurement Conference, ser. IMC ’16. New York, NY, Engineering, ser. FMSE ’04. New York, NY, USA: Association
USA: Association for Computing Machinery, 2016, p. 421–427. for Computing Machinery, 2004, p. 66–74. [Online]. Available:
[Online]. Available: [Link] [Link]
[35] L. Izhikevich, R. Teixeira, and Z. Durumeric, “LZR: Identifying [50] H. Hu, G.-J. Ahn, and K. Kulkarni, “Detecting and resolving firewall
unexpected internet services,” in 30th USENIX Security Symposium policy anomalies,” IEEE Transactions on Dependable and Secure
(USENIX Security 21). USENIX Association, Aug. 2021, pp. Computing, vol. 9, no. 3, pp. 318–331, 2012.
3111–3128. [Online]. Available: [Link]
usenixsecurity21/presentation/izhikevich [51] H. Pan, Z. Li, P. Zhang, P. Cui, K. Salamatian, and G. Xie,
“Misconfiguration-free compositional sdn for cloud networks,” IEEE
[36] ——, “Predicting ipv4 services across all ports,” in Proceedings Transactions on Dependable and Secure Computing, vol. 20, no. 3,
of the ACM SIGCOMM 2022 Conference, ser. SIGCOMM ’22. pp. 2484–2499, 2023.
New York, NY, USA: Association for Computing Machinery,
2022, p. 503–515. [Online]. Available: [Link] [52] D. Bringhenti, G. Marchetto, R. Sisto, F. Valenza, and J. Yusupov,
3544216.3544249 “Automated firewall configuration in virtual networks,” IEEE Trans-
actions on Dependable and Secure Computing, vol. 20, no. 2, pp.
[37] G. Song, L. He, T. Zhao, Y. Luo, Y. Wu, L. Fan, C. Li, Z. Wang, 1559–1576, 2023.
and J. Yang, “Which doors are open: Reinforcement learning-based
internet-wide port scanning,” in 2023 IEEE/ACM 31st International [53] “nmap/scripts/[Link] · nmap/nmap,” [Link]
Symposium on Quality of Service (IWQoS), 2023, pp. 1–10. nmap/nmap/blob/e263e648207995e491b6ffe3a94e24c3fbd4faba/
scripts/[Link]#L153, (Accessed on 09/29/2024).
[38] G. Wan, L. Izhikevich, D. Adrian, K. Yoshioka, R. Holz, C. Rossow,
and Z. Durumeric, “On the origin of scanning: The impact of [54] GlaDiaT0R, “Bypassing firewalls using an ftp,” 3 2010, [Online;
location on internet-wide scans,” in Proceedings of the ACM accessed 2025-04-01]. [Online]. Available: [Link]
Internet Measurement Conference, ser. IMC ’20. New York, NY, [Link]/papers/13651
USA: Association for Computing Machinery, 2020, p. 662–679.
[55] [Link], “Ephemeral source port selection strategies,”
[Online]. Available: [Link]
[Link] (Accessed on
[39] T. Rytilahti and T. Holz, “On using application-layer 09/10/2024).
middlebox protocols for peeking behind nat gateways,” in 27th
Annual Network and Distributed System Security Symposium, [56] I. Tsareva, T. V. Doan, and V. Bajpai, “A decade long view of internet
NDSS 2020, San Diego, California, USA, February 23-26, traffic composition in japan,” in 2023 IFIP Networking Conference
2020. The Internet Society, 2020. [Online]. Available: (IFIP Networking), 2023, pp. 1–9.
[Link] [57] L. Schumann, T. V. Doan, T. Shreedhar, R. Mok, and V. Bajpai,
layer-middlebox-protocols-for-peeking-behind-nat-gateways/ “Impact of evolving protocols and covid-19 on internet traffic
[40] X. Feng, S. Chen, and H. Wang, “An internet-wide penetration shares,” 2022. [Online]. Available: [Link]
study on nat boxes via tcp/ip side channel,” 2023. [Online]. [58] “zmap/zmap: Zmap is a fast single packet network scanner designed
Available: [Link] for internet-wide network surveys.” [Link]
[41] “Cve-2001-0851,” [Link] (Accessed on 09/16/2024).
CVE-2001-0851, mar 2002, (Accessed on 09/17/2024). [59] “zmap/zgrab2: Fast go application scanner,” [Link]
[42] Éric Leblond, “Playing with network layers to bypass zmap/zgrab2/, (Accessed on 09/16/2024).
firewalls’ filtering policy – to linux and beyond !” [60] A. Bhaskar and P. Pearce, “Many roads lead to rome: How packet
[Link] headers influence DNS censorship measurement,” in 31st USENIX
to-bypass-firewalls-filtering-policy/, mar 2012, (Accessed on Security Symposium (USENIX Security 22). Boston, MA: USENIX
09/16/2024). Association, Aug. 2022, pp. 449–464. [Online]. Available: https:
[43] S. Kamkar, “Nat pinning,” [Link] jan 2010, (Ac- //[Link]/conference/usenixsecurity22/presentation/bhaskar
cessed on 09/16/2024). [61] ——, “Understanding routing-induced censorship changes globally,”
[44] S. Sahay, “Stateful vs. stateless firewall: Differences ex- in Proceedings of the 2024 on ACM SIGSAC Conference on
plained,” [Link] Computer and Communications Security, ser. CCS ’24. New York,
vs-stateless-firewall, jun 2023, (Accessed on 09/10/2024). NY, USA: Association for Computing Machinery, 2024, p. 437–451.
[Online]. Available: [Link]
[45] Cisco, “Configure commonly used ip acls,” [Link]
c/en/us/support/docs/ip/access-lists/[Link], nov [62] “Cve-2024-6387,” [Link]
2023, (Accessed on 09/10/2024). CVE-2024-6387, jun 2024, (Accessed on 09/27/2024).
[46] D. US, “Dell emc networking command line [63] F. Bäumer, M. Brinkmann, and J. Schwenk, “Terrapin
reference guide for the s5048f–on system [Link],” attack: Breaking SSH channel integrity by sequence number
[Online; accessed 2025-04-01]. [Online]. Available: manipulation,” in 33rd USENIX Security Symposium (USENIX
[Link] Security 24). Philadelphia, PA: USENIX Association, Aug.
s5048f-on-[Link]-cli-pub/deny-tcp-for-extended-ip-acls?guid= 2024, pp. 7463–7480. [Online]. Available: [Link]
guid-a610d67e-86bb-41de-902d-3c6e23fa6ff7&lang=en-us conference/usenixsecurity24/presentation/b%C3%A4umer
[64] “debian/rules · 2df9bff12640a33749f0f20ae806b6efac327116 · de- [82] T. Albakour, O. Gasser, R. Beverly, and G. Smaragdakis, “Third
bian ssh maintainers / openssh · gitlab,” [Link] time’s not a charm: exploiting snmpv3 for router fingerprinting,” in
team/openssh/-/blob/2df9bff12640a33749f0f20ae806b6efac327116/ Proceedings of the 21st ACM Internet Measurement Conference,
debian/rules#L36, (Accessed on 09/28/2024). ser. IMC ’21. New York, NY, USA: Association for Computing
[65] “debian/rules - ubuntu/+source/openssh,” [Link] Machinery, 2021, p. 150–164. [Online]. Available: [Link]
ubuntu/+source/openssh/tree/debian/rules?h=ubuntu/noble- 10.1145/3487552.3487848
security&id=284288abcc5d0d41f890460e9a60af4472c42627#n36, [83] S. Thomas, “Brute forcing snmpv3 authentication,” [Link]
(Accessed on 09/28/2024). [Link]/resources/brute-forcing-snmpv3-authentication, jun 2020,
[66] “security/openssh-portable/files/extra-patch-version-addendum - (Accessed on 10/02/2024).
ports - freebsd ports tree,” [Link] [84] “Shawndevans/smbmap: Smbmap is a handy smb enumera-
security/openssh-portable/files/extra-patch-version-addendum?id= tion tool,” [Link] (Accessed on
6014ebaef2fc946f5fc971cd4c6d882acca60098#n5, (Accessed on 10/04/2024).
09/28/2024).
[85] “Eternalblue exploit: What it is and how it works | sentinelone,”
[67] T. Sasaki, T. Noma, Y. Morii, T. Shimura, M. v. Eeten, K. Yoshioka, [Link]
and T. Matsumoto, “Who left the door open? investigating the causes exploit-just-wont-die/, (Accessed on 10/04/2024).
of exposed iot devices in an academic network,” in 2024 IEEE
Symposium on Security and Privacy (SP), 2024, pp. 2291–2309. [86] N. Abulhul, “Privilege escalation with mysql user defined functions,”
[Link]
[68] H. Heo and S. Shin, “Who is knocking on the telnet port: A user-defined-functions-996ef7d5ceaf, oct 2021, (Accessed on
large-scale empirical study of network scanning,” in Proceedings 10/14/2024).
of the 2018 on Asia Conference on Computer and Communications
Security, ser. ASIACCS ’18. New York, NY, USA: Association [87] C. Cimpanu, “Hacker ransoms 23k mongodb databases and
for Computing Machinery, 2018, p. 625–636. [Online]. Available: threatens to contact gdpr authorities,” [Link]
[Link] article/hacker-ransoms-23k-mongodb-databases-and-threatens-to-
contact-gdpr-authorities/, jul 2020, (Accessed on 10/11/2024).
[69] L. Metongnon and R. Sadre, “Beyond telnet: Prevalence of
iot protocols in telescope and honeypot measurements,” in [88] J. Abley, Ólafur Guðmundsson, M. Majkowski, and E. Hunt,
Proceedings of the 2018 Workshop on Traffic Measurements for “Providing Minimal-Sized Responses to DNS Queries That
Cybersecurity, ser. WTMC ’18. New York, NY, USA: Association Have QTYPE=ANY,” RFC 8482, Jan. 2019. [Online]. Available:
for Computing Machinery, 2018, p. 21–26. [Online]. Available: [Link]
[Link] [89] Cloudflare, “What is recursive dns?” [Link]
[70] “[ms-nlmp]: Nt lan manager (ntlm) authentication protocol,” learning/dns/what-is-recursive-dns/, (Accessed on 11/15/2024).
[Link] [90] A. Herzberg and H. Shulman, “Fragmentation considered poisonous,
ms-nlmp/b38c36ed-2804-4868-a9ff-8dd3182128e4, aug 2022, or: [Link],” in 2013 IEEE Conference on
(Accessed on 10/14/2024). Communications and Network Security (CNS), 2013, pp. 224–232.
[71] “nuclei-templates/network/detection/[Link] [91] K. Man, Z. Qian, Z. Wang, X. Zheng, Y. Huang, and H. Duan, “Dns
· projectdiscovery/nuclei-templates,” https:// cache poisoning attack reloaded: Revolutions with side channels,”
[Link]/projectdiscovery/nuclei-templates/blob/ in Proceedings of the 2020 ACM SIGSAC Conference on Computer
d6003d408f5d1dd71ca16d1baf8f5fd00e332e58/network/detection/ and Communications Security, ser. CCS ’20. New York, NY,
[Link], (Accessed on 09/29/2024). USA: Association for Computing Machinery, 2020, p. 1337–1350.
[72] “Cve-2019-0708,” [Link] [Online]. Available: [Link]
CVE-2019-0708, may 2015, (Accessed on 09/27/2024). [92] X. Li, C. Lu, B. Liu, Q. Zhang, Z. Li, H. Duan, and Q. Li,
[73] “Cve-2018-0886,” [Link] “The maginot line: Attacking the boundary of DNS caching
CVE-2018-0886, mar 2018, (Accessed on 09/27/2024). protection,” in 32nd USENIX Security Symposium (USENIX
[74] “Cve-2012-0002,” [Link] Security 23). Anaheim, CA: USENIX Association, Aug. 2023, pp.
CVE-2012-0002, mar 2012, (Accessed on 09/27/2024). 3153–3170. [Online]. Available: [Link]
usenixsecurity23/presentation/li-xiang
[75] “Cve-2005-1794,” [Link]
CVE-2005-1794, jun 2005, (Accessed on 09/27/2024). [93] “scapy/scapy/layers/[Link] · secdev/scapy,” [Link]
secdev/scapy/blob/6f0faf38597080daca367d741903a99464e32760/
[76] “Default accounts : Ipmi anonymous login enabled,” scapy/layers/[Link]#L821, (Accessed on 10/11/2024).
[Link]
[Link].4.1.25623.1.0.103836, (Accessed on 09/29/2024). [94] Truespeed, “New router & mesh wi-fi system launched,”
[Link]
[77] “General : Ipmi no auth access mode enabled,” mesh-wi-fi-system/, (Accessed on 10/09/2024).
[Link]
[Link].4.1.25623.1.0.103837, (Accessed on 09/29/2024). [95] “Linksys spnmx42ts-uk faqs - linksys support,” https:
//[Link]/kb/article/3713-en/, (Accessed on
[78] “General : Ipmi null usernames allowed,” https: 10/09/2024).
//[Link]/smysecure/[Link]?id=
[Link].4.1.25623.1.0.103838, (Accessed on 09/29/2024). [96] X. Zhou, Q. Deng, J. Pu, K. Man, Z. Qian, and S. V. Krishnamurthy,
“Untangling the knot: Breaking access control in home wireless
[79] H. Moore, “A penetration tester’s guide to ipmi and bmcs,” mesh networks,” in Proceedings of the 2024 ACM SIGSAC Con-
[Link] ference on Computer and Communications Security, 2024.
testers-guide-to-ipmi/, jul 2013, (Accessed on 09/30/2024).
[97] “Cloud customer successes | oracle,” [Link]
[80] D. Hobbs, “Snmp. . . strings attached!” https://
customers/, (Accessed on 10/10/2024).
[Link]/snmp-strings-attached/, dec 2022,
(Accessed on 09/30/2024). [98] “Cve-2025-0650,” [Link]
CVE-2025-0650, jan 2025, (Accessed on 04/01/2024).
[81] D. Heiland, “Snmp data harvesting during penetration testing,”
[Link] [99] “Centos iptables open port 53 - server fault,” [Link]
harvesting-during-penetration-testing/, may 2016, (Accessed questions/508661/centos-iptables-open-port-53/508682#508682,
on 10/01/2024). (Accessed on 11/10/2024).
[100] “ubuntu - what are the iptables rules to permit ntp? - super user,” A.2. Organizational Distribution
[Link]
rules-to-permit-ntp/141795#141795, (Accessed on 10/10/2024).
We highlight some affected ASes belonging to well-
[101] “iis - can i use iptables on my varnish server to forward https traffic known enterprises in Table 22. This demonstrates the high
to a specific server? - server fault,” [Link]
442708/can-i-use-iptables-on-my-varnish-server-to-forward-https-
susceptibility of firewall misconfigurations of this kind. The
traffic-to-a-specific-s/442734#442734, (Accessed on 10/10/2024). data also indicates that UDP services are particularly vul-
[102] D. Maez, “Ip address allocation by country,” [Online; accessed 2025- nerable, probably due to the connectionless nature of UDP.
04-10]. [Online]. Available: [Link]
ASN AS Name Count Main Services
[103] “Windtre semplifica connessioni, energia, assicurazioni,” [Online;
accessed 2025-04-10]. [Online]. Available: [Link] 714 APPLE-ENGINEERING 8,348 DNS, NTP
14593 SPACEX-STARLINK 5,571 SNMPv3, NTP
36692 CISCO-UMBRELLA 4,914 DNS, SNMPv3
Appendix A. 45090 TENCENT-NET-AP 3,770 NTP, SSH, DNS
Misconfiguration Distributions 15169 GOOGLE 2,127 HTTPS, HTTP
13238 YANDEX 1,841 NTP, SNMPv3
132892 CLOUDFLARE 857 SNMPv3, NTP
A.1. Geographical Distribution 24429 Taobao 567 NTP, SNMPv3
202623 CLOUDFLARENET-CORE 265 NTP, SNMPv3
The geographical distribution of affected hosts is illus- 13335 CLOUDFLARENET 131 NTP, SNMPv3
trated in 3. 6185 APPLE-AUSTIN 130 DNS
44534 yandex-office 117 NTP, SNMPv3
19527 GOOGLE-2 60 HTTPS
109 CISCOSYSTEMS 46 IPMI
1216 ORACLE-OCI-IAD1 31 SNMPv3
394161 TESLA 25 SNMPv3, NTP
36040 YOUTUBE 14 SNMPv3, NTP

TABLE 22: Noteworthy Affected ASes

■ <1k ■ 1k-10k ■ 10k-100k ■ 100k-200k ■ >200k

Figure 3: Affected Host Distribution

As stated in Table 3, Italy has the most affected hosts,

more than the United States and China, the two countries
with the most IP address allocations [102]. The reason is that
AS1267 alone, which belongs to an Italian telecommunica-
tions company [103], accounted for 231,316 affected hosts,
as shown in Table 4.
We list the service distribution in AS1267 in Table 21.
Please note that one host may have more than one affected
service. We suspect that the affected hosts are mainly the
servers and network devices of this company.

Service Count % (of Hosts) Note

NTP 225,654 97.55% None allows monlist.
SNMPv3 4,062 1.76% 3,804 have the engine enter-
prise ID of Nokia (6527); 241
have that of Cisco (9).
SNMPv1 3,906 1.69% 3,750 run TiMOS by Nokia.
SNMPv2 3,889 1.68% 3,749 run TiMOS by Nokia.
DNS 1,833 0.79% 159 allow ANY queries.
HTTPS 1,358 0.59% 1,354 have the common name
[Link] in their
server certificates.
Others 91 0.04%

TABLE 21: Service Distribution in AS1267

Appendix B.
Meta-Review
The following meta-review was prepared by the program
committee for the 2025 IEEE Symposium on Security and
Privacy (S&P) as part of the review process as detailed in
the call for papers.

B.1. Summary

This work measures a firewall misconfiguration where

firewall rules allow traffic in either direction on a default
server port, allowing external actors to scan the network
using the server port as the source port. The authors scan
for these firewall rules using multiple vantage points across
different countries, finding this misconfiguration common in
the wild.

B.2. Scientific Contributions

• Identifies an Impactful Vulnerability

• Provides a Valuable Step Forward in an Established
Field

B.3. Reasons for Acceptance

1) This paper identifies an impactful vulnerability. The

authors demonstrate that in practice, many firewalls that
have rules to allow traffic to a server port will also
unintentionally allow traffic from a source port set to
the server port. Thus despite the firewall rules, external
actors can still scan a network. The authors demonstrate
that this misconfiguration occurs often across the Inter-
net.
2) This paper identifies a valuable step forward in an
established field. This work provides guidance on im-
proving firewall deployments, and also a technique
that may be helpful for Internet scanning, both well-
established fields.

B.4. Noteworthy Concerns

1) Broader evaluations of more source ports likely would

have observed a wider set of accessible services.