firewall-research.cs.ucr.edu Open in urlscan Pro
34.83.232.231  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Firewall Misconfiguration
 * What are we doing?
 * Why should I care?
 * What is going on?
 * Technical details
   * Stateless Firewall
   * Stateful Firewall
 * Verification steps
   * SSH Service
   * HTTP(S) Service
   * NTP Service
   * DNS Service
 * Possible fixes
   * Fix with stateful firewalls
   * Fix with stateless firewalls
 * Contact us / opt out

We are from a security research team at the University of California, Riverside
.

You are here because our recent academic study found possible firewall
misconfiguration in your autonomous system.

You can learn more about the study and the misconfiguration on this page.


WHAT ARE WE DOING?

We are conducting a study on the security of firewalls. We performed
Internet-wide scans to identify affected services behind misconfigured firewalls
and notified the contacts of corresponding autonomous systems.

Internet-wide scanning is a common practice for network security research,
including threat intelligence and vulnerability assessment. During our scanning,
we collected minimal data for analysis and did not perform any aggressive
probing.

We work to improve the security of cyberspace, and we are writing an academic
paper about this vulnerability.


WHY SHOULD I CARE?

Devices often get public IP addresses from ISPs, companies, universities, and
even cell carriers, which means they can be directly reached by anyone on the
Internet. At the same time, attackers are constantly scanning the whole Internet
to discover vulnerable devices and compromise them.

As a result, firewalls are widely deployed to enhance security, like blocking
external access.

However, we find that wrongly or imperfectly configured firewalls may fail
silently and expose internal hosts and sensitive services to external attackers,
which is likely to happen in your autonomous system.

Exposure and attacks on your internal services may lead to service outages,
information leakage, and/or compromise of devices.


WHAT IS GOING ON?

We find that wrongly or imperfectly configured firewalls may fail silently and
expose internal hosts and sensitive services to external attackers.

According to our measurement, this issue have probably affected the firewalls of
your organization or your clients. We have attached the list of affected hosts
and services in the email to you.

Well-functioning Firewall blocks external attacks.

Misconfigured firewall may fail silently.

While we find no conclusive signs of exploitation in the wild (for now), and the
exposed services are not necessarily vulnerable, the firewall can be effectively
nullified.

This poses a hidden threat to the affected hosts, and we highly recommend that
you patch it as soon as possible.


TECHNICAL DETAILS

With certain flawed rules, firewalls may be bypassed when attackers initiate
connections from spacial source ports.

The causes of this vulnerability vary depending on the type of firewall.


STATELESS FIREWALL

Stateless firewalls inspect network traffic on a packet basis and do not
understand network flows (like TCP connections and UDP sessions). When packets
flow through a stateless firewall, it matches the packets against the
provisioned policies and makes decisions based on properties like source port
and destination address.

Stateless firewalls are generally incapable of differentiating between inbound
and outbound connections. Therefore, flawed rules may result in loopholes that
permit unwanted traffic.

For example, a network administrator wants to configure the firewall to allow
accessing only external HTTP services on TCP port 80 and forbid any inbound
connections. They may set up the following rules:

 1. Permit all TCP segments from internal hosts to port 80 of external hosts.
 2. Permit all TCP segments from port 80 of external hosts to internal hosts.
 3. Discard all other IP packets.

These rules usually work well as operating systems typically use random high
ports as source ports, and inbound connections are supposed to be rejected by
Rule 3.

However, if an attacker initiates TCP connections to the internal hosts from
port 80, the initial SYN segment will be permitted by the second rule. Then, the
following traffic always falls into the first two rules, circumventing the
intention of blocking inbound connections.

Normal traffic: allowed

Attack from high ports: blocked

Attack from port 80: overlooked

Similar misconfiguration can happen when allowing UDP protocols like DNS (UDP
53) and NTP (UDP 123).


STATEFUL FIREWALL

Stateful firewalls are capable of tracking network flows and are less
vulnerable.

Stateful firewalls enforce policies against network flows. As it can
differentiate the direction of connections, it is rare for stateful firewalls to
undergo the same misconfiguration as stateless firewalls. However, they are
still prone to human errors like misspelling:

 1. Permit outbound new connections.
 2. Permit inbound connections from port 80.
 3. Discard all other IP packets.

In this example, the destination port is misspelled as a source port, opening up
a loophole.


VERIFICATION STEPS

