Security Best Practices

​

Access Control

​

Domain Restriction

1. Set during initial setup - Don’t deploy without domain restriction
2. Use your corporate domain - Typically your Google Workspace domain
3. Verify enforcement - Test with non-allowed domain before going live
4. Document exceptions - If allowing multiple domains, maintain a list of approved domains

# Good - restricts to company domain
NETBIRD_ALLOWED_DOMAIN=acmecorp.com

# Bad - no restriction
NETBIRD_ALLOWED_DOMAIN=

​

Admin Account Management

1. Use a group email if multiple administrators are needed
2. Rotate admin access when personnel changes occur
3. Document who has admin access and review regularly
4. Use personal accounts rather than shared credentials
5. Enable MFA on admin Google accounts

# Good - specific admin account
[email protected]

# Bad - generic or shared account
[email protected]

​

User Permissions

• Regular users can only modify their own resources
• Admins should use regular accounts for day-to-day work
• Review user list regularly and remove departed employees
• Use the activity log to audit user actions

​

API Token Management

​

NetBird API Token Security

​

Token Rotation Procedure

1. Generate new token in NetBird dashboard
2. Update .env file on production server
3. Restart application to load new token
4. Verify functionality with test resource creation
5. Revoke old token in NetBird dashboard
6. Document rotation in change log

​

Secrets Management

• AWS Secrets Manager
• HashiCorp Vault
• Azure Key Vault
• Google Secret Manager

# Example: Fetch from AWS Secrets Manager
NETBIRD_API_TOKEN=$(aws secretsmanager get-secret-value \
  --secret-id netbird/api-token \
  --query SecretString \
  --output text)

​

Resource Address Security

​

Understanding Blocked Ranges

​

Resource Naming Best Practices

Customer ABC - Production Database
Client XYZ - Staging Environment
Partner DEF - API Endpoint

• Include customer/client name for easy identification
• Specify environment (prod, staging, dev) if applicable
• Use consistent naming convention across organization
• Avoid sensitive information in names (e.g., “Bank XYZ - Critical”)
• Keep descriptions detailed but professional

[Customer Name] - [Environment] [Resource Type]

Examples:
Acme Corp - Production Web Server
Globex Inc - Staging API
Initech LLC - Database Cluster

​

Activity Log Monitoring

​

Regular Audit Schedule

• Review approvals and denials
• Check for unusual deletion patterns
• Verify admin actions

• Review all resource changes
• Verify user access patterns
• Check for unauthorized modifications

• Audit user list against employee roster
• Review blocked address attempts
• Analyze resource growth trends

​

Suspicious Activity Indicators

​

Log Retention

• Minimum: 90 days for compliance
• Recommended: 1 year for trend analysis
• High-security: 3-7 years

-- Archive old logs before deletion
CREATE TABLE resource_logs_archive AS 
SELECT * FROM resource_logs 
WHERE created_at < DATE_SUB(NOW(), INTERVAL 1 YEAR);

-- Delete archived logs from main table
DELETE FROM resource_logs 
WHERE created_at < DATE_SUB(NOW(), INTERVAL 1 YEAR);

​

Network Security

​

HTTPS Requirements

