3

Have a private network with servers that required SSH access. Since the instances are in a private subnet, they cannot be accessed directly via SSH and require a public Bastion host to access.

Workstation -> via SSH -> Bastion -> via SSH Forwarding -> private subnet instnce

We use a NAT host as a public gateway to the private network. 

User -> via HTTP -> NAT -> via private networking -> private subnet instance

What are the benefits of keeping the Bastion & NAT hosts separate? What are the benefits of combining them?

csi
  • 1,535
  • 7
  • 22
  • 42
  • Ask five people, you'll get five different answers. All of them backed by logic. This is purely opinion. – John Oct 01 '14 at 16:44
  • 1
    @John edited the question to elicit fact based answers. Can you provide your insight? – csi Oct 01 '14 at 17:44
  • I don’t think there are many _logically backed_ opinions in regards. – poige Jan 12 '20 at 06:51

2 Answers2

2

From a technical point of view you can use your NAT as your bastion host but from an architectural point of view you should never do that. And here is why:

Your bastion host is the entry point to your internal infrastructure and your NAT usually connects important services like your database to the internet. So both should be secured as much as possible.

Your bastion host and your NAT have opposite roles:

  • The bastion host should allow initiating connections from the internet (from a limited IP range) and deny all initiating traffic to the internet
  • The NAT should deny all initiating traffic from the internet and allow initiating traffic from the internal net to the internet

Also the bastion host is just a management server so a cheap instance is usually sufficient whereas the NAT must be able to potentially route a large amount of traffic.

There is no rational reason why you should use your NAT as your bastion host except you do not care about security ;-)

zebra
  • 21
  • 3
  • you misunderstood theirs use of NAT. NAT is broad term which can be Source NAT or Destination NAT (in terms of Linux’ Netfilter), for e. g.. – poige Jan 12 '20 at 06:26
0

Bastion host you described is a jump host in nutshell, which allows central control of the access at OSI levels starting from “Networking” and then upper. You can restrict access to such a single host by a user name and keys there and that would be sufficient. You can also deploy all kind of auditing/commands logging there.

NAT means networking level only — you can control protocols, source and destination IPs (and ports) but mostly that’s it.

When talking about combining them the only possible impact could be due to unwanted interference between those two. Worst case scenarios:

  • NAT misuse allows SSH logging into bastion host itself (highly unlikely, nearly impossible)
  • Users allowed to log into jump host will screw up NAT rules (possible in theory but relatively easy to be restricted and we should remember that SSH users are trusted ones by definition — meaning it’s a minor objection)
  • Traces mix. Unless separated forcefully you can’t distinguish Bastion’s host local users’ traffic and NATed. With due logging isn’t a problem. Using dedicated IPs for NAT and SSH environment also solves this. Isn’t an issue if Bastion’s SSH local users aren’t allowed to establish outgoing connections as well.
poige
  • 9,171
  • 2
  • 24
  • 50