Firewall und Traffic-Filterung

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Die Firewall ist keine einzelne Box am Perimeter, sondern ein Schichtfiltermodell von L3-L4 bis L7: Cloud Security Groups/NACL, Netzwerkrichtlinien in Kubernetes, Egress Control (Output), WAF und Bot Management am Edge und mTLS/Source-Wahrheiten für Service-to-Service. Für iGaming ist der Schlüssel der Schutz von Zahlungsströmen und Spieleanbietern, Geo-Richtlinien, DNS-Kontrolle und Beobachtbarkeit (wer, wo, wann und warum).

1) Ziele und Grundsätze

Default deny: standardmäßig verboten, erlauben wir das minimal Notwendige.
Defense-in-depth: Die gleichen Richtlinien auf dem Perimeter, in der Cloud, im Cluster und in der Anwendung.
Egress-first: Output-Traffic ist ebenso ein Risiko wie Input (PSP, Spieleanbieter, Mail, Analytics).
Identität> Adresse: Wo möglich, autorisieren wir durch Identität (mTLS/Spiffe) anstelle von nackten IPs.
Beobachtbarkeit und Audit: Entscheidungsprotokolle (allow/deny), Traces, Korrelation mit Vorfällen.

2) Filtrationsschichtkarte

1. Edge: CDN/WAF/DDoS/Bot-Schutz, L7-Regeln, TLS-Terminierung.
2. Cloud: Sicherheitsgruppen/NACL/Firewall-Regeln auf VPC/Subnet/VM-Ebene.
3. Cluster: Kubernetes NetworkPolicy, Service Mesh (Envoy/Istio) mit mTLS und L7-Filtern.
4. Gastgeber: iptables/nftables/ufw, Agentur eBPF Filter.
5. Anhang: rate-limit/idempotency/WAF in-app, Domainlisten für egress.
6. DNS: split-horizon, allowlist resolvers, Block von Risikodomänen/-typen.

3) Perimeter: WAF, DDoS und Bot-Management

WAF: Basissignaturen + benutzerdefinierte Regeln unter APIs (JSON-Schemas, Methoden/Inhaltstyp).
Bots: Behavioral Scoring, Device Fingerprint, Dynamic Captcha bei Anomalien.
DDoS: L3/4 (Volume/Synapse) und L7 (HTTP-Floods) - automatisches Verwerfen am Rand.
Geo/ASN: Begrenzung von Regionen/autonomen Systemen für Risikobereiche (z.B. Admin-Panel).

nginx
Разрешаем только JSON POST/GET на /api/
location /api/ {
limit_req zone=rl_api burst=50 nodelay;
if ($request_method!~ ^(GET    POST)$) { return 405; }
if ($http_content_type!~ "application/json") { return 415; }
proxy_pass http://api_upstream;
}
ModSecurity CRS + собственные правила modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/crs.conf;

4) Cloud: Sicherheitsgruppen und NACL

Security Group (stateful) - Filter nach Port/Protokoll/Segment.
NACL (stateless) - Grobe Netzfilterung von Subnetzen.

yaml security_group:
name: api-sg ingress:
- proto: tcp; port: 443; cidr: 0.0.0.0/0 # через CDN/WAF egress:
- proto: tcp; port: 443; cidr: 203.0.113.0/24  # PSP-X
- proto: tcp; port: 443; cidr: 198.51.100.0/24 # ProviderA
- proto: udp; port: 53; cidr: 10.10.0.10/32  # только наш DNS

Praxis: für Zahlungen halten separate SG und egress-allowlist auf bestimmte PSP diapozones/Spiel-Anbieter. Updates - durch IaC und Revue.

5) Kubernetes: NetworkPolicy und Service-Mesh

NetworkPolicy schränkt die L3/4 innerhalb des Clusters ein. Standardeinstellung „Jeder spricht mit jedem“ - Schließen.

yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: prod }
spec:
podSelector: {}
policyTypes: [Ingress, Egress]
ingress: []
egress: []
---
Разрешаем API разговаривать с платежным сервисом и DNS apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: api-allow-specific, namespace: prod }
spec:
podSelector: { matchLabels: { app: api } }
policyTypes: [Ingress, Egress]
egress:
- to:
- namespaceSelector: { matchLabels: { name: prod } }
podSelector: { matchLabels: { app: payments } }
ports: [{ protocol: TCP, port: 8080 }]
- to:
- ipBlock: { cidr: 10.10.0.10/32 }
ports: [{ protocol: UDP, port: 53 }]

• mTLS ist überall (Authentifizierung von Diensten durch Identität, nicht IP).
• L7-Filterung (Methoden/Hosts/Pfade/Header), Circuit-Breaker, Outlier-Ejection.
• Zugriffsrichtlinien nach Servicekonto/Spiffe-ID.

yaml apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: { name: api-to-payments, namespace: prod }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://prod/ns/prod/sa/api-sa"]
to:
- operation:
methods: ["POST"]
paths: ["/deposit","/withdraw"]

6) Host-Firewalls: iptables/nftables/eBPF

nft table inet filter {
sets {
psp { type ipv4_addr; elements = { 203.0.113.10, 203.0.113.11 } }
}
chains {
input { type filter hook input priority 0; policy drop;
ct state established,related accept iifname "lo" accept tcp dport {22,443} accept
}
output { type filter hook output priority 0; policy drop;
ct state established,related accept udp dport 53 ip daddr 10.10.0.10 accept  # только наш DNS tcp dport 443 ip daddr @psp accept    # egress к PSP
}
forward { type filter hook forward priority 0; policy drop; }
}
}

eBPF-Agenten (Cilium usw.) geben subtile L3-L7-Richtlinien und Sichtbarkeit (Flows, DNS, HTTP-Metadaten).

7) Egress-Kontrolle und Zielkataloge

Allowlist Domains/IP für externe Anrufe (PSP, Mail, KYC, Spieleanbieter).
DNS-Pinning/SNI-Richtlinien: Nur über vertrauenswürdigen Resolver löschen; Verbot von rohen IP-egress.
Getrennte VPC/VNet egress für Zahlung, Spiel und allgemeine Konturen.
Proxy mit TLS-Inspektion für Nicht-PII-Verkehr; Zahlungsströme - ohne MITM, nur direkte mTLS/PII-safe.

8) TLS/mTLS und Kryptopolitik

TLS 1. 2 +, moderne Chiffren, OCSP Stapeln, HSTS.
mTLS inside - Anbindung an Spiffe ID/Zertifizierung von Service-Accounts.
Regelmäßige Rotation von Zertifikaten und Überprüfung von Vertrauensketten.
CORS/CSP auf dem L7-Proxy, um die angreifenden Quellen an der Front zu schneiden.

9) Quote und L7-Quoten

Randlimits für IP/ASN/Präfixe; Anwendungsgrenzen - nach Identität (Konto/Tenant/Schlüssel).
Idempotency-keys für POST-Zahlungsvorgänge, damit Retrays keine Takes erzeugen.
Leaky/Token bucket mit jitter; beim Abbau - „graue Antworten „/Captcha/Verlangsamung.

10) DNS-Sicherheit

Nur Enterprise Resolver (VPC Resolver/gehobenes CoreDNS) sind erlaubt.
Split-Horizon: Interne Namen werden nicht nach außen ausgesprochen.
Block von schädlichen TLDs/Kategorien, DoH/DoT-Verbot von den Pods nach außen.
Protokollierung von Anfragen und Alerting nach Anomalien (neue Domains, häufige NXDOMAINs).

11) Protokolle, Beobachtbarkeit und Prüfung

Firewallprotokolle (allow/deny, Regeln, Bytes), WAF-Audit, DNS-Protokolle → SIEM/SOAR.
Beispiele: Blockierungsmetriken mit 'trace _ id' → schneller Sprung in die Spur der problematischen Abfrage.
Synthetik: Regelmäßige Verfügbarkeitsprüfungen von PSPs/Spieleanbietern aus den gewünschten Regionen.
Netzwerk-Chaos-Tests: Paket-Verlust, RTT, DNS-Fehler - überprüfen Sie die Reaktion der Regeln und Auto-Remediation.

12) Automatisierung und IaC

