160 lines
3.0 KiB
XML
160 lines
3.0 KiB
XML
|
<notes>
|
||
|
<note number="3">
|
||
|
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
|
||
|
</note>
|
||
|
|
||
|
<note number="4">
|
||
|
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
|
||
|
</note>
|
||
|
|
||
|
<note number="5">
|
||
|
für jedes Protokoll eigene Implementierung:
|
||
|
|
||
|
|
||
|
|
||
|
einerseits: protokoll-spezifischer Code → hohe Performance durch native Ausführung
|
||
|
|
||
|
|
||
|
andererseits: dennoch viel Ähnlichkeit der Implementierungen
|
||
|
</note>
|
||
|
|
||
|
<note number="6">
|
||
|
|
||
|
NIC = Network Interface Card = Netzwerkkarte
|
||
|
|
||
|
|
||
|
vorgegebene Tabellen: filter, nat → zeigen
|
||
|
|
||
|
vorgebene Cains:
|
||
|
filter:
|
||
|
input
|
||
|
forward
|
||
|
output
|
||
|
nat:
|
||
|
prerouting
|
||
|
postrouting
|
||
|
</note>
|
||
|
|
||
|
<note number="7">
|
||
|
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
|
||
|
</note>
|
||
|
|
||
|
<note number="8">
|
||
|
nur oberen Teil!!!
|
||
|
|
||
|
Netlink = schnelle Userspace ←→ Kernel Schnittstelle, transaktionsbasiert
|
||
|
|
||
|
NF-Tables-Core-Engine hängt sich in Netfilter ein
|
||
|
</note>
|
||
|
|
||
|
<note number="9">
|
||
|
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
|
||
|
</note>
|
||
|
|
||
|
<note number="10">
|
||
|
iptables = Firewall, Tool
|
||
|
</note>
|
||
|
|
||
|
<note number="11">
|
||
|
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
|
||
|
</note>
|
||
|
|
||
|
<note number="14">
|
||
|
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)
|
||
|
</note>
|
||
|
|
||
|
<note number="15">
|
||
|
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%
|
||
|
</note>
|
||
|
|
||
|
<note number="16">
|
||
|
eigentliche Messung
|
||
|
|
||
|
bis 25000 Regeln: iptables nach wie vor besser
|
||
|
</note>
|
||
|
|
||
|
<note number="17">
|
||
|
→ nftables besser, was Antwortzeit anbelangt
|
||
|
</note>
|
||
|
|
||
|
<note number="18">
|
||
|
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
|
||
|
</note>
|
||
|
|
||
|
</notes>
|