Konzept-Vorschlag Performance-Test Firewall-Cluster

Transkript

1 Sachgebiet Informationstechnik Konzept-Vorschlag Performance-Test Firewall-Cluster CPU-Last ( busy ): Summe Kernel User Abbildung 1: CPU-Auslastung einer Firewall während eines RBT-Lasttests Kontakt: Jürgen Wehner (Sachgebietsleiter) Tel: (0911) juergen.wehner@rbt-nbg.de Claus-Georg Pleyer Tel: (0911) claus-georg.pleyer@rbt-nbg.de Helmut Schmidt Tel: (0911) helmut.schmidt@rbt-nbg.de Stand: Mai Nürnberg, Wallensteinstraße 119 Telefon , Fax Amtsgericht Nürnberg HRB 609 Gesellschafter: Bayerischer Rundfunk - Hessischer Rundfunk - Mitteldeutscher Rundfunk - Radio Bremen - Rundfunk Berlin-Brandenburg Saarländischer Rundfunk- Südwestrundfunk - Zweites Deutsches Fernsehen Geschäftsführer: Dipl.-Ing. (FH) Alfred Preissner

2 Die RBT verfügt über Know-how, Erfahrung und Meßmittel für Firewall-Performancetests. Ziele Mit dem RBT-Testvorschlag sollen Investitionen in die bestmögliche Sicherheit bei anforderungsgemäßer und zukunftssicherer Performance der Firewall getätigt werden. Die Ziele der Untersuchung sind: - Ermittlung der Leistungsgrenzen des Systems - Überprüfung realer Betriebsszenarien - Kontrolle der Wirksamkeit von Schutz- und Failover-Mechanismen - Vergleich des Systems mit bereits getesteten Varianten - Optimierung von Konfigurationen in Bezug auf Sicherheit und Performance - Hilfe bei Investitions-Entscheidungen und der Auswahl von Alternativen Testkonzept Es werden vier zentrale Fragen geklärt: 1. Welche Performancewerte erreicht die Firewall? (Benchmark) Hierzu dienen die in RFC 3511 festgelegten Testgrößen: - maximale Sessionanzahl - maximale Sessionauf- und abbaurate - maximaler Durchsatz bei unterschiedlichen Paketgrößen - Latenzmessung - maximale http-transferrate - maximale http-transaktionsrate - Kombination aus maximaler http-transferrate und TCP/IP-Paketen mit SYN-Flag - Kombination aus maximaler http-transferrate und verbotenem Verkehr - Kombination aus maximaler http-transferrate und fragmentierten UDP/IP-Paketen 2. Reichen die CPU-Reserven der Firewall für den betrieblichen Einsatz aus? (vgl. Abb. 2) Realistischer Verkehr setzt sich aus den folgenden CPU-Einflußfaktoren zusammen: - Paketrate: mit kleinen Paketgrößen steigt der Protokoll-Overhead - Transferrate: auch Übertragungsrate, Durchsatz - Transaktionsrate: Wieviele Übertragungen werden pro Sekunde abgeschlossen? - Sessionrate: abhängig von der Fluktuation der aktiven Benutzer - Protokoll: bestimmt die obigen Faktoren und den Overhead - aktiver Firewall-Regelsatz (Rule-Set): bestimmt die Tiefe der Protokollprüfung - Network Address Translation (NAT): Umsetzung zw. internen u. Internet-IP-Adressen - Angriffslast und unerwünschter Verkehr Seite 2 / 6

3 direkte Abhängigkeit indirekte Abhängigkeit Sessionanzahl Transferrate [Mbit/s] Auf- u. Abbau von TCP-Sessions Dateigröße [Byte] Sessionrate [1/s] FW-CPU FW-CPU [% busy] Transaktionsrate [1/s] Angriffsrate [Pakete/s] FW-Regel, Overhead, Paketrate [1/s] Angriffe Protokoll Abbildung 2: Dynamische Einflußfaktoren auf die CPU-Auslastung der Firewall 3. Wie beeinflussen Firewall-Regeln die Performance? Die unter 1. und 2. genannten Größen werden mit unterschiedlichen Regelsätzen der Firewall ermittelt, um die optimale Konfiguration für den realen Betrieb herauszufinden. 4. Schützt die Firewall ausreichend vor Angriffen und unerwünschtem Verkehr? Hierzu können vom RBT-Testsystem folgende Streßarten erzeugt werden: - Viren-Angriff: Mails mit simuliertem Virus im Anhang - SYN-Flood: viele TCP-Pakete mit gesetztem SYN-Flag - IP Fragmentation: fragmentierte, übergroße IP-Pakete - Ping of Death: fragmentierte, übergroße ICMP-Pakete - IP Spoofing: Pakete mit gefälschter interner IP-Adresse - Land Attack: SYN-Flood oder Ping mit identischer Ziel- und Quell-IP-Adresse - Smurth Attack: Ping mit gefälschter Quell-Adresse an die Broadcast-IP-Adresse - Port-Scanning: TCP- und UDP-Pakete mit beliebig gesetzten Flags an beliebige Ports - Capture und Replay von bereits einmal akzeptierten, duplizierten Paketen Seite 3 / 6