• Obtain valid SSL/TLS certificate (Let’s Encrypt, commercial CA, or internal CA)
• Configure web server for HTTPS
• Set APP_URL=https://your-domain.com
• Set SESSION_SECURE_COOKIE=true
• Redirect HTTP to HTTPS at web server level
• Enable HSTS header
• Test with SSL Labs (https://www.ssllabs.com/ssltest/)

server {
    listen 443 ssl http2;
    server_name vpn.example.com;

    ssl_certificate /etc/ssl/certs/vpn.example.com.crt;
    ssl_certificate_key /etc/ssl/private/vpn.example.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # HSTS
    add_header Strict-Transport-Security "max-age=31536000" always;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name vpn.example.com;
    return 301 https://$server_name$request_uri;
}

​

Firewall Configuration

# Allow HTTPS from anywhere
sudo ufw allow 443/tcp

# Allow SSH only from corporate network
sudo ufw allow from 203.0.113.0/24 to any port 22

# Allow database only from localhost
sudo ufw deny 3306/tcp
sudo ufw allow from 127.0.0.1 to any port 3306

# Enable firewall
sudo ufw enable

• Only expose HTTPS (port 443) to the internet
• Restrict SSH access to known IP ranges
• Never expose database directly to the internet
• Use VPN or jump host for administrative access
• Keep firewall rules minimal and well-documented

​

Backup & Disaster Recovery

​

What to Back Up

​

Backup Schedule

• Frequency: Daily (minimum), hourly (recommended)
• Retention: 30 daily, 12 weekly, 12 monthly
• Location: Off-site, encrypted

• Frequency: After any change
• Retention: Version controlled
• Location: Secure secrets management system

​

Automated Database Backup

#!/bin/bash
# /usr/local/bin/backup-netbird-db.sh

set -e

BACKUP_DIR="/var/backups/netbird"
DATE=$(date +%Y%m%d_%H%M%S)
FILENAME="netbird_${DATE}.sql.gz"

# Create backup
mysqldump -u netbird_user -p${DB_PASSWORD} netbird_production | gzip > ${BACKUP_DIR}/${FILENAME}

# Encrypt backup
gpg --encrypt --recipient [email protected] ${BACKUP_DIR}/${FILENAME}
rm ${BACKUP_DIR}/${FILENAME}

# Upload to S3 (or other offsite storage)
aws s3 cp ${BACKUP_DIR}/${FILENAME}.gpg s3://company-backups/netbird/

# Cleanup old backups (keep 30 days)
find ${BACKUP_DIR} -name "netbird_*.sql.gz.gpg" -mtime +30 -delete

echo "Backup completed: ${FILENAME}.gpg"

# Daily at 2 AM
0 2 * * * /usr/local/bin/backup-netbird-db.sh

​

Disaster Recovery Procedure

1. Provision new server with same OS version
2. Install dependencies (PHP, MySQL, etc.)
3. Clone application from version control
4. Restore .env file from secure backup
5. Restore database from latest backup
6. Restore SSL certificates
7. Run migrations if needed: php artisan migrate
8. Test application functionality
9. Update DNS if IP changed
10. Verify OAuth callbacks still work

​

Operational Security

​

Security Audit Schedule

• Review access logs
• Audit user accounts
• Check for outdated dependencies: composer outdated
• Review security advisories
• Test backup restoration

• Rotate API tokens
• Rotate SSL certificates (if not automated)
• Review and update security policies
• Conduct penetration testing
• Update disaster recovery documentation

​

Dependency Management

# Check for security vulnerabilities
composer audit

# Update dependencies
composer update

# Update Laravel framework
php artisan about

# Check PHP version support
php -v

• Laravel Security Announcements
• PHP Security Advisories
• NetBird Status Updates
• GitHub Security Alerts (if using GitHub for code hosting)

​

Incident Response

1. Contain
   • Take application offline if necessary
   • Revoke compromised API tokens immediately
   • Lock compromised user accounts
2. Investigate
   • Review activity logs for unauthorized access
   • Check system logs for intrusion attempts
   • Identify scope of compromise
3. Remediate
   • Patch vulnerabilities
   • Rotate all credentials
   • Reset user sessions: php artisan session:flush
   • Restore from backup if needed
4. Document
   • Record timeline of events
   • Document actions taken
   • Identify root cause
   • Create post-mortem report
5. Prevent
   • Implement additional controls
   • Update security procedures
   • Conduct team training
   • Monitor for similar attacks

​

Compliance Considerations

​

Data Privacy

• User names (from Google OAuth)
• Email addresses
• User avatars
• IP addresses (in logs)
• Activity timestamps

• GDPR (if EU users)
• CCPA (if California users)
• SOC 2 (if enterprise customers)
• HIPAA (if healthcare data)

​

Data Subject Rights

-- Export user's data
SELECT * FROM users WHERE email = '[email protected]';
SELECT * FROM resources WHERE user_id = ?;
SELECT * FROM resource_logs WHERE performed_by = 'User Name';

-- Delete user's data (cascade should handle resources)
DELETE FROM users WHERE email = '[email protected]';

-- Or anonymize logs
UPDATE resource_logs 
SET performed_by = 'Deleted User', 
    email = '[email protected]' 
WHERE performed_by = 'User Name';

• Users can update their own resource descriptions
• Admins can correct data on behalf of users
• Activity logs are immutable by design

​

Next Steps