# Firewall und IPv6 – Grundlagen und empfohlene Umsetzung
---
<style>
/* Logo-Positionierung */
.reveal .slides {
background: url(https://hedgedoc.xinux.net/uploads/xinux-weiss.png) no-repeat;
background-position: right 10px bottom 10px;
background-size: 80px;
}
/* Listen-Anpassungen */
.reveal ul li {
font-size: 28px !important;
line-height: 1.3 !important;
margin-bottom: 10px !important;
}
/* Optional: Verbesserte Lesbarkeit */
.reveal .slides section {
text-align: left;
padding: 20px 40px !important;
}
</style>
## IPv6 und Firewalls: Warum ein eigenes Thema?
- IPv6 arbeitet grundsätzlich ohne NAT – echtes Ende-zu-Ende
- Neue Protokolle wie ICMPv6 und Neighbor Discovery (ND)
- SLAAC und DHCPv6 als Optionen für Adressvergabe
- Deutlich größerer Adressraum mit neuen Schutzanforderungen
- Firewalls müssen IPv6 spezifisch berücksichtigen
---
## IPv6 Firewall-Grundsätze (aus Standards und Praxis)
- Default-Deny-Ansatz empfohlen
- ICMPv6 ist unverzichtbar für IPv6 und darf nicht pauschal blockiert werden
- Stateful-Filterung bevorzugt
- Regeln für eingehenden und ausgehenden Verkehr separat definieren
- Logging aller nicht erlaubten Pakete
---
## Vergleich IPv4 und IPv6 Firewalling
- Keine Port- oder Session-NAT bei IPv6 (außer evtl. NPTv6)
- Klare Trennung von Routing und Sicherheit
- ICMPv6 als elementarer Bestandteil notwendig
- Stateful-Filterung bleibt wichtig
---
## Bedrohungen und Risiken
- Automatische Adressbildung
- Link-Local- und Multicast-Kommunikation
- ICMPv6-Missbrauch (z.B. RA-Flooding)
- Umgehung von Filterregeln über Extension Header
- Angriffe auf ND und Multicast
---
## ICMPv6: Notwendige Freigaben
- Echo Request/Reply (Typ 128/129)
- Destination Unreachable (Typ 1)
- Packet Too Big (Typ 2)
- Time Exceeded (Typ 3)
- Neighbor Solicitation/Advertisement (Typ 135/136)
---
## Router Advertisements (RA)
- Nicht pauschal blockieren
- Gezieltes Zulassen auf SLAAC-Interfaces
- Absicherung auf Switch-Ebene (RA-Guard)
- Überwachung auf Fake-RA (z. B. NDPMon)
---
## Multicast und Link-local
- Multicast ist Standard bei IPv6 (z.B. ff02::1)
- Nur notwendige Gruppen zulassen
- Link-Local Verkehr prüfen und filtern
- Switch-Features wie MLD Snooping nutzen
---
## Beispielregelwerk: Eingehend
- Default: DROP
- ICMPv6 selektiv erlauben
- Notwendige Ports (SSH, HTTPS) gezielt erlauben
- ND nur auf lokalen Interfaces zulassen
- Logging für alle Drops aktivieren
---
## Beispielregelwerk: Ausgehend
- DNS (53), HTTP/HTTPS (80/443) explizit erlauben
- ICMPv6 selektiv erlauben
- Keine "Allow Any"-Regeln
- Optional weitere Dienste explizit freigeben
---
## Stateful vs. Stateless Filtering
- Stateful-Filterung wird bevorzugt
- Fragmentierung und Extension Header beachten
- Stateless sinnvoll für einfache Protokolle (z.B. DNS)
- Monitoring und Logging notwendig
---
## Extension Header
- Erhöhen Komplexität der Prüfung
- Firewalls müssen Next-Header-Ketten verarbeiten können
- RFC 7112 beschreibt Anforderungen an Fragment Handling
- Logging ungewöhnlicher Header empfohlen
---
## NPTv6 – Network Prefix Translation
- Übersetzt nur das Präfix, keine Ports oder Interface-Identifier
- Unterstützt ISP-Präfixwechsel und Multi-Homing
- Definiert in RFC 6296
- Keine offizielle Empfehlung oder Ablehnung durch BSI
- Wird in der Praxis als pragmatische Lösung betrachtet
---
## NAT66
- Übersetzt gesamte Adresse
- Bricht das Ende-zu-Ende-Prinzip
- Erschwert Debugging und Anwendungskompatibilität
- Kein IETF-Standard, daher problematisch
- Wird von Experten in der Regel abgelehnt
---
## Privacy Extensions und temporäre Adressen
- Erschweren Quell-Adressbasierte Firewall-Regeln
- Erhöhen Privatsphäre der Clients
- Server sollten keine Privacy Extensions nutzen
- Logging wird durch wechselnde Adressen erschwert
---
## Empfehlungen für Server
- Statische Adressen (keine Privacy Extensions)
- Manuelle oder DHCPv6-Adressvergabe
- Firewall-Regeln gezielt auf feste Adressen
- Sauberes Logging möglich
---
## Empfehlungen für Clients
- Privacy Extensions optional, aber zulässig
- Nur ausgehender Traffic erlauben
- Keine direkte Internet-Erreichbarkeit nötig
- Überwachung und Analyse von Verbindungen empfohlen
---
## Dual Stack
- IPv4 und IPv6 müssen separat gefiltert werden
- Kein NAT bei IPv6 → Firewall trägt größere Verantwortung
- Aufwand durch doppelte Regeln und Pflege
- Langfristiges Ziel: IPv6-Only-Betrieb
---
## Logging und Monitoring
- ICMPv6 separat erfassen
- Logging mit Rate-Limiting
- Monitoring-Tools: Suricata, Zeek, ip6tables/nftables
- Zentrale Sammlung (z.B. Syslog-Server)
---
## Prüfwergzeuge für IPv6-Firewalls
- `nmap -6` für IPv6-Portscans
- `ping6`, `traceroute6`, `tcpdump` für Traffic-Analyse
- `scapy`, `ndisc6`, `rdisc6` für ND-Tests
- `conntrack -L` für Sessions
- Integration in Monitoring möglich
---
## Fazit
- IPv6 erfordert sorgfältiges, regelbasiertes Firewall-Design
- Kein NAT bedeutet klarere und sauberere Zuständigkeiten
- Praxisnahe Empfehlungen aus IETF und Betriebserfahrungen verfügbar
- Mit sorgfältiger Planung ist IPv6 sicher und transparent betreibbar