Due to the volatility of networks, some or all of the services in your report
may not work. This does not mean the issue has been automatically resolved and
there may be other services affected by it.

You may refer to the following steps to reproduce and verify the affected
services in the report.

Please run the command on a machine outside your organization, ideally without
NAT, in case the firewall excludes internal traffic or the source port gets
modified.


SSH SERVICE

To verify the SSH service on a.b.c.d is affected:

# There is no response if the connection is initiated from a random port.
nc a.b.c.d 22

# There is an SSH banner if the connection is initiated from port 80.
sudo nc -p 80 a.b.c.d 22


HTTP(S) SERVICE

To verify the HTTP service on a.b.c.d is affected:

# There is no response if the HTTP request is sent from a random port.
curl -v http://a.b.c.d

# There is a webpage if the HTTP request is sent from port 80.
sudo curl -v --local-port 80 http://a.b.c.d


To verify an HTTPS service, please add -k and change http:// to https://:

# There is no response if the HTTP request is sent from a random port.
curl -vk https://a.b.c.d

# There is a webpage if the HTTP request is sent from port 80.
sudo curl -vk --local-port 80 https://a.b.c.d



NTP SERVICE

To verify the NTP service on a.b.c.d is affected:

# There is no response if the request is sent from a random port.
cat ntp_123.pkt | nc -u a.b.c.d 123

# There is a response if the request is sent from port 53.
cat ntp_123.pkt | sudo nc -u -p 53 a.b.c.d 123


You can download ntp_123.pkt from GitHub.


DNS SERVICE

To verify the DNS service on a.b.c.d is affected:

# There is no response if the request is sent from a random port.
cat dns_53.pkt | nc -u a.b.c.d 53

# There is a response if the request is sent from port 53.
cat dns_53.pkt | sudo nc -u -p 53 a.b.c.d 53


You can download dns_53.pkt from GitHub.


POSSIBLE FIXES

If you do not directly manage the involved hosts/firewalls, please notify their
actual administrators.

Due to the diversity of firewall products, there is no universal solution.
However, we have some general suggestions.


FIX WITH STATEFUL FIREWALLS

Stateful firewalls can track network flows and block inbound connections. You
can use a stateful firewall for a complete fix.

If you already use a stateful firewall...

If you are currently using a stateful firewall but still received the
notification, please check whether the rules accidentally allow inbound
connections from TCP port 80 or UDP port 53.

One common mistake in iptables is misspelling the dport as sport.

If you use a dual-mode firewall...

Some firewalls support both stateful and stateless modes, like iptables. In this
case, please adopt the stateful mode whenever possible.

For example, to allow DNS traffic with iptables, please use:

iptables -A OUTPUT -p udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --sport 53 -m state --state ESTABLISHED -j ACCEPT


instead of:

iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT



FIX WITH STATELESS FIREWALLS

If you must keep using a stateless firewall, you can still implement partial
fixes.

If your TCP services are affected & your firewall supports TCP flag filtering...

Some stateless firewalls support filtering TCP segments by the TCP flags,
including SYN. You may block incoming TCP segments with the SYN flag to block
unwanted inbound connections.

However, this is only a partial fix, as it only applies to TCP traffic, not UDP.
The implementations of some firewall products can be problematic, too,
preventing this mechanism from taking effect.

If your UDP services are affected & you only need access to a few known UDP
services...

If you only need access to a few essential UDP services like DNS or NTP on known
hosts (like public DNS/NTP servers), you may block all UDP traffic except that
from/to the ports of the known servers.

However, this may affect other UDP services used by the users, like VPN or VoIP.

If you have no other choice...

You may apply a temporary fix by blocking all traffic to and from the sensitive
port of your internal hosts.

For example, if port 22 of one host a.b.c.d is affected, you may add an extra
rule to block all traffic to and from a.b.c.d:22. This does not affect internal
access and should not cause problems as a.b.c.d should not initiate connections
from port 22.


CONTACT US / OPT OUT

If you have any further questions or would like to share the case and root cause
in your organization, you may reach us at firewallresearch@ucr.edu.

However, due to the large volume of emails, we may not respond to all inquiries
in time.

Please email us if you want to opt out of this study. Due to the nature of the
Internet, it is infeasible to get consent in advance when performing
Internet-wide studies. While we did not perform any aggressive probing, we
respect your opinion about opting out.

Icons Designed by Freepik