fix: Prevent sensitive information from being logged

[dguido]

Summary

This PR implements comprehensive privacy and security enhancements for Algo VPN, addressing sensitive data exposure in logs (#1617) while maintaining operational visibility for troubleshooting.

Key Improvements

1. Credential Protection with no_log

Added no_log: true to 50+ Ansible tasks across all cloud providers and VPN components to prevent sensitive data from being logged:

• Cloud API credentials (AWS, Azure, GCP, DigitalOcean, etc.)
• VPN private keys and certificates
• User passwords and authentication tokens
• SSH keys and configuration data

2. Privacy Enhancements Role

New roles/privacy/ implements configurable privacy features:

• Log rotation: Automatic 7-day retention with compression
• VPN log filtering: Hides connection patterns while preserving errors
• History clearing: Removes deployment traces
• Automatic cleanup: Scheduled temporary file removal

3. Simplified Configuration

Streamlined config.cfg from 308 to 198 lines (35% reduction):

### Privacy Settings ###
# StrongSwan connection logging (-1 = disabled, 2 = debug)
strongswan_log_level: -1

# Master switch for privacy enhancements
privacy_enhancements_enabled: true

# Hide sensitive data in Ansible output (passwords, keys, etc.)
algo_no_log: true

4. Documentation Improvements

• Restructured FAQ to be more concise with link to detailed information
• Added comprehensive "Privacy and Logging" section to README
• Added privacy features to the main features list
• Clear distinction between deployment privacy (algo_no_log) and server privacy

What Gets Protected

Hidden from logs:

• VPN connection handshakes and user IP addresses
• DNS queries (when privacy enhanced)
• API credentials and authentication tokens
• Private keys and certificates

Preserved for debugging:

• Failed authentication attempts (security monitoring)
• Service errors and warnings
• System security events
• Network interface issues

Configuration Options

Default (Balanced):

privacy_enhancements_enabled: true  # Privacy features on
strongswan_log_level: -1            # Connection logging off
algo_no_log: true                   # Credential protection on

Debug Mode:

privacy_enhancements_enabled: false # Full logging
strongswan_log_level: 2             # Debug verbosity
algo_no_log: false                  # Show all output

Testing

All tests pass:

• ✅ 59 unit tests passing
• ✅ Ansible-lint compliant
• ✅ All linters passing (yamllint, ruff, shellcheck)
• ✅ Successfully deployed on Ubuntu 22.04

Compatibility

• No breaking changes for existing deployments
• Old config.cfg files work unchanged
• Can disable all privacy features if needed
• Ubuntu 22.04 iptables compatibility fixed

---

This implementation balances privacy with operational needs, ensuring sensitive data is protected while maintaining the debugging capabilities essential for a reliable VPN service.

Fixes #1617

[dguido]

I'm not fully happy with the documentation for this PR yet. Will fix soon.

[claude]

Claude finished @dguido's task —— View job

---

Code Review Analysis

I've completed a comprehensive review of this privacy implementation PR. Here's my detailed feedback:

🟢 Strengths & Positive Aspects

1. Comprehensive Credential Protection

• Excellent coverage: 49 tasks now properly protected with no_log: true across all cloud providers
• Consistent implementation: All sensitive operations (API keys, passwords, certificates) are protected
• Follows Ansible best practices: Uses conditional algo_no_log | default(true) pattern

2. Well-Designed Privacy Architecture

• Surgical approach: Filters user activity logs while preserving security/debugging capabilities
• Modular design: Privacy role is cleanly separated with clear responsibilities
• Granular control: Individual toggles for different privacy features

3. Security-Conscious Implementation

• Preserves critical logs: Failed connections, errors, and security events still logged
• Proper defaults: Conservative settings that balance privacy with operational needs
• Certificate protection: VPN keys and credentials properly secured

4. Strong Configuration Management

• Backward compatibility: Existing deployments continue to work unchanged
• Clear documentation: Comprehensive README with usage examples and security considerations
• Flexible options: Users can disable privacy features when debugging needed

⚠️ Areas of Concern

1. Log Filtering Regex Security

File: roles/privacy/templates/49-privacy-vpn-filter.conf.j2:23-24

:msg, regex, "IN=wg[0-9]+" stop
:msg, regex, "OUT=wg[0-9]+" stop

Issues:

• Unanchored regex patterns are vulnerable to bypass attacks
• Missing start/end anchors (^ and $)
• Should use more specific patterns to prevent false matches

Recommendation:

:msg, regex, "^[^:]*: IN=wg[0-9]+" stop
:msg, regex, "^[^:]*: OUT=wg[0-9]+" stop

2. Overly Broad Filtering

File: roles/privacy/templates/49-privacy-vpn-filter.conf.j2:29

:msg, contains, "netfilter" stop

Issue: This could filter legitimate security events and firewall logs that contain "netfilter"

Recommendation: Use more specific patterns targeting only VPN-related netfilter messages

3. Missing IPv6 Support

The current regex patterns don't account for IPv6 addresses in log filtering, which could lead to privacy leaks for IPv6 VPN traffic.

Recommendation: Add IPv6-specific patterns:

:msg, regex, "^[^:]*: IN=wg[0-9]+ .* SRC=[0-9a-fA-F:]+::" stop

4. Test Coverage Gap

Missing: No specific tests found for the privacy role functionality
Risk: Changes could break privacy filtering without detection

Recommendation: Add unit tests for:

• Log filtering regex patterns
• Configuration validation
• Template rendering with different privacy settings

📊 Configuration Assessment

Strong Points:

• Sensible default: strongswan_log_level: -1 (disabled logging)
• Conditional privacy role execution: when: privacy_enhancements_enabled | default(true)
• Clear separation of privacy vs. debugging modes

Concerns:

File: config.cfg:49

strongswan_log_level: -1

Issue: The PR description mentions level 1 (alerts) as the implementation, but config shows -1 (disabled). This inconsistency could lead to either broken debugging or unintended logging.

🚀 Performance Considerations

Positive:

• Log filtering at rsyslog level is efficient
• Reduced disk I/O from smaller log files
• Faster log searches due to reduced volume

Potential Concerns:

• Regex processing overhead for every log message
• Additional rsyslog configuration files to process

🔒 Security Analysis

Excellent Security Practices:

1. Defense in Depth: Multiple layers of credential protection
2. Principle of Least Privilege: Only filters user activity, not security events
3. Secure Defaults: Privacy enabled by default but debuggable when needed
4. Certificate Security: All VPN key operations properly protected

Security Recommendations:

1. Regex Hardening: Anchor all regex patterns to prevent bypass
2. Pattern Specificity: Use more targeted filtering to avoid blocking security logs
3. IPv6 Coverage: Add IPv6-aware filtering patterns
4. Test Validation: Add security tests to prevent regression

📝 Code Quality

Positive:

• Clean Ansible role structure
• Well-documented templates with clear comments
• Consistent variable naming
• Proper file permissions and ownership

Areas for Improvement:

• Some complex Jinja2 expressions could be simplified
• Consider extracting complex regex patterns to variables for maintainability

🏆 Overall Assessment

This is a solid, security-conscious implementation that successfully addresses the core privacy concerns while maintaining operational capabilities. The surgical approach to privacy filtering is well-designed and the comprehensive credential protection is excellent.

Key Strengths:

• ✅ Comprehensive credential protection across all components
• ✅ Thoughtful balance between privacy and debugging capabilities
• ✅ Backward compatibility and clear configuration options
• ✅ Security-first approach that preserves critical monitoring

Must-Fix Issues:

• ❌ Regex security vulnerabilities (unanchored patterns)
• ❌ Missing IPv6 support in log filtering
• ❌ Configuration inconsistency (strongswan log level)

Recommended Improvements:

• ⚠️ Add comprehensive test coverage for privacy functionality
• ⚠️ More specific netfilter filtering patterns
• ⚠️ Consider extracting complex regex to variables

Verdict: Approve with Required Changes - The implementation is fundamentally sound but needs the regex security issues fixed before merge.

---