4 Testleistungen Ein Test durch die RBT leistet Folgendes: - Generierung ausreichender Lasten über zwei bis vier Gigabit-Netzwerkkarten eines modularen Client/Server-Meßsystems aus spezieller Hard- und Software - Nachbildung eines individuellen Lastmixes aus verschiedenen Anwendungen und Verkehrsprofilen - Skalierung bis auf mehrere tausend Verbindungen mit individuellen IP- und MAC- Adressen - Streßlast mit unerwünschten Verkehrsarten und typischen Angriffen aus dem Internet - Monitoring von Systemressourcen - Verifizierbare Lastszenarien um Auswirkungen von Konfigurations-Änderungen, Updates oder Upgrades zu erkennen - Orientierung an den RFCs 3511, 2647 und 2544 Verkehrsanalyse im Vorfeld Die RBT kann den im realen Betrieb an der Firewall auftretenden Verkehr mit einer speziellen Gigabit Ethernet Hardwarekarte und der Analysesoftware Omnipeek der Firma WildPackets mitschneiden und analysieren. Die in Abb. 2 gezeigten Einflußfaktoren lassen sich so als Grundlage für realistische Testkonfigurationen quantifizieren. Beispielsweise zeigt Abb. 3 die Transferraten- Verteilung über fünf gängige und noch erweiterbare Benutzer-Protokolle eines RBT-Lastmixes. RTSP; 60; 6% SMTP; 100; 10% HTTP; 400; 42% HTTPS; 150; 16% FTP; 250; 26% Abbildung 3: Beispiel-Lastmix aus 5 Protokollen mit unterschiedlicher Transferrate (in Mbit/s) Seite 4 / 6

5 Testaufbau Über die zu untersuchende Firewall wird von der RBT durch zwei Last-Module variabel konfigurierbarer Nutz- und Angriffsverkehr gesendet (s. Abb. 4). LAN / DMZ Angriffslast WAN / Internet Anwender- Verkehr Client/Server Last-Modul 1 Firewall Abbildung 4: RBT-Testaufbau mit der zu untersuchenden Firewall (schematisch) Client/Server Last-Modul 2 Ein Controller-Laptop mit der Software NetPressure steuert und überwacht die Messungen über ein separates Management-LAN. Ein spezielles ReportingTool dient zur vergleichenden Auswertung der Ergebnisse. Diese Komponenten bilden das Dienste-Meßsystem NetworkTester der Firma Agilent Technologies. Beispiele aus einem RBT-Bericht 1. Zusammenhang von Transfer- und Sessionrate mit der CPU-Zeit der Firewall Oberhalb der orangenen Kurve droht die Überlastung des Systems. Transferrate [Mbit/s] Sessionrate [1/s] Auslastung der FW-CPU 80 % 50 % Zunehmende Paketu. Transaktionsraten, komplexere Firewall- Regeln u. Angriffslast drücken die Kurven zu den Achsen Abbildung 5: Lastszenario aus Transfer- und Sessionrate über eine Firewall an Gigabit Ethernet Seite 5 / 6

6 2. Zunehmender Denial-of-Service-Angriff auf die Firewall bei Anwender-Verkehrsmix Mit ansteigenden SYN-Flood-Paketen sinken Transfer-, Transaktions- und Sessionrate der Anwender-Protokolle. Es treten zunehmend Timeout-Fehler auf. Die Firewall-CPU wird bis zu 90 % ausgelastet, wenn der Angriff den Nutzerverkehr überwiegt Angriffsverkehr: Angriffsrate [Mbit/s] Anwenderverkehr: Transferrate [Mbit/s] Transaktionsrate [1/s] Sessionrate [1/s] Fehler :00 00:20 00:40 01:00 01:20 01:40 02:00 02:20 Zeit [mm:ss] CPU-Last ( busy ): Summe Kernel User Normalbetrieb Beeinträchtigung Überlastung Abbildung 6: Verkehrsmix mit steigendem SYN-Flood-Angriff u. resultierender CPU-Last der Firewall Ergebnisse Auf der Basis der strukturierten Untersuchung entstehen folgende Unterlagen: - bewertete (Vergleichs-)Graphiken zu Durchsatz, Antwortzeiten, Fehler, etc. - Dokumentation der Leistungsgrenzen der Firewall - Benennung von möglichen Engpässen je nach betrieblichem Einsatz - Dokumentation des Schutzverhaltens bei angriffsartigem Verkehr - Performancevergleich mit anderen Systemen Seite 6 / 6