Network Segmentation

Module: Infrastructure Security

Section: VPC Security

Lesson: Network Segmentation

Introduction: The Foundation of Modern Network Defense

In the early days of cloud computing, many organizations treated their Virtual Private Cloud (VPC) as a flat, single-network environment. This approach, while simple to configure, is fundamentally flawed from a security perspective. If an attacker gains access to one resource in a flat network, they gain the ability to move laterally across the entire environment, potentially reaching sensitive databases, internal APIs, or administrative consoles. Network segmentation is the practice of dividing a single network into smaller, isolated sub-networks, each with its own security policies and access controls.

Network segmentation is not merely a "nice-to-have" feature; it is a critical defensive strategy. By creating boundaries, you minimize the "blast radius" of a potential security breach. If a web server in a public-facing subnet is compromised, proper segmentation ensures that the attacker cannot easily reach the backend database or the internal management systems. This lesson explores the mechanics of network segmentation within a VPC, detailing how to implement it effectively using subnets, security groups, and network access control lists (NACLs).

The Core Components of VPC Segmentation

To understand how to segment a network, we must first look at the building blocks provided by cloud service providers. While terminology might vary slightly between providers like AWS, Azure, or GCP, the underlying concepts remain consistent.

1. Subnets

A subnet is a range of IP addresses in your VPC. By dividing your VPC into multiple subnets, you create the primary layer of logical separation. Typically, you will have:

• Public Subnets: These contain resources that must be accessible from the internet, such as load balancers or bastion hosts.
• Private Subnets: These contain internal resources like application servers and databases that should never have a direct route to the internet.
• Isolated Subnets: These are highly restricted areas for sensitive data, with no route to the internet and limited access even from other internal subnets.

2. Security Groups

Security groups act as virtual firewalls for individual instances or containers. Unlike subnets, which operate at the network level, security groups are stateful, meaning that if you send a request out, the response is automatically allowed back in. They operate on a "deny-all" default, meaning you must explicitly define which traffic is allowed to enter or leave the resource.

3. Network Access Control Lists (NACLs)

NACLs act as a firewall for the entire subnet. They are stateless, which means you must define rules for both inbound and outbound traffic separately. While security groups provide granular control at the instance level, NACLs provide a secondary layer of defense at the network perimeter.

Callout: Stateful vs. Stateless Firewalls The distinction between stateful and stateless firewalls is crucial for network security. A stateful firewall (Security Group) tracks the state of active connections; when a request is made, the return traffic is permitted automatically. A stateless firewall (NACL) treats every packet as an independent event. If you allow inbound traffic on a port, you must also define an outbound rule to allow the response to leave, or the traffic will be dropped.

Designing a Segmented VPC Architecture

A well-designed VPC architecture follows the principle of least privilege. You should never place all your resources in a single subnet. Instead, you should map your network topology to the specific requirements of your application tiers.

The Three-Tier Architecture Example

Most web applications benefit from a three-tier design:

1. Web Tier (Public Subnet): Contains load balancers and static content servers.
2. App Tier (Private Subnet): Contains the application logic. This tier is only accessible from the Web Tier.
3. Data Tier (Isolated Subnet): Contains databases. This tier is only accessible from the App Tier.

By implementing this structure, you ensure that a user on the internet can only talk to the Load Balancer. They cannot directly reach the App Tier or the Data Tier. This separation is enforced by security groups that only accept traffic from specific source security groups or specific CIDR blocks.

Practical Implementation: Step-by-Step

Let's look at how to implement this using a common configuration approach. We will use a hypothetical Terraform-style definition to demonstrate how to isolate a database from an application server.

Step 1: Defining the Subnets

First, we divide the VPC into logical segments.

# Public Subnet for Web Tier
resource "aws_subnet" "web_tier" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

# Private Subnet for App Tier
resource "aws_subnet" "app_tier" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.2.0/24"
}

# Isolated Subnet for Data Tier
resource "aws_subnet" "data_tier" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.3.0/24"
}

Step 2: Configuring Security Groups

Next, we define the security groups to enforce the flow of traffic. The key here is to reference the security group ID of the calling tier rather than an IP address.

# App Tier Security Group
resource "aws_security_group" "app_sg" {
  vpc_id = aws_vpc.main.id

  # Allow inbound from Web Tier only
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.web_sg.id]
  }
}

# Data Tier Security Group
resource "aws_security_group" "db_sg" {
  vpc_id = aws_vpc.main.id

  # Allow inbound from App Tier only
  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app_sg.id]
  }
}

Note: Always use security group references instead of hardcoded IP addresses whenever possible. IP addresses in cloud environments are often dynamic and can change due to auto-scaling events. Referencing by security group ID ensures that your security rules remain effective even as your infrastructure scales.

Advanced Segmentation Techniques

Once you have established basic sub-network segmentation, you can apply more advanced patterns to harden your environment further.

VPC Peering and Transit Gateways

When you have multiple VPCs (e.g., one for production and one for staging), you need a way to connect them securely. Rather than creating a wide-open connection, use VPC peering or a Transit Gateway with strictly defined route tables. By limiting the routes between VPCs, you ensure that even if a production server is compromised, it cannot reach the staging environment unless you have explicitly allowed that path.

Micro-segmentation

Micro-segmentation takes the concept of network segmentation to the individual workload level. Instead of just isolating tiers, you isolate individual services or containers. This is often achieved using Service Meshes (like Istio or Linkerd) or cloud-native container security policies. In a micro-segmented environment, two services in the same subnet might be prevented from talking to each other unless an explicit policy allows it.

Egress Filtering

