| orm@doc-tcpip.org | Erstellt: Mai 2003 - Letzte Modifikation: Juni 2004 |
Bei allen Problemen auf dem Netzwerk ist meist die Firewall zuerst in Verdacht. Daher schien es wünschenswert, die Angaben in der Firewall-Dokumentation mit ein paar gezielten Messungen besser zu verstehen.
Mit Hilfe des trace-Kommandos kann man die Zeit messen, die der Kernel (also die CPU) mit dem Abarbeiten einer bestimmten Routine (wenn Trace-Hooks entsprechend gesetzt sind) braucht. Diese Werte wurden für eine Test-Verbindung bei ansteigender Zahl an Regeln ermittelt und dann untersucht.
Im Trace findet man zwei Arten von Zeitstempeln: Einmal wird die seit Start des Traces verfloßene Zeit protokolliert, sowie die zwischen den Hooks aufgelaufene Zeit als Delta in milli-Sekunden angegeben. Man muß also nur (!) die Routine finden, die das Regelwerk durchsucht, und kann dann die verbrauchte Zeit gegen die Anzahl der Regeln auftragen.
Durchgeführt wurden die Tests auf einer der ältesten IBM PowerPC Maschinen - einer 6015 (PReP Architektur) mit 48 MB Hauptspeicher. Dieser Typ wurde später in 7020 (40P) umbenannt. Für derartige Tests ist diese Maschine nicht schlecht geeignet, da bei sowenig CPU-Power leicht große Effekte erzielt werden können.
Daher sind die Ergebnisse quantitativ in keinem Fall auf aktuelle Maschinen zu übertragen. Die Trends und die qualitative Aussage ist jedoch voll zutreffend - wobei bei Maschinen mit mehr CPUs die Steigung der Geraden neu ermittelt werden müßte.
Bei der IBM-Secureway Firewall gibt es im Normalfall zwei Routinen, die das Regelwerk prüfen (wahrscheinlich steckt dahinter eine Subroutine, das ist aber ohne Kenntnis des Source-Codes nur eine Annahme) und zwar je nach Richtung des Pakets (inbound oder outbound). Der Suchlauf im Regelwerk startet nach der Prüfung auf NAT bzw. des Filters für ausgehende Pakete.
Also müßte das zeitliche Delta zwischen Ende der Routine fwnati_after bzw. fltro4 bis zur Meldung Matched filter rule ... die Zeit des Durchlaufs sein. Als Beispiel je ein Paket inbound sowie ein Paket outbound. Die gemessenen Routinen sind fltri4 und fltrio4 (9.540864 msec bzw. 1.678464 msec).
Paket inbound, Routine fltri4.
2DF 3.195408000 621.320832 IPSEC_FILTER_INFO fwnati_before: src=AC100121.42962 dst=AC101602.23 len=44 sum=15142
2DF 3.195569536 0.161536 IPSEC_FILTER_INFO fwnati_after: src=AC100121.42962 dst=AC101602.23 len=44 sum=15142 PERMIT
2DF 3.205110400 9.540864 IPSEC_FILTER_INFO fltri4: Matched filter rule 1: Action is PERMIT
Delta in msec: ^^^^^^^^^
Paket outbound, Routine ftrio4.
2DF 3.205608192 0.497792 IPSEC_FILTER_INFO fltro4: (en0) sad=AC100121 dad=AC101602 pr=6
2DF 3.205662976 0.054784 IPSEC_FILTER_INFO fltro4: ak/rs=0 sprt=42962 dprt=23 loc=0 frg=0 frghdr=0 len=44
2DF 3.207341440 1.678464 IPSEC_FILTER_INFO fltro4: Matched rule 2, action is PERMIT
Delta in msec: ^^^^^^^^
Betrachtet wird ein TCP Handshake (also 6 Pakete) zwischen einem sicheren und einem unsicheren Host. Die Regeln sind spezifisch für die Verbindung angelegt.
# fwfilter cmd=list 501|2|permit|172.16.1.3|255.255.255.255|172.16.22.2|255.255.255.255|tcp|gt|1023| eq|23|secure|route|inbound|0|y|y| 501|3|permit|172.16.1.3|255.255.255.255|172.16.22.2|255.255.255.255|tcp|gt|1023| eq|23|non-secure|route|outbound|0|y|y| 501|4|permit|172.16.22.2|255.255.255.255|172.16.1.3|255.255.255.255|tcp|eq|23|gt |1023|non-secure|route|inbound|0|y|y| 501|5|permit|172.16.22.2|255.255.255.255|172.16.1.3|255.255.255.255|tcp|eq|23|gt |1023|secure|route|outbound|0|y|y|Zusätzlich wird der sichere IP-Host noch auf der Firewall per NAT auf eine externe Adresse gemapped.
Vor diese Regeln wurden dann 2000 sinnlose Regeln gesetzt.
Dazu wurde eine Regel benutzt, die den Zugriff
auf Ports größer 10000 des sicheren Hosts vom Port 23 des unsicheren
Host verbietet. Eine solche
Regel kann dann über die Range der freien Ports beliebig
erweitert werden. Der benutzte Befehl
fwfrule cmd=add name=L1 desc=Orm type=deny protocol=tcp srcopcode=gt
srcport=1023 destopcode=eq destport=10000 interface=secure routing=route
log=no direction=inbound
wurde per Skript über die 2000 Ports gezogen.
505|deny|L1|Orm|tcp|gt|1023|eq|10000|secure||route|inbound|no|| 505|deny|L2|Orm|tcp|gt|1023|eq|10001|secure||route|inbound|no|| 505|deny|L3|Orm|tcp|gt|1023|eq|10002|secure||route|inbound|no|| 505|deny|L4|Orm|tcp|gt|1023|eq|10003|secure||route|inbound|no|| ......Diese Regel wurde in Paketen zu je 200 Stück in einen Service gesteckt, und pro Service eine Connection definiert.
Erstellen von Services mit je 200 Regeln: 502 SL0 Orm 507 SL1000 Orm 508 SL1200 Orm 509 SL1400 Orm 510 SL1600 Orm 511 SL1800 Orm 503 SL200 Orm 504 SL400 Orm 505 SL600 Orm 506 SL800 OrmErstellen einer Connection pro Service:
# fwnwobj cmd=list 502 Interface NonSecureInt-172.16.22.1 (Created by setup wizard) 508 Host Secure Host 1 Host drinnen 509 Host Secure Host 2 (NAT) NAT Host selbes Netz 501 Interface SecureInt-172.16.1.1 (Created by setup wizard) 503 Network SecureNet-172.16.1.0 (Created by setup wizard) 1 Network The World 507 Host Unsecure host 1 Host DraussenConnection von Secure2 nach World:
Die so entstandenen Verbindungen werden nun vor die Telnet-Regeln gestellt und dann stufenweise aktiviert. Für jede Stufe wird ein Trace gestartet, das Telnet-Kommando abgesetzt und nach Erscheinen des Login-Promptes wird der Trace gestoppt.
Der Paket-Fluß ist also:
Das Trace File wird per Skript formatiert und die ersten 6 Matched rule .. Zeitstempel werden in eine Datei geschrieben und per gnuplot als Grafik ausgegeben.
Als zweiter Test wurde der Einfluß einer großen NAT-Tabelle auf die Rechenzeit geprüft. Dazu wird analog zum ersten Fall eine lange NAT-Tabelle erzeugt (200 Einträge) und in Stufen von 50 Einträgen gesteigert.
Die Ergebnisse sind in den folgenden Abbildungen dargestellt und in der Tabelle wiedergegeben. Einer der Traces ist unter Tracing (Network Address Translation im Trace) in voller Länge und kommentiert zu sehen.
Die Testfälle im NAT Test sind:
Werte aus dem Firewall Lasttest zum Vergleich. Die Messung erfolgte aus dem Trace, immer in der Differenz NACH der fwnat* Funktion. Angaben in msec auf einer sehr alten RS6000 mit 1822 Regeln.
Test mit derselben Anzahl an Regeln, aber einer anderen IP im selben Netz.
Jetzt mit derselben Anzahl an Regeln, aber mit einer IP aus einem anderen Netz.
Jetzt mit derselben Anzahl an Regeln, aber einer ganz anderen IP
Jetzt die Telnet-NAT Rule nach ganz oben, ansonsten alles wie vor
Jetzt inbound/outbound getauscht, NW getauscht
Wie erwartet steigt die Zeit linear mit der Zahl der Regeln. Die Firewall muß einfach mehr Regeln durchgehen. Allerdings unterscheidet die Firewall nach Interface und Richtung des Verkehrs. In unserem Fall ist die Richtung inbound über das secIF mit sehr vielen Regeln befrachtet - die anderen Richtungen bzw. Interfaces erleben einen Anstieg, der der Last der Maschine entspricht.
Baut man ein Firewall Regelwerk auf, so sollte man versuchen, die Zahl der Regeln gering zu halten. Regeln, die Zusammenfassend wirken, sind zu bevorzugen (jeden Port einzeln zu sperren, wie hier im Test gemacht, ist ein schwerer Fehler).
NAT: Kein Einfluß erkennbar.
Folgende Tests wären noch von Interesse:
Zur Vollständigkeit die ersten 6 Pakete, also das TCP-Handshake, für 1200 Regeln vor der eigentlichen Telnet-Regel sowie die Ergebnisse der Messungen.
2DF 3.195408000 621.320832 IPSEC_FILTER_INFO fwnati_before: src=AC100121.42962 dst=AC101602.23 len=44 sum=15142 2DF 3.195569536 0.161536 IPSEC_FILTER_INFO fwnati_after: src=AC100121.42962 dst=AC101602.23 len=44 sum=15142 PERMIT 2DF 3.205110400 9.540864 IPSEC_FILTER_INFO fltri4: Matched filter rule 1: Action is PERMIT 2DF 3.205608192 0.497792 IPSEC_FILTER_INFO fltro4: (en0) sad=AC100121 dad=AC101602 pr=6 2DF 3.205662976 0.054784 IPSEC_FILTER_INFO fltro4: ak/rs=0 sprt=42962 dprt=23 loc=0 frg=0 frghdr=0 len=44 2DF 3.207341440 1.678464 IPSEC_FILTER_INFO fltro4: Matched rule 2, action is PERMIT 2DF 3.207546368 0.204928 IPSEC_FILTER_INFO fwnato_before: src=AC100121.42962 dst=AC101602.23 len=44 sum=15142 2DF 3.207813632 0.267264 IPSEC_FILTER_INFO fwnato_after: src=AC101603.42962 dst=AC101602.23 len=44 sum=9796 PERMIT 2DF 3.209888512 2.074880 IPSEC_FILTER_INFO fwnati_before: src=AC101602.23 dst=AC101603.42962 len=44 sum=42776 2DF 3.210174720 0.286208 IPSEC_FILTER_INFO fwnati_after: src=AC101602.23 dst=AC100121.42962 len=44 sum=48122 PERMIT 2DF 3.213192832 3.018112 IPSEC_FILTER_INFO fltri4: Matched filter rule 3: Action is PERMIT 2DF 3.213661440 0.468608 IPSEC_FILTER_INFO fltro4: (en1) sad=AC101602 dad=AC100121 pr=6 2DF 3.213715200 0.053760 IPSEC_FILTER_INFO fltro4: ak/rs=1 sprt=23 dprt=42962 loc=0 frg=0 frghdr=0 len=44 2DF 3.215397120 1.681920 IPSEC_FILTER_INFO fltro4: Matched rule 4, action is PERMIT 2DF 3.215593088 0.195968 IPSEC_FILTER_INFO fwnato_before: src=AC101602.23 dst=AC100121.42962 len=44 sum=48122 2DF 3.215751296 0.158208 IPSEC_FILTER_INFO fwnato_after: src=AC101602.23 dst=AC100121.42962 len=44 sum=48122 PERMIT 2DF 3.217117184 1.365888 IPSEC_FILTER_INFO fwnati_before: src=AC100121.42962 dst=AC101602.23 len=40 sum=15145 2DF 3.217276416 0.159232 IPSEC_FILTER_INFO fwnati_after: src=AC100121.42962 dst=AC101602.23 len=40 sum=15145 PERMIT 2DF 3.226781056 9.504640 IPSEC_FILTER_INFO fltri4: Matched filter rule 1: Action is PERMIT 2DF 3.227250304 0.469248 IPSEC_FILTER_INFO fltro4: (en0) sad=AC100121 dad=AC101602 pr=6 2DF 3.227303808 0.053504 IPSEC_FILTER_INFO fltro4: ak/rs=1 sprt=42962 dprt=23 loc=0 frg=0 frghdr=0 len=40 2DF 3.228983296 1.679488 IPSEC_FILTER_INFO fltro4: Matched rule 2, action is PERMIT 2DF 3.229189120 0.205824 IPSEC_FILTER_INFO fwnato_before: src=AC100121.42962 dst=AC101602.23 len=40 sum=15145 2DF 3.229459072 0.269952 IPSEC_FILTER_INFO fwnato_after: src=AC101603.42962 dst=AC101602.23 len=40 sum=9799 PERMIT
# Werte aus Firewall Lasttest. #Regeln Regel 1 2 3 4 1 2 12 0.093056 0.084480 0.096768 0.093440 0.089088 0.088192 415 3.258240 0.679552 1.090688 0.683776 3.251072 0.685952 817 6.438272 1.190528 2.032256 1.255296 6.351872 1.192192 1219 9.540864 1.678464 3.018112 1.681920 9.504640 1.679488 1621 12.636160 2.168320 3.880832 2.172800 12.594688 2.169728 1822 14.193920 2.416512 4.338304 2.486016 14.144000 2.418560
# 1 Werte aus Firewall Lasttest. MEssung aus Trace, immer in der Differenz NACH der fwnat* Funktion # In msec auf einer alten Mühle. Mit 1822 Regeln # 2 Jetzt mit derselben Anzahl an Regeln, aber einen anderen IP im selben # Netz. # 3 Jetzt mit derselben Anzahl an Regeln, aber einen IP aus einem anderen Netz # 4 Jetzt mit derselben Anzahl an Regeln, aber einer ganz anderen IP # 5 Jetzt die Telnet-NAT Rule nach ganz oben, ansonsten alles wie vor # 6 Jetzt inbound/outbound getauscht, NW getauscht #Regel 1 #Regel 2 #Regel 3 #Regel 4 #Regel 1 #Regel 2 #0 0 0 0 0 0 0 1 14.185344 2.413056 4.318464 2.475136 14.131712 2.411136 2 6.493312 2.413568 4.313472 2.412800 6.379904 2.481280 3 6.497152 2.411904 4.337536 2.407680 6.373248 2.400960 4 6.426624 2.406016 4.333696 2.472960 6.453760 2.408576 5 0.095232 0.093824 0.097408 0.090240 0.093056 0.087680 6 2.537984 5.214336 2.435328 10.548864 2.406912 5.214336 #7 0 0 0 0 0 0
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL