Secure Networking: Bastion Servers and Effective Firewalls
Bastion [bas-chuhn, -tee-uhn]
noun
-
Fortification. a projecting portion of a rampart or fortification that forms an irregular pentagon attached at the base to the main work.
-
A fortified place.
Resource accessibility and network security challenges
Anything connected to The Internet is a potential target for external attacks. Period. It’s as simple as that. While steps can be taken to secure resources, such as using firewalls, the reality is that if a service has a public IP address, there’s the risk that malicious parties will attempt to compromise it. Every internet-facing device in the estate increases your potential attack surface. Additionally, external IP addresses come with associated costs!
How can we effectively reduce this risk? (and associated costs)
We can implement a network topology that restricts services from allowing direct inbound access to our resources to effectively mitigate the risk of them becoming compromised and reduce costs associated with IP addresses. By default, NexGen resources permit all outbound connectivity (In this guide we will focus on securing inbound traffic). Assigning private IP addresses exclusively to components that do not need to direct external accessibility—such as backend app and DB servers meant to communicate only with frontend services like web hosts-reduces the external footprint, improving your security posture.
To learn more about the public and private IP addresses click here.
Figure 1: Bastion vs Direct Device Access
Customer Environment 1
- In the figure above, devices are allocated with public IP addresses, making them directly accessible from The Internet, posing potential risks from both authorized and unauthorized personnel. To mitigate this, security controls must be applied to all devices and consistently managed and monitored. However, as the estate expands or undergoes changes, maintaining access rules can become complex.
Customer Environment 2
- In the figure above, only Bastion-1 is exposed to The Internet. Server-1 and Server-2 do not have public IP addresses, making them inaccessible externally. Services can be proxied (relayed via another service – e.g. Bastion-1) if needed, but in many designs, inbound access is unnecessary. Utilizing Bastion-1 as a jump host enables access, as SSH. This topology offers the advantage of stricter controls at the “front door”, reducing the attack-vector and enhancing manageability. Additionally, making changes to rules, such as allowing specific public IP addresses to SSH to your estate, is simpler as there is only a single device to manage.
Planning your network topology
“Measure twice, cut once”
We highly recommend creating a diagram of your estate. Having a clear understanding of your existing and future network topology allows for informed design decisions and simplifies troubleshooting efforts. Investing time in planning pays off in the long run. An excellent and free tool for this purpose is (www.draw.io) – you’re welcome!
Figure 2: Network topology diagram
Designing firewall rules for your network
Once you have your diagram, creating a table of necessary firewall rules becomes straightforward. The most effective approach is to list sources, destinations, ports, and whether the connection is one-way or bi-directional. These rules will serve as the foundation for defining permitted connectivity, ensuring the security of your environment.
| Rule # | Rule Name | Source | Destination | Ports | Direction |
|---|---|---|---|---|---|
| 1 | Bastion SSH | Any (0.0.0.0 /0) | Bastion (PUBLIC IP) | TCP22 | Ingress |
| 2 | Bastion to internal | Bastion (PRIVATE IP) | APPLICATION (10.10.1.0/24) | TCP22 | Ingress |
Rule 1: Bastion SSH
- The source is set to known IP addresses, such as the office, and the destination is set to the public address of the bastion server.
Rule 2: Bastion to internal IP
- The source address is set as the private IP address of the bastion server, and the destinations are defined as the APPLICATION and BACKEND networks.
Once you have determined the firewall rules needed to keep your resources secure, learn about the steps to implement them in Hyperstack or through the Infrahub API here.