fix: Gitea Traefik routing and connection pool optimization
Some checks failed
🚀 Build & Deploy Image / Determine Build Necessity (push) Failing after 10m14s
🚀 Build & Deploy Image / Build Runtime Base Image (push) Has been skipped
🚀 Build & Deploy Image / Build Docker Image (push) Has been skipped
🚀 Build & Deploy Image / Run Tests & Quality Checks (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Staging (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Production (push) Has been skipped
Security Vulnerability Scan / Check for Dependency Changes (push) Failing after 11m25s
Security Vulnerability Scan / Composer Security Audit (push) Has been cancelled
Some checks failed
🚀 Build & Deploy Image / Determine Build Necessity (push) Failing after 10m14s
🚀 Build & Deploy Image / Build Runtime Base Image (push) Has been skipped
🚀 Build & Deploy Image / Build Docker Image (push) Has been skipped
🚀 Build & Deploy Image / Run Tests & Quality Checks (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Staging (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Production (push) Has been skipped
Security Vulnerability Scan / Check for Dependency Changes (push) Failing after 11m25s
Security Vulnerability Scan / Composer Security Audit (push) Has been cancelled
- Remove middleware reference from Gitea Traefik labels (caused routing issues) - Optimize Gitea connection pool settings (MAX_IDLE_CONNS=30, authentication_timeout=180s) - Add explicit service reference in Traefik labels - Fix intermittent 504 timeouts by improving PostgreSQL connection handling Fixes Gitea unreachability via git.michaelschiemer.de
This commit is contained in:
143
deployment/docs/guides/security-hardening.md
Normal file
143
deployment/docs/guides/security-hardening.md
Normal file
@@ -0,0 +1,143 @@
|
||||
# Security Hardening - Dokumentation
|
||||
|
||||
## Aktuelle Security-Maßnahmen
|
||||
|
||||
### 1. Firewall (nftables)
|
||||
- **Status**: ✅ Implementiert
|
||||
- **Konfiguration**: `deployment/ansible/templates/wireguard-host-firewall.nft.j2`
|
||||
- **Features**:
|
||||
- Admin-Services nur über VPN erreichbar
|
||||
- Public Services (HTTP, HTTPS, SSH) öffentlich erreichbar
|
||||
- ICMP (Ping) erlaubt
|
||||
- Established/Related Connections erlaubt
|
||||
|
||||
### 2. WireGuard VPN
|
||||
- **Status**: ✅ Implementiert
|
||||
- **Zweck**: Admin-Services isoliert hinter VPN
|
||||
- **Ports**: 8080 (Traefik), 9090 (Prometheus), 3001 (Grafana), 9000 (Portainer), 8001 (Redis Insight)
|
||||
- **Konfiguration**: `deployment/ansible/playbooks/setup-wireguard-host.yml`
|
||||
|
||||
### 3. Unattended-Upgrades
|
||||
- **Status**: ✅ Implementiert
|
||||
- **Konfiguration**: `deployment/ansible/roles/system/tasks/main.yml`
|
||||
- **Features**:
|
||||
- Automatische Security-Updates
|
||||
- Konfigurierbare Reboot-Zeiten
|
||||
- APT Cache Management
|
||||
|
||||
### 4. Security Headers (Traefik)
|
||||
- **Status**: ✅ Implementiert
|
||||
- **Konfiguration**: Traefik Dynamic Config
|
||||
- **Headers**: HSTS, X-Frame-Options, X-Content-Type-Options, etc.
|
||||
|
||||
### 5. Docker Secrets
|
||||
- **Status**: ✅ Implementiert
|
||||
- **Verwendung**: Secrets werden über Docker Secrets verwaltet
|
||||
- **Zugriff**: Secrets werden für PHP (www-data) zugänglich gemacht
|
||||
|
||||
## Geplante Verbesserungen
|
||||
|
||||
### 1. SSH Hardening
|
||||
**Status**: ⚠️ Noch nicht implementiert
|
||||
|
||||
**Geplante Maßnahmen**:
|
||||
- Key-only Authentication (keine Passwort-Authentifizierung)
|
||||
- Rate Limiting für SSH
|
||||
- Disable Root-Login
|
||||
- SSH-Keys Rotation Policy
|
||||
|
||||
**Implementierung**:
|
||||
```yaml
|
||||
# deployment/ansible/roles/ssh/tasks/main.yml
|
||||
- name: Configure SSH hardening
|
||||
lineinfile:
|
||||
path: /etc/ssh/sshd_config
|
||||
regexp: "{{ item.regexp }}"
|
||||
line: "{{ item.line }}"
|
||||
loop:
|
||||
- { regexp: '^#?PasswordAuthentication', line: 'PasswordAuthentication no' }
|
||||
- { regexp: '^#?PermitRootLogin', line: 'PermitRootLogin no' }
|
||||
- { regexp: '^#?MaxAuthTries', line: 'MaxAuthTries 3' }
|
||||
```
|
||||
|
||||
### 2. Container Security Scanning
|
||||
**Status**: ❌ Nicht implementiert
|
||||
|
||||
**Geplante Tools**:
|
||||
- Trivy für Container-Scanning
|
||||
- Integration in CI/CD Pipeline
|
||||
- Automatische Scans vor Deployment
|
||||
|
||||
### 3. Secrets Rotation Policy
|
||||
**Status**: ⚠️ Manuell
|
||||
|
||||
**Geplante Maßnahmen**:
|
||||
- Automatische Secrets-Rotation
|
||||
- Secrets-Versioning
|
||||
- Secrets-Audit-Logging
|
||||
|
||||
### 4. DDoS Protection
|
||||
**Status**: ⚠️ Teilweise (Traefik Rate Limiting)
|
||||
|
||||
**Geplante Maßnahmen**:
|
||||
- Erweiterte Rate Limiting Rules
|
||||
- IP-based Rate Limiting
|
||||
- Geo-blocking für Admin-Endpoints
|
||||
|
||||
### 5. Network Isolation Verification
|
||||
**Status**: ✅ Basis vorhanden
|
||||
|
||||
**Aktuell**:
|
||||
- `traefik-public` und `app-internal` Networks
|
||||
- WireGuard für Admin Services
|
||||
|
||||
**Zu prüfen**:
|
||||
- Database Network Isolation
|
||||
- Redis Network Isolation
|
||||
- Service-to-Service Communication Audit
|
||||
|
||||
## Security Checklist
|
||||
|
||||
### Vor Production-Deployment
|
||||
|
||||
- [ ] Firewall Rules Audit durchgeführt
|
||||
- [ ] SSH Hardening konfiguriert
|
||||
- [ ] Container Security Scanning aktiviert
|
||||
- [ ] Secrets Rotation Policy definiert
|
||||
- [ ] DDoS Protection konfiguriert
|
||||
- [ ] Network Isolation verifiziert
|
||||
- [ ] Security Headers verifiziert
|
||||
- [ ] SSL/TLS Configuration geprüft
|
||||
|
||||
### Regelmäßige Audits
|
||||
|
||||
- [ ] Monatliche Security-Updates
|
||||
- [ ] Quartalsweise Firewall Rules Review
|
||||
- [ ] Jährliche Secrets Rotation
|
||||
- [ ] Kontinuierliche Container Scanning
|
||||
|
||||
## Security Best Practices
|
||||
|
||||
1. **Principle of Least Privilege**: Services haben nur die minimal notwendigen Berechtigungen
|
||||
2. **Defense in Depth**: Mehrere Security-Layer (Firewall, VPN, Application-Level)
|
||||
3. **Regular Updates**: Automatische Security-Updates aktiviert
|
||||
4. **Secrets Management**: Secrets werden sicher verwaltet (Docker Secrets, Ansible Vault)
|
||||
5. **Network Segmentation**: Admin-Services isoliert hinter VPN
|
||||
6. **Monitoring**: Security-Events werden geloggt und überwacht
|
||||
|
||||
## Incident Response
|
||||
|
||||
Bei Security-Incidents:
|
||||
|
||||
1. **Isolation**: Betroffene Services isolieren
|
||||
2. **Investigation**: Logs analysieren
|
||||
3. **Remediation**: Sicherheitslücken schließen
|
||||
4. **Documentation**: Incident dokumentieren
|
||||
5. **Prevention**: Maßnahmen zur Verhinderung zukünftiger Incidents
|
||||
|
||||
## Kontakt
|
||||
|
||||
Bei Security-Fragen oder Incidents:
|
||||
- **Email**: kontakt@michaelschiemer.de
|
||||
- **Documentation**: `deployment/docs/guides/security-hardening.md`
|
||||
|
||||
Reference in New Issue
Block a user