Many security professionals focus heavily on inbound traffic, but egress (outbound) traffic is equally dangerous. If a server is compromised, the first thing it will attempt to do is "phone home" to a Command and Control (C2) server or download malicious payloads. You should restrict outbound traffic to only the necessary endpoints. This can be done via:

• NAT Gateways: Using a central NAT gateway to filter traffic.
• Proxy Servers: Routing all outbound traffic through an authenticated proxy that inspects the destination.
• Security Groups: Denying all outbound traffic by default and allowing only specific ports to specific CIDR blocks.

Comparison: Security Groups vs. Network ACLs

It is common for beginners to be confused about where to apply rules. The following table provides a quick reference to help you decide which tool to use.

Warning: Do not rely on NACLs for fine-grained application security. Because NACLs are stateless and apply to the entire subnet, they are difficult to manage for complex applications. Use them for "coarse" filtering, such as blocking entire ranges of malicious IP addresses, and reserve Security Groups for the specific communication requirements of your application services.

Common Pitfalls and How to Avoid Them

Even with a strong design, security gaps can appear due to configuration errors. Here are the most common mistakes to watch out for.

1. The "Allow All" Rule

The most dangerous rule in any security group is 0.0.0.0/0 on port 22 (SSH) or 3389 (RDP). This essentially opens your administrative ports to the entire internet.

• The Fix: Use a Bastion host (Jump Box), a VPN, or a Session Manager service to access your instances. Never expose management ports to the public internet.

2. Overly Permissive CIDR Blocks

Sometimes developers use broad CIDR blocks (e.g., 10.0.0.0/8) to allow communication between subnets to avoid "troubleshooting headaches." While this makes the network easy to manage, it defeats the purpose of segmentation.

• The Fix: Define the smallest possible CIDR range required for the service to function. If a service only needs to talk to one specific database, allow that specific IP or security group, not the entire subnet.

3. Neglecting Egress Control

Many teams leave the default "Allow all outbound" rule in place. This allows compromised instances to exfiltrate data easily.

• The Fix: Implement a "Default Deny" egress policy. Only allow traffic to necessary destinations like update repositories, API endpoints, or database clusters.

4. The "Flat Network" Trap

As organizations grow, they often add new services to existing subnets simply because it is faster than creating new ones. Over time, the subnets become bloated and lack proper isolation.

• The Fix: Review your VPC architecture quarterly. If a service has grown significantly, consider moving it to its own dedicated subnet with its own set of security group rules.

Best Practices for Infrastructure Security

To maintain a secure network, follow these industry-standard practices:

1. Infrastructure as Code (IaC): Use tools like Terraform or CloudFormation to define your network. This ensures that your security policies are version-controlled, auditable, and repeatable. You can also run automated scans (like tfsec or checkov) against your code to catch insecure configurations before they are deployed.
2. Least Privilege: Every security group rule should be as restrictive as possible. If a service doesn't need to talk to the internet, it shouldn't have a route to a NAT Gateway or Internet Gateway.
3. Centralized Logging: Enable VPC Flow Logs. Flow logs capture information about the IP traffic going to and from network interfaces in your VPC. This data is invaluable for detecting anomalous traffic patterns or identifying unauthorized attempts to access your resources.
4. Regular Audits: Use automated tools to scan your VPC for overly permissive security groups. Many cloud providers offer native services (like AWS Security Hub) that continuously monitor your network configuration against security standards.
5. Separate Environments: Always use separate VPCs for development, staging, and production. This ensures that a misconfiguration in a non-production environment cannot affect your live, customer-facing services.

Addressing Common Questions (FAQ)

Q: If I have a small application, is segmentation really necessary? A: Yes. Even small applications are targets for automated bots that scan the internet for open ports. If you leave a database exposed, it will eventually be discovered. Segmentation provides a layer of protection that is relatively low-effort to implement but high-value in terms of defense.

Q: Should I use NACLs if I already have Security Groups? A: You don't have to, but it is considered a best practice for defense-in-depth. NACLs provide a "fail-safe" if someone accidentally opens a security group to the world. They act as a final barrier to prevent traffic from entering a subnet.

Q: How do I manage security groups as my application scales? A: Use descriptive names and tags for your security groups. Document what each rule does and why it exists. When you remove a service, ensure you also remove the corresponding security group rules. If you find yourself with hundreds of rules, it may be time to move to a more advanced solution like a Service Mesh.

Summary and Key Takeaways

Network segmentation is a fundamental pillar of VPC security. By logically dividing your network and enforcing strict access controls, you can significantly reduce the risk of lateral movement and data exfiltration.

Key Takeaways:

• Implement Tiered Architecture: Always separate your resources into public, private, and isolated subnets based on their exposure to the internet and their role in the application.
• Use Security Groups for Granular Control: Leverage stateful security groups at the instance level to define exactly who can talk to whom, using security group IDs rather than IP addresses.
• Apply NACLs for Perimeter Defense: Use stateless network ACLs as a secondary, subnet-level firewall to block or allow traffic at the network boundary.
• Restrict Egress Traffic: Do not allow unrestricted outbound access. Control what your resources can reach to prevent data exfiltration and C2 communication.
• Automate and Audit: Treat your network security as code. Use IaC for deployments and implement automated monitoring to detect configuration drift or insecure rules.
• Adopt "Default Deny": Always start with a policy that denies all traffic and explicitly open only what is required for the application to function.
• Maintain Separation of Environments: Keep production and non-production environments in separate VPCs to ensure that a security incident in one does not compromise the other.

By following these principles, you build a resilient infrastructure that is not only secure against external threats but also robust enough to contain internal failures. Security is not a one-time setup; it is a continuous process of refinement, monitoring, and adaptation to the evolving threat landscape.