Why Use a Bastion Host?

Have you ever wanted to create a network of machines to work together? Maybe for fun, or maybe because you are running an organization that needs more computers. Whatever the reason may be, it is best to use bastion hosts. Bastion hosts act as gateways into your network and they can protect all other devices on the network from unwanted visitors. In this blog post, we will discuss what exactly bastion hosts are and why they should be used by everyone who wants their data protected!

Why Use a Bastion Host?

A bastion host is a server that gives authorized users access to internal servers, such as web or database. For example, if you have software hosted on an application server and want to give your customers updates over the internet then the only way they can do this is through a secure connection using SSH (Secure Shell). Only certain people in your organization should be able to log into it directly. This creates a security risk because anyone could ssh from outside of your network without going inside first. By putting a machine between them and your internal infrastructure you create what’s called ‘defense in depth’ which means building multiple layers of defense against attack instead of just one layer. The more layers there are the harder it will be for unauthorized parties to get past them to run scripts on your application server.

This is where a bastion host comes in. It sits between an edge router and the internal servers, requiring anyone who wants to access them from outside of your network’s firewall to first log into it using SSH (Secure Shell). From there authorized parties can then use other protocols like SFTP or SCP (SSH File Transfer Protocol) over port 22 when accessing sensitive information about users or applications that are hosted inside of private networks. Only people with valid credentials should be able to ssh into this box, which makes managing their keys extremely important because if someone obtains root privileges they could potentially disable auditing altogether for all clients connecting through it!

A good example would be hosting WordPress websites internally behind Apache web servers. To update your plugins or themes you need to log into the box via SSH and use SFTP, SCP, or FTP to transfer files back and forth between WordPress servers in order to prevent attackers from being able to execute arbitrary code on them.

The very existence of this server also acts as a deterrent for malicious parties because it’s well known that many organizations have their own internal security policies which oftentimes require updates be done through secure protocols like SSH instead of less-secure ones such as FTP. This means even if an attacker is skilled enough they are still unable to take advantage of vulnerabilities found within individual applications until after they’ve breached the bastion host first!

How to Set up a Bastion Host?

The best way to set up a bastion host is by using what’s called ‘jump boxes’. They are just servers that you install ssh on, give them one or more IP addresses, then configure your routers to send traffic destined for those IPs into it instead. You can either do this manually each time or write scripts which will automatically configure the router every time you make changes!

For example, let’s say we have an internal network (192.168.0.0/24) where everything should be accessible only from inside of our LAN and external access should go through the bastion server first before continuing along its intended path:

You would need two different subnets in order to allow SSH connections but not let anything else pass through. One subnet would be for your bastion server’s IP range, the other is where you’d want to send SSH traffic destined for internal servers.

The first thing you will do is set up an ACL (Access Control List) on your router that sends all traffic with a destination of 192.168 .0 .X into this box instead:

ACL Name Type Protocol Source Address Destination Address Action Allow-SSH any TCP 192.168 .0 0/24 anywhere allow 192.168 .0 0/24 ANY deny Keep in mind by doing it this way ALL non-SSH related protocols are blocked from passing through! This includes FTP, SCP, SFTP, ICMP packets etc so don’t forget about those!

The next step is to set up a keypair for SSH access, and configure your bastion host so it only allows connections from the above ACL:

ssh -i /root/keys/privatekey 192.168 .0 0.XXX ” ulimit -S -c 0 & tail -f /var/log/messages” This command opens port 22 on all interfaces (0.0.0.0) of the box which matches the IP address in ‘From’ section of our ACL earlier AND logs everything that happens on this port into ‘/var/logs’. The second line runs every time someone successfully connects through it so you can see what’s happening in real-time having to login yourself!

The next step is to create a reverse-proxy rule which sends all web traffic destined for the internal network (192.168 .0 0/24) through port 80 on your bastion host first:

iptables -t nat -A PREROUTING -i eth0 \ –destination 192.168 .0 0/24 \ –protocol tcp –dport 80 \ -j REDIRECT You can configure this by editing ‘/etc/sysconfig/iptables’ file, just make sure it’s saved after making changes! This will ensure that any packets sent from our LAN with destination IPs within range of ‘internal_net’ are redirected through port 80 & 443 of the bastion host instead.

The final step is to setup a rule on your bastion host which will forward packets destined for 192.168 .0 0/24 through port 80 & 443 of the internal web server:

iptables -A INPUT -i eth0 \ –destination 192.168 .0 0/24 \ –protocol tcp –dport 80 \ -j ACCEPT iptables -A INPUT -i eth0 \ –destination 192.168 .0 0/24 \ –protocol tcp –dport 443 \ -j ACCEPT If you ever need to undo these changes just run ‘iptables-save’ to dump your current rules, then use ‘iptables-restore’ to revert back to them!

So now you should have access over SSH and be able to connect through it from any machine on the internet. Your internal LAN will be inaccessible unless they are also logged into their own private key as well. You can set up additional jump servers at other locations which allow for even more security by adding another layer of VPNs or physical isolation between machines.

Common Uses for Bastion Hosts:

Preventing direct access to internal servers from the public web
SSH tunneling/forwarding which allows for secure connections between two machines without having to expose them directly on the internet.
Accessing and controlling internal servers across the internet
Creating a network within a network, or segmentation of resources for security purposes.
Bypassing restrictive firewall rules, such as those which prevent access to certain ports/protocols.
Removing machines from a network and putting them in their own protected space to reduce the surface area for attacks.
Isolating potentially malicious users who are not trusted with full administrative rights on all systems (just bastion host).

When to Use a Bastion Host and When not to Use One at All?

A bastion host should not be used for hosting any publicly accessible service. If you need to provide public access to a resource, use a reverse proxy instead of opening an SSH connection back into your internal network.

A bastion host is only necessary when there are no other options available to secure access into your internal systems or networks. For example: if you’re using an open wireless network with default ports/protocols exposed then it’s probably time to look at either changing how your users connect (e.g.: captive portal), upgrading your hardware/software which provides internet connectivity (router) or even replacing this system altogether. Or in cases where VPN software isn’t supported on certain operating systems, such as Chromebooks running ChromeOS, OpenWrt routers etc

Bastion hosts are only useful when trying something like this:

You have significantly limited resources available (memory/cpu) and want the added security provided by compartmentalization.
You’re using cloud computing services which prevent direct access to machines running inside them (like AWS).
The machine has very little traffic passing through it or uses protocols that will not work over NAT (UDP is one example).
Your firewall rules allow inbound connections on port 22 but nothing else.
You do not want to use SSH tunneling for security reasons, maybe because you’re afraid of exposing keys or forwarding port 22 to an attacker who connects back into your internal network (which the bastion host will prevent).
SSH can also display banners when connecting that may give away information about your OS and software versions. Using SSL tunnels with stunnel & XMPP/Jabber instead is another option here if it suits your needs better than using SSH.

Why Use a Bastion Host?