6

I've been running four servers on AWS for a few years. It's for a hobby project. All servers live in the same subnet in the same VPC.

To simplify the management of accounts and permissions, I've decided to use Active Directory. This means installing domain controller(s). Documentation indicates that to use AWS domain controller services, the domain controllers must be in a private subnet of the VPC. Continuing my research into private subnets, a term unfamiliar to me, I learned that EC2s in the private subnet must be behind a NAT gateway -- or at least that's a strong recommendation.

The recommendation to put domain controllers in a private subnet behind a NAT gateway is apparently based on the security benefits provided. This leads to my question: What exactly are those security benefits?

Here's why I ask...

My existing four servers each have a private IP and a routable ("elastic") IP but the firewall prevents anyone from connecting on the latter, unless I create a security rule that allows it. Why would this be any different for domain controllers? I understand that DCs will only be used by servers on my network, and never by random outside parties on the Internet, but wouldn't that simply be the default state of affairs unless I create an inbound security rule to the contrary? What's the point of segregating these DCs on an isolated subnet with their own NAT gateway? It seems to be adding complexity with no real upside. Well, presumably there is an upside and I just don't know what it is, thus my question.

(I'm a hobbyest, not a professional, so if you feel that this question is more suitable for SuperUser, I'll delete and repost there. I just figured since it was server-related this site might be more appropriate.)

Festus Martingale
  • 225
  • 1
  • 7
  • 5
    You might someday mess up the inbound rules and accidentally expose it. That's not possible if you're in a private subnet. – ceejayoz Jan 27 '19 at 22:00

4 Answers4

11

If an instance has a Public / Elastic IP I can directly target it with an attack. Maybe you left some unneeded ports open in the Security Group that I can exploit.

If it doesn’t have a Public / Elastic IP it’s close to invisible to the Internet and I can’t directly target it from outside.

Think of a house - if it’s got door directly on the street your house security depends on the door lock. However if it’s in a section behind a solid wall it’s much harder to even get to the door and try to break the lock. Even if you by mistake leave the door unlocked you should still be pretty secure.

So yes, if everything works as expected then the security of public and private subnets should be similar. But mistakes happen and having your resources in Private subnet gives you an extra layer of protection in such times.

Hope that helps :)

MLu
  • 24,849
  • 5
  • 59
  • 86
  • Yes, this makes sense, @MLu. Thanks for the explanation. One follow up question: If an EC2 on the public subnet with a routable (elastic) IP is attacked on a port that is *not* open via a legitimate security rule, will the malicious connection attempts actually hit the TCP/IP stack of the EC2 where they'll be rejected, or does the firewall block the request in such a manner so as the EC2 never even *sees* the attempts, nor uses any processing resources to reject/drop the packets? Put another way: Can the attacker execute an DOS against the EC2 by attacking ports NOT open by a valid sec rule? – Festus Martingale Jan 28 '19 at 02:56
  • 2
    @FestusMartingale Security Group blocks the traffic before it gets to your instance. The instance will never see it. – MLu Jan 28 '19 at 02:59
  • 1
    I believe based on bits and pieces I've read here and there that security groups and NACLs run on the hypervisor, so they don't reach the instance but they do reach the physical server. If you run Shield Advanced [the docs](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-responding.html) say the NACLs can be hosted at the network edge for increased performance rather than the instance. – Tim Jan 28 '19 at 06:40
0

tl;dr Security in depth.

While security groups can block incoming connections from external IPs, it is possible that they are misconfigured.

It's like locking the front gate in addition to the doors and windows. Even if a window is unlocked, an attacker can't reach it.

It seems to be adding complexity with no real upside.

There is certainly a case to be made for insufficient gains. NAT introduces another point of failure, it (sort of) breaks FTP, can introduce security concerns for UDP and multicast, etc.

In any case, it's upside is an additional layer of security.

Paul Draper
  • 317
  • 5
  • 24
0

In addition to the network considerations, think about service isolation. AD DS + DNS + File Server ideally are the only roles on domain controller hosts. Probably don't want a public web server on the same box as the credentials to your network.

You can make the directory someone else's problem by using a hosted directory service. At the cost of less flexibility and learning opportunity.

Secure networks are possible with a private or public IP. The difference is personal preference of how obvious you want to make the isolation.

Let's look at "private subnet" and "behind a NAT gateway" independently.

Separating an admin subnet from a public facing network subnet makes the boundary between the security zones obvious. At a glance, an IP is either internal or external. You can add AWS network ACLs or a third party firewall between them. (On top of security groups which are associated to instances, not subnets.)

NAT gateway doesn't really add security. Incoming connections are not allowed, but that's also doable with security groups.

NAT does conserve IPv4 addresses. Or, IPv6 with a egress-only Internet gateway uses zero IPv4 addresses.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
0

It's not more secure assuming the firewall rules were created correctly and you only have one server. The reason why you would want a private IP range is because it allows communication between multiple servers to happen securely. Take for example a web server and domain controller. You would want the web server to be able to securely communicate with the domain controller over a private network and you would also want to allow outside access to port 80/443. To accomplish this, would simply port forward port 80 and 443 directly to the www server. This configuration would protect the domain controller traffic by not exposing it to the public network.

Joe
  • 1,170
  • 1
  • 8
  • 12