Zeile → genauer im Laufe des Vortrags Vereinfachung + Redundanz-Vermeidung -> auf der übernächsten Folie näher erklärt effizient → immer angestrebt Fehlermeldungen -> besseres Debugging auf lange Sicht ipfw: 1994, Kernel 1.0, von FreeBSD ipfwadm: 1996, Kernel 2.0 ipchains: 1999, Kernel 2.2 iptables: 2000, Kernel 2.3 nftables: Anfang Februar 2014, Kernel 3.13 für jedes Protokoll eigene Implementierung: einerseits: protokoll-spezifischer Code → hohe Performance durch native Ausführung andererseits: dennoch viel Ähnlichkeit der Implementierungen NIC = Network Interface Card = Netzwerkkarte vorgegebene Tabellen: filter, nat → zeigen vorgebene Cains: filter: input forward output nat: prerouting postrouting ein Tool, eine Kernel-Implementierung einheitliche Schnittstelle → durch virtuelle Maschine → nur noch Byte-Code Regeln werden im Userspace durch "nft" Tool kompiliert siehe Folie vergleichen: IP-Adressen direkt vergleichen airthmetische + logische Operationen: z.B. Bereich aus IP maskieren Änderungen: SNAT, DNAT siehe Folie nur oberen Teil!!! Netlink = schnelle Userspace ←→ Kernel Schnittstelle, transaktionsbasiert NF-Tables-Core-Engine hängt sich in Netfilter ein payload = IP Packet 4 → Anzahl Bytes offset network header + 16 → Destination IP Address in IP Header compare → Vergleichsoperation danach: Sprung lookup in Tabelle → "verdict" → Urteil → auf rechter Seite nur Targets möglich iptables = Firewall, Tool nftables = Firewall nft = Tool Voraussetzung: eigene Tabelle: beliebiger Name eigene Chain: beliebiger Name Chain: type = Tabelle } jeweils aus hook = Chain } iptables nft inzwischen in Arch in community Repo Performance messen: möglichst viele Pakete pro Sekunde → Datenrate und PPS über Ethernet-Größe auftragen → Frame-Größe sukzessiv kleiner machen → bei ca. 300 Byte Framegröße: Sender kann nicht schneller Pakete schicken CPU-Last dauerhaft auf 100 % → busy waiting (Delay hätte man einfügen können) das gleiche beim Empfänger → hier schon bei ca. 450 Byte Framegröße CPU-Last eingetragen → Messung mittels "top" → schlägt erst aus, wenn Pakete nicht mehr schnell genug bearbeitet werden können → Kern-Prozess "ksoftirq" fast sofort auf 100% eigentliche Messung bis 25000 Regeln: iptables nach wie vor besser → nftables besser, was Antwortzeit anbelangt mittlere Regelanzahl → typischer Fall virtuelle Maschine → sehr leicht neue Erweiterungen machbar Dokumentation: bis vor einer Woche: lediglich ein Tutorial verfügbar jetzt: Wiki mit einigen Beispielen noch keine vollständige Dokumentation