Network security is about controlling who can communicate with what, when, and how. Good security policies protect your applications while still allowing legitimate traffic to flow. Poor security policies either leave you vulnerable or break functionality in confusing ways.

Prerequisites

Understanding of IP addressing and ports from previous sections
Terminal access with sudo privileges for firewall configuration
Basic understanding of your application's communication patterns

Network Security Fundamentals

Every network connection has three key attributes you can control:

Source: Where is the traffic coming from?
Destination: Where is it trying to go?
Protocol/Port: What type of communication is it?

Let's see what connections currently exist on your system:

# Show all network connections
netstat -tuln

# Show connections with process information
sudo netstat -tulnp

This reveals what services are listening and what connections are active. Each line represents a potential security consideration.

Default Security Posture

Most systems start with relatively open networking. Let's check your current firewall status:

# Ubuntu/Debian firewall status
sudo ufw status

# CentOS/RHEL firewall status
sudo firewall-cmd --list-all

# Raw iptables rules (Linux)
sudo iptables -L

If you see "inactive" or minimal rules, your system is probably accepting all connections by default.

Firewall Types and Tools

Host-Based Firewalls

Host-based firewalls run on individual servers and control traffic to/from that specific machine.

UFW (Ubuntu/Debian):

# Enable the firewall
sudo ufw enable

# Allow SSH access (important - don't lock yourself out!)
sudo ufw allow ssh

# Allow specific ports
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Allow from specific IP addresses
sudo ufw allow from 192.168.1.100 to any port 22

firewalld (CentOS/RHEL):

# Check current zones and rules
sudo firewall-cmd --list-all

# Allow specific services
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

# Allow specific ports
sudo firewall-cmd --permanent --add-port=8080/tcp

# Reload configuration
sudo firewall-cmd --reload

Network-Based Firewalls

Network firewalls control traffic between network segments. Cloud providers offer these as security groups or network ACLs.

AWS Security Groups example:

# Allow HTTP traffic from anywhere
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

# Allow database access only from application servers
aws ec2 authorize-security-group-ingress \
  --group-id sg-database \
  --protocol tcp \
  --port 5432 \
  --source-group sg-application

Practical Firewall Configuration

Let's configure a typical web server firewall policy:

Web Server Setup

Start with a deny-all policy, then explicitly allow needed traffic:

# Reset firewall to defaults
sudo ufw --force reset

# Default policies: deny incoming, allow outgoing
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (adjust port if you use non-standard)
sudo ufw allow 22/tcp

# Allow web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable the firewall
sudo ufw enable

Test that your web server still works after enabling the firewall.

Database Server Security

Database servers need more restrictive policies:

# Allow database connections only from application servers
sudo ufw allow from 10.0.1.0/24 to any port 5432

# Allow SSH from management network only
sudo ufw allow from 10.0.100.0/24 to any port 22

# Deny everything else (default policy)
sudo ufw default deny incoming

Application Server Configuration

Application servers often need to make outbound connections:

# Allow inbound connections from load balancer
sudo ufw allow from 10.0.2.0/24 to any port 8080

# Outbound connections are allowed by default
# But you can restrict them if needed:
sudo ufw default deny outgoing
sudo ufw allow out 53      # DNS
sudo ufw allow out 80      # HTTP
sudo ufw allow out 443     # HTTPS
sudo ufw allow out 5432    # Database

Network Segmentation

Segmentation divides your network into zones with different security policies.

                           Internet
                              │
                              ▼
┌────────────────────────────────────────────────────────────┐
│                    DMZ (10.0.1.0/24)                       │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │Load Balancer│  │ Web Server  │  │ Web Server  │         │
│  │10.0.1.10    │  │10.0.1.20    │  │10.0.1.21    │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
└─────────────────────┬──────────────────────────────────────┘
                      │ Firewall Rules:
                      │ ✓ HTTP/HTTPS from Internet
                      │ ✓ Limited access to Internal
                      ▼
┌────────────────────────────────────────────────────────────┐
│                Internal Zone (10.0.2.0/24)                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │API Server   │  │App Server   │  │App Server   │         │
│  │10.0.2.10    │  │10.0.2.20    │  │10.0.2.21    │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
└─────────────────────┬──────────────────────────────────────┘
                      │ Firewall Rules:
                      │ ✓ Access from DMZ only
                      │ ✓ Specific ports to Secure Zone
                      ▼
┌───────────────────────────────────────────────────────────┐
│                 Secure Zone (10.0.3.0/24)                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
│  │Database     │  │File Server  │  │Backup       │        │
│  │10.0.3.10    │  │10.0.3.20    │  │10.0.3.30    │        │
│  └─────────────┘  └─────────────┘  └─────────────┘        │
│                                                           │
│  Firewall Rules:                                          │
│  ✓ Access from Internal Zone only                         │
│  ✓ Management access from Admin network                   │
│  ✗ No direct Internet access                              │
└───────────────────────────────────────────────────────────┘

Basic Network Zones

DMZ (Demilitarized Zone): Public-facing servers

# DMZ subnet: 10.0.1.0/24
# - Web servers
# - Load balancers
# - Reverse proxies
# Allow: Internet → DMZ (ports 80, 443)
# Allow: DMZ → Internal (specific ports only)

Internal Zone: Application servers

# Internal subnet: 10.0.2.0/24
# - Application servers
# - API services
# - Microservices
# Allow: DMZ → Internal (application ports)
# Deny: Internet → Internal

Secure Zone: Data and management

# Secure subnet: 10.0.3.0/24
# - Database servers
# - File servers
# - Management tools
# Allow: Internal → Secure (specific ports)
# Allow: Management → Secure (SSH, monitoring)
# Deny: DMZ → Secure, Internet → Secure

