Security: Implement network namespace isolation for VPN services

[dguido]

Summary

Algo VPN services (WireGuard, StrongSwan, dnscrypt-proxy) currently share the same network namespace, allowing compromised services to interfere with each other. Implementing network namespace isolation would provide defense-in-depth by creating separate network stacks for each service.

Problem

Current State

• All VPN services run in the default network namespace
• WireGuard, StrongSwan, and DNS services can see and interact with each other's network interfaces
• If one service is compromised, it can:
  • Snoop on traffic from other VPN protocols
  • Interfere with routing tables and network configuration
  • Perform cross-service attacks
  • Access network interfaces it doesn't need

Attack Scenarios

1. Cross-service interference: Compromised StrongSwan could modify WireGuard routing
2. Traffic interception: Malicious code in one service could capture packets destined for another
3. Network stack manipulation: Compromised service could affect global network configuration
4. Resource exhaustion: One service could exhaust network resources affecting others

Proposed Solution

Create isolated network namespaces for each VPN service, providing separate network stacks while maintaining functionality.

Implementation Overview

# Create dedicated network namespaces
ip netns add strongswan-ns
ip netns add wireguard-ns  
ip netns add dns-ns

# Each service runs in its own network environment
# with only the interfaces and routes it needs

Service-Specific Network Isolation

StrongSwan Namespace

# Create isolated namespace for IPsec
ip netns add strongswan-ns

# Add only necessary interfaces to namespace
ip link set dev eth0 netns strongswan-ns  # Main interface
ip netns exec strongswan-ns ip addr add <server-ip>/24 dev eth0
ip netns exec strongswan-ns ip route add default via <gateway>

# Run StrongSwan in isolated namespace
ip netns exec strongswan-ns systemctl start strongswan

WireGuard Namespace

# Create isolated namespace for WireGuard
ip netns add wireguard-ns

# WireGuard creates its own interface, but isolate from other services
ip netns exec wireguard-ns wg-quick up wg0

DNS Service Namespace

# Create isolated namespace for DNS
ip netns add dns-ns

# Only provide loopback and necessary interfaces
ip netns exec dns-ns systemctl start dnscrypt-proxy

Service Communication

Services would communicate through:

• Shared routing tables (where needed)
• Unix domain sockets (for local communication)
• Specific interface bridges (only where required)

Configuration Management

• Ansible integration: Automate namespace creation and service binding
• Systemd integration: Services start in correct namespaces automatically
• Monitoring: Health checks work across namespace boundaries

Benefits

Security Improvements

• Blast radius reduction: Compromised service cannot affect others' network stack
• Traffic isolation: Services cannot intercept each other's network traffic
• Interface restriction: Each service only sees interfaces it actually needs
• Routing isolation: Services cannot manipulate global routing tables

Operational Benefits

• Clear service boundaries: Network configuration is explicitly scoped per service
• Debugging isolation: Network issues in one service don't affect others
• Resource accounting: Network usage can be tracked per service
• Configuration safety: Network changes are contained to specific services

Implementation Considerations

Complexity

• Medium complexity: Requires careful interface and routing management
• Testing overhead: Need to verify connectivity across namespace boundaries
• Debugging: Network troubleshooting becomes more complex

Compatibility

• Client impact: None - clients connect normally to external interfaces
• Monitoring: May need updates to work across namespaces
• Logging: Network logs may need namespace context

Alternative Approach

Consider starting with systemd network restrictions (RestrictAddressFamilies, PrivateNetwork) before full namespace isolation.

Implementation Plan

Phase 1: Research and Testing

1. Create proof-of-concept with namespace isolation
2. Test VPN functionality in isolated namespaces
3. Verify client connectivity and performance impact
4. Document namespace communication requirements

Phase 2: DNS Service Isolation (Lowest Risk)

1. Isolate dnscrypt-proxy in separate namespace
2. Maintain connectivity to VPN clients through specific interfaces
3. Test and validate DNS resolution functionality

Phase 3: VPN Protocol Isolation

1. Isolate StrongSwan in dedicated namespace
2. Isolate WireGuard in dedicated namespace
3. Ensure proper routing between services where needed
4. Comprehensive testing of all VPN functionality

Phase 4: Integration and Documentation

1. Integrate namespace creation into Ansible playbooks
2. Update systemd service files for namespace execution
3. Add monitoring and troubleshooting documentation
4. Create rollback procedures

Security Impact

• High security benefit: Significantly reduces attack surface between services
• Defense in depth: Adds network-level isolation to existing security measures
• Minimal user impact: Transparent to VPN clients
• Operational complexity: Increases system administration complexity

Related Issues

This complements other security hardening efforts:

• systemd security hardening (separate issue)
• AppArmor profile improvements
• Service capability restrictions

References

• Linux Network Namespaces
• systemd PrivateNetwork
• Network Namespace Security