Alle Regeln sind wie ein Code (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Pull-request-Revue mit Sicherheitsrichtlinien (OPA).
Versionierung und Anmerkungen: Jede Regeländerung wird in den Diagrammen markiert.
Kanarische Veränderungen: Netzwerkrichtlinien schrittweise ausrollen (Namespace/Label, 5-10% der Pods).

13) Besonderheiten von iGaming

Zahlungswege (PSP): separate egress-Gruppen, strikte allowlist, Code/Timeout-Überwachung.
Spieleanbieter: Whitelisting von CDN-Domains, Schutz vor plötzlichen Weiterleitungen.
Geo-Regeln: Einhaltung lokaler Beschränkungen, Regionalblöcke am Rand.
Backoffice/KYC: Zugriff nur von vertrauenswürdigen Netzwerken/über bastion + MFA.
Betrug: Velocity-Limits für L7 und „schwere“ Anfragen an die APIs anomaler Quellen.

14) Beispiele für schnelle Regeln

UFW (Gastgeber)

bash ufw default deny incoming ufw default deny outgoing ufw allow 22/tcp ufw allow 443/tcp ufw allow out to 10.10.0.10 port 53 proto udp ufw allow out to 203.0.113.0/24 port 443 proto tcp

Istio EnvoyFilter (Verbot nicht standardmäßiger Methoden, Idee)

yaml typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router до роутера — Lua/Match для блокировки методов not in [GET,POST,OPTIONS]

NGINX rate-limit

nginx limit_req_zone $binary_remote_addr zone=rl_api:10m rate=10r/s;
server {
location /api/ { limit_req zone=rl_api burst=50 nodelay; proxy_pass http://api; }
}

15) Checkliste Umsetzung

1. Default deny auf Cloud- (SG/NACL), Cluster- (NetworkPolicy) und Host-Ebene.
2. Egress-allowlist zu PSPs/Providern, resolvim nur über trusted DNS.
3. WAF/Bot Management/DDoS auf Edge, L7-Regeln unter REST/JSON und Downloads.
4. mTLS zwischen Diensten, Identitätsberechtigung (Spiffe/SA).
5. Rate-limit/quotas auf der Kante und in der app, idempotency-keys für Zahlungen.
6. DNS-Richtlinien: DoH/DoT-Verbot, Split-Horizon, Protokollierung.
7. Logs und SIEM: zentrale Erfassung von Allow/Deny/WAF/DNS, Alerts für Anomalien.
8. IaC-Prozesse: Regelcode, PR-Revue, Kanarienrollen, Annotationen.
9. Tests/Chaos: RTT/Verlust/DNS-Abstürze, Überprüfung von Fallback-Routen und Auto-Skripten.
10. Regelmäßige Revisionen: Prüfung nicht verwendeter Regeln, Rotation von PSP/CDN-Adressen.

16) Anti-Muster

„Alles öffnen und auf WAF hoffen“ - der Perimeter wird den Binnenverkehr nicht retten.
Keine egress-Steuerung - Lampentunnel nach außen für Lecks/C2.
Allow-all NetworkPolicy in Kubernetes - seitliche Bewegung garantiert.
Filterung nur über IP in einer dynamischen CDN/PSP-Welt ohne Domain/DNS-Kontrolle.
Der einzige TLS-Terminationspunkt ohne mTLS im Inneren ist der Austausch von Diensten.
Manuelle Regeländerungen in der Produktion ohne IaC/Audit - nicht reproduzierbar und Schulden.
Firewall-Protokolle „im Nirgendwo“ - ohne Beobachtbarkeit ist es nur eine „Black Box“.

Ergebnisse

Effiziente Traffic-Filterung ist das architektonische Gefüge der Plattform: von Edge-WAF und Cloud SG über NetworkPolicy und mTLS innerhalb des Clusters, mit harter Egress-Steuerung zu PSPs/Providern und Management über IaC. Ein solches System reduziert das Risiko von Lecks und Angriffen, hält Zahlungen und Spiele innerhalb des SLO und hilft bei der schnellen Untersuchung von Vorfällen durch vollständige Audits und Beobachtbarkeit.