Implementing Segmentation

Use subnets and firewall rules to enforce segmentation:

# Allow web servers to reach app servers
sudo ufw allow from 10.0.1.0/24 to 10.0.2.0/24 port 8080

# Allow app servers to reach databases
sudo ufw allow from 10.0.2.0/24 to 10.0.3.0/24 port 5432

# Deny direct web-to-database connections
sudo ufw deny from 10.0.1.0/24 to 10.0.3.0/24

Container Security

Container environments need special security considerations.

Docker Network Security

By default, Docker containers can reach each other freely:

# Create isolated networks for different applications
docker network create --driver bridge app1-network
docker network create --driver bridge app2-network

# Run containers on isolated networks
docker run --network app1-network --name app1-web nginx
docker run --network app1-network --name app1-db postgres

docker run --network app2-network --name app2-web nginx
docker run --network app2-network --name app2-db postgres

Containers on different networks cannot communicate unless explicitly connected.

Kubernetes Network Policies

Kubernetes allows fine-grained network policies:

# NetworkPolicy: Allow only specific pod-to-pod communication
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 8080

Apply these policies:

# Apply network policies
kubectl apply -f network-policies.yaml

# Verify policies are active
kubectl get networkpolicies -n production

Service-to-Service Authentication

Network security alone isn't enough. Services should authenticate each other.

API Keys and Tokens

Services can authenticate using API keys:

# Service A calls Service B with authentication
curl -H "Authorization: Bearer $API_TOKEN" \
  http://service-b.internal.com/api/data

Mutual TLS (mTLS)

For highly secure environments, use mutual TLS where both client and server authenticate:

# Client provides certificate to server
curl --cert client.pem --key client-key.pem \
  --cacert ca.pem \
  https://secure-service.internal.com/api

Service Meshes

Service mesh tools like Istio provide automatic mTLS:

# Istio: Require mTLS for all service communication
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: require-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT

Monitoring and Logging

Security policies are only effective if you monitor them.

Connection Monitoring

Monitor active connections for unusual patterns:

# Watch active connections in real-time
watch 'netstat -tuln | grep ESTABLISHED'

# Log connection attempts
sudo ufw logging on
tail -f /var/log/ufw.log

Failed Connection Attempts

Failed connections often indicate attacks or misconfigurations:

# Check for blocked connections in UFW logs
sudo grep "BLOCK" /var/log/ufw.log

# Look for patterns in failed attempts
sudo grep "DPT=22" /var/log/ufw.log | grep "BLOCK"

Application-Level Monitoring

Monitor your applications for authentication failures:

# Web server access logs
tail -f /var/log/nginx/access.log | grep "401\|403"

# Application logs
tail -f /var/log/app/auth.log | grep "FAILED"

Common Security Mistakes

Overly Permissive Rules

Avoid rules that allow too much access:

# Bad: Allow everything from internal network
sudo ufw allow from 10.0.0.0/8

# Better: Allow specific services from specific subnets
sudo ufw allow from 10.0.1.0/24 to any port 8080
sudo ufw allow from 10.0.2.0/24 to any port 5432

Forgetting Outbound Rules

Don't forget that compromised services can make outbound connections:

# Consider restricting outbound connections
sudo ufw default deny outgoing

# Then explicitly allow needed outbound traffic
sudo ufw allow out 53   # DNS
sudo ufw allow out 80   # HTTP
sudo ufw allow out 443  # HTTPS

Not Testing Changes

Always test firewall changes before applying them to production:

# Test firewall rules in a non-production environment first
# Use automation to apply consistent rules across environments

# Keep a rollback plan ready
sudo ufw disable  # Emergency rollback command

Advanced Security Patterns

Zero Trust Networking

Zero trust assumes no network location is inherently trustworthy:

# Every connection requires authentication
# Even "internal" services verify each request
# Network location grants no implicit access

Defense in Depth

Layer multiple security controls:

Network firewalls: Control traffic between segments
Host firewalls: Control traffic to individual servers
Application authentication: Verify every request
Encryption: Protect data in transit
Monitoring: Detect unusual patterns

Rate Limiting

Protect against abuse with rate limiting:

# nginx rate limiting example
http {
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

    server {
        location /api/ {
            limit_req zone=api burst=20 nodelay;
            proxy_pass http://backend;
        }
    }
}

Cloud Security Groups

Cloud providers offer network security as a service:

AWS Security Groups

Security groups act as virtual firewalls:

# Create security group
aws ec2 create-security-group \
  --group-name web-servers \
  --description "Security group for web servers"

# Add rules
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 80 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

Network ACLs

Network ACLs provide subnet-level filtering:

# Network ACLs are stateless (must allow both inbound and outbound)
# Security groups are stateful (return traffic is automatically allowed)

Troubleshooting Security Issues

Connection Refused vs Connection Timeout

Different error messages indicate different problems:

# Connection refused: Service is reachable but not listening on port
telnet server.com 80
# Immediate "Connection refused" = firewall allows, service unavailable

# Connection timeout: Firewall blocking or network unreachable
telnet server.com 80
# Hangs then times out = firewall blocking or routing problem

Testing Firewall Rules

Verify rules work as expected:

# Test from allowed source
ssh user@allowed-ip "curl -I http://your-server"

# Test from blocked source
ssh user@blocked-ip "curl -I http://your-server"

# Check firewall logs for blocked attempts
sudo tail -f /var/log/ufw.log

In the next section, we'll explore load balancing and high availability - distributing traffic across multiple servers while maintaining security boundaries.

Network security is about finding the right balance between protection and functionality. Start with restrictive policies and explicitly allow only the traffic your applications need.

Happy securing!

Tags