In networking, creating a firewall pinhole is a method that allows hosts outside an enterprise network to gain access to a resource, such as a web server, found inside the enterprise network. The word “pinhole” refers to a transport layer destination port that is unprotected and thus allows incoming traffic to traverse the firewall.
In an IPv4 environment, Network Address Translation (NAT) is almost always implemented at the edge of the enterprise network. When this is the case, we use what is known as port forwarding, which is also considered a kind of pinholing.
Security is always the major concern when implementing any kind of firewall or network-edge pinhole. The pinhole is a single port among over 65,000 possible ports used by TCP or UDP. As such, it may sound quite difficult for an attacker to discover a single open port, comparing it to something like looking for a needle (or a pin) in a haystack. Nevertheless, it is almost trivial for an attacker to discover pinholes these days, so any such configuration must employ the appropriate security safeguards.
The pinhole as a concept is essentially the same when it comes to IPv6 as in IPv4. However, the very nature of IPv6 makes pinholing in such an environment somewhat easier but also somewhat more prone to security issues, primarily due to the elimination of NAT.
In this article, we’ll examine firewall pinholes in general, the security concerns and mitigation techniques that accompany them, and how IPv6 pinholing can be done efficiently and safely.
Summary of key concepts
| Firewall Pinholing | Firewall pinholing is the act of configuring an unprotected transport layer port on a firewall. |
| Pinholing with NAT | Pinholing within a NAT environment is also called port forwarding. |
| Pinholing with IPv6 | IPv6 pinholing is simple because public IPv6 addresses can be routinely used within an enterprise network. |
| IPv6 Pinholing Security Concerns | IPv6 pinholing potentially exposes internal IPv6 hosts to malicious attacks. |
| Security Techniques for Pinholing | Pinholing must be accompanied by mechanisms that will open and close pinholes dynamically by implementing user validation and authorization. |
Securing the network edge
An enterprise network consists of one or more local area networks (LANs) where internal hosts such as PCs, wireless access points, IP phones, cameras, printers, and other network devices are connected. These LANs are connected, in turn, to the Internet via one or more Internet Service Providers (ISPs). The enterprise network devices that connect to the ISPs are typically security devices such as firewalls, edge devices such as routers, or a combination of both. This portion of the network is called the edge network.
One of the responsibilities of the edge network is to block potentially malicious attacks from the Internet. This is done by denying incoming traffic that originates on the Internet that attempts to enter the enterprise network.
What is pinholing?
Creating security policies on the network edge is fundamental to securing an enterprise network from a wide variety of malicious attacks originating on the Internet. However, what if you want to allow legitimate Internet users to access a specific resource found on your enterprise network? Take a look at the following diagram.
Let’s say there’s a web server on the internal enterprise network with a public IPv4 address (one advertised on the Internet), so a legitimate user is attempting to access that server, as shown. The edge network device, which is typically a firewall, must allow that traffic to traverse the firewall and reach the web server even if it blocks traffic normally.
This is where pinholing comes in. The firewall can be configured to allow any traffic destined for the web server IP address on a specific TCP port, say port 80 (which is for HTTP), to traverse the firewall and reach the intended destination. The pinhole allows only traffic that conforms to this IP address / TCP port combination, blocking anything else.
What about NAT?
In an IPv4 environment, the vast majority of enterprise networks have internal devices using IPv4 private addresses such as those defined in RFC 1918. In such cases, the edge network device will also implement NAT to translate those private addresses into public routable addresses. By design, NAT will typically deny any incoming traffic that has originated from the Internet unless it has been specifically configured to translate such traffic.
A pinhole configured in a NAT environment is known by its much more common name: port forwarding. For example, take a look at this revised diagram.
The web server has an internal IP address of 10.10.10.1, while the edge network device performing NAT has an outside interface address of 147.52.1.1. A NAT rule has been configured on this firewall that translates the destination address/port combination of all traffic destined for 147.52.1.1:8080 to 10.10.10.1:80. Thus, port 8080 on the outside interface has been port-forwarded, or pinholed, to port 80 on the web server. This allows legitimate users to reach the web server only if they know to use the appropriate port number that has been pinholed.
Securing a pinhole
Astute readers will realize that this arrangement is not very secure at all. Whether we use NAT or not, port numbers such as 80 and even 8080 are well known and will be tested by attackers for security weaknesses. Even if you choose a random value, such as 53487, the same problems occur because your legitimate users must know to use this port number, so malicious attackers will discover it. Even curious folks experimenting with port scanning utilities can easily scan the full range of TCP and UDP ports for vulnerabilities, discovering “obscure” port numbers literally in seconds.
Additional security features must be applied to make the creation, maintenance, and closing of pinholes dynamic.
Using IPv6 with pinholes
The advent of IPv6 introduces a new dimension to pinholing. IPv6’s vast address space negates the need for NAT, so every host on every internal network in the world can have a public IPv6 address that is routable on the Internet, vastly simplifying pinholing. Any internal host can have a pinhole opened up by simply indicating which transport layer port you want to allow through the security device at the edge of your network. No port forwarding is necessary, so a layer of sometimes complex NAT configuration is eliminated.
In essence, pinholing for IPv6 is an upside-down version of pinholing for IPv4. Where IPv4 requires pinholes to be opened in NAT for particular addresses, IPv6 pinholing can be viewed as consisting of blocking undesired traffic to specific devices or processes, since reachability is guaranteed by the IPv6 protocol itself.
At the same time, security concerns are vastly increased because of the removal of NAT. A side effect of NAT, which is the most typical implementation, is that by default, without any other security features configured, it is generally more difficult for an attacker on the Internet to reach an internal host. Since there is no NAT to introduce this additional deterrent to potential attackers, the opening up of pinholes must be done with even more care, since this obstacle, albeit a side effect of another feature, is gone.
Implementing an IPv6 pinhole
The right way to set up a pinhole depends highly on the security device being used. It may be a firewall, intrusion detection system (IDS), intrusion prevention system (IPS), or just an access list configured on a plain router. The following example describes the simple setup of an IPv6 access list on a Cisco router that is configured to allow web access via a specific TCP port.
For this example, we’ll be using the following topology:
We’ll create an access list that will be applied on the outside interface of the edge router in an incoming direction to block all access to the web server except for port 18080. Thus, we will open a pinhole in the edge router to the web server on port 18080.
To do so, we will first create an access list and call it WebServerPinhole, like so:
EdgeRouter(config)#ipv6 access-list WebServerPinhole
Next, we will permit traffic that fulfills the following conditions:
- Uses the TCP protocol
- Comes from any source IPv6 address
- Has a destination address of 2001:ABCD:0:10::1 and a destination TCP port of 18080
EdgeRouter(config-ipv6-acl)#permit tcp any host 2001:ABCD:0:10::1 eq 18080
Next, we want to block all other types of traffic. This can be done by adding the following access list entry and then exiting access list configuration mode:
EdgeRouter(config-ipv6-acl)#deny any any
EdgeRouter(config-ipv6-acl)#exit
EdgeRouter(config)#
Note that Cisco devices default to always having an implicit deny statement at the end of all access lists, blocking everything else, but we put it in here explicitly for clarity.
Finally, we can now apply this access list in an incoming direction on the Internet-facing interface:
EdgeRouter(config)#interface gigabitethernet 0/1
EdgeRouter(config-if)#ipv6 traffic-filter WebServerPinhole in
In the absence of an actual host on the Internet with a browser, we can use a Linux utility called netcat to test which ports are open and which are not. Let’s assume our Internet host is a Linux device. We issue the following commands:
$ nc -vz 2001:ABCD:0:10::1 18080
2001:ABCD:0:10::1 18080 open
The -v option means “verbose,” and the -z option means no data is exchanged, only the open port is detected.
Note that the port is indeed open. If we try to check any other port, we will get the following result:
$ nc -vz 2001:ABCD:0:10::1 80
2001:ABCD:0:10::1 80 80 (http) : Connection refused
The pinhole has been successfully created.
Note that the purpose of this example is to showcase the concept and the mechanisms involved in pinholing. In a production environment, many more precautions should be taken such as dropping all TCP non-SYN packets belonging to non-opened TCP sessions, as well as filtering any IPv6 Unique Local addresses which should never be seen as source addresses from the Internet.
In addition, this is a manually configured pinhole. As you will see in the following section, manually configured pinholes should generally be avoided whenever possible on a production environment, especially on the network edge.
Recommendations and best practices
Pinholing, especially in an IPv6 environment, must be implemented with great care, taking into account security concerns inherent to the protocol’s nature. The following sections describe some of the most important recommendations and best practices to keep in mind when implementing it.
Use pinholing sparingly
- Pinholing should be used only in situations where there is no alternative, or the alternative is impractical to implement either due to a lack of equipment or prohibitive cost.
- It should be used only when there are no more than one or two internal resources that you want to make available to the Internet at large.
- It should be applied for low-risk resources and not services requiring highly secure communications, such as financial transactions or databases with sensitive information or personal data.
Implementing pinhole security
Pinholes should never be configured manually or statically without the appropriate level of security. Such a situation would present a permanently vulnerable port to the Internet, where attackers will find it relatively quickly and compromise it. Pinholes should always be created dynamically using authentication and authorization techniques. Once again, because of the existence of NAT, IPv4 uses techniques such as:
- TCP and UDP Hole Punching: A technique used to connect two hosts, typically over the Internet, when both hosts connect behind a NAT router. This is especially useful in peer-to-peer applications.
- NAT Traversal (NAT-T): A methodology used to establish and maintain IP connections across gateways that use NAT.
- Universal Plug and Play (UPnP): A set of networking protocols that can be used to dynamically add and remove port mappings to allow or deny traffic across a NAT router.
These techniques and technologies primarily deal with resolving NAT issues associated with the use of IPv4. IPv6 pinholing requires more sophisticated applications that will employ user authentication to open pinholes and close them when they’re no longer needed.
The trouble is that there are still few such mechanisms for IPv6. One way to recreate the level of security that IPv4 NAT delivered is to use NAT66, which is IPv6’s equivalent to NAT. It translates public global unicast IPv6 addresses to unique local addresses (ULAs) as defined in RFC 4193. These are IPv6’s equivalent of IPv4’s private addresses (RFC 1918). However, while this is an option, the benefits are vastly outweighed by the problems that reintroducing NAT into the network would create.
Pinholing can also be applied in conjunction with a NGFW. Today’s advanced firewalls can perform deep packet inspection to determine the nature of a particular packet before letting it traverse the firewall. The contents of packets can be inspected all the way up to layer 7 (the application layer) to determine whether the packet is valid and from a legitimate source or comes from a suspicious source.
Alternatives to pinholes
Unless security is not a great concern, it is almost always preferable to use an alternative to pinholing to enable users on the Internet to gain access to your internal resources, especially when using IPv6.
One option is to implement a demilitarized zone (DMZ) on the edge of your enterprise network and place all your Internet-facing services within it. A DMZ is a network segment specially designed to allow access to these services from the Internet while maintaining an acceptable level of security.
Another possibility is hosting services on offsite, outsourced data centers. This is particularly worth considering if you have resources you want to make available to your customers on the Internet regularly. Such data centers have all the necessary security measures in place to ensure that your data and services remain secure.
Conclusion
Firewall pinholing is a quick and easy fix to an often difficult problem: providing limited access to an internal network while maintaining general security. With IPv4 and NAT, the process was often more complex and involved the development of various additional protocols to enable it to function. With the advent of IPv6 and the resulting removal of the need for NAT, pinholing has become much easier but much more prone to security risks.
By taking the correct precautions, it is possible to ensure that a pinhole is implemented correctly and securely. However, it is always best practice, whenever possible, to use other, more appropriate industry-standard methods to allow users to gain access to resources inside your network.