Secure network ingress and egress traffic

Network ingress and egress controls determine what traffic can enter and leave your infrastructure. As you transition to a security culture centered around identity, managing traffic to and from your infrastructure, both cloud and self-managed, becomes an essential component of security.

Traditional infrastructure relies on network-based controls to manage ingress traffic, which is traffic coming into your network, and egress traffic, which is traffic exiting your network.

Small networks often use a flat network and can only manage traffic at the network perimeter. Larger networks or organizations with a more mature security program create virtual networks (VLANs) to separate network traffic. VLANs allow you to create internal network perimeters and deploy network access controls (NACL) to manage traffic. Security teams also have the option to configure operating system firewalls to help manage traffic. Managing local operating system firewalls is often difficult to manage at scale and places additional overhead on each system to process traffic.

Modern infrastructure still relies on VLANs for network isolation, however advances in networking services provide even greater control. Most modern infrastructure as a service (IaaS) providers allow you to filter both ingress and egress traffic at the network interface (NIC) level, before it reaches the operating system. Managing traffic at the NIC level is also known as micro-segmentation and is a key component as you build towards a zero trust network architecture.

Why network ingress and egress security matters

Managing network ingress has been a standard security practice for decades. Managing egress traffic, however, is often overlooked. Managing egress traffic ensures that systems that do not require outbound network access are not able to initiate connections to external systems. This helps prevent data exfiltration and limits the ability of attackers to communicate with command and control servers.

While managing network ingress and egress is important, it can be resource intensive to manage at scale. As you build a culture of security centered around identity, you begin to shift away from network-based controls, and focus on identity-based security.

Use service mesh for traffic control with Consul

HashiCorp Consul allows you to connect infrastructure and services using a service mesh. Consul protects communication using mutual TLS (mTLS) to ensure that only authorized services can communicate with each other. Using Consul provides you with:

Automatic mTLS encryption for all service communication, eliminating the need for network-level encryption.
Service intentions that act as application-aware firewall rules, allowing you to define which services can communicate based on identity rather than IP addresses.
Transparent proxy integration that automatically routes and secures traffic without application code changes.
L7 traffic management including traffic splitting, timeouts, and retries that reduce the need for complex network configurations.

By using Consul, you shift from managing network ports and IP-based ACL rules to managing identities and communication policies.

Consul service intentions allow you to manage which services communicate with each other. For example, you can write an intention that blocks traffic for a specific infrastructure component or service:

Kind = "service-intentions"
Name = "backend"
Sources = [
  {
    Name = "frontend"
    Action = "deny"
  }
]

Secure north-south traffic with Consul gateways

A service mesh provides zero-trust security for all services inside the mesh and simplifies security management with identity based permissions (intentions).

The Consul service mesh uses mTLS across all services in the mesh to both identify and encrypt traffic.

For north-south traffic scenarios where you cannot use mTLS, for example when having external services that require to access services in your mesh, Consul gateways help you manage ingress and egress traffic for your mesh.

API gateways enable external network clients to access applications and services running in a Consul service mesh. Consul API gateways can also forward requests from clients to specific destinations based on path or request protocol.
Terminating gateways enable connectivity within your organizational network from services in the Consul service mesh to services and destinations outside the mesh. They terminate service mesh mTLS connections, enforce intentions, and forward requests to the appropriate destination.

Secure network access with Boundary

HashiCorp Boundary allows you to limit network ingress by providing secure, identity-based access to infrastructure without opening network ports or managing VPN connections. Boundary verifies user identity and grants just-in-time access to specific resources based on their authenticated identity and assigned permissions. Boundary provides:

Credential-less access that removes the need to distribute SSH keys or manage VPN certificates.
Just-in-time network access that creates temporary, session-based connections rather than permanent network paths.
Multi-hop architecture that allows secure access to private networks without exposing internal network topology.
Session recording and monitoring that provides complete audit trails without network packet inspection.
Integration with identity providers that tie network access decisions to your existing user directory.

Deploy firewall rules with Terraform

For infrastructure not well integrated with a service mesh, you can use HashiCorp Terraform to manage network policies. Terraform enables you to manage network ingress and egress rules as code, ensuring consistent security configurations across all environments, making your network policies auditable and version-controlled. Managing network policies with Terraform provides:

Standardizing security group configurations across multiple cloud providers and environments.
Implementing least-privilege network policies through code review and approval processes.
Automating security group updates based on application deployment patterns.
Providing drift detection to identify when network configurations have been manually modified.
Enabling policy-as-code where network security rules are tested and versioned like application code.

The following example Terraform configuration creates an AWS security group with no defined network egress. Using Terraform to create the security group removes the default egress rule that normally allows all outbound traffic.

# By omitting egress rules, this security group blocks all outbound traffic
# (removes AWS default "allow all" egress rule)

resource "aws_security_group" "no_egress_sg" {
  name        = "no-egress-security-group"
  description = "Security group that blocks all outbound traffic"
  vpc_id      = aws_vpc.main.id

  # Ingress rules
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["192.168.1.0/24"] # Allow SSH from specific CIDR
    description = "Allow SSH inbound"
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/24"] # Allow HTTP from specific CIDR
    description = "Allow HTTP inbound"
  }

  tags = {
    Name = "no-egress-security-group"
    }
}

HashiCorp resources:

External resources:

What is a service mesh

Next steps

In this section of how to Secure infrastructure, you learned why it is important to secure network ingress and egress traffic. Unmanaged traffic creates risks for your company's security programs, leading to leaked secrets, or unauthorized access to data. Secure network traffic with ingress and egress is part of the Secure systems pillar.

Following these documents in order ensures a logical progression through the key concepts and best practices, helping you build a strong foundation for your organization's security program.