Home

Entwicklung einer allgemeinen Teststrategie für zustandsbehaftete

1. 47 5 1 Entscheidungsarten eines Paketfilters 51 5 2 Arbeitsdaten und mittel der Firewallsoftware 53 7 1 FWTStrategy im Kontext von ISO9646 72 7 2 Beispiel f r die in einem Vektor beschriebenen Informationen 74 7 3 Beispiele und Kategorisierung der Auswertungsfunktionen 77 7 4 Hierarchische Auswertung der Testergebnisse 78 7 5 Beispiel f r die Wahl von Testpunkten 84 8 1 Liste der unterst tzten iptables Merkmale im Prototyp 88 9 1 Auswertung der Testabdeckung f r Beispielkonfigurationen 104 9 2 Potenzial zur Verbesserung der aktiven Testabdeckung 106 9 3 Auflistung der entdeckten Abweichungen im netfilter Verhalten 106 9 4 Anderungen der berg nge in der TCP Zustandsmaschine 107 A 1 Tabellarische Modellierung der netfilter iptables Firewall 126 A 2 Auflistung von netfilter iptables Optionen I 127 A 3 Auflistung von netfilter iptables Optionen I 128 A 4 Konfiguration der virtuellen Switche 134 A 5 Netzwerkeinstellungen der virtuellen Systeme 134 Listings 4 1 Beispiel f r Zustandsinformationen ll 40 4 2 Beispiel f r iptables Zustandsinformationen umformatiert 42 4 3 Beispiel f r IPFW Zustandsinformationen 43 4 4 Beispiele f r IPF Zustandsinformatione
2. Der Advanced Maryland Automatic Network Disc Archiver Amanda ist ein Backup System Siehe http www amanda org f r weitere Informationen Analysiert wurde die Datei linux net ipv4 netfilter ip conntrack proto udp c 96 8 2 Umsetzung der Protokolltests Implementierung der TCP Tests Beim Verwalten einer TCP Verbindung gibt es eine gr ere Menge von Kriterien als bei den anderen Protokollen die ber cksichtigt werden m ssen Aufer IP Adressen und TCP Ports m ssen unterschiedliche Flag Kombinationen sowie die berg nge und Zust nde in der Zustandsmaschine der TCP Zustandsverfolgung siehe Abbil dung 4 10 f r das Erzeugen der TCP Pakete ber cksichtigt werden Die prototypische Implementierung ist nicht in der Lage TCP Verbindungen im RELATED Zustand zu erzeugen da hierf r wie bei UDP die Implementierung von Anwendungsprotokollen notwendig w re Netfilter unterst tzt die Verbindungsver folgung von den teilweise auf TCP basierenden Protokollen H323 FTP PPTP IRC und NetBIOS INVALID Wie bei UDP wird der INVALID Zustand bei TCP mit einem Paket mit einer falschen Pr fsumme erzeugt Die Verbindungsverfolgung ordnet auch bestimmte Flag Kombinationen dem INVALID Zustand zu NEW Der NEW Zustand wird durch ein Paket erzeugt das keiner Assoziation in der Verbindungsverfolgung zugeordnet werden kann Es ist m glich den NEW Zustand mit zahlreichen Flag Kombinationen zu erreichen nicht jede davon l sst sich jedoc
3. BCD04 BG92 BIFABAO3 Al Shaer Ehab S und Hazem H Hamed Firewall policy advisor for anomaly detection and rule editing In Proc IEEE IFIP 8th Int Symp Integrated Network Management IM 2003 2003 pp 17 30 Al Shaer Ehab S und Hazem H Hamed Discovery of policy an omalies in distributed firewalls In INFOCOM 2004 Bd 4 2004 ISBN 0 7803 8355 9 pp 2605 2616 Ayuso Pablo Neira Netfilter s connection tracking system In LOGIN Vol 31 No 3 Juni 2006 pp 34 39 B r Udo OSI Konformit tstests Validierung und qualitative Bewer tung VDI Reihe 10 Nr 270 VDI Verlag GmbH D sseldorf 1994 Bartal Yair u a Firmato A Novel Firewall Management Toolkit In Symposium on Security and Privacy IEEE 00 1999 ISSN 1540 7993 DOI 10 1109 SECPRI 1999 766714 Bastien Greg Earl Carter und Christian Degu CCSP Cisco Secure PIX Firewall Advanced Exam Certification Guide 2 Aufl Cisco Press 2004 ISBN 1 58720 123 2 Baumgarten Bernd und Alfred Giessler OSI Testmethodik und TT CN Berichte der Gesellschaft f r Mathematik und Datenverarbeitung Nr 202 Oldenbourg Verlag M nchen Wien 1992 ISBN 3 486 22410 0 Bibliographisches Institut amp F A Brockhaus AG Mannheim Brock haus Naturwissenschaft und Technik Online Edition Bibliographi sches Institut amp F A Brockhaus AG Mannheim 2003 137 Quellenverzeichnis BS06 BSIO2 BS106 Buc96
4. CF02 CPS03 DH04 EZ01 Gi102 GL05al 138 Von Bidder Senn Diana Specification based Firewall Testing 533 Technischer Report Eidgen ssische Technische Hochschule Z rich Information Security 2006 Bundesamt f r Sicherheit in der Informationstechnik BST Leitfaden zur Einf hrung von Intrusion Detection Systemen Version 1 0 31 Okt 2002 URL http www bsi bund de literat studien ids02 index htm besucht am 23 07 2007 Bundesamt f r Sicherheit in der Informationstechnik IT Grunschutzkataloge M2 338 Erstellung von zielgruppengerechten IT Sicherheitsrichtlinien 2006 URL http www bsi de gshb deutsch m m02338 htm Buchanan Robert W Art of Testing Network Systems New York John Wiley and Sons Inc 1996 ISBN 0471132233 Conoboy Brendan und Erik Fichtner JP Filter Based Firewalls HOWTO Dez 2002 URL http www obfuscation org ipf be sucht am 26 06 2007 Check Point Software Technologies Advanced Technical Reference Guide NG with Application Intelligence CPTS DOC ATRG 01 S NGApplnt Ramat Gan Israel 2003 Du Yong und Daniel Hoffman PBit A Pattern Based Testing Framework for iptables In CNSR 04 Proceedings of the Second Annual Conference on Communication Networks and Services Rese arch CNSR 04 Washington DC USA IEEE Computer Society 2004 ISBN 0 7695 2096 0 DOI 10 1109 DNSR 2004 1344718 pp 107 112 Eronen Pasi und Jukka Zitting
5. 2 Firewalls beide Mengen gleich grof und jedes Element aus Menge A wird statisch und line ar auf ein Element der Menge B abgebildet Sind die Mengen ungleich geschaffen k nnen verschiedene dynamische Abbildungen eingesetzt werden die die gerade un benutzten Elemente ber cksichtigen Dabei gibt es u a Strategien die versuchen e bei SNAT f r ein System immer die gleiche Quelladresse beizubehalten oder e die Abbildung m glichst zuf llig zu w hlen e bei DNAT zu einer Gruppe die Auslastung gleich zu verteilen load balancing Eine besondere Variante der dynamischen source NAPT ist auch als masquarading oder hide NAT bekannt die dazu verhilft den internen Netzaufbau zu verschleiern oder einen privaten Adressraum auf einen ffentlichen Adressraum abzubilden Dabei werden die Quelladresse und port aller durch die Firewall oder den Router ausge henden Pakete durch eine der externen IP Adressen und einen ungenutzten Port des Routers bzw der Firewall selbst ersetzt Die Zuordenbarkeit der Verbindungspartner bleibt aufgrund des eindeutigen ungenutzten lokalen Ports weiterhin erhalten Weitere Szenarien f r die NAT verwendet werden kann sind die Aufl sung von Adresskonflikten und berlappungen von Adressbereichen die Realisierung transpa renter Proxies oder die tempor re Umleitung von Anfragen auf ein anderes System Besonders zu beachten ist dass s mtliche Formen von NAT nicht nur f r die Adres sen im IP Header durchg
6. Syntaxtest Iransaktionsflussbasierter Test Test auf Basis von Entscheidungstabellen und weitere diversifizierend Vergleich der Testergebnisse mehrerer Versionen Regressionstest und weitere Bereichstest Statistischer Test Error guessing Grenzwertanalyse Zusicherungstechniken Aus der gew hlten Pr ftechnik ergibt sich der notwendige Testzugang der den Zu gangspunkt zur Testebene und die zur Testdurchf hrung ben tigte Informationsmen ge beschreibt Dabei werden im Gegensatz zueinander White Box auch Glass Box genannt und Black Box Tests unterschieden Im ersten Fall sind die interne Struk tur und der Inhalt bekannt so dass jeder Ausf hrungspfad gezielt getestet inspiziert oder sogar manipuliert werden kann Diese Methode wird vorzugsweise f r Quellcode Tests benutzt Bei der Black Box Methode k nnen lediglich die Eingabeparameter beeinflusst und die Ausgaben an der externen Schnittstelle eines Systems beobach tet werden Eine Spezifikation der internen Abl ufe oder Strukturen liegt nicht vor Mischformen zwischen den beiden werden auch als Grey Box Tests bezeichnet Alle statischen und manche dynamischen Pr ftechniken z B alle strukturorien tierten Tests bed rfen des Zugangs zum Programmcode und k nnen als White Box Tests klassifiziert werden Die Black Box Testtechniken basieren nicht auf dem Pro grammcode sondern auf Spezifikationen Dazu z hlen u a alle funktionsori
7. 6 Testen rektheit von Systemen und deren Komponenten d h die bereinstimmung der Istei genschaften mit den durch die Spezifikation formal beschriebenen Solleigenschaften best tigt Ein Fehlverhalten das auf einen internen System Fehlzustand hindeutet wird mit Hilfe von Debugging Werkzeugen untersucht Debugging ist das schrittweise und protokollierte Ausf hren eines Programms zum Auffinden der Fehlerquellen und ursachen f r bereits gesichtetes Fehlverhalten von Software Bisher wurde allgemein von Fehlern oder Fehleigenschaften gesprochen Das Insti tute of Electrical and Electronics Engineers IEEE hat in der Softwaretechnik die Begriffe error fault failure und mistake identifiziert und mit den folgenden Definitionen belegt IEE90 failure St rung Fehlerwirkung oder Symptom Eine Fehlerwirkung bedeutet dass die Software sich nicht wie erwartet verh lt und den spezifizierten Dienst nicht erbringen kann Beispiel Programm st rzt aufgrund eines Zugriffs auf einen undefinierten Wert ab error Abweichung oder Fehler Eine Abweichung ist ein Unterschied zwischen einem berechneten beobachteten oder gemessenen und dem spezifizierten oder theoretisch korrekten Wert bzw Zustand Beispiel ein Unterschied von 30 Me tern zwischen einem berechneten und dem korrekten Resultat fault Defekt Mangel oder Fehlerzustand Ein Defekt ist eine inkorrekte An weisung oder ein Datum das durch eine
8. 80 80 assoc UTR REL await prerouting nat 130 A 2 Schnittstelle zum FWA LOG log prefix foo bar DNAT to destination 10 0 0 4 8080 1 mangle LOG log prefix foo bar MARK set mark 42 bs forward filter ACCEPT Ys postrouting mat ACCEPT Is hs linepath 5 11 6 3 JE usos Listing A 3 Vektorbeispiele Zur Bedeutung der einzelnen Bezeichner progress_idx Nummer der Berechnung des Testvektors im FWA Die Nummer kann mehrfach vergeben worden sein und kann nicht als eindeutige Referenz auf den Vektor verwendet werden proto Bereich von bis der Protokolle route Senderichtung und ziel des Paketes aus Sicht der Firewall dir angesprochene Kette Chain im Netfilter sip Bereich von bis der Quelladressen dip Bereich von bis der Zieladressen assoc Bereich der Verbindungszust nde await Die kumulierten erwarteten Reaktionen der Firewall linepath Liste von Zeilennummern aus denen der Vektor generiert wurde Dazu kommen noch protokollabh ngige Angaben wie ICMP Type bzw Code itype und icode Quell und Zielports f r TCP und UDP sport und dport sowie f r TCP zus tzlich noch die Flags tflags 131 Anhang A Anhang Die Datenstrukturen der einzelnen Vektoren werden beim Interpretieren
9. Liefert den aktuellen Zustand zur ck getStates Liefert eine Liste aller definierten Zust nde zur ck getStateTrans name Liefert die definierten Transititionen ausgehend von dem Zustand name zur ck 93 8 Proof of concept 8 1 3 Beschreibung des Probanden Obwohl der Firewall Analyzer aktuell nur eine Konfigurationssprache unterst tzt setzt FW TStrategy laut Aufgabenstellung eine allgemeine Teststrategie die sich an die Merkmale einer konkreten Firewall anpassen und konfigurieren l sst um Die eigentlichen Ausgaben vom FWA sind selbstbeschreibend und abstrakt gehalten so dass auch andere Firewalls in Zukunft damit beschrieben werden k nnen Beim Ein lesen der Daten und der Einstellung der Teststrategie auf das jeweilige Modell muss den Bezeichnern jedoch eine Semantik zugeordnet werden Diese produktspezifischen Eigenschaften m ssen deswegen entsprechend beschrieben werden Unter den ben tigten Informationen wurden die Gruppen Verbindungsverfolgung NAT Einstellungen Routing und die Zuordnung von Ports zu durchgef hrten An wendungsinspektionen identifiziert Letztere sind notwendig um bei tieferen Unter suchungen des Paketfilters deep inspection zumindest korrekte Musterpakete auf Anwendungsebene erstellen oder bei Misserfolg den Benutzer ausf hrlicher informie ren zu k nnen Im Prototyp wird bei TCP Verbindungen maximal ein vollst ndiger TCP Handshake ausgef hrt bei dem keine Daten ausgetauscht werden d
10. hs Manual Config descr E FWTest fw model FWTStrategy je Abbildung 7 2 Interaktion der Komponenten in FWTStrategy 7 1 Vereinfachter Testablauf f r einen Testpunkt In diesem Abschnitt wird die Teststrategie entwickelt Zuerst wird ein vereinfachter Testablauf diskutiert der einen Test f r einen einzigen Testpunkt durchf hrt Die ses Vorgehen wird analysiert um das Prinzip eines solchen Tests in Abschnitt 7 2 auf eine ganze Testreihe zu bertragen Dabei werden die Probleme einer direkten bertragung aufgezeigt um im folgenden Abschnitt die gew hlte L sung mit den Optimierungen vorzustellen Die konkrete Umsetzung der dort behandelten Algo rithmen wird in Kapitel 8 besprochen Ausgehend von der Abbildung 7 1 kann die Teststrategie in mehrere Schritte un terteilt werden in denen die Aufgaben e Eingabe eines Testpunktes e Einstellung der Teststrategie auf den Probanden e Vorbereitung des Probanden f r den Test 73 7 Allgemeine Teststrategie e Durchf hrung und Auswertung des Tests und e Bericht an den Benutzer gel st werden m ssen Der FWA bernimmt die Analyse des Regelwerkes und gibt der Teststrategie die zu testenden Bereiche vor In der weiteren Betrachtung wird nur von einem Vektor ausgegangen der den zu testenden Bereich beschreibt Tabelle 7 2 zeigt eine v
11. technical Commission International Standard ISO IEC 7498 1 1994 Information Technology Open Systems Interconnection Basic Re ference Model The Basic Model 1994 139 Quellenverzeichnis ISO9126 JWO1 Lig02 LLBO2 MK05 MWZO0 MWZO5 Pru04 Ran05 RFC792 RFC950 140 International Organization for Standardization International Electro technical Commission International Standard ISO IEC 9126 Infor mation Technology Software product evaluation Quality characte ristics and guidelines for their use 1991 J rjens Jan und Guido Wimmel Specification Based Testing of Fi rewalls In PST 02 Revised Papers from the 4th International Andrei Ershov Memorial Conference om Perspectives of System Informatics Bd LNCS 2244 2001 Lecture Notes in Computer Science Berlin Heidelberg Germany Springer Verlag 2001 ISBN 3 540 43075 X pp 308 316 Liggesmeyer Peter Software Qualit t Testen Analysieren und Ve rifizieren von Software Spektrum Akademischer Verlag 2002 ISBN 978 3827411181 Lidl Kurt J Deborah G Lidl und Paul R Borman Flexible Packet Filtering Providing a Rich Toolbox In BSDCon San Francisco USA 2002 URL http www pix net software ipfw ipfw pdf Marmorstein Robert und Phil Kearns ITVal A Tool for Auto mated IPtables Firewall Analysis In USENIX Annual Technical Conference Anaheim CA USA 2005 pp 71 81 U
12. An expert system for analyzing firewall rules In Proceedings of the 6th Nordic Workshop om Se cure IT Systems Technical Report IMM TR 2001 14 Copenhagen Denmark Technical University of Denmark 2001 pp 100 107 URL http citeseer ist psu edu eronenOlexpert html Gill Stephen Maximizing Firewall Availability Techniques on Im proving Resilience to Session Table DoS Attacks Technischer Report 2002 Gouda Mohamed G und Alex X Liu A Model of Stateful Firewalls and Its Properties In DSN 05 Proceedings of the 2005 International Conference on Dependable Systems and Networks Washington DC USA IEEE Computer Society 2005 ISBN 0 7695 2282 3 Dor 10 1109 DSN 2005 9 pp 128 137 GLO5b GS98 Gut97 Hae97 HPS03 HY05 TEE90 F02 IHAS05 ISO7498 1 Gouda Mohamed G und Alex X Liu Complete Redundancy Detec tion in Firewalls In Data and Applications Security XIX Bd LNCS 3654 2005 Lecture Notes in Computer Science Springer Berlin Hei delberg 2005 ISBN 978 3 540 28138 2 DOI 10 1007 11535706 pp 193 206 Goldsmith David und Michael Schiffman Firewalking Okt 1998 URL http www packetfactory net projects firewalk firewalk final pdf besucht am 23 07 2007 Guttman J D Filtering postures local enforcement for global poli cies In SP 97 Proceedings of the 1997 IEEE Symposium on Security and Privacy Washington DC USA IEEE Comp
13. Mechanismen auf die darauf folgenden In diesem Abschnitt wurden die sechs ausgesuchten Firewalls netfilter iptables IP FireWall IPFilter Packet Filter PIX und FireWall 1 anhand der Dokumen tation und sofern vorhanden anhand des Quellcodes analysiert Die identifizierten Paketfl sse werden beschrieben und grafisch repr sentiert F r die Darstellung der Funktionsbl cke werden in Abbildung 4 1 Symbole eingef hrt die f r die unterschie denen Funktionstypen verwendet werden netfilter iptables Die Grundidee des netfilter Frameworks basiert auf der Einf hrung von f nf Zu griffspunkten hooks in verschiedenen Phasen der Verarbeitung von Paketen im Netzwerkstack die in Abbildung 4 2 zu sehen sind Ein vom Netzwerkadapter oder F r eine ausf hrliche Betrachtung des netfilter Frameworks siehe Ayu06 Spe06 RW02 29 4 Funktionsweise der Paketfilter a Kernfunktion des b Zusatzfunktion Paketfilters im Paketfluss state operation c Zustandsabfrage d Zustandsmodifi kation anlegen aktualisieren anwenden l schen Abbildung 4 1 Symbole f r Kern und Zusatzfunktionen im Paketfluss vom lokalen System kommendes Paket kann somit einen von drei m glichen Wegen durch die Netzwerkbehandlungsroutinen nehmen Ein ankommendes Paket betritt das System ber PREROUTING wonach die routing Entscheidung getroffen wird Ist das Paket f r das lokale System bestimmt so geht es weiter zum Punkt
14. PREROUTING nat ACCEPT forward KERNEL route PREROUTING nat DNAT forward KERNEL route PREROUTING nat DROP stop PREROUTING nat LOG non term continue PREROUTING nat NETMAP forward KERNEL route PREROUTING nat REDIRECT forward KERNEL route PREROUTING nat ULOG non term continue INPUT filter ACCEPT forward INPUT mangle INPUT filter DROP stop INPUT filter LOG non term continue INPUT filter REJECT stop INPUT filter ULOG non term continue INPUT mangle ACCEPT forward KERNEL INPUT mangle CONNMARK non term continue INPUT mangle CONNSECMARK non term continue INPUT mangle DROP stop INPUT mangle DSCP non term continue INPUT mangle ECN non term continue INPUT mangle LOG non term continue INPUT mangle MARK non term continue INPUT mangle SECMARK non term continue INPUT mangle TOS non term continue INPUT mangle TTL non term continue 124 A 1 Modellierung von netfilter iptables phase chain task type next processing point INPUT mangle ULOG non term continue FORWARD mangle ACCEPT forward FORWARDfFf filtering FORWARD mangle CLASSIFY non term continue FORWARD mangle CONNMARK non term continue FORWARD mangle CONNSECMARK non term continue FORWARD mangle DROP stop FORWARD mangle DSCP non term continue FORWARD mangle ECN non term continue FORWARD mangle LOG non term continue FORWARD mangle MARK non term continue FORWARD mangle SECMARK non term continue FORWARD mangle TCPMSS non term continue FORWARD mangle TOS non
15. Vernetzungsmerkmale Die kommerziellen Systeme unterscheiden sich in der Schwerpunktsetzung auf ent weder Routing mit Firewallf higkeiten oder Firewall mit Routingf higkeiten Neben statischem IP Routing beherrschen die untersuchten Firewallsysteme auch dynamische Routingtabellen mittels der Routingprotokolle OSPF BGP oder RIP Besondere Routingvarianten wie policy based routing PBR also das Weiterleiten von Paketen basierend auf weiteren Merkmalen wie Quelladresse oder Zielport oder redundante Routen die gew hlt werden wenn die prim re Verbindung nicht verf gbar ist sind eingeschr nkt bei manchen Produkten verf gbar NAT wird von allen Systemen unterst tzt die Anzahl der verf gbaren Strategien bei dynamischem NAT unterscheidet sich jedoch Weiterhin sind die unterst tzten NAT Arten f r Anwendungsprotokolle ein Unterscheidungsmerkmal IPFW ben tigt f r NAT bei FreeBSD Versionen bis einschlieflich 6 2 ein separates Programm natd das an jeder beliebigen Stelle im Regelwerk ber die divert Schnittstelle aufgerufen werden kann In der Version 7 0 wurde die NAT Unterst tzung im Kernel realisiert Bei IPFilter wird NAT ebenfalls ber ein gesondertes Regelwerk und das Kom mandozeilenprogramm ipnat gesteuert Dabei unterst tzt es neben source und des tination NAT auch ausgefallenere Varianten von dynamischem NAPT bei dem auch individuelle Portbereiche ICMP ID bersetzung ein Round Robin Verfahren bzw Cisco
16. bernehmen Im Gegensatz zum Kernel Routing kann die Fire wall zahlreiche zus tzliche Entscheidungskriterien zum Routing ermitteln die auch f r ihre Filterfunktion notwendig sind Damit stellt sie ein m chtiges Routingwerk zeug zur Verf gung Der vorgegebene Datenfluss einer Firewall kann sich jedoch einschr nkend auf die Routing M glichkeiten auswirken wenn das Netzwerkstapel Routing nicht umgangen werden kann 5 3 Anwendung auf den Paketfilter netfilter iptables In diesem Abschnitt wird die eingef hrte Modellierung beispielhaft auf netfilter ipta bles angewendet In Abschnitt 3 3 wurde dieser Paketfilter bereits als funktionell ver gleichbar mit den anderen Paketfiltern ermittelt Aufgrund seiner modularen Struk tur und der M glichkeit alle Regeln explizit zu formulieren lassen sich die Abl ufe und Funktionen der anderen Paketfilter nachbilden Bei der Nutzung der Zustandseintr ge konnten zwei Varianten identifiziert werden die fest eingestellte Abfrage die einer Designentscheidung folgt und die explizite Abfrage durch eine benutzerdefinierte Regel wie es bei iptables mit den Verbin dungseintr gen der Fall ist Erstere wird von mehreren Firewalls zur Reduzierung der ben tigten Abfragen f r akzeptierte Assoziationen fest vorgegeben Hier hat der Benutzer kaum Einfluss auf die Reglementierung der Pakete die einer bestehenden Assoziation zugeordnet werden Bei iptables l t sich sowohl eine fr he Entscheidung f r bekan
17. berpr fen k nnen Durch das einge setzte CASE Werkzeug ist die Methode flexibel und einfach zu benutzen Fragw rdig an dieser Arbeit ist jedoch wann und von wem diese CASE Spezifikation erzeugt und vor allem synchron mit der Netzwerkumgebung gehalten werden soll Auch wird nicht beschrieben wie die Pakete zur berpr fung der Testf lle erzeugt bertragen und getestet werden Aus Sicht des Autors fehlt auch eine Stellungnahme zum Testen von zustandsbehafteten Paketfiltern Untersuchung der Sicherheitsrichtlinien Diana von Bidder Senn BS06 zeigt eine formelle Beschreibung f r die Sicherheits richtlinien eines Netzwerks auf aus der automatisch Testf lle generiert werden k nnen die ein eingesetztes System testen k nnen Somit wird die Konformit t eines Regel werks zu einer aufgeschriebenen Richtlinie berpr ft Die Sicherheitsrichtlinie wird im Sinne eines Zugriffsmodells also wer darf wo auf was zugreifen verstanden Die generierten Testf lle h ngen stark von der organisationsspezifischen Umgebung ab k nnen aber laut Von Bidder Senn Fehler sowohl in der Konfiguration selbst wie auch in der eingesetzten Firewall aufsp ren Bei den Tests wird die Firewall als Black Box betrachtet und die Protokollfl sse allein aufgrund der Spezifikation der Kommunikati on zwischen den Endpunkten hergestellt F r die Betrachtung der Eignung dieses An satzes wurde aus der Protokollspezifikation f r TCP ein Automat f r den Zwischen punkt ab
18. chst m gliche Anwendungsf lle vorgestellt um die praktische Relevanz der Teststrategie zu belegen In Abschnitt 9 2 wird die Untersuchung mehrerer Kon figurationen als Beispiel der Testabdeckung vorgestellt Erkenntnisse aus der Unter suchung des iptables Paketfilters werden in Abschnitt 9 3 aufgezeigt Kapitel 10 vergleicht die erarbeitete L sung mit anderen Arbeiten In Abschnitt 10 1 wird die Implementierung der Teststrategie mit anderen Werkzeugen verglichen Ab schnitt 10 2 dagegen stellt die gesamte Arbeit in den Kontext anderer wissenschaft licher Untersuchungen Am Ende werden sowohl die Teststrategie als Konzept als auch FW TStrategy als Werkeug bewertet Eine Zusammenfassung der Arbeit und ein Ausblick auf m gliche Fortf hrung der Arbeit bzw der Untersuchung werden in Kapitel 11 behandelt 2 Firewalls Die vorliegende Arbeit besch ftigt sich mit der Untersuchung von zustandsbehaf teten Paketfiltern Daf r ist es notwendig diese Klasse von Netzwerkger ten genau zu erfassen und von anderen Ger ten abzugrenzen In diesem Kapitel werden zwei Aspekte vorgestellt die zur Klassifizierung der Netzwerkger te und deren Merkmale verwendet werden In Abschnitt 2 1 werden verschiedene Netzwerkger te und deren Funktionen ein gef hrt Darunter werden verschiedene Firewalltypen also Netzwerkknoten mit Schutz aufgaben betrachtet Abschnitt 2 2 stellt allgemeine Sicherheitsziele der Informationssicherheit sowie die speziellen Bed
19. schiedlichen logischen Phasen innerhalb dieser Methoden auf die eine Konfiguration oder der Benutzer nur indirekt Einfluss hat local processes queue a loggin e gging I filter Le Ere Hyves EN eae ais kernel routing decision oy a EEE Cr SE 2 CREE 1 FAQ M E EE 1 ks 5 c mangle I mangle Q mangle I d I s 3 Be eR ERAS DRE i filter 5 filter Q d E aaa NT A O Hago ae a rd e PA mangle re routing I x i filter P Ox T aff re Q to devices i Abbildung 4 4 Paketfl sse durch BSD OS IPFW output Alle Pakete wurden zun chst in der pre input Phase behandelt wo sie ver ndert werden durften Anschlie end wurde beim Routing festgestellt ob ein Paket f r das lokale System bestimmt war oder weitergeleitet werden sollte Die lokalen Pakete konnten in der input Phase gefiltert geloggt und an Benutzerprogramme weiter gereicht werden Pakete die weitergeleitet wurden konnten in den forward und pre output Phasen gefiltert oder erneut ver ndert bzw umadressiert werden Hier sollte aber die Umadressierung nicht mehr dazu f hren das Paket f r das lokale System zu bestimmen F r lokal erstellte Pakete wurde zun chst beim Routing ei ne ausgehende Netzwerkschnittstelle und der n chste Hop bestimmt bevor sie im pre output ver ndert und gefiltert werden kon
20. tersucht werden ob der Testraum bzw die Testgranularit t reduziert werden k nnen ob alle Variationen auch tats chlich an dem Testger t getestet werden k nnen ob zustandsbehaftete Testf lle aufeinander aufbauen k nnen statt jeden Testfall ein zeln zu betrachten und ob bestimmte Tests parallel ausgef hrt werden k nnen um Arbeitspausen zu vermeiden Die Aufgabenstellung bezieht sich auf die berpr fung von spezifikationskonfor men Protokollfl ssen unter Realbedingungen wodurch die m glichen Variationen eines Paketes reduziert werden k nnen da die Anwendung der Spezifikationen die Die genannten 40 byte ergeben sich aus den Mindesl ngen der TCP und IPv4 Header die jeweils 20 byte betragen Bei Ber cksichtigung der weiteren Nutzlast k nnte die L nge bis auf 1500 byte erweitert werden was der maximale L nge eines ber Ethernet verschickten Datagrams entspricht 66 6 4 Reduzierung des Testraums Pakete mit einer Semantik belegt die eingehalten werden muss Bei Ber cksichtigung der Spezifikationen ist es nicht sinnvoll alle m glichen Bitmuster tats chlich zu tes ten Werte au erhalb der Spezifikation die dazu f hren k nnen dass das Paket nicht interpretiert werden kann k nnen nur direkt am Probanden ber entsprechende Sti mulatoren eingegeben werden Andernfalls w rden sie von dazwischen liegenden ver mittelnden Knoten oder von den tieferen Protokollschichten im Probanden verworfen werden Leider be
21. werden erreicht werden 8 1 Modulkonzept Die Vektoren werden vom FWA bereits als Pythonstrukturen ausgegeben die in der Teststeuerung direkt eingelesen und interpretiert werden k nnen Das genaue Format dieser Datei ist im Anhang in Abschnitt A 2 dokumentiert FWTStrategy nutzt die Beschreibung des Paketflusses und der Firewallaktionen f r die Zuordnung der symbolischen Aktionsbezeichner die vom FWA bergeben werden zu den firewallabh ngigen Funktionen Dazu werden die Aktionen entsprechend der Tabelle 5 2 in die Klassen NAT mo dify filter inspect route handle fragment und handle state eingeteilt f r die jeweils 88 8 1 Modulkonzept spezialisierte Funktionsmodule implementiert werden Sie sind einerseits f r die Ab bildung der Vektoren in Paketeigenschaften aber auch f r die anschlie ende Auswer tung der empfangenen Pakete verantwortlich Die Definition der Aktionen kann daf r verwendet werden die Berechnungen f r terminierende Pfade vorzeitig zu beenden um Ressourcen zu sparen o un gt ee ticketing veclib Nr ass Se ny ta Conf A auaa LA add femal a a ash ali h at an yas aana a 7 testICMP i bitVector 1 F gt l FWTStrategy testUDP pdulib TreeNode 7 testTCP l gt conntrackFSM R on en 3 A GEN PktCompare lt 4 interpret netfilterLib Abbildung 8 1 Modularchitektur der
22. 1 Modellierung von netfilter iptables sn A2 Schnittstelle zum FWA 2 2 22 eo geek oe tere er A9 Benutzerhandbuch 6r uer Se tet NE hee BE Ar u 3 Quellenverzeichnis vi 101 101 104 106 109 109 111 116 119 123 124 129 133 137 Abbildungsverzeichnis ok 22s 2 3 3 1 4 1 4 2 4 3 4 4 4 5 4 6 4 7 4 8 4 9 4 10 5 1 5 2 5 3 5 4 5 5 5 6 6 1 6 2 6 3 6 4 6 5 6 6 T Ge 7 3 8 1 8 2 8 3 Das OSI und das TCP IP Referenzmodell im Vergleich Firewall Betriebsmodi im Vergleich Hierarchischer Aufbau von Richtlinien Schutzvarianten gegen SYN Flooding Symbole f r Kern und Zusatzfunktionen im Paketfluss Entscheidungspunkte f r den Paketfluss bei iptables Paketfl sse durch FreeBSD IPFW Paketfl sse durch BSD OS IPFW Paketfl sse durch IPFilter Paketfl sse durch die PF Firewall Paketfl sse durch die Cisco PIX Paketfl sse durch FW 1 Uneindeutige Situationen im vermittelndem Knoten B Darstellung der iptables TCP Zustandsmaschine 2 2 2 2 Zwei Modelle der Paketverarbeitungsphasen Verzweigungsarten bei der Regelauswertung Ergebnistypen der Firewal Anweisungen Symbole zur Modellierung der Arbeitsschritte Zwei Modellierungen der NAT Funktion Modellierung der Paketfl sse bei
23. 1 einzeln modelliert Die Modellierung wird in Abschnitt 5 2 auf besondere Funktionen und in Abschnitt 5 3 auf einen ausgew hlten Paketfilter angewendet Kapitel 6 f hrt in den zweiten Aspekt das Testen ein Dort werden allgemeine netzwerk und firewallspezifische Konzepte und Methoden des Testens vorgestellt Eine Teststrategie f r die zuvor modellierten Paketfilter wird in Kapitel 7 erar beitet Sie wird in Form einer Teststeuerung unter der Bezeichnung FW TStrategy realisiert Zun chst werden die Anforderungen an die Teststrategie und die Vorbe dingungen f r die Entwicklung behandelt Dabei wird das Konzept in den Kontext der Testmethodologie gestellt und neue Begrifflichkeiten eingef hrt Die Teststrate gie wird in mehreren Schritten entwickelt In Abschnitt 7 1 wird mit den Test eines einzelnen Testvektors begonnen was in Abschnitt 7 2 auf eine vollst ndige und op timierte Teststrategie bertragen wird Auf die Umsetzung der Teststrategie wird in Kapitel 8 eingegangen das die ben tigte Beschreibung des Probanden f r die Testkonfiguration und das Modulkonzept des Programms beschreibt Abschnitt 8 2 dokumentiert die konkrete Umsetzung und die aufgetretenen Probleme der jeweiligen Tests Einen Ausblick auf k nftige Erweite rungen der Teststeuerung gibt Abschnitt 8 3 Die gesammelten Ergebnisse aus der Entwicklung und Anwendung verschiedener Testreihen mit dem erstellten Prototypen werden in Kapitel 9 beschrieben Dabei werden zun
24. 201 testbare Vorgeschichten abgeleitet 388 Testf lle zeigten eine erwartete Reaktion und 14 Testf lle eine unerwartete 135 4 10 30 32 34 36 38 40 44 46 48 50 Anhang A Anhang Execute vector list from file udp vec testpath of vectors 6 16 10 testpoint 1 OK OK vector 6 A2B UDP NEW ACCEPT ed as expected Linepath to rule 21 10 1 0 1 gt 10 130 0 1 port 67 67 OK vector 16 B2A UDP EST ACCEPT ed as expected Linepath to rule 21 10 130 0 1 gt 10 1 0 1 port 67 67 OK Sent Packet IP UDP 10 1 0 1 bootps gt 10 130 0 1 bootps Raw Receiver side UDP packet Modified Fields IP TTL UDP K Linepath to rule 21 18 vector 10 A2B ICMP REL DROP ed as expected testpoint 2 OK OK OK 10 1 0 1 210 130 0 1 iType iCode 3 0 OK 10 1 0 1 210 130 0 1 iType iCode 3 15 OK 10 1 0 1 210 130 0 1 iType iCode 12 0 OK 10 1 0 1 210 130 0 1 iType iCode 12 1 OK vector 6 A2B UDP NEW ACCEPT ed as expected vector 16 B2A UDP EST ACCEPT ed as expected vector 10 A2B ICMP REL DROP ed as expected vectors 296 testcases skipped skipped skipped skipped skipped skipped skipped skipped skipped skipped skipped testpath skipped skipped skipped skipped 78
25. 26 06 2007 Biondi Philippe Scapy URL http www secdev org projects scapy besucht am 26 06 2007 Combs Gerald u a Wireshark URL http www wireshark org besucht am 26 06 2007 143 Erkl rung Die selbstst ndige und eigenh ndige Anfertigung versichere ich an Eides statt Ort Datum Unterschrift 145
26. 651 45 Tabelle 7 4 Hierarchische Auswertung der Testergebnisse den evtl auftretende Probleme identifiziert die im folgenden Abschnitt in eine neue Teststrategie umgesetzt werden Im Gegensatz zum einzelnen Vektor m ssen nun die Vektoren f r den vollst ndigen Testraum eingelesen und eventuell in ein internes Format der FW TStrategy gewan delt werden Sofern m glich soll hier eine Pr fung der Konsistenz der Daten gesche hen bevor die aufwendigen Tests beginnen FW TStrategy muss zus tzlich sicherstel len dass alle ben tigten Strukturen tats chlich vorhanden sind und nicht z B eine ltere Version des Dateiformats oder gar eine unbekannte Datei eingelesen wurde Durch die vergr ferte Anzahl der Testvektoren muss nun eine Testreihenfolge be stimmt werden Hier wird der einfachste Fall betrachtet bei dem die Vektoren in der Eingabereihenfolge getestet werden Die Herstellung des Kontextes f r einen Testpunkt im h heren Zustand setzt vor aus dass der Paketfluss der Vorgeschichte vom Paketfilter akzeptiert und weitergelei tet wird Dabei wird von der Verbindungsverfolgung des Probanden ein Zustandsein trag f r diesen Testpunkt vorgenommen der f r einen protokollabh ngigen Zeitraum gespeichert wird Die Testpunkte der Vorgeschichte sind aufgrund der Vollst ndigkeit des aufgespannten Testraums ebenfalls durch Vektoren beschrieben was dazu f hrt dass sie unabh ngig von dem h heren Zustand zu einem anderen Zeitpunkt ber
27. Adressierung Quell IP und port Ziel IP und port Schnittstellen Zustand aktuell gesamt Speicherbeh lternummer Protokoll IP Version Protokollnummer IP IP Optionen TTL TCP aktuelle und Start Sequenznummern TCP Window Window Scale ISN Offsets Flags ICMP Typ und Code Filter pass block Regeloptionen Statistik Paket und Bytez hler in out Flags Sync Status Markierungen Tabelle 4 1 Zusammenfassung der Zustandsinformationen bei ipfstat PF Packet Filter Die Dokumentation zum Kontrollprogramm pfctl zeigt viele Beispiele zur Anzeige und Auswertung der umfangreich gesammelten Zustandsdaten Neben den aktiven 44 4 2 Zustandsbehaftete Verbindungsverfolgung NAT Regeln den Eintr gen in der Zustands und der source tracking Tabelle werden auch viele Accounting Daten gesammelt Diese k nnen nach NAT nach geladenen Queues nach Filterregel nach Tabelle nach Markierung und nach Netzwerkschnitt stelle aufgeschl sselt werden Ein Ausschnitt der Zustandstabelle ist in Listing 4 5 zu sehen und die m glichen Zust nde sind in Tabelle 4 2 aufgeschl sselt self icmp 10 0 1 2 2755 10 0 1 1 0 0 self tcp 127 0 0 1 113 127 0 0 1 54358 TIME WAIT TIME WAIT self tcp 127 0 0 1 54358 127 0 0 1 113 CLOSED SYN SENT self tcp 10 0 1 2 22 10 0 1 4 33905 EST EST self udp 255 255 255 255 138 10 0 1 2 138 NO TRAFFIC SINGLE self udp 10 0 1 2 10318 10 0 1 21 7594 MULTIPLE MULTI
28. Sichtweise des Paketfilters auf den Protokollfluss eingenommen um gezielt die in der Konfiguration beschriebenen 117 10 Bewertung und Vergleich und vom Paketfilter untersuchten Merkmale des Protokollflusses herzustellen und mit der postulierten Reaktion zu vergleichen Genau wie Von Bidder Senn Kap 5 1 und 5 3 wurde dabei festgestellt dass sich die Sicht des Paketfilters auf die Protokoll fl sse von der strikten Auslegung der Protokollspezifikation unterscheidet und diese Abweichungen nicht formal dokumentiert sind Deswegen m ssen sie rekonstruiert werden Die Analyse der ausgew hlten Paketfilter und die darauf aufbauende Ent wicklung eines Modells zum Beschreiben des Paketfilter in der vorliegenden Arbeit stellen die Voraussetzung f r einen Test zum berpr fen der Paketfilterkonfiguration dar Das entwickelte Werkzeug FW T Strategy setzt eine solche Teststrategie proto typisch um Als vergleichbare Testwerkzeuge k men Blowtorch FTester und fwtest von der ETH Z rich in Frage Blowtorch bietet ein m chtiges aber auch komplexes Frame work an was sich durch die Implementierung in der Sprache C nur schwer vom Endbenutzer anpassen lie e Leider konnte auch neben dem vorgestellten Bericht keine weitere Quelle f r eine Evaluation gefunden werden F Tester ist zwar in einer Scripting Sprache implementiert ist aber nur durch eine statische Konfigurationsda tei zu steuern und erlaubt nur sehr einfache Manipulationen des Pake
29. Switches und WLAN Access Points geh ren werden nur zur Abgrenzung genannt Router arbeiten auf Schicht 3 und besitzen f r jedes angeschlossene Netz eine zumindest logische Schnittstelle um zwischen den Netzen zu vermitteln Die Wei terleitungsregeln f r die Adressaten werden einer Routingtabelle entnommen Router arbeiten medienunabh ngig und k nnen an den Schnittstellen unterschiedliche Netz 2 Firewalls 7 Application 6 Presentation Application 4 5 Session 4 Transport H Transport 3 d Network Internet 2 2 Data Link Network Access 1 1 Physical OSI Model TCP IP Model Abbildung 2 1 Das OSI und das TCP IP Referenzmodell im Vergleich techniken verwenden Daf r m ssen aber die weiterzuleitenden Protokolle der Schicht 3 bekannt sein weswegen Router protokollabh ngig arbeiten Ein Router der mehre re Protokolle weiterleiten kann z B IP und IPX wird auch Multi Protocol Router genannt Gateways werden im allgemeinen Sprachgebrauch oftmals mit Routern gleichge setzt obwohl ein Gateway im Gegensatz zum Router auf allen Schichten implemen tiert werden kann und in der Lage ist auch zwischen verschiedenen Protokollen zu vermitteln Dementsprechend lautet die deutsche Bezeichnung auch Protokollum setzer In einigen Betriebssystemen wird die IP Adresse des default routers auch als Gateway bezeichnet In dieser Arbeit wird Gateway im Sinne der ersten Defin
30. Timeout gesteuerten Uberg ngen Abbildung 4 10 Darstellung der iptables TCP Zustandsmaschine Das m chtigere Modul conntrack erm glicht es zus tzlich Pakete bei denen SN AT oder DNAT angewendet wurde sowie die detaillierten internen Zust nde EXPECTED UNREPLIED ASSURED NONE der jeweiligen Protokoll Zustandsmaschine zur Ver bindungsverfolgung abzufragen F r die komplexere Zustandsmaschine von TCP sind die g ltigen berg nge in Abbildung 4 10 dargestellt Bei den Transitionen werden drei Typen unterschieden ein Zustands bergang aufgrund einer validen Eingabe Die Abbildung basiert auf der Analyse des Quellcodes von linux net ipv4 netfilter ip_ conntrack proto tcp c Version 2 2 in Linux 2 6 20 A 4 Funktionsweise der Paketfilter kein Zustands bergang f r ignorierte Eingaben und kein Zustands bergang bei in validen Eingaben Der Unterschied zwischen validen und ignorierten Eingaben ist dass erstere eine Erneuerung des mit dem Zustand verkn pften Timeouts bewirken wogegen die ignorierten Eingaben die Eingabe akzeptieren aber den Timeout nicht ver ndern Die TCP Flags PUSH und URGENT werden bei den berg ngen zwischen den Zust nden nur indirekt bei iptables ber cksichtigt da alle gesetzten Flags mit ei ner Tabelle von validen Kombinationen verglichen wird bei der auch PUSH und URGENT eingetragen sind Eine solche Zustandsmaschine konnte nur bei netfilter identifiziert werden Bei den anderen drei
31. Zwei Modellierungen der NAT Funktion hnlich zu der NAT Funktion mit Zustandseintr gen kann die Speicherung von Fragmenten mittels keep frags bei IPFilter modelliert werden Hierbei wird relativ 54 5 3 Anwendung auf den Paketfilter netfilter iptables fr h im Datenfluss ein Zustandseintrag abgefragt der beim Evaluieren einer entspre chenden Filterregel f r das erste Fragment im neuen Kontext angelegt wurde Bei einer bereinstimmung mit dem gespeicherten Zustand wird die erneute Auswertung des Regelwerks bersprungen Mithilfe der gew hlten Modellierung lassen sich auch die verschiedenen Routingar ten zusammenfassen und zu den Firewall Funktionen aufnehmen Klassisches Rou ting wird vom Netzwerkstapel bzw Kernel erledigt und basiert lediglich auf der Ziel Adresse Daneben existieren auch m chtigere Routingvarianten wie policy based rou ting PBR also das Routing aufgrund von Quell Adresse Ports oder Anwendungs schichtprotokoll sowie Load Balancing als Speziallfall des Routings Sie alle greifen auf eine Routingtabelle oder ein Regelwerk zu ermitteln den n chsten Vermittlungs punkt sowie den ausgehenden Netzwerkadapter und tragen diese Informationen in den Paketverwaltungsblock ein Somit ist dieses Vorgehen von den Arbeitsschritten her nicht anders als die bereits vorgestellten Paketmodifikationen und markierungen Deswegen k nnen mehrere der untersuchten Firewalls Routingaufgaben unterst tzen oder sogar komplett
32. aufschl sselt Die genaue Form und Bedeutung der Ausgaben wird im Benutzerhandbuch in Abschnitt A 3 beschrieben Offene Verbindungen behandeln Beim Umgang mit verbrannten Testpunkten sind zwei Szenarien zu unterschei den die gegenseitige Beeinflussung von Tests innerhalb einer und zwischen mehreren Programmausf hrungen Nachdem der letzte Test gelaufen und ausgewertet ist kann es passieren dass aus den vorangegangenen Tests noch Kontextinformationen auf der Firewall vorhan den sind die einen weiteren Testlauf beeinflussen k nnten Diese Informationen sind ebenfalls im Ticket System gespeichert und k nnen ausgewertet werden F r verbin dungsorientierte Protokolle wie TCP k nnen diese Informationen dazu genutzt wer den die noch aktiven Verbindungen zu beenden F r alle anderen Protokolle m ssen diese Informationen persistent gespeichert werden so dass sie beim Neustart von FWTStrategy eingelesen und gegebenenfalls ber cksichtigt werden k nnen Dadurch wird die Wiederholbarkeit der Tests gew hrleistet Die Parametrisierung der Testf lle muss zwischen den Testl ufen identisch bleiben Die L sung der Anforderung ist durch das Anlegen einer Logdatei zum anschliefen den Einlesen trivial zu l sen 86 8 Proof of concept Im vorherigen Kapitel wurde die Teststrategie konzeptionell erarbeitet Diese Vor berlegungen wurden in einem proof of concept prototypisch f r den Paketfilter net filter iptables umgesetzt Dur
33. automatisch die Hin und die R ckrichtung reserviert Die Reservierungen werden an die Timeouts der jeweiligen Zustandsverfolgung ge kn pft und erst nach Ablauf des Timeouts wieder frei gegeben F r verbindungsori entierte Protokolle wie TCP kann der finale Timeout durch einen Verbindungsabbau verk rzt werden bei anderen Protokollen muss jedoch abgewartet werden Zum Registrieren einer Verbindung und dem Ausstellen der Tickets m ssen aus den im Vektor noch als Bereiche angegebenen IP Adressen und Ports konkrete Wer te aus den Randwerten der Schl sseleigenschaften ausgew hlt werden Pro Testpfad werden so zwei Testpunkte bestimmt f r die auch zwei Tickets ausgestellt werden Die Testpunkte m ssen die diagonalen Eigenschaften die in Abschnitt 6 4 beschrie ben wurden erf llen Tabelle 7 5 zeigt Beispiele f r die Wahl der Testpunkte Sollte zum gegebenen Zeitpunkt keine Diagonale gebildet werden k nnen z B weil alle m glichen Testpunkte noch von fr heren Tests reserviert sind so wird aus den zur ckgemeldeten Timeouts der k rzeste gew hlt Liegt dieser in einem konfi Das Ticketsystem erf llt keine Sicherheitsanspr che und verhindert es nicht dass nur der ur spr ngliche Empf nger des Tickets dieses verl ngern darf 83 7 Allgemeine Teststrategie Testpunkt 1 src dst sport dport Testpunkt 2 src dst sport dport min min min min max max max max min min min max max max max min min min ma
34. bei dem System um ein Endsystem oder Relaysystem handelt und wie viele der sieben Schichten durch OSI Protokolle betrieben werden Daraus ergibt sich der Grad der Kontrollierbarkeit und Einflussnahme auf die IUT Anhand der benutzen PCOs sowie der Schnittstelle zwischen LT und IUT bzw UT und IUT wurden in der Norm verschiedene Testmethoden f r vermittelnde und End systeme definiert F r den weiteren Kontext sind allerdings nur Testmethoden f r vermittelnde Systeme von Bedeutung F r IUTs in vermittelnden Systemen gibt es 62 6 2 Testen von Firewalls die R ckschleifetestmethode loop back test method und die transversale Test methode transverse test method die in Abbildung 6 3 abgebildet sind Diese werden entsprechend der Anzahl der beteiligten Protokollschichten als Single Party Testing SPyT und Multi Party Testing MPyT bezeichnet Jede Protokollschicht eines Endpunktes kommuniziert ber protocol data units PDU mit der jeweiligen Protokollschicht des Kommunikationspartners F r die vermittelnden Testmethoden werden nur lower tester eingesetzt da der Zugriff ausschlie lich ber die unteren Protokollschichten vermittelt wird und kein Zugriff von oben erfolgt LT PDU Relay SUT LT PDU Relay SYT pou_ LT Pa perm PCO1 PCO2 PCO 1 PCO2 ry A AA AA A A A yY Y v Y Y Sub Network 1 S
35. bei fehlerhaften oder nicht dokumen tierten Verhaltensweisen jedoch auftreten Im Top Down Verfahren wird von einem maximal vollst ndigen Test ausgegan gen und durch schrittweise Einschr nkungen ein Optimum f r die Balance zwischen Testabdeckung und Ressourcennutzung entwickelt Dabei werden alle Abweichungen diskutiert und begr ndet Die vollst ndige Abdeckung des Testraums w rde einen Maximaltest erfordern der alle Variationen der Aspekte f r jede der Testeingaben ber cksichtigt Dazu sind f r einen zustandsbehafteten Paketfilter zumindest Variationen e der L nge eines Paketes e der Anzahl von Paketen der Abfolge von Paketen e des Inhalts eines Paketes des Zeitablaufs zwischen den Paketen m glich wobei die Aufz hlung nur einen Teil der m glichen Eigenschaften ausmacht Dies w rde bei der Untersuchung eines einzigen TCP IPv4 Paketes ohne Nutzlast eine Paketl nge von mindestens 40 byte erfordern was 23 m gliche Bitkombinatio nen und damit auch Testf lle erg be Durch die Betrachtung eines zustandsbehafte ten Testobjektes das die Pakete in Kontext zueinander stellt w rde die Kombination dieser Eigenschaften zu einer Zustandsexplosion f hren die einen Test mit endlich zur Verf gung stehenden Ressourcen z B Zeit oder Speicher unm glich macht Um trotzdem einen Test durchf hren zu k nnen m ssen M glichkeiten gesucht werden den Testaufwand und die ben tigten Ressourcen zu reduzieren Dabei soll un
36. ber cksichtigt werden um eine Fremdmanipulation einer Verbindung z B durch Session Hijacking zu verhindern Die meisten dieser Informationen ergeben sich aus der Analyse des Pakets und des Paketflusses Die Timeouts werden teilweise von den jeweiligen Protokollspezifikatio nen vorgegeben sind aber auch Teil der Firewallkonfiguration Sie k nnen besonders gro z gig oder besonders strikt vorgegeben sein Je nach Freiheitsgrad der Konfigu rationssprache k nnen sie global f r eine Regel f r einen Dienst ein Protokoll oder einen Protokollzustand eingestellt werden netfilter iptables netfilter iptables hat zwei M glichkeiten Verbindungszustandsinformationen zu ver walten Das Modul state bietet eine vereinfachte Sicht und das Modul conntrack eine ausf hrliche Sicht auf die Assoziationszust nde Im ersten Fall stehen dem Be nutzer die Zust nde INVALID NEW ESTABLISHED RELATED und UNTRACKED zur Verf gung die wie folgt definiert sind NEW Die Assoziation startet und der Zustand ist erreicht wenn das Paket ein g ltiges Initiierungspaket in der Sequenz zur Herstellung einer Assoziation ist und die Firewall einen Datenstrom nur in eine Richtung beobachtet hat ESTABLISHED Die Assoziation wurde hergestellt und die Firewall hat Datenstrom in beiden Richtungen gesehen 40 4 2 Zustandsbehaftete Verbindungsverfolgung RELATED Das ist eine erwartete Assoziation im Kontext einer bereits hergestellten Assoziation Darunter we
37. berpr fung der Qualit tsmerkmale Funktionalit t Zuverl ssigkeit Benutz barkeit Effizienz Wartungsfreundlichkeit und bertragbarkeit bei der Firewallsoft ware ist f r Entwickler und Hersteller von grofer Bedeutung F r die Linux Firewall netfilter iptables wurde je ein Testansatz f r Regressionstests DH04 und f r Leis tungstests HPS03 vorgestellt Ein Endbenutzer oder ein Administrator ist jedoch daran interessiert den Betrieb und die Umsetzung der Aufgabenstellung zu berpr fen Hierzu wurden verschiedene Arbeiten zur Analyse Modifikation und zum Testen von formalen Sicherheitsricht linien und Regelwerken vorgestellt Dabei konnten vier Ans tze identifiziert werden e Analyse der Richtlinie oder eines abstrakten Regelwerks e Analyse der Richtlinie abgeleitet aus den Regeln Erstellen der Regeln abgeleitet aus der Richtlinie e Testen nach Ableitung der Testf lle aus der Richtlinie oder den Regeln Der erste Fall birgt das Problem dass Richtlinien und das Regelwerk separat syn chron gehalten oder sogar manuell ineinander berf hrt werden m ssen Zudem setzt es voraus dass eine informale Sicherheitsrichtlinie f r eine bestimmte Umgebung et wa eine Firma oder ein Netzwerk bereits existiert und in eine formale Form berf hrt werden kann Au erdem umfasst eine Sicherheitsrichtlinie die globale Sicht al so mehrere Objekte die alle einzeln identifiziert spezifiziert und getestet werden m ssen D
38. bevor eine allgemeine Regel das Standardverhalten definiert Solch eine M glichkeit bieten der Packet Filter ber no nat no rdr und no binat sowie Cisco PIX ber nat 0 Bei iptables l sst sich hnliche Funktionalit t durch Verzweigungen in den Regellisten mit jump und goto erreichen Bei IP FireWall und IPFilter konnte f r NAT kein Ausschlussmechanismus gefunden werden FW 1 konnte nicht berpr ft werden M chtigkeit des Paketfilters und der Paketver nderungen Ein Unterschied zwischen den untersuchten Open Source und den kommerziellen Pa ketfiltern sind voreingestellte Konsistenzpr fungen des Datenverkehrs und Schutz funktionen die in den kommerziellen Systemen oft als implizite Regeln oder sogar Teil des Paketfilters bzw IDS implementiert sind In den freien Paketfiltern k nnen hnliche Funktionalit ten erreicht werden m ssen aber bei der Konfiguration u U manuell eingestellt werden Dies soll nicht unbedingt als Nachteil sondern als Flexi bilit t der Einstellungsm glichkeiten eines Paketfilters betrachtet werden Die verf gbaren Filterkriterien sind ein Indiz daf r wie genau der Benutzer durch Einstellung der Regeln die Inspizierung der Pakete oder der Paketfl sse kontrollieren kann um Entscheidungen zu treffen oder Modifikationen der Pakete durchzuf hren In den betrachteten kommerziellen Paketfiltern wie auch in den meisten Publi kationen zur zustandsbehafteten Filterung werden vor allem die Kriterien src dst s
39. dem Linux Kernel 2 6 20 entnommen 126 A 1 Modellierung von netfilter iptables I wuondg sop qeagdt 1o3 g3ou uoa Sunjsirpn y z y PALL I 2o1rpor pues e juoo I SII9MPIT9 MI9S e FUO Joyy yyed osioaol 0 Joyy dr fe juoo JSL UOA Sunj3le I19319AA 0 SUIpIeAIOJ our Te JUOD I SUIPIBMIOF JE JUOI 0 o3nor o24nos 3dooov e juoo 0 SI9911P9T 3dooov e juoo I sdure3sauug dog 0 son ooou s d SMOV NAS 9pueqoj4ssne xeu PZOT soppeq u s xeur dog ojuourgder spusyesule Inj gunupJOu xeul v9 ys p xew serdi ojuourgel MJ 3192031 AA XLU 0 oui serdi ojuourgderg inj Joyotedsg xeur vVvICOC ysoiyy ysy serdi oquourder Ing Joyorods urui 309961 ysoryy Mop sedr HIN SZI lt uen Sr2ueuqe W vu GESI xeur xpoe1quuoo dr LNALNO My xew unu 000IO S04c osuer 110d eoo dt T9 T13 ynejop di qoud wered poxo our uouonb oas yaea un jop my 3rumogezd 8919 y1sewoyerdunm das ysoy oid s3sw dum 0 purge rdu uojpeq IoA O30301d sosessour Ioro sngoq o1ousr durior Sooegr uoJo1Qour loq 0 Ippejr punoqur sn s1o Lro dwor uoddojs Mq ue surd yseopeoiq I syseopeoiq 9IOUST oyoo dwor uoddojs Mq ue ssurd o e 0 pe e1ousr oyoo dwor Sunqrerq pseq JIOMpIepueIg log euog 127 Anhang A Anhang T ueuondq so qeadt 1o3 g3ou uoa Sunjsrgn y e y 9ereqer OST wears ynoowty dpn yoerguuoo dr Joy you 08 poou dpn xoer1uuoo dr 1o3 g3ou OZI jre oui 3noourm doy xo e11uuoo dr 1o3 g3eu OcI quos UAS 3noouij doy xpe1juuoo d
40. der Da tei durch die init O Methode in der Klassendefinition erstellt Dabei wird f r alle Schl ssel also auch die nicht explizit belegten in den Vektoren ein Eintrag im Speicher erstellt so dass eine einfache berpr fung auf Existenz des Schl ssels nicht ausreicht und zus tzlich die Existenz von Daten hinter dem Schl ssel berpr ft wer den muss Im negativen Fall m ssen Standardwerte die evtl abh ngig von den Daten der anderen Schl ssel sind f r diese Schl ssel in FW TStrategy vorgesehen werden Wenn der FWA Aussagen ber mehrere Protokolle trifft so berl sst er die Belegung der protokollspezifischen Schl ssel dem Interpreter der Vektoren path_al target tstate tproto troute cand cstate cproto croute 63 EST ICMP FORWARD 344 EST ICMP FORWARD Listing A 4 association list In Listing A 4 wird eine Zeile aus der association list dargestellt in der der FWA bereits m gliche Kandidaten zur Herstellung einer Vorgeschichte vorschl gt Die Liste besteht aus Tupeln mit 8 Elementen die eine Verkn pfung zwischen dem Vektor mit der Nummer in Feld 1 target unter den Aspekten in den Feldern 2 4 target state target protocol target route und einem Kandidaten in Feld 5 candidate mit den Aspekten in den Feldern 6 8 candidate state candidate protocol candidate route herstellt 132 A 3 Benutzerhandbuch A 3 Benutzerhandbuch In diesem A
41. eine Kombination aus filternden Routern auf der Transportebene und Proxies auf Anwendungsebene vgl auch IF02 Sie entstanden aus der Erkenntnis dass nicht alle Netzteilnehmer kooperative Ziele verfolgen wozu sicherlich die ersten Netzwerkw rmer beigetragen haben Aufgrund der zunehmenden Netzwerkkomplexit t wuchsen auch die Anforde rungen an die Regelwerke der Firewalls und somit auch die notwendige Fachkenntnis der zust ndigen Administratoren um sie zu bedienen Gerade die kommerziellen Anbieter versuchen ihre Produkte durch das Argument der einfachen Bedienbarkeit und unterst tzender Werkzeuge hervorzuheben doch die nun abstrahierten Kon zepte und Mechanismen sind im Detail kaum noch nachvollziehbar und k nnen zu unerw nschten Nebeneffekten f hren Zus tzlich sind Netzwerkadministratoren und der IT Support dauerhaft in einer reaktiven Feuerbek mpfenden Position beim Versuch die Verf gbarkeit Zuverl ssig 1 Einleitung keit und Leistung ihrer Netzwerke zu sichern was durch die eingeschr nkten Res sourcen Zeit Geld Ausr stung und Personal weiter kompliziert wird R Buchanan schrieb in seinem Buch The Art of Testing Network Systems Buc96 Netzwerk berwachung zeigt an was passiert ist Netzwerktests zeigen was passieren wird Die vorliegende Arbeit besch ftigt sich mit der Modellierung von Paketfiltern als Bestandteil von Firewalls die eine besondere Art der Netzwerksysteme sind sowie der Entwick
42. erkannt werden kann 18 3 1 Sicherheits und Netzwerkfunktionen Eine M glichkeit Angriffe auf die Firewall zu erschweren ist diese erst gar nicht als Vermittlungspunkt sichtbar zu machen Dies kann als Nebeneffekt vom Betrieb der Firewall im Bridgemodus erreicht werden wodurch die Firewall transparent f r das Netzwerk arbeitet und nicht adressierbar ist Im Routingmodus kann die Fire wall Verschleierungsmethoden nutzen die keine Informationen ber sie oder ihren Zustand nach aufen dringen lassen Dies wird erreicht indem die Firewall entweder keine Antworten und Fehlernachrichten sendet oder sich bei diesen als das Zielsys tem ausgibt Weiterhin kann sie beim Weiterleiten der IP Pakete den TTL Wert nicht wie blich vermindern wodurch sie als Weiterleitungsstation nicht sichtbar wird Ei ne entsprechende Manipulation der TTL ist mit PF IPFilter und iptables m glich IPFW kann sich beim Ablehnen der Verbindungen als das Zielsystem ausgeben F r eine besonders hohe Verf gbarkeit bietet es sich an die Firewall redundant auszulegen und die Zustandsdaten der einzelnen Einheiten untereinander zu syn chronisieren Die meisten Anbieter bieten eine Infrastruktur an bei der bei einem Ausfall eine andere Einheit den Betrieb bernehmen kann Aus lizenztechnischen Gr nden unterscheiden die kommerziellen Anbieter oft zwischen mehreren vollwer tigen und gleichzeitig einsetzbaren Einheiten im so genannten active active Betrieb und zus tz
43. fehlenden Funktionen durch weitere Komponenten bereitgestellt werden Durch einen Vergleich der Funktionalit ten der untersuchten Paketfilter konnte netfilter iptables als das substanzielle System mit der gr ten Konfigurationsfrei heit ermittelt werden Tabelle 3 2 zeigt die verf gbaren Filterkriterien von iptables die f r die m glichen Entscheidungen und Aktionen aus Tabelle 3 3 herangezogen werden k nnen Bis auf die Aktionen die unter nicht unterst tzt gelistet sind k nnen alle Funktionen bzw Optionen der vorgestellten Paketfilter als gleichwertige iptables Regeln formuliert werden Als gleichwertig werden die extern beobachtbaren Resultate und nicht unbedingt die internen Mechanismen bzw Strategien verstanden Protokoll und Protokollfelder Layer 3 IP IP Fragmente TTL TOS DSCP ECN IP Optionen Layer 4 TCP UDP ICMP IPSEC DCCP SCTP Adressierung Layer 1 interface in out physical Layer 2 MAC pkttype ucast bcast mcast Layer 3 IP iprange ipset addrtype ucast bcast mcast local anycast black hole unreachable prohibit throw nat xresolve unspec Layer 4 ports Layer 5 BGP routing realm Limits connlimit connections source TCP only hashlimit pkts sec Hash ber Liste aus srcip srcport dstip dstport limit pkts t t sec min hour days fuzzy pkts sec quota pkts max connrate bytes sec connbytes mode direction mode pkts bytes avgpkt direction in out both 27 3 Merkmale der Fire
44. filter ACCEPT forward KERNEL route OUTPUT filter DROP stop OUTPUT filter LOG non term continue OUTPUT filter REJECT stop OUTPUT filter TCPMSS non term continue OUTPUT filter ULOG non term continue POSTROUTING mangle ACCEPT forward POSTROUTING nat POSTROUTING mangle CLASSIFY non term continue POSTROUTING mangle CONNMARK non term continue POSTROUTING mangle CONNSECMARK non term continue POSTROUTING mangle DROP stop POSTROUTING mangle DSCP non term continue POSTROUTING mangle ECN non term continue POSTROUTING mangle LOG non term continue POSTROUTING mangle MARK non term continue POSTROUTING mangle SECMARK non term continue POSTROUTING mangle TCPMSS non term continue POSTROUTING mangle TOS non term continue POSTROUTING mangle TTL non term continue POSTROUTING mangle ULOG non term continue POSTROUTING nat ACCEPT forward POSTROUTING finished POSTROUTING nat DROP stop POSTROUTING nat LOG non term continue POSTROUTING nat MASQUERADE forward KERNEL POSTROUTING nat TCPMSS non term continue POSTROUTING nat NETMAP forward KERNEL POSTROUTING nat SNAT forward KERNEL POSTROUTING nat ULOG non term continue Tabelle A 1 Tabellarische Modellierung der netfilter iptables Firewall Alle Schalter sind mit sysctl w variable value zu setzen bzw mit sysctl variable abzu fragen Aus Platzgr nden sind die hier gelisteten Schalter gek rzt wiedergegben und vor Gebrauch mit dem Prefix net ipv4 zu erg nzen Die Standardwerte sind
45. im IP Stack ber die Schl sselw rter to oder das Synonym fastroute zu umgehen wobei IPF selbst das Paket routet und an den n chsten Hop adressiert Durch eine auth Regel ist es m glich ein externes Programm zur Benutzerauthen tifizierung aufzurufen welches dann die Filterentscheidung trifft Ein so akzeptiertes Paket bzw die dazugeh rende Assoziation berspringt alle weiteren berpr fungen in der bearbeiteten Richtung Der beschriebene Paketfluss basiert auf der Dokumentation unter http coombs anu edu au avalon 3 fastroute wird vor allem fiir einen stealth Modus verwendet bei dem die IP TTL nicht vermindert wird und dadurch die Firewall als zus tzliche Station unsichtbar bleibt 34 4 1 Paketfl sse PF Packet Filter F r die Analyse des Packet Filters wurden die Projektdokumentation und der Quell code herangezogen Eine Besonderheit in den Funktionen von PF und damit auch im Paketfluss der in Abbildung 4 6 zu sehen ist sind die eingebauten zusammengefassten Mechanis men zur Paketmodifikation Einerseits k nnen mit scrub die IP TTL und ID die Maximum Segment Size MSS f r TCP moduliert und andererseits die Fragment flags und Fragmentierung bereinigt werden F r TCP sind zudem Modulation der Sequenznummer und der Einsatz eines SYN Proxies m glich die mit der Zustand stabelle bzw Zustandserstellung verkn pft sind Diese k nnen regelbasiert mit keep state modulate state und synproxy state akti
46. im Quellcode verf gbaren Paketfiltern werden an verschiedenen Stellen einzelne TCP Flags verglichen ber die kommerziellen Paketfilter kann keine Aussage gemacht werden Die Verbindungsverfolgung f r UDP unterscheidet aufgrund der verbindungslo sen Natur des Protokolls nur zwischen den einfacheren Zust nden NEW ESTABLISHED und RELATED Assoziationen letztere beiden werden auch nach Senderichtung unter schieden Bei ICMP werden den drei Zust nden bestimmte ICMP Typen zugeordnet Vier Frage Antwort Paare werden als NEW bzw ESTABLISHED und f nf Fehlerbenach richtigungen f r bestehende Assoziationen als RELATED klassifiziert Bei den Paaren wird intern ein Z hler dazu verwendet den Eintrag nur so lange zu erhalten wie Antworten auf gesendete Anfragen ausstehen tcp 6 431992 ESTABLISHED src 10 0 1 1 dst 10 0 2 2 sport 9575 dport 1863 pkts 2 bytes 109 src 10 0 2 2 dst 10 0 1 1 sport 1863 dport 9575 pkts 1 bytes 60 ASSURED mark 0 use 1 tcp 6 93 SYN_SENT src 10 0 1 1 dst 10 0 2 2 sport 9546 dport 631 pkts 1 bytes 60 UNREPLIED src 10 0 2 2 dst 10 0 1 1 sport 631 dport 9546 pkts 0 bytes 0 mark 0 use 1 udp 17 178 src 10 0 1 1 dst 10 0 2 2 sport 2869 dport 53 pkts 2 bytes 130 src 10 0 2 2 dst 10 0 1 1 sport 53 dport 2869 pkts 2 bytes 234 ASSURED mark 0 use 1 icmp 1 30 src 10 0 2 2 dst 10 0 2 255 type 8 code 0 id 352 pkts 1 bytes 84 UNREPLIED src 10 0 2 255 dst 10 0 2 2 type 0 code 0 id 352 pkts 0 bytes 0 mark 0 use 1 Li
47. in der TCP Zustandsmaschine Die in der Tabelle und in der vorliegenden Arbeit beschriebene Zustandsma schine wurde erst in Linux 2 6 9 eingef hrt Vorher wurden die TCP Flags an mehreren Stellen im Code einzeln berpr ft hnlich wie es IPFilter PF und IPFW bis heute noch machen 107 10 Bewertung und Vergleich In diesem Kapitel werden die entwickelte Teststrategie und das Werkzeug FWTStra tegy in den Kontext anderer Arbeiten gestellt Dabei wird die erarbeitete L sung verglichen und bewertet In Abschnitt 10 1 werden zun chst Werkzeuge vorgestellt die verschiedene Aspek te der Netzwerk und Firewalltests umsetzen Sie werden in zwei grofe Gruppen unterteilt und kurz vorgestellt Abschnitt 10 2 stellt verwandte wissenschaftliche Arbeiten vor die sich mit dem Testen von Firewalls besch ftigen Auch hier wird eine Kategorisierung eingef hrt um die Schwerpunkte der Arbeiten besser voneinander abgrenzen zu k nnen In Abschnitt 10 3 werden schlieflich die hnlichsten Ans tze aus den Werkzeugen und den verwandten Arbeiten ausgew hlt und mit der vorliegenden Arbeit verglichen Am Ende des Vergleichs steht eine Bewertung der Teststrategie auf qualitativer und quantitativer Ebene 10 1 Testwerkzeuge Die hier vorgestellten Werkzeuge stellen nur eine kleine Auswahl der vorhandenen Software dar die Netzwerk und Sicherheitsanalysen durchf hren k nnen Vor allem im kommerziellen Sektor gibt es Programme die sich diesen Zie
48. kann weswegen er sie ver werfen muss Eine M glichkeit f r so einen Angriff ist das SYN Flooding das die erste Phase des 3 Wege Handshakes bei TCP von nicht antwortenden Quelladressen vort uscht und so die SY N Backlog Tabellen des Zielsystems in denen unvollst ndige TCP Verbindungsversuche verwaltet werden berflutet hnliche Flooding Angriffe sind auch mit ICMP und UDP m glich Die Verf gbarkeit der Dienste kann gest rt werden indem das Zielsystem oder die vermittelnden Knoten angegriffen werden Deswegen zielen auch manche Angriffe auf die Firewalls selbst die ebenfalls eine Angriffsfl che bieten auch wenn sie darauf ab gestimmt sind Angriffen und berlastungen entgegenzuwirken Mit dem Ausfall der Firewall w rden auch die Erreichbarkeit und der Dienst aller ber sie verbundenen Systeme wegfallen Deswegen ist ein Teil der Firewallfunktionen auch daf r gedacht den Betrieb zu sichern und die Verf gbarkeit zu erh hen Die Merkmale der Firewalls k nnen als Methoden und Strategien angesehen werden die Sicherheitsziele und die Sicherheitsrichtlinien durchzusetzen Die hier untersuch ten Paketfilter dienen der Umsetzung der Zugriffskontrolle auf Systeme und Dienste Indirekt k nnen sie auch die Zurechenbarkeit z B ber das Logging der Zugriffe die Verf gbarkeit z B ber die Reglementierung der berm igen Dienstnutzung oder das Filtern von Angriffen auf den IP Stack die Vertraulichkeit der Netzwerk struktur
49. lle lassen sich aber durch die Implementierung entsprechender Erweiterungen der Teststrate gie ebenfalls abdecken Bad Protocol Properties Diese Testf lle konnten wegen den im Vektor geforder ten Protokolleigenschaften nicht umgesetzt werden Diese Eigenschaften sind eine direkte oder indirekte Folge der Konfiguration und ergeben sich entweder durch die explizite Forderung durch eine Regel oder aus der Vervollst ndigung des Testraumes durch den FWA Die Anzahl der nicht getesteten Testf lle f r die explizit geforderten Eigenschaften l sst sich durch eine Konfigurati ons nderung ver ndern No Prehistory F r diese Testf lle konnte kein geeigneter Kontext gefunden wer den mit dem der Testfall vorbereitet werden k nnte Diese Gruppe fasst zwei weitere F lle zusammen Der FWA liefert in der association list keine Vorge schichte zu diesem Testfall weil keine Regel in der Konfiguration einen voran gegangenen Verbindungszustand erlaubt Weiterhin ist es m glich dass akzep tierende Regeln f r die Verbindungszust nde existieren aber diese aufgrund der geforderten Protokolleigenschaften sich f r keinen spezifikationskonformen Protokollfluss verwenden lassen In beiden F llen kann auch im regul ren Be trieb des Paketfilters ein solcher Kontext nicht hergestellt werden In Test und Skip Die unter In Test genannte Zahl bezeichnet die tats chlich ge testeten Testf lle f r die ein Protokollfluss hergestellt wurde Die unt
50. mit der Erwartung fast berein Eine Paket ver nderung ist aufgetreten Fehler Ein unerwartetes Ereignis Empfangsfehler Das empfangene und das gesendete Paket stimmen nicht berein M glicherweise wurde ein fremdes Paket empfangen Die daf r ben tigten Vergleichsfunktionen k nnen in protokoll bzw bertragungs bedingte sowie in probandenabh ngige F lle eingeteilt werden Die erste Gruppe kann generisch von der Teststrategie zur Verf gung gestellt werden Letztere m ssen f r jede das Paket ver ndernde Funktion in der firewallabh ngigen Beschreibung zur Verf gung gestellt werden Der generische Teil ben tigt zur Auswertung Angaben ber die Senderichtung des Paketes das gesendete Paket die empfangenen Pakete auf beiden Seiten und eine Beschreibung der postulierten Reaktion des Paketfilters Darauf aufbauend kann ein Auswertungsalgorithmus wie in Abbildung 7 3 dargestellt vorgehen interpret route sendPkt replies expected sender got packet receiver got packet no expected filter result DROP packets match OK FAIL OK RecvErr FAIL OK FAIL FAIL OK RecvErr FAIL RecvErr Abbildung 7 3 Entscheidungsgraph zur Testauswertung Besonders wichtig bei der Entscheidung ber das Endergebnis ist der letzte Ver gleich der berpr ft ob das empfangene Paket mit dem gesendeten Paket korreliert 76 7 1 Vereinfachter Tes
51. sechs Felder bis zum Semikolon bilden einen Schl ssel ber den die fol genden Werte referenziert werden k nnen Sie beschreiben die initiale Verbindungs richtung die Quelladresse und den Quellport die Zieladresse und den Zielport sowie die Nummer des IP Protokolls Die weiteren Felder werden in Tabelle 4 3 benannt Feld Beschreibung 1 6 eindeutiger Schl ssel 7 type r ctype zusammengesetztes Feld 8 flags r cflags hex 9 Regelnummer die zu dem Eintrag f hrte 10 vorgegebener timeout f r die Assoziation 11 Adresse der Behandlungsroutine f r Pakete dieser Assoziation 12 15 eindeutige ID der Assoziation 16 ID der eingehenden Schnittstelle auf Client Seite 17 ID der ausgehenden Schnittstelle auf Client Seite 18 ID der eingehenden Schnittstelle auf Server Seite 19 ID der ausgehenden Schnittstelle auf Server Seite 20 n 4 IDs der Kernelbuffer n Zeit verbliebene G ltigkeit gesamte G ltigkeit Tabelle 4 3 Feldbeschreibungen in Zustandsinformationen bei FW 1 Seit Version NG von VPN 1 FireWall 1 werden in der Zustandstabelle auch sym bolische Verkn pfungen angelegt Diese benutzen die gleiche Art von Schl ssel wie regul re Eintr ge und verweisen auf einen ebensolchen Schl ssel Zus tzlich haben sie noch einen Wert der den Typen der Verkn pfung angibt Die meisten Assoziatio nen werden durch vier Eintr ge in der Zustandstabelle abgebildet die die ein und ausgehenden Assoziationsdaten auf Clien
52. spezielle Art der Anweisungen dient der Strukturierung des Regelwerks die einen Entscheidungsgraphen mit Verzweigungen aufbauen Auch die Filterentschei dungen k nnen den weiteren Verlauf im Entscheidungsgraphen und damit auch im Paketfluss beeinflussen Deswegen wird f r die Modellierung der Arbeitsschritte zu n chst die Modellierung der Regelwerk ver ndernden Funktionen ben tigt Die Regeln eines Regelwerks bilden Knoten in einem Entscheidungsgraphen Je de Regel besteht aus einem Bedingungsteil und einer Anweisung die den weiteren Pfad beeinflusst Falls der Bedingungsteil zutrifft kann eine Anweisung den Gra phen verzweigen zusammenf hren fortf hren oder abbrechen Anweisungen k nnen gruppiert werden um Verzweigungs bzw Anspringpunkte zu realisieren Das wird firewall spezifisch durch die Bearbeitungsphasen vorgegeben und kann durch be nutzerdefinierte Regelgruppen vgl Abschnitt 3 2 verfeinert werden Im Folgenden werden f r Arbeitsschritte der Begriff task und f r Regelgruppen die von iptables bernommene Bezeichnung chain verwendet In Abbildung 5 2 wird eine symbolische Repr sentation der Regeln eingef hrt und dazu verwendet zwei unterschiedliche Arten der Verzweigung im Regelwerk vorzu 50 5 1 Bausteine des Modells Abarbeitungsreihenfolge CD Action unbedingte Aktion TRUE Pl iac AND pU e 3 Action bedingte Aktion 12 gero I sd user x ous i 2 Action terminierende Aktion
53. system under test SUT Der Tester umschlie t die IUT Schichten von oben und unten weswegen er in die zwei Komponenten upper tester UT und lower tester LT aufgeteilt ist vgl Abbildung 6 2 Die Pr fmethoden der OSI Konformit tstests sind generell Black Box Tests die nur mit den u eren Schnittstellen der IUT den so genannten points of control and observation PCO kommunizieren und so das externe Ver halten testen Die Interaktion ber die PCOs entspricht dem Grundsatz das Proto kollverhalten und nicht eine bestimmte Implementierung zu spezifizieren Deswegen wird oft die Form von mehr oder weniger abstrakten endlichen Automaten finite state machine FSM gew hlt oder sie l sst sich zumindest in solche berf hren Reale Implementierungen lehnen sich dementsprechend eng an die Beschreibung an auch wenn nicht alle abstrakten Zust nde auch real vorhanden sind Upper Tester T est C oordination IUT SUT l l l l l l I l P rocedure Lower Tester Abbildung 6 2 Konzeptionelle Testarchitektur Da sich die Implementierungen von Protokollspezifikationen nicht nur in ihrer Kon figuration sondern auch in Funktion und Aufbau unterscheiden k nnen wurden sog abstrakte Testmethoden abstract test methods ATM definiert die das gesamte Spektrum der zu testenden Systeme abdecken sollen Unterschieden wird dabei ob es sich
54. te erh ht Trotzdem wird eine eindeutige Spezifikation ben tigt gegen die ein Zwischenpunkt gepr ft werden kann D von Bidder Senn besch ftigt sich mit diesem Problem und zeigt in BS06 wie es m glich ist Zwischenpunktspezifikationen aus den Endpunkts pezifikationen systematisch zu erzeugen Sie schl gt einen Algorithmus vor der unter Eingabe von Automaten f r die Endpunkte eines Protokolls einen Protokollautoma ten f r den Zwischenpunkt erzeugt Mit so einem Automaten w re es m glich eine Firewall zu konstruiren Die vorliegende Arbeit jedoch nimmt die Sicht der End punkte ein und testet die Reaktion der Firewall auf die Kommunikation zwischen den beiden Protokollpartnern Alle Mechanismen von zustandsbehafteten Paketfiltern basieren auf der Verfol gung von Assoziationen zwischen den Endpunkten Dabei werden innerhalb einer Assoziation mehrere Phasen unterschieden die bedingt durch die jeweilige Protokoll spezifikation voneinander abh ngen und deshalb von der Firewall durchgesetzt wer den Dadurch ist es m glich die Initiierung einer Assoziation nur von ausgew hlten Endpunkten zu erlauben und die R ckrichtung nur f r korrekte Antwortpakete zu ffnen was eine erh hte Kontrolle und striktere Filterung der Pakete erlaubt Ebenso ist es dann m glich Kontroll und Fehlernachrichten nur im Kontext einer bekannten Assoziation zuzulassen Damit dieser Mechanismus funktioniert m ssen ber die zugelassenen Assozia Ein Bei
55. und die internen Abl ufe im Vordergrund der Betrachtung In Abschnitt 4 1 werden die Paketfl sse der Paketfilter betrachtet Sie sollen dazu genutzt werden die Zugriffs und die Entscheidungspunkte des Paketfilter sowie die Bearbeitungsschritte f r die empfangenen die weitergeleiteten und die gesendeten Pakete zu identifizieren Zus tzlich soll die Reihenfolge und die Abh ngigkeiten zwi schen den bereits ermittelten Merkmale und Funktionen festgehalten werden Beide Aspekte k nnen dazu beitragen die Tests genauer zu steuern und sie einzustellen Im zweiten Abschnitt wird die zustandsbehaftete Verbindungsverfolgung vorge stellt die ein Mechanismus der Firewalls ist mit dem die Zust nde der Endpunkte verfolgt und verwaltet werden Die Analyse dieses Mechanismus ist notwendig um eine Grundlage zu schaffen die von dem Paketfilter unterschiedenen Zust nde bei der Teststrategie zu ber cksichtigen und sie gezielt ansteuern zu k nnen 4 1 Paketfl sse Die vorgestellten Funktionen der Firewalls bzw der Paketfilter werden entwurfsbe dingt von den einzelnen Probanden in unterschiedlichen Reihenfolgen abgearbeitet Diese Reihenfolge bestimmt die Priorit ten der Sicherheitsfunktionen und ist einer seits ein Mittel zur Entlastung der Firewall von komplexeren berpr fungen wenn ein Paket bereits aufgrund der Nicht bereinstimmung mit einfacheren Kriterien ver worfen werden kann und andererseits bestimmt sie die Einflussnahme der fr heren
56. vgl Abschnitt 3 3 In Kapitel 4 wurde die Funktionsweise der Paketfilter weiter analysiert Dazu wurden speziell die Paketfl sse und die zustandsbehaftete Verbindungsverfolgung der Paketfilter anhand der Dokumentation und Quellcodes rekonstruiert um die Abh ngigkeiten der Funktionen und ihre Wirkung auf den Entscheidungsprozess beim Filtern festzustellen Dieser Schritt war notwendig weil die internen Mecha nismen der Firewalls nicht oder nur ungen gend dokumentiert sind und sie auf grund ihrer beobachtenden Position zwischen den Endpunkten Entscheidungen tref fen m ssen die von der Sicherheitsrichtlinie vorgegeben werden Ein Paketfilter 119 11 Zusammenfassung und Ausblick hat eine eigene sicherheitsbezogene Sicht auf den Protokollfluss weswegen nicht die Endpunkt basierenden Protokollspezifikationen f r diese Analyse herangezogen wer den konnten Zudem ist die Erfassung der Kernfunktion der zustandsbehafteten Pa ketfilter und die Identifizierung des Konfigurationseinflusses auf das Verhalten Vor aussetzung f r einen gezielten Test der Paketfilter Hier konnte festgestellt werden dass die untersuchten Paketfilter vergleichbare Informationen zur Identifizierung der Verbindungen speichern Kapitel 5 fasst die Analyseergebnisse schlie lich zusammen und entwickelt ein Modell zur Beschreibung der Paketfl sse und der Entscheidungspunkte f r die Pa ketfilterung und die Paketver nderung Das Modell ist nach dem Baukastenprinzi
57. von Firewall Regelwerken und Eigenschaften von Intrusion Detecti on Systemen IDS Es ist in der Skriptsprache Perl realisiert und besteht aus einem Paketinjektor sowie einem Paketempf nger Die Testdaten werden ber eine Konfi gurationsdatei definiert und vom Paketinjektor versendet Beide Seiten legen jeweils Log Dateien an aus deren direktem Vergleich die geblockten oder ver nderten Pa kete ermittelt werden k nnen Der Testprozess und die dazugeh rige Konfiguration m ssen manuell f r jeden neuen Fall erstellt analysiert und interpretiert werden Leider bietet die Konfigurationsdatei keine M glichkeit die Pakete genau zu spezi fizieren und es lassen sich damit auch keine bedingten bzw komplexeren Abl ufe definieren Im Rahmen mehrerer Semesterarbeiten wurde an der ETH Z rich das Werkzeug fwtest ETH Z rich fwtest entwickelt Mit Hilfe einer einfachen Konfigurati onssprache k nnen statische Testf lle definiert und sequentiell oder im begrenzten Rahmen auch parallel abgearbeitet werden Ein Testfall besteht aus mehreren Pa keten f r die jeweils das Protokoll ausgew hlte Protokollfelder ein symbolischer Zeitschlitz sowie das erwartete Ergebnis angegeben werden k nnen Die gesamten Ergebnisse werden in einer Logdatei protokolliert Auch dieses Tool ist nur ein geschr nkt f r komplexere Einsatzszenarien geeignet da keine bedingten Abl ufe m glich sind die Abweichungen zwischen den gesendeten und den empfangenen Pa kete
58. vorherige Authentifizierung ber ssh bzw inzwischen seltener ber telnet Wird eine Web Proxy Funktion mit angeboten so ist eine Au thentifizierung auch ber das Proxy Protokoll SOCKS V5 m glich Netfilter bietet als Framework selbst keinen Authentifizierungsdienst an kann aber mit verschiedenen externen Projekten erg nzt werden Darunter w re z B das NuFW Projekt zu nennen das eine differenzierte Benutzerauthentifizierung ber ein client Programm auch auf Mehrbenutzersystemen erlaubt IP FireWall und IPFilter bieten ebenfalls eine allgemeine Schnittstelle an um Pro gramme zur Authentifizierung von Benutzern anzubinden Bei IPFW werden dazu divert bei IPF auth Regeln benutzt Ein konkreter Dienst wird dar ber allerdings nicht angeboten In beiden F llen m ssen nach der Authentifizierung zus tzlich ent sprechende Regeln f r folgende Pakete gesetzt werden IPF erleichtert diese Aufgabe durch spezielle preauth Regeln die auf eine dynamische Liste mit Authentifizierungs regeln zur ckgreifen k nnen Wird dort eine weitere passende Regel gefunden wird ihre Filterentscheidung benutzt Andernfalls wird das Paket geblockt PF bietet einen vollst ndigen Dienst ber authpf an Hierbei k nnen sich Benutzer ber SSH auf der Firewall anmelden woraufhin ihre Quelladresse f r die Dauer der SSH Verbindung f r konfigurierte Verbindungen frei geschaltet wird Die Cisco PIX kann ber die Protokolle RADIUS und TACACS neben Authenti fi
59. werden Zur weiteren Strukturierung k nnen ber das Schl sselwort skip gefolgt von der Anzahl der Regeln Regeln gezielt bersprungen werden Die PF Firewall arbeitet wie die IPF ebenfalls nach dem last match Prinzip und kann ber das Schl sselwort quick die Abarbeitung terminieren Zur Strukturierung des Regelwerks k nnen Ankerpunkte anchors definiert werden die als Unterbaum abgearbeitet werden Diese k nnen hnlich wie Verzeichnisse im Dateisystem z B Ein externes Projekt das die Konfiguration einlesen und wiedergeben kann ist unter http www wormnet nl cprules zu finden 23 3 Merkmale der Firewallsysteme incoming mail spamfilter ber mehrere Ebenen angelegt werden und dabei auch in bergeordnete Teilb ume z B proxy zur ckspringen Alle Cisco Produkte so auch die PIX arbeiten mit so genannten access lists Die se werden sowohl f r die Filterung wie auch f r policy NAT und die Zuordnung der VPN Tunnel benutzt Access lists gelten grunds tzlich f r den ankommenden Ver kehr und werden an eine Netzwerkschnittstelle eine NAT oder eine VPN Definition gebunden Sie k nnen nicht weiter strukturiert werden Checkpoint Produkte werden ber das grafische Programm SmartDashboard ad ministriert Dort werden alle Objekte in statischen und dynamischen Gruppen ge pflegt auf die sich das Regelwerk bezieht Es gibt je eine Regelliste f r Filterung NAT VPN Quality of Service und weitere installierte Z
60. Die Auf trennung des Pfades in mehrere Teilpfade wird f r das Herstellen von Kontexten f r unterschiedliche Protokolle z B ICMP Fehlermeldungen folgend auf TCP Pakete ben tigt Erst nachdem ein erwartungsgem es Ergebnis f r ein Paket best tigt wer den konnte wird das n chste Paket oder der n chste Schritt im Testpfad ausgef hrt Auswertung Die Auswertung der Testf lle in der neuen Teststrategie unterscheidet sich konzep tionell nicht von der Auswertung f r einen einzelnen Vektor Bei der Auswertung der Vorgeschichte k nnen aber die Ergebnisse f r jeden Testschritt einem Vektor zugeordnet werden Die Informationen und Ergebnisse der Auswertung werden gesondert auf Testfall und Paketebene zur weiteren Auswertung gesammelt um daraus einen Bericht er stellen zu k nnen Bei einer abweichenden Reaktion der Firewall wird eine entspre chende Mitteilung an den Benutzer generiert und die folgenden Tests gegebenenfalls entsprechend neu bewertet bzw angeordnet 85 7 Allgemeine Teststrategie Erstellung der Teil Berichte Bereits w hrend der Ausf hrung des Tests werden dem Benutzer Teilergebnisse an gezeigt um den Fortschritt beobachten zu k nnen Die Lautst rke der Ausgaben ist ber Kommandozeilenschalter konfigurierbar In der Standardeinstellung werden nur unerwartete Ergebnisse detaillierter ausgegeben Am Ende aller Tests wird zus tzlich eine bersicht erstellt die die ausgef hrten Tests nach Ergebnis
61. INPUT Ein Paket das weitergeleitet werden soll geht weiter ber FORWARD und POSTROUTING Lokal auf dem System erstellte Pakete treffen ber den Zugriffspunkt OUTPUT ein und gehen ebenfalls ber das POSTROUTING weiter An jedem der f nf Zugriffspunkte k nnen sich netfilter Erweiterungen mit callback Funktionen unterschiedlicher Priorit t registrieren um ber ein neues Paket infor miert zu werden Daraufhin verarbeiten sie das Paket und melden einen Verarbei tungsstatus zur ck Neben den Funktionen des Paketfilters passieren die Pakete wei tere Behandlungsroutinen Darunter sind die Quality of Service Behandlung und das Routing Im netfilter Framework einschlie lich der aktuellen Version in Linux 2 6 20 k nnen die Erweiterungen unter folgenden Entscheidungen w hlen Paket wurde akzeptiert und darf weiter verarbeitet werden ACCEPT Paket wird verworfen DROP Pa ket wird im Userspace weiterverarbeitet QUEUE Weiterbehandlung wartet auf ein Ereignis und Paket wird festgehalten STOLEN sowie das Paket soll den Zugriffs punkt nochmal von vorne durchlaufen REPEAT Das Konfigurationsprogramm iptables nutzt diese Infrastruktur und verwaltet die Benutzerregeln in mehreren Tabellen die sich je nach Aufgabe an unterschiedlichen Zugriffspunkten registrieren iptables in der untersuchten Version 1 3 5 kennt in der Standardkonfiguration die Tabellen filter nat mangle raw und conntrack wobei nur die ersten vier vom Benutzer manipulie
62. IOS Router k nnen um ein Firewall Modul erweitert werden wodurch sie auch komplexere Filterungen durchf hren k nnen Die Cisco PIX Firewall hat im Gegenzug auch eingeschr nkte Routingfunktionen 21 3 Merkmale der Firewallsysteme einfaches Load Balancing angegeben werden k nnen F r die NAT Umsetzung von Protokollen auf Anwendungsebene z B FTP k nnen Proxies im Kernel oder trans parente Proxies im Userspace eingesetzt werden In Abschnitt 2 1 auf Seite 7 wurden die zwei Betriebsarten Routing und Bridge modus vorgestellt Au er der Cisco PIX unterst tzen alle Firewallsysteme beide Betriebsarten Im Bridgemodus wie auch im Routingmodus mit dem gleichzeitigen Einsatz von SNAT nimmt die Firewall die Pakete f r die hinter ihr liegenden Systeme entgegen indem sie sich f r sie ausgibt Dies wird erreicht durch das Aktivieren von ProxyARP auf den gew nschten Netzwerkschnittstellen ProxyARP kann bei allen Systemen konfiguriert werden Eine zus tzliche Separationsebene zwischen den Systemen in einem Netzwerk kann mittels VLAN erfolgen das ein physisches Netz in weitere logische und vonein ander getrennte Netzwerke aufteilt Dadurch kann einerseits die Sicherheit erh ht werden da nur noch Systeme innerhalb eines logischen Netzes miteinander kommu nizieren k nnen und andererseits wird durch die gleichzeitige Einschr nkung der Broadcast Dom nen die Netzwerkauslastung verbessert Alle untersuchten Systeme unterst tzen den Bet
63. IPTables Struktur einer ISO9646 Testsuite Konzeptionelle Testarchitektur Testmethoden nach ISO IEC 9646 f r vermittelnde Systeme Abstraktionsebenen beim Testen von Firewalls 22222 Problem der Zustandsexplosion Diagonale Wahl der IP Adressen und Ports 2 2 22 2 2020 Ben tigte Informationen f r die Teststrategie 2 2 2 Interaktion der Komponenten in FWTStrategy 2 2 2 Entscheidungsgraph zur Testauswertung Modularchitektur der Teststrategie Klassen des Ticketsystems Klassen der TCP Zustandsverfolgung 13 18 30 31 32 33 34 35 36 37 39 41 50 ol 52 53 54 56 61 62 63 64 65 68 70 73 76 89 90 93 vil Abbildungsverzeichnis A 1 FWA Klassen A 2 Aufbau der Testumgebung viii Tabellenverzeichnis 2 1 Unterscheidungsmerkmale von Firewall Inspektionstypen 8 2 2 Sicherheitsziele und Angriffsklassen 0 11 2 3 Vergleich der betrachteten Firewalls a 14 3 1 Unterst tzte traffic Regulierungen llle 20 3 2 Filterkriterien von iptables 2 2 omo eR I X 28 3 3 M gliche Aktionen des iptables Paketfilters 28 4 1 Zusammenfassung der Zustandsinformationen bei ipfstat 44 4 2 Aufschl sselung der Protokollzust nde bei PF 2 2 2 45 4 3 Feldbeschreibungen in Zustandsinformationen bei FW 1
64. PLE self udp 10 0 1 2 23449 10 0 1 21 7594 SINGLE MULTIPLE all tcp 10 0 1 21 2212 gt 10 0 1 1 55070 10 5 5 5 22 EST EST Listing 4 5 Beispiel f r PF Zustandsinformationen Zustand t in sec Beschreibung tcp first 120 nach dem ersten Paket tcp opening 30 bevor das Ziel nur ein Paket gesendet hat tcp established 86400 vollst ndig aufgebaute Verbindung tcp closing 900 nach dem ersten FIN Paket tcp finwait 45 nachdem beide Seiten FIN gesendet haben Die Ver bindung ist geschlossen tcp closed 90 nachdem ein RST gesichtet wurde udp first 60 nach dem ersten Paket udp single 30 nachdem nur eine Seite mehrere Pakete verschickt hat udp multiple 60 nachdem beide Seiten Pakete geschickt haben icmp first 20 nach dem ersten Paket icmp error 10 nachdem eine ICMP Fehlernachricht als Antwort auf ein ICMP Paket gesichtet wurde other first 60 nach dem ersten Paket other single 30 nachdem nur eine Seite mehrere Pakete verschickt hat other multiple 60 nachdem beide Seiten Pakete geschickt haben Tabelle 4 2 Aufschl sselung der Protokollzust nde bei PF Das Verhalten der Verbindungsverfolgung l sst sich sehr umfangreich anpassen Neben den festen und adaptiven G ltigkeitsdauern f r Eintr ge sind auch Beschr nk ungen der maximalen Anzahl von Zust nden von Fragmenten und von Eintr gen pro Quelladresse regulierbar jeweils global und pro Regel Daneben kann f r Zustands eintr ge eine Alter
65. R 0 INV 1 NEW 2 EST 3 REL 4 Ec 4 tus class Vector fwa Vector def init self new_data self d self d index Path progress_idx new_data self d proto Path proto new_data self d dir Path dir new_data self d route Path route new data self d sip Path sip new data self d dip Path dip new_data self d assoc Path assoc new_data self d sport Path sport new_data self d dport Path dport new_data self d tflags Path tflags new data self d itype Path itype new data self d icode Path icode new data self d logpref Path logpref new data self d lpath Path linepath new_data Listing A 2 Deklaration der Vektordatenstruktur Im zweiten Teil wird eine Liste von Vektoren mit der Bezeichnung path vl angelegt Jeder Testvektor wie in Listing A 3 dargestellt beschreibt die Werte der verschie denen Aspekte als Tupel Einige Parameter z B sip und dip sind als Bereiche route und dir als einzelne Werte linepath als Liste und await als Hashtabelle definiert path_vl r ENT Path Vector progress idx 15 proto TCP TCP route UNSPEC dir FORWARD sip 0 0 0 0 255 255 255 255 dip 0 0 0 0 255 255 255 255 sport 0 65535 dport
66. RETURN K 5 Action i D Action Aktion mit Verzweigung D Default Action J Abbildung 5 2 Verzweigungsarten bei der Regelauswertung stellen Diese zwei Arten sind ebenfalls an iptables angelehnt Das iptables JUMP ist von der Wirkung her hnlich zum jump subroutine jsr aus der Assembler Programmierung Dabei wird die Position in der aufrufenden chain gespeichert und bei explizitem RETURN bzw Ende der aufgerufenen chain wieder fortgesetzt Der Sprungbefehl GOTO dagegen ist mit dem einfachen jump jmp vergleichbar ret tet nicht die Position der gerade aufrufenden chain und setzt beim R cksprung die Bearbeitung bei der zuletzt geretteten Position fort Bei iptables wird die Standard Richtlinie default policy als oberstes R cksprungziel vorgegeben Die Verzweigun gen anderer Firewalls lassen sich auf diese Verzweigungsarten abbilden Das Ergebnis einer Anweisung kann wie bereits erw hnt den Entscheidungspfad beeinflussen indem die Bearbeitung nach einer Entscheidung f r das betrachtete Ereignis Paket fortgef hrt oder abgebrochen wird Damit wird neben einer funk tionellen Klassifizierung der Anweisungen eine weitere eingef hrt die den Paketfluss ber cksichtigt Art Beispiele terminierend Drop und Reject nicht terminierend Modifikationen von IP Optionen TTL Fragmentierungsbits TOS Feldern sowie TCP Sequenznummern und MSS interne Markierungen Logging und Ac
67. RL https www usenix org events usenix05 tech freenix full_papers marmorstein marmorstein html Mayer Alain Avishai Wool und Elisha Ziskind Fang A Firewall Analysis Engine In Symposium on Security and Privacy IEEE 00 2000 ISSN 1540 7993 DOI 10 1109 SECPRI 2000 848455 Mayer Alain Avishai Wool und Elisha Ziskind Offline firewall analy sis In International Journal of Information Security 5 3 Juni 2005 pp 125 144 ISSN 1615 5262 DOI 10 1007 s10207 005 0074 z Prunoiu Florin Cisco PIX Firewall Practical Guide 10 Aug 2004 URL http www enterastream com whitepapers cisco pix pix practical guide html besucht am 23 07 2007 Ranum Marcus J What is Deep Inspection The speaker break room Interop Mandalay Bay Hotel and McCarran Airport Gate 33 06 Mai 2005 URL http www ranum com security computer security editorials deepinspect besucht am 23 07 2007 Postel Jon RFC792 Internet Control Message Protocol 1981 URL ftp ftp rfc editor org in notes rfc792 txt besucht am 26 06 2007 Mogul J und Jon Postel RFC950 Internet Standard Subnetting Procedure 1985 URL http www rfc editor org rfc rfc950 txt besucht am 26 06 2007 RFC1108 RFC1122 RFC1256 RFC1812 RFC2002 RFC2663 RFC3022 RFC3027 RFC3489 Ro000 Roy87 RW02 Sch03 Kent Stephen RFC1108 U S Department of Defense Security Op tions for
68. TPUT registriert wo neue Zust nde erstellt werden in der Abbildung mit add state gekennzeichnet In den Zu griffspunkten POSTROUTING bzw INPUT werden die Eintr ge best tigt state ack Diese Zweiteilung wird durchgef hrt um nur gefilterte und zugelassene Pakete zu verwalten raw Die raw Tabelle wurde erst nachtr glich 2003 hinzugef gt um bestimmte Pa kete von der Verbindungsverfolgung ausschlie en zu k nnen Sie wird vor dem conntrack in PREROUTING und OUTPUT registriert Andere netfilter bezogene Parameter die bei der Konfiguration und vor allem bei 3l 4 Funktionsweise der Paketfilter der Verbindungsverfolgung ber cksichtigt werden sollten steuern die Timeouts die Gr fe der Tabelle oder das Logging Ein Ausschnitt der wichtigsten Parameter ist im Anhang in Tabelle A 2 gelistet und in Spe06 ausf hrlich beschrieben IPFW IP FireWall In dieser Sektion zu IP FireWall werden die zwei gefundenen Varianten des Paket filters vorgestellt Die erste Variante wurde unter FreeBSD analysiert und ist heute noch im Einsatz Die Variante von BSD OS ist nicht mehr verf gbar wird aber auf grund der abweichenden Architektur vorgestellt die gleichzeitig als einzige mit der netfilter Architektur vergleichbar ist Bei FreeBSD IPFW kann ein Paket an mehreren Stellen des Protokollstapels mit den aktiven Regellisten verglichen werden was durch Systemvariablen gesteuert wird vgl dazu auch die Struktur des Regelwerks in Abs
69. Technische Universit t Berlin SS 2007 Fakult t IV Elektrotechnik und Informatik Institut f r Telekommunikationssysteme Kommunikations und Betriebssysteme Diplomarbeit Entwicklung einer allgemeinen Teststrategie f r zustandsbehaftete Paketfilter cand Inform Nikolaus Filus 15 August 2007 Prof Dr Hans Ulrich Hei Diese Arbeit wurde mit Hilfe von KOMA Script und IXTEX gesetzt Network monitoring tells what has happened Network testing tells what will happen The Art of Testing Network Systems R W Buchanan Wiley 1996 Inhaltsverzeichnis Abbildungsverzeichnis vii Tabellenverzeichnis ix Listings xi 1 Einleitung 1 ke Zielder Arbeit soseta Ge dee oso petu Be D S um C rM agree D fana 2 1 2 Vorgehen und Struktur 2 2 du Sg Gash Goo ES ee eke aed 3 2 Firewalls 5 2 1 Netzwerkfunktionen und Firewalltypen 5 2 2 Sicherheitsziele und deren Bedrohungen 10 2 3 Auswahl und Klassifizierung repr sentativer Firewallsysteme 13 3 Merkmale der Firewallsysteme 17 3 1 Sicherheits und Netzwerkfunktionen 2 2 222 2 17 3 2 Merkmale der Regelverarbeitungs und Filtereinheiten 22 3 3 Vergleich und Bewertung der Paketfilter 27 4 Funktionsweise der Paketfilter 29 Tug PakerHussos aes La LEA doses Saa ne 29 4 2 Zustandsbehaftete Verbindungsverfolgung 38 5 Allgemeines Modell f r zustandsbehaftete Paketfilter 49 5 1 Bausteine de
70. Teststrategie Der grobe Ablauf der Teststrategie wurde bereits in Abschnitt 7 2 vorgestellt In Erg nzung dazu wird hier die Interaktion der einzelnen Module beschrieben Abbildung 8 1 zeigt die Modularchitektur der Teststrategie Zentrale Komponente der Teststategie ist die Teststeuerung FWTStrategy Sie steuert und interagiert mit verschiedenen Modulen die f r verschiedene Aufgaben zust ndig sind und Dienste bzw Schnittstellen f r die anderen Module anbieten Alle Funktionen zum Einlesen und Verarbeiten der Vektoren sind in der Funktions bibliothek veclib zusammengefasst Darunter sind auch Funktionen zum berf hren der Vektoren in die intern verwendeten Testf lle Die firewallspezifischen Definitionen Funktionen und Strukturen sind f r den im Prototyp ber cksichtigten Paketfilter in der netfilterLib enthalten Zu den wich tigsten Komponenten dieses Moduls geh ren die Beschreibung der TCP Zustands verfolgung und die Funktionen zur Auswertung der Aktionen bzw zur Abbildung der Filterkriterien in den Paketeigenschaften Die Zustandsverfolgung setzt auf ei nem generischen Automaten aus dem Modul conntrackFSM auf Zur Berechnung und Verwaltung der Testf lle sowie der Testpunkte werden die Module bitVector TreeNode und ticketing verwendet Mit Hilfe der Struktur bitVector und den darauf basierenden Operationen ist es m glich besonders einfach alle diagonalen Testpunkte f r einen gegebenen Testfall zu bestimmen In TreeNode wird di
71. User Datagram Protocol UDP Through Network Address Translators NATs 2003 URL http www rfc editor org rfc rfc3489 txt besucht am 26 06 2007 Van Rooij Guido Real Stateful TCP Packet Filtering in Ipfilter In 2nd International SANE Conference 2000 Royce Winston W Managing the development of large software systems concepts and techniques In ICSE 87 Proceedings of the 9th international conference om Software Engineering Los Alamitos CA USA IEEE Computer Society Press 1987 ISBN 0 89791 216 0 pp 328 338 Russell Rusty und Harald Welte Linux netfiller Hacking HOW TO Juli 2002 URL http www netfilter org documentation HOWTO netfilter hacking HOWTO html besucht am 26 06 2007 Sch fer G nter Netzsicherheit Algorithmische Grundlagen und Pro tokolle dpunkt verlag 2003 ISBN ISBN 3 89864 212 7 141 Quellenverzeichnis Sch97 Spe06 Vig97 VP05 Wel07 Woo0 1 Woo04 X290 Yua06 ZCCO00 Schuba Christoph L u a Analysis of a Denial of Service Attack on TCP In Proceedings of the 1997 IEEE Symposium on Securi ty and Privacy IEEE Computer Society IEEE Computer Society Press 1997 pp 208 223 URL https www cerias purdue edu techreports ssl public 97 06 ps Spenneberg Ralf Linuz Firewalls mit iptables amp Co M nchen Germany Addison Wesley Verlag 2006 Vigna Giovanni A Formal Model for Firewall Testing unpubli
72. abelle 5 2 auf gef hrt sind Funktionen Paketfilter Paketmodifikation NAT Routing IDS IPS Proxy Authentifikation QoS VPN Arbeitsobjekte Pakete Paketverwaltungsbl cke Regelwerk e Rou tingtabelle n Zustandsdaten Assoziationen Modifikationen IP Fragmente NAT Eintr ge Statistikdaten Zustandsfunktionen anlegen aktualisieren abfragen anwenden l schen Tabelle 5 2 Arbeitsdaten und mittel der Firewallsoftware Durch unterschiedliche Nutzungen der Arbeitsobjekte der Zustandseintr ge und funktionen lassen sich verschiedene Abl ufe bei der Paketverarbeitung festlegen Durch die Abfrage der bereits vorhandenen Zustandseintr ge f r das aktuell unter suchte Paket k nnen abh ngig vom internen Zustand unterschiedliche Abl ufe rea lisiert werden So werden zur Optimierung der Rechenzeit und der Laufzeit h ufig 53 5 Allgemeines Modell f r zustandsbehaftete Paketfilter die aufwendigeren Vergleiche mit dem Regelwerk bersprungen wenn ein geeigneter Zustandseintrag vorhanden ist und angewendet werden kann 5 2 Anwendung auf Firewallfunktionen Die in Tabelle 5 2 genannten Funktionen und Arbeitsmittel der Firewalls werden in diesem Abschnitt mit den vereinbarten Symbolen modelliert und besprochen Aus der Gruppe der Funktionen werden die Paketfilterung die Paketmodifikation NAT und Routing behandelt Die ID amp P Komponenten Authentifikation QoS und VPN werden nur als eine nicht n her definierte Black Box
73. ablen ablegen und in den Regeln referenzieren PF kann hnlich zur IPFW Adressen und Ports in Listen zusammenfassen Bsp 10 1 0 0 24 10 2 1 1 sie ber Variablen referenzieren sowie Tabellen benut zen Ein besonderer Anwendungsfall f r Tabellen ist das dynamische Hinzuf gen von Elementen beim berschreiten von definierten Obergrenzen f r Verbindungen oder Verbindungsversuche Die betroffenen Eintr ge z B angreifende Systeme k nnen dann mit anderen Regeln gesondert behandelt werden Vergleichbare Funktionalit t ist bei iptables mit dem recent Modul erreichbar das nach frei w hlbaren Kriterien Quelladressen in Tabellen eintragen bzw aktualisieren kann Die Objektgruppen der PIX k nnen Netzwerke Systeme Dienste Protokolle 24 3 2 Merkmale der Regelverarbeitungs und Filtereinheiten ICMP Typen und weitere Objektgruppen vom gleichen Typ zusammenfassen Sie werden anschlie end in den access lists referenziert Die gesamte Konfiguration der FW 1 basiert auf Objekten Vor der Regelerstellung muss der Administrator alle Netzwerkobjekte anlegen und kann sie daraufhin in den Regeln referenzieren Dienste sind bereits vordefiniert und k nnen erweitert werden Eine weitere M glichkeit Eigenschaftsbereiche zusammenzufassen wird vor allem in NAT Regeln verwendet und ist deshalb oft unter der Bezeichnung NAT Exemption anzutreffen Hierbei handelt es sich um die M glichkeit zuerst spezielle Bereiche aus dem NAT auszuschlie en
74. ache Protokollfl sse zu reduzieren so dass sie jeder spezifikationskonforme Paketfilter akzeptiert Die Tests sollen unter Labor und Realbedingungen also nicht nur in einer Labor umgebung mit direktem bzw exklusivem Anschluss an den Probanden durchf hrbar sein Die Umsetzung der Teststrategie ben tigt Informationen auf deren Grundlage die Planung und Steuerung der Tests durchgef hrt werden kann Wie in Abbildung 7 1 dargestellt sind das eine Beschreibung des Probanden dessen Konfiguration die zu untersuchenden Testvektoren und die Protokollspezifikationen mit denen der Test umgesetzt wird Die Teststrategie steuert den Testablauf stimuliert den Probanden und wertet die Ergebnisse aus Testvektoren Firewall beschreibung Firewall Protokoll konfiguration spezifikation Abbildung 7 1 Ben tigte Informationen f r die Teststrategie Strategie Zur Beschreibung des Probanden geh ren die produktspezifischen Eigenschaften Dazu z hlen die internen Mechanismen bei der Abarbeitung der Pakete evtl vorein gestellte Standardeinstellungen und implizite Filterfunktionen oder die verwendete Zustandsverfolgung mit ihren Timeouts Basis der Firewallbeschreibung bildet das entwickelte Modell welches abstrakte Funktionsbausteine verwendet die in Fire wallsystemen und Paketfiltern identifiziert wurden und mit denen sich durch eine geeignete Kombination verschiedene Produkte abbilden lassen Das Modell hilft den internen Pa
75. ag der ber das Ereignis event den Zeitstempel tstamp eine G l tigkeitsdauer timeout und den Inhalt data beschrieben wird hasExpired Abfragefunktion zur Feststellung ob der Logeintrag entsprechend des Zeitstempels und der G ltigkeitsdauer noch g ltig ist getTimestamp Liefert den Zeitpunkt der Erstellung des Eintrags zur ck match event data Vergleichsfunktion Liefert einen Wahrheitswert ob dieser Ein trag mit einem ber event und data beschriebenen Eintrag bereinstimmt class timedRingBuffer Der timedRingBuffer ist ein Ringspeicher der nur Eintr ge bis zu einer voreinge stellten Dauer beh lt und sie danach verwirft timedRingBuffer age max Konstruktorfunktion Legt einen timedRingBuffer mit der maximalen G ltigkeitsdauer von age maz f r dessen Eintr ge append x F gt der vorliegenden Instanz einen neuen Eintrag hinzu cleanExpired Entfernt alle Eintr ge aus dem Speicher die die voreingestellte G ltigkeitsdauer berschritten haben 92 8 1 Modulkonzept conntrackStateMachine state state state name string states list transitions list conntrackStateMachine state name add name origin flags newstate addTrans origin flags newstate setStart name getTrans go origin flags simulate state origin flags t getState getStates getStateTrans name Abbildung 8 3 Klassen d
76. allem durch den Einsatz von kryptopgrafischen Pro tokollen umgesetzt Verf gbarkeit der Dienste Firewalls setzen Mechanismen ein mit denen sie die Verf gbarkeit der anderen Kno ten erh hen k nnen Dazu k nnen sie z B stellvertretend f r die Dienste antworten und den Verbindungsversuch verifizieren SYN Proxy mit einem verk rztem Ti meout die berlastung verhindern SYN Gateway die Quelladressen auf Erreich barkeit pr fen Anti Spoofing Beschr nkungen bez glich der Verbindungsversuche pro Zeiteinheit setzen und strikte Timeouts einhalten Der Einsatz eines SYN Proxies f r TCP Verbindungen verhindert das berlaufen der Zustandstabelle durch Verbindungsversuche von gef lschten Adressen Nach ei nem erfolgreichen und legitimen Verbindungsaufbau werden weitere Pakete nur noch mit der Zustandstabelle und den dort gespeicherten Daten verglichen Von den un tersuchten Firewalls bieten nur Checkpoint FireWall 1 und Packet Filter einen SYN Proxy erste sogar die zwei Mechanismen in Abbildung 3 1 17 3 Merkmale der Firewallsysteme A FW B A FW B 0 SYN 0 LV SYN eYN AC Zn Br _SYN AGK A Drs c pee ded ACk only SENE d d c es gt active GW il Het b po ce timeout t t I HEP Y Y Y a SYN Proxy b SYN Gateway Abbildung 3 1 Schutzvarianten gegen SYN Flooding Damit die Firewall nicht auch berlastet wird neue Verbindungsversuche ablehnt und die Diensterreichbarke
77. alls eine besondere Ber ck sichtigung beim Testen weswegen eine Beschreibungsm glichkeit entworfen werden soll mit der das allgemeine Modell und die Teststrategie f r einen spezifischen Pa ketfilter in geeigneter Form vom Anwender eingestellt bzw angepasst werden kann Eine m glichst vollst ndige Abdeckung der identifizierten Merkmale soll erreicht und alle Abweichungen sollen begr ndet dokumentiert werden Schlie lich soll eine f r die Testumgebung konfigurierbare Teststeuerung entwor fen werden die durch aktives aber ressourcenschonendes Testen die spezifikations konforme Funktionsweise des Paketfilters berpr fen kann Eine Beschreibung der Netzwerkumgebung des Probanden soll ber cksichtigt werden sodass nicht nur La bortests sondern auch Tests in einer Produktivumgebung m glich werden Die Auf gabenstellung gibt vor dass die Teststrategie auf den zwei Werkzeugen FWA und FWTest aufbauen soll die im Fachbereich Kommunikations und Betriebssysteme der TU Berlin entwickelt wurden Dabei analysiert der FWA die produktabh ngige Konfiguration eines Paketfilters und errechnet daraus die zu untersuchenden Eigen schaften Die Teststrategie soll auf dieser Analyse aufbauen und mit Hilfe von FW Test die Testpakete generieren sowie mit dem Paketfilter kommunizieren Die Untersuchungsergebnisse der Teststrategie sollen f r den Anwender in unter schiedlichen Detaillierungsgraden aufbereitet werden um Fehlerquellen nderungs potent
78. arbeitungszeit konnten nur ausgew hlte Funktionen umgesetzt werden die aber die Grundlage jeder Konfiguration darstellen und die M glichkeiten der Teststrategie aufzeigen F r die Fortf hrung der vorliegenden Arbeit bietet es sich zun chst an die feh lenden Filterkriterien und Filteraktionen des netfilter iptables Paketfilters zu ver vollst ndigen Damit k nnte die Testabdeckung f r diesen Paketfilter erh ht werden und die M chtigkeit der Programmschnittstellen berpr ft werden Die Untersuchung beschr nkte sich auf die Umsetzung einer Teststrategie f r die Protokolle T CP UDP und ICMP ohne die Anwendungsprotokolle zu ber cksichtigen Damit k nnen keine Protokollfl sse f r den related Zustand bei TCP und UDP her gestellt werden Die Erweiterung der Teststrategie auf die Herstellung von Proto kollfl ssen der Anwendungsebene bedarf der Entwicklung einer neuen Schnittstelle die auf Basis der implementierten Steuerung der Netzwerk und Transportschicht auch die Nutzlast der Anwendungsschicht steuern testen und auswerten kann Eine m gliche Fortf hrung der Arbeit k nnte die Eignung von Agenten oder Automaten f r die Realisierung der Protokollinstanzen untersuchen Die Teststrategie baut zur Stimulation des Probanden auf dem Programm FW Test auf Damit ist eine Kommunikation von zwei Protokollpartnern durch die Firewall m glich Die aktuelle Architektur der FWTest Agenten schr nkt deren Betrieb auf Linux Systeme ein wodurch
79. arianten Cisco PIX 6 3 1994 HW OS Finesse kommerziell Systems CheckPoint Firewall 1 SPLAT R60 1994 HW Bundle kommerziell Software SecurePlatform Tabelle 2 3 Vergleich der betrachteten Firewalls Die beiden kommerziellen Vertreter geh rten laut IDC im Jahr 2004 zu den f nf st rksten Anbietern im westeurop ischen Gebiet Netfilter Netfilter ist eine Kernel Schnittstelle zur Reglementierung von Paket fl ssen und bildet die Basis f r alle Firewallfunktionen unter Linux Netfilter exis tiert seit 1999 und nutzt die mit dem bis zur Kernelserie 2 3 eingesetzten Firewall system ipchains gewonnenen Erfahrungen um dessen Schw chen zu beseitigen Die Regeln werden in Tabellen abgelegt und je nach Betriebsmodus der Firewall ber die Kommandozeilenprogramme iptables bzw ip6tables sowie ebtables und arptables konfiguriert Die beiden ersteren sind Bestandteil des iptables Paketes und dienen zur Reglementierung von IPv4 und IPv6 im Routingmodus Ebtables und arptables sind im ebtables Paket enthalten und erm glichen die Konfiguration einer bridging Firewall IP FireWall IPFW bezeichnet sowohl den Filter Code im Kernel als auch das Kommandozeilenprogramm IPFW zum Einstellen der Filterregeln IPFW geh rt zu den ltesten Unix Firewalls weswegen die ersten Quellen auch auf das Jahr 1993 und BSD OS der Firma BSDi zur ckzuf hren sind wo es bis zum Ende der Distribution im Jahre 2003 weiterentwickelt wurde IPFW wurde im November 1994 off
80. ath fw type name iptables version 7 fw tool name iptables save version analyzer name fwa version 7 vector name v3p version path vl path_vl al path al tn path tn Listing A 1 Hauptzugriffsstruktur einer Vektordatei C object gt index literal_listbynature r literal static literal dynamic A n literal listbynature lin m literal_static_lin id literal_dynamic_lin E to to to A 4 A N mt 12 be ife iifa etc itype pot eae air route fe oife limits oife oifa icode assoc await strategy literal_ipv4 y to literal_static_exp frbits tobits t literal_port tflags Abbildung A 1 FWA Klassen 129 Anhang A Anhang Die Deklaration der Datenstruktur wurde in Form von Python Klassen vorgenom men und setzt auf abstrakt definierten Datentypen aus dem Python Modul fwa py auf welches Teil des FWA Paketes ist Alle hier definierten und in den Vektoren benutzten Typen sind davon abgeleitet und in Abbildung A 1 dargestellt import fwa class Path object class pol fwa literal static lin val2index DROP 0 ACCEPT 1 REJECT 2 class assoc fwa literal static lin val2index UT
81. auf beiden Systemen gestartet werden Danach kann FWTStrategy mit Hilfe fwtest gestartet werden Ein erforderlicher Aufruf sieht wie folgt aus wobei das gleich nach der Option o gegebene Parameter eine durch fwa erzeugte Testvektoren Datei ist fwtest a 192 168 10 2 b 192 168 10 3 1500 f FWTStrategy py o udp vec 134 A 3 Benutzerhandbuch Ausgaben und deren Bedeutungen Nach der unterschiedlichen Debuglevel Einstellung ist es m glich eine einfache oder detaillierte Ausgabe zu erhalten Eine Beispielausgabe sieht wie folgt aus Wie im Abschnitt 7 1 erw hnt wurde besteht jeder Testfall aus zwei Testpunkten Zeile 4 und Zeile 20 In diesem Beispiel wird der Vektor 10 getestet wobei ein ICMP Paket von A Seite zu B Seite mit REL Zustand gesendet werden soll Zeile 14 und Zeile 23 Um einem REL Zustand erreichen zu k nnen wird zuerst eine Vorgeschichte mit den Zust nden NEW und EST erstellt Zeilen 5 8 21 und 22 Die Zeilen 6 9 und 15 sind Referenzen zu Regeln in der Firewallkonfiguration Die ausf hrliche Information des gesendeten Pakets befindet sich zwischen den Zeilen 11 bis 13 wobei die Zeile 12 enth lt was f r ein Paket der Empf nger erhalten hat Am Ende wird eine statistische Information ausgegeben Zeilen 26 51 In diesem Beispiel wurden 348 Testf lle erzeugt Davon wurden 248 Testf lle nicht getestet wo bei die Begr ndungen in den Zeilen davon aufgeschl sselt sind Aus den 79 Testf llen wurden schlie lich
82. b2 und Rusty 2 verwenden neben ACCEPT DROP und REJECT auch MASQUERADING als Aktionen TC not implemented Bad Protocol NO In Paths Config Vec Total UTR U REL T REL Properties Prehistory Test Skip Skip In Test TP Uniseb2 368 488 70 24 72 78 94 135 15 1224 257 514 ICMP 20 150 30 2 2 46 32 38 0 1032 38 76 Rusty 2 5 30 6 2 2 17 3 5 19 38 clean 2 30 6 2 2 14 6 2 22 44 Tabelle 9 1 Auswertung der Testabdeckung f r Beispielkonfigurationen Die Ergebnisse der Auswertung nach der Durchf hrung der Tests mit den Konfi gurationen werden angelehnt an die Tabelle 7 4 in Tabelle 9 1 aufgeschl sselt Die Spalten sind wie folgt zu lesen Config Name der Konfiguration Vektoranzahl Anzahl der vom FWA berechneten Vektoren TC Total Die Anzahl der Testf lle die aus den Vektoren abgeleitet wurden Sie sind die obere Schranke der m glichen Tests 104 9 2 Beispiele der Testabdeckung not implemented Im Prototyp konnte nur eine Auswahl von Tests umgesetzt wer den Zu den fehlenden Tests geh rt eine Umsetzung des untracked Zustandes UTR der Verbindungsverfolgung sowie der related Zustand f r UDP und TCP Letztere beiden ben tigen die Implementierung eines Anwendungspro tokolls wie FTP oder H323 f r die iptables spezielle Erweiterungen anbietet Die Vervollst ndigung der Testabdeckung f r den untracked Zustand konnte in der gegebenen Bearbeitungszeit nicht gel st werden Alle drei F
83. ber NAPT und beschr nkt auch die Integrit t der Daten z B durch die berpr fung der Checksummen und der Sequenznummern umsetzen Angriffe auf die Vermittlungs und Transportschicht geh ren zu dem Standardre pertoire der verf gbaren Angriffswerkzeuge und k nnen inzwischen von allen Pa ketfiltern abgewehrt wrden Zu diesen Angriffen geh rt Adressf lschung Erkundung von Netzwerken Session Hijacking bzw Packet injection und verschiedene Sabotage Akte Weitere und immer noch erfolgreiche Angriffe nutzen Schw chen der Dienste und der Applikationen aus Deswegen ist f r eine striktere Umsetzung der Sicher heitsziele und Abwehr der Angriffe eine Kombination mit den anderen vorgestellten Schutzkomponenten und konzepten notwendig was den Trend zur Integration der Komponenten in ein Unified Threat Management unterst tzt Sicherheitsrichtlinien Der Schutzbedarf und die Schutzma nahmen f r eine organisatorische Einheit werden in sogenannten Sicherheitsrichtlinien engl security policy definiert Nach BSI06 werden Sicherheitsrichtlinien mehrstufig aufgebaut Die oberste Leitlinie wird i d R von der Gesch ftsleitung als Teil der unternehmensweiten allgemeinen Sicherheits ziele die auch Datenschutz Personensicherheit Ger teschutz Computer und Netz werksicherheit beinhaltet aufgestellt Diese Richtlinien sind meist so informell so wie allgemein genug und unabh ngig von einer konkreten Umsetzung gefasst dass nderungen sel
84. ber die gew hlten Parameter und Standardwerte im PIXIT protocol implementation extra information for testing an gegeben Damit die Tests entsprechend den Formularen konsistent und in einer definier ten Form ausgew hlt werden k nnen schl gt ISO9646 eine Strukturierung f r die Testreihen test suite vor die in Abbildung 6 1 in UML Notation abgebildet ist 0 0 Test Suite 9 Test Group Test Case 9 7 Test Step x Test Event Abbildung 6 1 Struktur einer ISO9646 Testsuite Weiterhin wird f r die Konformit tstests analog zu den OSI Protokollen die keine bestimmte Implementierung vorschreiben zuerst eine abstract test suite ATS spezifiziert die in einer parameterized executable test suite PETS bzw ETS umgesetzt wird Die ATS ist eine Sammlung von Testdaten und Testf llen die eine 61 6 Testen abstrakte Sicht auf Aspekte wie Kommunikation Zeit oder Daten haben Die P ETS kann dagegen in einer realen Umgebung ausgef hrt werden Um die Testf lle in einer realen Umgebung ausf hren zu k nnen bedarf es einer Interaktion zwischen dem Probanden und dem Tester Im I809646 Jargon hei t die Komponente die Gegenstand des Konformit tstestens ist implementation under test IUT und kann eine oder mehrere Protokolle in derselben OSI Schicht oder benachbarten Schichten umfassen Die IUT ist also ein Teil eines
85. bh ngig von der Betriebsart der Firewall Die Art und Tiefe der Inspektion hat sich mit der Zeit weiter entwickelt so dass nun verschiedene Schutzkonzepte nebeneinander existieren und sich erg nzen Tabelle 2 1 fasst die Arten zusammen und schl sselt die untersuchten OSI Ebenen mit ihren Eigenschaften auf vgl hierzu auch ZCC00 Kap 5 und Spe06 Kap 2 OSI Layer Typ 3 4 5 7 untersucht stateless filter V v IP Ports stateful filter Vv v IP Ports Verbindungszustand Proxy ALG v Anwendungsspezifische Untersuchungen IDS IPS v Signaturen Heuristiken Anomalieerkennung Deep Packet Inspection v v Vv Stateful Filtering IDS IPS UTM v v v DPI Anti Virus Tabelle 2 1 Unterscheidungsmerkmale von Firewall Inspektionstypen Die fr hen Paketfilter beherrschen das sogenannte stateless filtering untersuchen die OSI Schichten 3 und 4 und werten statische Eigenschaften jedes einzelnen Paketes kontextfrei aus Einige Varianten unterst tzen auch die Untersuchung der Schicht 2 Sp ter wurden zustandsbehaftete Paketfilter stateful filtering entwickelt die im Vergleich zum stateless filter auch dynamische Eigenschaften der OSI Schicht 4 be r cksichtigen Im Gegensatz zu den einfachen Paketfiltern haben sie eine begrenzte Vorstellung von einer Assoziation und dem Protokollfluss zwischen den Endpunkten wodurch sie abh ngig von der Phase der Assoziation gezielter reglementieren k nnen Neuer
86. bschnitt wird erl utert wie eine Teststellung mit FWTStrategy aufgebaut werden kann Daf r wird die Konfiguration und der Betrieb des Werkzeugs beschrie ben F r einen konkreten Einsatz werden die Ergebnisse eines Testlauf beschrieben und Hinweise gegeben wie diese zu interpretieren sind Aufbau und Konfiguration einer Testumgebung FWTStrategy wird zusammen mit dem FWA und FW Test in einer Versionsverwal tung unter svn seclab kbs cs tu berlin de fwtest entwickelt F r das Her unterladen der Projektquellen ist ein Subversion Client notwendig Die Software wurde f r Linux entwickelt und auf mehreren aktuellen Systemen getestet Neben den Bibliotheken die in der Dokumentation der Werkzeuge beschrieben sind wird Python ben tigt Es wird zumindest die Version 2 4 empfohlen Die Dokumentation zu FW Test enth lt man pages fwagent 1 und fwtest 1 in der die Bedienung und Konfiguration beschrieben sind Der Betrieb von FWTStrategy wurde explizit auch in einer produktiven Umge bung vorgesehen F r eine erste Teststellung wird jedoch eine virtuelle Umgebung empfohlen Im Folgenden wird beispielhaft die Konfiguration einer Testumgebung unter der Virtualisierungsumgebung VMWare Server beschrieben unter der auch die Entwicklung betrieben wurde F r eine minimale Testumgebung werden entsprechend der Abbildung 7 2 mindes tens drei virtuelle Systeme ben tigt mindestens ein System mit einem Paketfilter und zwei Systeme f r die FWTest Agente
87. by NOT IMPLEMENTED untracked UTR association 14 by NOT IMPLEMENTED UDP related 50 by NOT IMPLEMENTED TCP related 15 by testcase already tested as prehistory 11 by itypes not testable in state NEW 8 by itypes not testable in state REL 32 by invalid TCP flags 7 by can t establish conformant packet flow from testpath 6 by no usable path found 40 by no prehistory can t test ESTABLISHED without prehistory 2 by no prehistory can t test RELATED without prehistory 248 TOTAL skipped 79 In Test 342 TOTAL testcases 168 by no usable prehistory after intersection 534 by invalid TCP flags 366 by can t establish conformant packet flow from testpath 156 by itypes not testable in state NEW 1224 TOTAL skipped 201 In Test testpoints tested tested 388 OK 14 FAILED 136 Listing A 5 Ausgabe von FWTStrategy Quellenverzeichnis Das Quellenverzeichnis ist in zwei Teile aufgespalten Unter den prim ren Quellen befinden sich alle publizierten Werke Dazu werden auch Handb cher und technische Standards hinzugef gt die teilweise online abgerufen werden k nnen Die referen zierten Werkzeuge und Projekte im Internet werden unter Projektseiten gef hrt Die Literaturangaben sind alphabetisch nach den Namen der Autoren bzw bei meh reren Autoren nach dem ersten Autor sortiert Webseiten werden mit einem eigenem Schl ssel aufgef hrt Prim re Quellen ASHO3 ASHOA Ayu06 B r94 Bar99
88. ch den gesetzten Zeitrahmen f r eine Diplomarbeit und die gew hlten Werk zeuge konnte nur ein Teil der konzeptionell erarbeiteten Teststrategie umgesetzt wer den Der Firewall Analyser konnte zum Zeitpunkt dieser Arbeit die Konfiguration ei ner netfilter iptables Firewall interpretieren und analysieren Andere Konfigurations sprachen sollen in Zukunft hinzugef gt werden Dadurch war nur eine Testumgebung verwendbar und die Anwendbarkeit der Teststrategie auf anderen Plattformen konn te nicht berpr ft werden Zur Entwicklung wurde der FWA in den Versionen der Serie 0 9 x verwendet worauf sich die folgenden Beschreibungen beziehen Getestet wurde mit den Standard netfilter Komponenten im Linux Kernel 2 6 x bis 2 6 20 und iptables in der Version 1 3 6 Die Tests konnten nur f r den vermittelnden Aspekt der Konfigurationen um gesetzt werden da die aktuellen FWTest Agenten nicht auf einer filternden Netz werkkomponente betrieben werden k nnen Deswegen konnten die von einer Firewall ausgehenden oder die dorthin gerichteten Assoziationen bei der Teststrategie nicht getestet werden Diese Einschr nkung reduzierte die Testabdeckung kann aber prin zipiell nur f r Firewallsysteme ge ndert werden auf denen der Administrator auch Fremdsoftware nachinstallieren kann Dies schlie t die meisten Hardware Appliances aus Bei der Auswahl der unterst tzten Filteraktionen und Filterkriterien von iptables musste aus Zeitgr nden eine Auswahl getroff
89. ch ist trotz der selektiven Tests in den Grenzbereichen der Segmente eine hohe Testabdeckung m glich Ports DPORT 2 4 nn 3 2 Z 3 F 4 E DPORT 1 is ron ee J Po 5 k 6 EN 7 8 SPORT 2 E SPORT 1 Le m SIP 1 SIP 2 DIP 1 DIP 2 IPs Abbildung 6 6 Diagonale Wahl der IP Adressen und Ports Nicht alle m glichen Kombinationen der Randpunkte m ssen getestet werden F r die berpr fung eines Segmentes m ssen jeweils die zwei begrenzenden Punkte Mini mum und Maximum aus jedem Aspekt gew hlt werden wodurch auch zwei Testf lle bzw Testpunkte pro Segment entstehen Betrachtet man die Testpunkte im geome trischen Raum so w rden sie zwei jeweils diagonal zueinander liegende Endpunkte beschreiben Bei n betrachteten Aspekten ergeben sich so 2 M glichkeiten f r die Wahl der gegen berliegenden Testpunkte Die Diagonalen werden ungerichtet betrachtet wes wegen Testpunkt1 Testpunkt2 gleichbedeutend mit Testpunkt2 Testpunkt1 ist F r das in Abbildung 6 6 angegebene Beispiel mit den vier Aspekten Quell und Zieladresse sowie Quell und Zielport ergeben sich 24 2 8 M glichkeiten die Testpunkte zu w hlen Sollte eine Firewall neben den identifizierten Segmenten weitere Unterscheidungen treffen die weder aus der Spezifikation noch aus der Konfigura
90. chen Firewalls und Routern Eine Firewall im Sinne einer allgemeinen Schutzkomponente kann auf jeder Ebe ne des OSI Schichtenmodells implementiert werden Dabei trennt eine Firewall der Schicht n die Schichten 1 n und verbindet die n te Schicht Routing Firewall Level of inspection Bridging Firewall Level of inspection 7 7i 7 7 7 7 6 t 6 6 6 6 5 TE 5 5 is 5 4 T 4 4 Nu 4 2 ki 2 2 EE 2 1 1 u ae 1 Client A Client B Client A Client B a Routing Firewall b Bridging Firewall Abbildung 2 2 Firewall Betriebsmodi im Vergleich Die Personal Firewall wird auf den Systemen vieler Heimbenutzer eingesetzt Sie wird aufgrund der abweichenden Zielfunktion in dieser Arbeit nicht betrachtet Zur Firewallgeschichte vergleiche IF02 und Spe06 Seiten 37 44 2 Firewalls In Abbildung 2 2 sind die meist eingesetzten Routing und Bridgemodi abgebildet Im ersten Fall verh lt sich die Firewall wie ein Router wobei jeder Netzwerkadapter eine IP Adresse bekommt und dar ber ansprechbar ist Im Bridgemodus funktioniert die Firewall wie ein Switch bzw eine Bridge Letzteres hat den Vorteil dass die Firewall nicht direkt ansprechbar und dadurch auch schwerer angreifbar ist Die Inspektionstiefe bei der Filterung ist una
91. chnitt 3 2 So variiert die Anzahl der Zugriffspunkte zwischen 0 und 4 abh ngig von der Konfiguration aktiviertes Bridging Filterung von Ethernet Filterung von IP sowie der Quelle bzw dem Ziel des Paketes Jedes Paket wird jedesmal mit der gesamten aktiven Regelmenge ver glichen was bei der Formulierung der Zugriffskriterien ber cksichtigt werden muss Ebenso m ssen die vom Benutzer frei w hlbare Platzierung des bergabepunktes zum NAT Dienst und die folgenden Filterregeln bedacht werden Abh ngig vom Ort des Zugriffs k nnen der Regelliste unterschiedliche Informa tionen zur Verf gung stehen da Kopfdaten je nach Netzwerkschicht entfernt oder hinzugef gt werden k nnen Deshalb wird der positive Vergleich von MAC Adressen innerhalb von ip input bzw ip6 input immer fehlschlagen ein negierter Vergleich dagegen immer zutreffen Der Anwender kann die betreffenden Regeln f r solche F lle mit einem Schl sselwort gezielt berspringen INBOUND ip input ip6 input ether demux ip output ip6 output ether output ANNOALNO bridge_forward to devices Abbildung 4 3 Paketfl sse durch FreeBSD IPFW Bei IPFW in BSD OS wurde nach LLB02 die gesamte Paketverarbeitung neben den bereits bekannte Methoden ip_input ip_output zus tzlich von ip_forward durchgef hrt Die in Abbildung 4 4 dargestellten Zugriffspunkte entsprechen unter 32 4 1 Paketfl sse
92. counting weiterleitend Accept verschiedene NAT Arten Re Routing Tabelle 5 1 Entscheidungsarten eines Paketfilters Drei Typen der Anweisungen k nnen unterschieden werden terminierend nicht terminierend und weiterleitend bez glich der Regelevaluation im aktuellen task Ei ne terminierende Entscheidung w rde das Paket verwerfen und die weitere Untersu chung abbrechen eine nicht terminierende w rde mit den nachfolgenden Regeln fort 51 5 Allgemeines Modell f r zustandsbehaftete Paketfilter fahren eine weiterleitende w rde den Arbeitsschritt als bearbeitet ansehen und mit dem n chsten task weiter machen Eine Zuordnung von bekannten Anweisungen und Funktionen zu den Ergebnisarten ist der Tabelle 5 1 zu entnehmen Abbildung 5 3 veranschaulicht die Wirkung der drei Typen auf die Fortsetzung der Abarbeitung der Arbeitsschritte a 2 NonTerm Action 7 Ne task iG mese l E 73 task j mam 4 ot task Abbildung 5 3 Ergebnistypen der Firewall Anweisungen Genauer betrachtet bestehen viele der Aktionen und Arbeitsschritte der Paketbe arbeitung aus einzelnen Schritten die nicht explizit erkenntlich sind Ihre Identifizie rung hilft aber der Verallgemeinerung der einzelnen Abl ufe und der Modellierung Unter den impliziten Funktionen wurden folgende Aktionen identifiziert Regelwerk konsultieren und anwenden Zustandseintrag anlegen aktualisieren
93. d Testraumgr e erarbeitet Die Teststrategie wird in Kapitel 7 entwickelt Dabei wurden die Ziele der Un abh ngigkeit von konkreten Produkten Unabh ngigkeit von den betrachteten Pro tokollen Einstellbarkeit der Tests f r eine konkrete Firewall Bestimmung der Rele vanz und der Detailtiefe der Testf lle Optimierung der Nutzung der Testressourcen Durchf hrbarkeit der Tests unter Labor und Realbedingungen sowie die Wiederhol barkeit der Tests verfolgt Die Ergebnisse in Kapitel 9 zeigen dass die Teststrate gie vielf ltig einsetzbar ist und bereits im Prototyp grundlegende Konfigurationen berpr fen kann Durch den modularen Aufbau und die Wahl einer einfach zu er lernenden Hochsprache f r die Umsetzung ist die einfache Erweiterbarkeit der Test strategie f r weitere Testumgebungen und Anforderungen gegeben Die Bewertung und der Vergleich der Teststrategie im Kontext anderer Werkzeuge und Arbeiten in Abschnitt 10 3 zeigt den Beitrag dieser Arbeit zur Verbesserung und zur Erleichterung der Testbarkeit von Firewallkonfigurationen Dies wird in ei nem benutzerfreundlichen Werkzeug mit Nutzen f r Entwickler und Administratoren zusammengefasst 120 Ausblick Der entwickelte Prototyp der Teststrategie bietet eine gute Grundlage f r weitere Untersuchungen und das Testen von Firewalls Die modulare Struktur wurde von Anfang an daf r konzipiert Erweiterungen zu entwickeln und einzubinden Aufgrund der beschr nkt verf gbaren Be
94. de der Protokollschichten f r jede Assoziation jeweils einen Zustand die alle zusammen wiederum den Gesamtzustand des Knotens darstellen F r einen vollst ndigen Test von so einem Knoten in diesem Fall der Firewall m ssten alle m glichen Zust nde berpr ft werden Das w rde bereits bei zwei oder drei betrachteten Schichten zu einer Zustandsexplosion f hren da die Potenzmenge einer beliebigen Anzahl von gehaltenen Assoziationen und einer beliebigen Vorge schichte zu jedem Zustand ber cksichtigt werden m sste Abbildung 6 5 versucht die Zustandsexplosion zu visualisieren la a N S s m f N E M gt c S 28 a E UM ibo a c i i ES Ai RN i od gt ym H8 yo I lt Tm U 54 A N association 4 packet filter system Abbildung 6 5 Problem der Zustandsexplosion 65 6 Testen Aus diesem Grund baut diese Arbeit auf der Annahme auf dass Netzwerk und Vermittlungsger te daf r vorgesehen sind eine grofe Menge von beliebigen Daten str men gleichzeitig sowie ohne gegenseitige Beeinflussung zu verarbeiten und zu transportieren Durch eine Beschr nkung der betrachteten Testeigenschaften und durch geeignete Teststrategien wird das Risiko der gegenseitigen Beeinflussung redu ziert Unvorhergesehene Nebeneffekte k nnen
95. den Rechnern und der Fi rewall in Graphen abbildet und Funktionen vereinbart die Teilmengen der Knoten mit gew nschten Eigenschaften Netzwerkdienste bis Ebene 4 des OSI Modells lie fern Darauf aufbauend kann er die beste Position einer Firewall in der untersuchten Topologie bestimmen bzw die untersuchte Position bewerten Firewallkonfiguration Analyse und Erstellung von Regeln und Richtlinien Basis f r die meisten Arbeiten ist oft Firmato ein Firewall Management Toolkit das die folgenden Aufgaben vereinfachen sollte die Sicherheitsrichtlinie unabh ngig von einem konkreten Produkt von dessen Eigenschaften und von der Netzwerktopologie zu formulieren die Firewallkonfiguration automatisch aus dieser Richtlinie zu gene rieren und die M glichkeit schaffen Konfigurationen auf einer abstrakteren Ebene zu untersuchen Dazu wurden ein Entity Relationship Model ERM eine Model Defi nition Language MDL ein Model Compiler und eine Visualisierung f r die Regeln entwickelt siehe Bar99 Aufbauend auf den Arbeiten an Firmato hat die Forschungsgruppe um Wool FANG die Firewall ANalysis Engine MWZO00 entwickelt Auf diesem Prototyp aufbauend entstanden dann der Lumeta Firewall Analyzer LFA Woo01 MW2Z05 und schlieflich eine kommerzielle Version von AlgoSec Alle Versionen sind in der Lage automatisch verschiedene Konfigurationssprachen und routing Informationen Informationen zum AlgoSec Firewall Analyzer k nnen unter http
96. dings wurden auch die Bezeichnungen stateful inspection bzw deep inspection f r Firewalls eingef hrt die neben dem stateful filtering auch die anwendungsspezifi schen Datenbereiche der Pakete auf Konformit t bzw atypische Muster untersuchen Ran05 Erg nzend zu den Paketfiltern wurden Proxy basierende Applikationsfilter ALG Application Level Gateway eingesetzt die den Netzwerkverkehr der OSI Schichten 5 bis 7 auswerten also den Protokollfluss auf der Anwendungsebene analysieren und gegebenenfalls bereinigt weiterleiten oder unterbrechen k nnen ALGs terminieren den ankommenden Datenverkehr und bauen eine zweite Verbindung zum eigentli chen Zielsystem auf Im Gegensatz zu einem Paketfilter muss ein ALG das vermit telte Protokoll vollst ndig verstehen um die neue Verbindung aufbauen zu k nnen ALGs k nnen auch zus tzliche Funktionen wie Caching Logging suchwortbasieren de Inhaltskontrolle z B Java und ActiveX entfernen gewalt oder sexuellorientierte Inhalte blockieren Anti Virus Ma nahmen sowie Authentifizierung anbieten Man che SSL Proxies werden als vorgeschalteter Terminierungspunkt f r interne Server eingesetzt wodurch sie sich f r die Server ausgeben und auch verschl sselten Da 2 1 Netzwerkfunktionen und Firewalltypen tenverkehr untersuchen k nnen Dadurch wird aber die Ende zu Ende Semantik von verschl sselten Kan len aufgehoben Eine andere Ebene der Inspektion bieten Intrusion Detection IDS bzw In
97. e die in sogenannten Vektoren beschrieben werden Die Teststrategie benutzt die Testvektoren zur Bestimmung der Testpunkte f r die die Testsequenzen erstellt werden Aktuell kann vom FWA nur die Konfiguration von net filter iptables eingelesen werden aber eine Erweiterung auf weitere Konfigurations sprachen ist geplant wodurch auch die Teststrategie f r den Test anderer Paketfilter verwendet werden kann F r die Erstellung der Testsequenzen und zur berpr fung des spezifikationskon formen Verhaltens des Probanden werden die jeweiligen Protokollspezifikationen zu Grunde gelegt Diese werden als Teil der Teststrategie implementiert Als Werkzeug f r die Erstellung die Manipulation den Versand und den Empfang von Paketen wurde FW Test TU Berlin vorgegeben Es besteht aus einem Steuer programm und zwei Agenten die f r den Versand und den Empfang von Paketen zust ndig sind Das Konzept der Agenten ist besonders dazu geeignet die Firewall von zwei Seiten zu stimulieren bzw zu beobachten Die bereits vorhandene Python Schnittstelle wird jedoch mit Scapy erweitert das eine m chtigere Funktionalit t zum Erstellen und Analysieren von Paketen besitzt Testmethodologie und verwendete Bezeichnungen Mit den Begriffen der Testmethodologie ausgedr ckt handelt es sich bei der geplan ten Teststrategie um die berpr fung des Qualit tsmerkmals Konformit t aus der Kategorie Funktionalit t Dem werden die funktionsorientierten Testarten au
98. e Basisstruktur zum Aufbau eines Baumes aus der Association List und der Traversierung aller Pfade implementiert Im Modul ticketing wird das bereits ein gef hrte Ticketsystem implementiert das die reservierten die aktiven und die ver brannten Testpunkte verwaltet Die spezifischen Tests der Protokolle die auf den jeweiligen Protokollspezifikatio 89 8 Proof of concept nen basieren sind in eigenen Modulen umgesetzt Im Prototyp sind die Protokolle TCP UDP und ICMP ber cksichtigt Sie alle implementieren jeweils die Logik f r die Herstellung des jeweiligen Protokollflusses und Methoden zur Bewertung der Testpfa de Die Funktionen zum Versenden und Empfangen der Pakete auf die diese Module zugreifen k nnen sind in der pdulib gekapselt Das Modul testTCP greift zus tzlich auf die Paketfilter spezifische Zustandsverfolgung zu Die letzten beiden Module im Schaubild dienen der Auswertung der Testergebnisse Das Modul interpret vergleicht das gesendete Paket mit dem bzw den empfange nen Paketen und der postulierten Aktion Zum Vergleich der Pakete nutzt es die Funktionen aus dem PktCompare Modul Die Verwaltung der Testpunkte durch das Ticketsystem der Basisautomat der Zustandsverfolgung die Umsetzung der Protokollspezifikationen und die Proban denbeschreibung sind essentielle Bestandteile der Teststrategie die in den folgenden Unterabschnitten beschrieben werden Auf die weitere Beschreibung der Auswertung wird verzichte
99. e Funktionsweise der Paketfilter untersucht Dabei wurden in Abschnitt 4 1 anhand der verf gbaren Dokumentation die Paketfl sse durch die Fire walls identifiziert und in Abschnitt 4 2 die Mechanismen der Verbindungsverfolgung analysiert In diesem Kapitel wird jetzt ein Schritt von der Analyse zur Entwicklung eines Baukastenmodells gemacht mit dem sich die Paketfl sse und die Funktionen der zustandsbehafteten Paketfilter allgemein und vereinheitlicht beschreiben lassen Diese Verallgemeinerung ergibt sich aus den Aufgaben von vermittelnden Paketfil tern weswegen sie alle im Kern ein vergleichbares Vorgehen aufweisen Abschnitt 5 1 stellt die entwickelten Bausteine des Modells auf verschiedenen Abstraktionsebenen vor In Abschnitt 5 2 werden diese Bausteine verwendet aus gew hlte Funktionen zu modellieren Abschnitt 5 3 zeigt beispielhaft die vollst ndige Modellierung des netfilter iptables Paketfilters 5 1 Bausteine des Modells In Abschnitt 4 2 wurden mehrere Arbeitsabl ufe bzw Paketfl sse vorgestellt die auf zwei immer wiederkehrende Ablaufdiagramme bei der Paketbearbeitung abge bildet werden k nnen Der dominierende Ablauf der bei den Firewalls PF IP Filter FreeBSD IPFireWall PIX und FW1 beobachtet werden kann besteht aus den drei Phasen Input Routing und Output Netfilter iptables und die BSD OS Variante von IPFW dagegen arbeiten mit f nf Phasen die als Preprocessing Input Forward Output und Postprocessing vereinheit
100. e alleinige Entscheidungskraft hat Proble matisch wird es wenn mehrere solcher Knoten den gleichen Paketfluss reglementieren und sich u U gegenseitig wie auch die Kommunikation behindern Das kann dazu 38 4 2 Zustandsbehaftete Verbindungsverfolgung T gt _ SYNACK l FWA sm A MB 1 I 1 I a I 1 SYN ACK r 9 I 1 Baal EEE b SYN PWA gt A 1 I T I L Abbildung 4 9 Uneindeutige Situationen im vermittelndem Knoten B f hren dass auch die Protokollpartner nicht mehr korrekt kommunizieren k nnen Firewall Hersteller haben aufgrund der fehlenden Protokollspezifikationen f r Zwi schenpunkte keine Richtlinien daf r wie sie eine beobachtende Protokollinstanz im plementieren sollten Dabei unterliegen sie gleichzeitig einem Interessenkonflikt zwi schen den Sicherheitsanforderungen an eine Firewall die m glichst konservativ und streng reglementieren sollte und der Benutzerfreundlichkeit bzw Kompatibilit t mit anderen Produkten wodurch sie mehrere Interpretationen und Variationen von Pro tokollen zulassen m ssen Beide Aspekte f hren zu unterschiedlichen Auslegungen wie ein Zwischenpunkt ein bestimmtes Protokoll oder einen Paketfluss zu handha ben hat wobei es nicht zwangsl ufig ein richtig oder falsch gibt In der Praxis wird eine Implementierung ber Jahre hinweg den praktischen Erfahrungen und anderen Ger ten angepasst wodurch sich die gegenseitige Kompatibilit t der Ger
101. ef hrt werden m ssen woraus sich verschiedene Komplika tionen ergeben vgl RFC3027 Anzupassen sind auch gegebenenfalls Routinganga ben in den IP Optionen und ICMP Fehlernachrichten Auch viele Anwendungspro tokolle die zus tzliche Verbindungskan le vereinbaren benutzen die lokal bekannten Adressen und m ssen ebenfalls angepasst werden vor allem wenn sie selbst keine Mechanismen bereitstellen mit NAT umzugehen Als Beispiele w ren hier Protokolle aus den Bereichen VoIP SIP h323 Dateitausch FTP IRC DCC und zahlreiche Peer to Peer Anwendungen zu nennen Diese Funktionalit t kann in Form von Erwei terungen f r den Paketfilter bereit gestellt oder in einer Proxy Anwendung realisiert werden 2 2 Sicherheitsziele und deren Bedrohungen Zu den Grundprinzipien und Zielen der Informationssicherheit geh rt die Sicherung der Vertraulichkeit der Integrit t und der Verf gbarkeit Zus tzlich existieren meh rere Erweiterungen des Modells Tabelle 2 2 zeigt eine Erweiterung der Aspekte um Zurechenbarkeit und Zugriffskontrolle nach Sch03 Kapitel 1 Zugriffskontrolle wird mit Hilfe der Authorisierung umgesetzt die die Identifikation und die Authentifikati on des zugreifenden Subjektes voraussetzt Jede so gestattete oder verbotene Aktion gt Im englischen Sprachraum als CIA Triade Confidentiality Integrity Availability bekannt 9 Tabelle ist zus tzlich mit den Angriffsbeispielen erweitert 10 2 2 Sicher
102. eiche aus der Konfiguration rein mathematisch interpretiert Er liefert z B f r das Teilnetz 10 0 0 0 24 die Eckpunkte 10 0 0 0 und 10 0 0 255 die wahrscheinlich aus der Sicht eines Routers spezielle Adressen Broadcasts sind die unter Umst nden nicht weitergeleitet werden Die Interpretation von Netzmas ken und Netzsegmenten muss in der Teststeuerung durchgef hrt werden wobei der Benutzer ber jede Abweichung von den Segmentr ndern informiert werden muss Ein vollst ndiger Test dieses Vektors w rde 255x255x30975x1x2 4 028 298 750 Testpunkte f r jedes Protokoll ergeben Durch die in Abschnitt 6 4 diskutierte Opti mierung kann die Testmenge auf die diagonalen Randpunkte reduziert werden wo durch noch zwei aus acht m glichen Testpunkten 2 x 2 x 1 x 2 f r jedes Protokoll zu 74 7 1 Vereinfachter Testablauf f r einen Testpunkt testen sind F r den Test von TCP werden in dem Beispiel keine besonderen TCP Flags gefordert weswegen eine freie Wahl getroffen werden kann die am besten der Protokollspezifikation entspricht Sollten weitere Eigenschaften verlangt werden so ist zu berpr fen ob diese spezifikationskonform sind und den Paketfilter erreichen sowie von ihm verarbeitet werden k nnen Aus den im Vektor beschriebenen Eigenschaften werden f r die Tests konkrete Werte ausgew hlt die sich f r die berf hrung in ein Paket eignen Als Beispiel werden hier die zwei Testpunkte e 10 0 0 0 Port 1025 10 1 0 0 P
103. en weil die Vorbedingungen nicht erf llt werden k nnen untracked UDP related TCP related zusammen gesamt uniseb2 14 396 4 9 14 8 34 65 ICMP 20 1 396 1 396 22 6 47 6 rusty 2 20 6 7 6 7 33 4 90 4 clean 20 6 7 6 7 33 4 80 4 Tabelle 9 2 Potenzial zur Verbesserung der aktiven Testabdeckung Das Maf der aktiven Testabdeckung ergibt sich aus dem Quotienten der getesteten Testf lle und deren Gesamtanzahl Dabei beinahlten die getesteten Testf lle die auf gef hrten Zahlen unter In Test und Skip Darauf basierend ergeben sich f r uniseb2 eine Testabdeckung von 31 f r ICMP 25 f r clean 47 und f r Rusty 2 57 Diese Testabdeckung kann bei der Erg nzung der Teststrategie durch die fehlenden Tests zwischen 22 und 34 gesteigert werden Die letzte Spalte der Tabelle zeigt die dann erreichbare Gesamtabdeckung der Testf lle auf Basis der Testvektoren 9 3 Erkenntnisse aus der Untersuchung von iptables Bei der Entwicklung der Teststrategie und verschiedener Testszenarien konnten Ab weichungen zwischen den erwarteten und den tats chlichen Ergebnissen beobachtet werden Zun chst wurde angenommen dass es sich bei den Abweichungen um Fehler in der Implementierung oder undokumentiertes Verhalten handelt Bei der weiteren Nachforschung zu den Abweichungen konnte jedoch das beobachtete Verhalten auf die im RFC1812 beschriebenen Anforderungen an IPv4 Router zur ckgef hrt wer den Alle entdeckten Unsteti
104. en 3 und 4 einen sehr gro en Zustandsraum aufspannen der noch zu untersuchen ist Die Aufgaben einer eingesetzten Firewall und des Paketfilters als einer Kompo nente davon werden aus dem Schutzbedarf und dem Schutzkonzept die in den Si cherheitsrichtlinien security policy beschrieben sind abgeleitet Ein Funktionstest der Firewall m sste dementsprechend die korrekte Umsetzung der Richtlinien testen Allerdings sind Sicherheitsrichtlinien wenn sie berhaupt aufgeschrieben werden oft informal recht oberfl chlich und f r das Netzwerk als Einheit definiert weswegen sie als Basis f r eine Teststrategie ungeeignet sind Die Konfiguration eines Paketfilters muss allerdings immer vorgenommen werden und stellt in vielen Einsatzszenarien die erste vorhandene formale Beschreibung der Aufgabenstellung dar die einen testbaren Zugriffspunkt beschreibt Deswegen wird bei dieser Arbeit die Konfiguration als Teil der Spezifikation betrachtet mit deren Hilfe das zur jeweiligen Protokollspezifikation konforme Verhalten berpr ft wird Als Grundlage f r die Teststrategie soll ein allgemeines Modell f r die zustands 1 2 Vorgehen und Struktur behaftete Paketfilterung und ver nderung erstellt werden Die Analyse soll auf den Spezifikationen bzw der offiziellen Dokumentation der Paketfilter basieren wobei eine Klassifizierung der Verhaltensweisen nach typischen und atypischen Merkmalen durchgef hrt werden soll Letztere ben tigen gegebenenf
105. en jedoch nicht die Abwesenheit von Fehlern garantieren da allum fassendes Testen von komplexen Systemen mit den verf gbaren Technologien und Ressourcen nicht realisierbar ist Trotz der verbliebenen Restunsicherheit kann auf Tests nicht verzichtet werden weil das bekannte und spezifizierte Verhalten best tigt werden kann und der Verzicht auf das Testen keine Alternative darstellt Es gibt eine Reihe von verschiedenen Testans tzen die von informalen ad hoc bis formal spezifizierten und kontrollierten Methoden reichen Im Folgenden wird Testen als ein technischer Prozess der einer spezifizierten und damit wiederholbaren Prozedur folgend in einer kontrollierten Umgebung durchgef hrt wird verstanden Das Wasserfallmodell Roy87 eine Vorgehensweise im Softwareentwicklungspro zess gibt f r jede Phase der Softwareentwicklung Verfahren an die jeweils andere Fehleigenschaften aufzeigen k nnen und zur Pr fung der Zwischenergebnisse einge setzt werden bevor die n chste Phase begonnen wird Zur Abgrenzung der Begriffe werden hier Validierung Verifikation und das Debugging nach Brockhaus Naturwis senschaft und Technik BIFABAO3 eingef hrt Die Validierung ist eine berpr fung der bereinstimmung von Zielstellung und erreichtem Ergebnis Bei Software ist damit auch die G ltigkeit eines Objektes in Bezug auf den definierten Wertebereich und Typ gemeint Verifikation ist ein formaler Nachweis mit mathematischen Methoden der die Kor 57
106. en oder neu zusam menstellen und Uneindeutigkeiten bereinigen kann Ebenfalls zu den Paketver nderungen geh rt das Entfernen von optionalen Daten Besonders h ufig wird das bei IP Optionen gemacht die zwar von der Spezifika tion vorgesehen wurden aber aus Sicherheitsgr nden bedenklich sind Sie k nnen von manchen fehlerhaften Netzwerkstapeln nicht interpretiert werden und lassen sich f r verschiedene Angriffe missbrauchen So werden von den meisten Firewalls M glichkeiten geboten zumindest die IP Routing Optionen zu filtern bzw zu ver werfen Die m chtigsten Ver nderungen erm glichen PF und netfilter wobei PF mit den scrub bzw modulate Optionen mehrere sicherheitsrelevante Modifikationen zusam menfasst und netfilter f r jedes Paketfeld eine spezialisierte und frei konfigurierbare Option anbietet IPFilter und IPFireWall bieten keine M glichkeiten an Pakete zu modifizieren Pakete k nnten aber an Benutzerprogramme bergeben werden die evtl Ver nderungen durchf hren k nnten Solche Erweiterungen sind jedoch zur Zeit nicht bekannt Die beiden kommerziellen Produkte Cisco PIX und Checkpoint FW 1 bieten ebenfalls keine direkten M glichkeiten an Paketfelder zu ver ndern Bestimm te nderungen lassen sich jedoch ber Optionen einschalten Dazu geh ren vor allem die Randomisierung der Sequenznummer und Zeitstempel sowie die Entfernung von n der Regel sind doppelte Fragmente Fragmente au erhalb der Reihenfolge und we
107. en werden Die Liste der ausgew hlten Funktionen wird in Tabelle 8 1 wiedergegeben Die wichtigsten Optionen die das Verhalten des Paketfilters abweichend zu den verwendeten Standardwerten ver ndern k nnen sind der Tabelle A 2 zu entnehmen Die Untersuchung dieser Optionen wird vom Prototyp nicht unterst tzt In den folgenden Abschnitten werden die praktische Umsetzung das Design und die konkreten Tests beschrieben Im ersten Unterabschnitt werden die Aufteilung der Funktionalit ten auf die Module sowie die wichtigsten Funktionen und Algorithmen beschrieben Der zweite Abschnitt stellt die Beschreibung des Probanden in dem Fall netfilter iptables vor Anschlie end werden die funktionellen Aspekte der reali sierten Protokolltests aufgezeigt Im letzten Abschnitt wird ein Ausblick auf m gliche Erweiterungen und die Fortf hrung der Teststrategie gegeben Am Anfang des Kapitels 7 wurden Anforderungen an die Teststrategie definiert die in diesem Abschnitt wieder aufgegriffen werden um die Konzepte zu ihrer Umsetzung 8T 8 Proof of concept Filterentscheidungen IP source destination TTL TOS DSCP ECN TCP sport dport UDP sport dport ICMP type code state INV NEW EST REL Filteraktionen ACCEPT DROP REJECT DNAT SNAT MASQUERADE Tabelle 8 1 Liste der unterst tzten iptables Merkmale im Prototyp zu erl utern Die Durchf hrbarkeit unter Realbedingungen impliziert die Unterscheidung zwi schen Labor und Pr
108. entierten Methoden deren Testf lle eine vollst ndige Abdeckung der Spezifikation aber keine garantierte Vollst ndigkeit der Abdeckung der Programmstruktur erlauben Die im Folgenden behandelten Netzwerk und Protokolltests geh ren dieser Kategorie an 6 1 Netzwerk und Protokolltests Das Testen von Protokollen und Netzwerkger ten setzt auf den zuvor vorgestellten Prinzipien auf und wurde in den Normen ISO IEC 9646 bzw ITU T X 290 X290 International Telecommunication Union ITU Telecommunication Standardization Sector ist aus dem fr heren Comit Consultatif International T l phonique et T l graphique CCITT hervorgegangen 60 6 1 Netzwerk und Protokolltests festgehalten Stellvertretend f r beide Normen wird jetzt von ISO9646 gesprochen Beide Normen beschreiben ein Rahmenwerk und die Methodologie des Konfor mit tstestens von Protokollen Andere Testarten wie Robustheits Leistungs bzw Belastungstests sind in 1809646 nur soweit ber cksichtigt wie sie zur Erbringung der Konformit t mit der Spezifikation notwendig und ein Teil dieser sind Das Rah menwerk enth lt Vorschriften und Anleitungen nach denen Protokolle eindeutig for muliert Test Suiten erstellt und der Prozess des Testens auf Konformit t ausgef hrt werden sollen Die einzelnen Aspekte wurden in sieben Teile gegliedert wobei nur die allgemeinen Konzepte in Teil 1 f r diese Arbeit von Bedeutung sind Der interessier te Leser sei auf die j
109. eoretischer Natur und kann bereits durch relativ einfache Firewallkonfigurationen entstehen Bei den Untersuchungen hat sich weiter herausgestellt dass Python die Objekte anders verwaltet wenn die gleiche Menge an Listen in einer Schleife erzeugt wird Aus diesem Grund wird eine eigene Implementierung der Evaluierungsfunktion f r eine m gliche Fortf hrung des Projekts empfohlen 99 8 Proof of concept Eine alternative Form der Teststrategie k nnte dazu genutzt werden bei der Rekon struktion einer unbekannten Firewall und ihrer Einstellungen zu helfen Methoden zur Ermittlung der verwendeten TCP Zustandsmaschine und den voreingestellten Timeouts k nnen untersucht werden Eine weitere Anwendungsform der Teststrategie k nnte die Reaktion der Firewall auf verschiedene bekannte Angriffsformen untersuchen hnliche Werkzeuge existie ren bereits sie f hren jedoch Black Box Tests durch Hier k nnte der Einfluss der Konfiguration im Grey Box Verfahren betrachtet werden 100 9 Ergebnisse In diesem Kapitel werden m gliche Anwendungsf lle der entworfenen Teststrategie und die erzielten Ergebnisse aus durchgef hrten Testl ufen vorgestellt Die Anwen dungsf lle sollen den praktischen Nutzen der Arbeit belegen In Abschnitt 9 2 wird die Testabdeckung durch den Prototyp f r ausgew hlte Konfigurationen und Verbesse rungspotenzial durch Fortentwicklung der Teststrategie aufgezeigt Der anschlie ende Abschnitt 9 3 fasst die Erkennt
110. er zur Verf gung steht Es ist in Syntax und Funktionsumfang mit IPF vergleichbar Die Private Internet eXchange Security Appliance kurz PIX ist das meistverkauf te Firewallsystem bei Cisco Systems Es ist eine Kombination aus sicherheitsorien tierter Hardware und der echtzeitf higen PIX Systemsoftware die in verschiedenen Ausbaustufen angeboten werden Die Untersuchung basiert auf der Dokumentation der Systemsoftware Version 6 3 und kann f r neuere Versionen abweichen da neuere Softwareversionen der PIX 7 x Reihe auf der Architektur der Cisco Adaptive Security Appliance ASA 55xx Firewallsysteme basieren CheckPoint FireWall 1 war die erste kommerzielle Firewall mit einer vereinfachten Konfiguration ber eine grafische Oberfl che weswegen sie seit ihrer Einf hrung 1994 sehr schnell gro e Verbreitung fand Zudem basiert das Konzept der zustandsbehaf teten Untersuchung von Paketen auf der von CheckPoint 1997 patentierten stateful inspection und deren INSPECT Engine Die folgenden Beschreibungen beziehen sich auf die Dokumentation der FireWall 1 NGX auf der Secure Platform R60 Die Merkmale und Funktionen der Sidewinder Firewall wurden ebenfalls ausgewertet werden jedoch nicht separat dargestellt F r eine detailierte Darstellung vgl http www sidewinder com 10Vg http www cisco com en US products hw vpndevc ps2030 index html und http www networkworld com community q node 12346 HSiehe http www checkpoint com prod
111. er Skip zusammengefassten Testf lle wurde ebenfalls getestet indem sie f r die Herstel lung eines Kontextes f r andere Testf lle benutzt wurden Sie werden aufgrund der eingebauten Optimierung der Laufzeit nicht nochmal separat getestet Paths Skip und In Test Die hier genannten Zahlen beschreiben die Anzahl der betrachteten Testpfade f r die zu testenden Testf lle aus der vorangegangenen Rubrik Dabei bezeichnet Skip die Anzahl der Testpfade die aufgrund einer Verletzung der jeweiligen Protokollspezifikation nicht in einem Protokollfluss umgesetzt werden k nnen Die Zahl unter n Test sind die tats chlich getesteten Pfade Beide Zahlen sind unabh ngig von der Anzahl der Vektoren oder der Testf lle Die Anzahl der Testpfade h ngt von der Konfiguration ab TP Die letzte Spalte gibt die Anzahl der Testpunkte wieder Sie l sst sich direkt aus der Anzahl der getesteten Testpfade ableiten da f r jeden Testpfad zwei diagonale Testpunkte ausgew hlt werden vgl Abschnitt 6 4 105 9 Ergebnisse Die Testabdeckung kann als die aktive berpr fung der geforderten Eigenschaften durch die Herstellung eines Protokollflusses oder als eine begr ndete Stellungnahme zum Auslassen des Tests verstanden werden Ziel ist es m glichst vollst ndig die Eigenschaften aktiv zu berpr fen Durch die Bindung aller Protokollfl sse an die Protokollspezifikationen k nnen jedoch nicht alle Testf lle die der FWA beschreibt berpr ft werd
112. er TCP Zustandsverfolgung 8 1 2 Automat zur Beschreibung der Zustandsverfolgung class conntrackStateMachine Die hier modellierte conntrackStateMachine entspricht einem Mealy Automaten da die Ausgaben bei Zustands berg ngen die Timeouts entsprechend der Beschrei bung zur Abbildung 4 10 abh ngig von dem Zustand und der Eingabe sind Die Signalisierung eines validen und nicht ignorierten bergangs wird ber die Ausgabe des neuen Zustands realisiert F r ignorierte Eingaben wird der reservierte Zustands bezeichner IGNORE verwendet conntrackStateMachine Konstruktorfunktion Liefert eine neue Instanz der conntrackStateMachine add name origin flags newstate F gt der Instanzvariablen states eine neue Transition mit der Bezeichnung name einer Eingabe bestehend aus Sender origin und Flags flags sowie dem Folgezustand newstate hinzu Die vor gegebenen Senderdefinitionen beinhalten Server Client und Beliebig setStart name Definiert den Zustand name als Startzustand go origin flags Versucht mit der Eingabe origin und flags eine Transition durchzuf hren Bei einer validen Eingabe wird der neue Zustandsname oder IGNORE zur ck geliefert und der neue Zustand in der Instanzvariablen state vermerkt simulate state origin flags Simuliert den bergang ausgehend von dem Zustand state mit der Eingabe von origin und flags und liefert ein Ergebnis analog zu go ohne den neuen Zustand intern zu speichern getState
113. er Untersuchung werden sechs Firewallsysteme betrachtet von denen die ers ten vier Vertreter netfilter iptables IP FireWall IPFilter und Packet Filter zustandsbehaftete Paketfilter sind Sie sind auch alle im Quellcode verf gbar was die detaillierte Untersuchung m glich macht Zus tzlich werden zwei kommerzielle Produkte untersucht die der Kategorie deep inspection filter zuzuordnen sind Die Firewalls wurden aufgrund ihrer Verf gbarkeit zum Untersuchungszeitpunkt ausgew hlt Es wird aber auch angenommen dass sie repr sentativ f r typisch ein gesetzte Systeme sind Genaue Informationen zur Marktverteilung von Paketfiltern konnten nicht ermittelt werden Allerdings werden bei der Untersuchung alle aktuel len Open Source Paketfilter betrachtet Laut einer Sch tzung vom OSS Experten Ha rald Welte Wel07 wird bei ber der H lfte der seit 2003 produzierten eingebetteten Netzwerkger te Linux verwendet und demnach auch netfilter iptables sofern ein Paketfilter Teil des Funktionsumfangs ist Sowohl Linux wie auch die BSD Systeme sind als Basis f r Internet Server sehr beliebt 13 2 Firewalls Anbieter Produktname Version seit Plattform OS Lizenz netfilter org netfilter Linux 2 6 20 1999 Linux GPL freebsd org IP FireWall FreeBSD 7 1993 FreeBSD BSD MacOS X BSD OS openbsd org Packet Filter OpenBSD 4 1 2001 OpenBSD BSD FreeBSD NetBSD DragonFly Darren Reed IPFilter 4 1 19 1993 verschiedene IPFilter UNIX V
114. er nicht verwendet wird Network Address Translation NAT wird h ufig in die Gruppe der Firewalltechno logien eingereiht wurde jedoch zun chst als Antwort auf die beschr nkte Anzahl von IPv4 Adressen im Internet entwickelt Es erm glicht die Abbildung einer Menge von Netzwerkadressen auf eine andere Wird dabei die Quelladresse ver ndert so wird von source NAT SNAT gesprochen Die nderung der Zieladresse wird als destina tion NAT DNAT bezeichnet Gleiche Abbildungen sind auch mit den Portadressen m glich was als Port Address Translation PAT bezeichnet wird NAPT beschreibt die gleichzeitige nderung von Adresse und Port Diese ist besonders m chtig in Verbindung mit Policy NAT bei der die Abbildung nur unter Ber cksichtigung der Quell und Zieladresse bzw der Ports durchgef hrt wird Bis auf wenige untypische Spezialf lle ben tigen alle NAT Varianten eine zustands behaftete Verbindungsverfolgung um eine bidirektionale Kommunikation unterst t zen und die aktuellen Zuordnungen aufl sen zu k nnen Eine allgemeine NAT Um setzung ist deshalb ohne Zustandsaufzeichnung kaum sinnvoll Bei der Abbildung einer Adress und Portmenge auf eine andere k nnen unter schiedliche Mechanismen und Strategien benutzt werden Im einfachsten Fall sind Eine detailierte Einf hrung in die Funktionsweise und den Betrieb von NIDS und IPS kann von BSI02 angefordert oder online abgerufen werden Hierzu vergleiche z B Spe06 Kapitel 2
115. erein fachte Darstellung der in einem Vektor beschriebenen Angaben Eine vollst ndige Beschreibung der Vektoren und der Schnittstelle zum FWA wird im Anhang in Ab schnitt A 2 dokumentiert Eigenschaft Werte bereich Protokollle TCP UDP Senderichtung A zu B Quelladresse 10 0 0 0 10 0 0 255 Zieladresse 10 1 0 0 10 0 0 255 Quellport 1025 32000 Zielport 80 Zust nde new established FW Aktionen log masquerade SNAT accept Tabelle 7 2 Beispiel f r die in einem Vektor beschriebenen Informationen Neben den Vektoren liefert der FWA eine Angabe des zu testenden Paketfilters also z B netfilter iptables Damit kann die Teststrategie die dazu passende Beschrei bung des Probanden laden und den Vektor interpretieren Der FWA arbeitet fast vollst ndig auf der syntaktischen Ebene der Konfigura tion und macht deswegen keine Aussagen oder Annahmen ber die Semantik der einzelnen Symbole Dementsprechend unterscheidet der FWA genauso viele Symbole und Werte wie die jeweilige Konfigurationssprache vorsieht Zu den grundlegenden Ausnahmen geh ren die Unterscheidung und die Auswirkung von terminierenden Anweisungen wie ACCEPT und DROP Die Belegung der Symbole mit einer Semantik wird erst durch die Anwendung der Spezifikationen und der Probandenbeschreibung in FWTStrategy durchgef hrt Zum Beispiel muss bei der Interpretation der aus gegebenen IP Adressen gegebenenfalls eine Anpassung durchgef hrt werden da der FWA die Netzwerkber
116. erheitsrichtlinien in Abschnitt 2 2 Beim Testen von Netzwerkkomponenten k nnen die zu testenden Aspekte nach verschiedenen Kriterien geordnet werden Zun chst sei die Rolle des Testers zu be trachten wobei zumindest Entwickler Administratoren Netzwerknutzer und Angrei fer unterschieden werden k nnen Ein Entwickler sowohl der Hardwareplattform wie auch der Software berpr ft zum Beispiel die Schnittstellen und Abh ngigkeiten zu benachbarten Komponenten die implementierte Funktionalit t vollst ndige Be handlung m glicher Parameter oder Leistungsmerkmale Ein Administrator kann zum Teil auch die gleichen Aspekte testen will aber zudem sicherstellen dass das Sys tem erwartungsgem und zuverl ssig in der eingesetzten Infrastruktur und im Kon text funktioniert Netzwerknutzer k nnten gezwungen werden Tests durchzuf hren wenn sie im Rahmen der Fehlersuche f r sich oder den zust ndigen Administrator Fehlverhalten diagnostizieren Dies k nnten gest rte oder eingeschr nkte Konnekti vit t sowie unzureichende Leistung sein Zuletzt w ren noch der sicherheitskritische Administrator oder ein b swilliger Nutzer anzuf hren die sich wie ein Eindringling verhalten Dieser w rde vor allem die Robustheit und Un Zuverl ssigkeit eines Sys tems untersuchen wollen indem er es grenzwertigen und undefinierten Situationen aussetzt um damit Fehlverhalten zu provozieren Speziell bei Protokoll bzw Netzwerktests werden die Quel
117. erscheidungs merkmale der Konfigurationssprache in kleinere Bereiche zerteilt die jeweils alle Re pr sentanten einer Konfigurationseinstellung zusammenfassen Diese Repr sentanten bilden sogenannte quivalenzklassen von denen jeweils nur wenige berpr ft werden m ssen um eine Aussage ber den Bereich treffen zu k nnen Das Konzept der Zerteilung des Testraums in kleinere Bereiche geht davon aus dass Abweichungen zwischen den Ergebnissen wahrscheinlicher an den Stellen sind an denen die Firewall aufgrund der Konfiguration oder ihrem Design Entscheidungen trifft und Verzweigungen macht Im Gegenzug wird erwartet dass sie sich in steti gen Bereichen auch gleichartig verh lt und die Aktionen f r Randwerte identisch mit den inneren Werten sind Eine hnliche Vorgehensweise wurde auch in Policy segmentation for intelligent firewall testing IHASO05 verwendet wobei dort nur der Adressraum zerteilt wurde der mit verschiedenen aus den Regeln hervorgegangenen Gr en gewichtet wurde Die Autoren zeigen dass die Auswahl der Testpunkte auf grund der Segmentierung und der Gewichtung eine signifikante Verbesserung der 67 6 Testen Testabdeckung im Gegensatz zum unsystematischen bzw zuf lligen Testen erreicht In der vorliegenden Arbeit wird die Segmentierung konsequent auf alle durch die Kon figuration vorgegebenen Filterkriterien angewendet was zu mehr Testf llen f hrt als die Segmentierung in der zitierten Arbeit Dadur
118. esehen kommunizieren zwei Teilnehmer miteinander wobei die Fire wall sich dazwischen befindet und versucht die Kommunikation zu beobachten sowie gegebenenfalls zu reglementieren Dabei kann sie den korrekten Empfang von Nach richten und damit auch den zugeordneten Zustand des Endpunktes nur aufgrund von entsprechenden Antworten der Gegenseite annehmen Verlorene oder anderwei tig geblockte Nachrichten kann sie nicht entdecken was zu der Uneindeutigkeit f hrt Abbildung 4 9 zeigt den TCP Handshake und die Situation f r Firewall B Im Fall a w re ein erneutes SYN Paket von A nach B ein valides Vorgehen in der Protokolls pezifikation Im Fall b hat A aber schon den Verbindungsaufbau abgeschlossen und ein weiteres SYN Paket w re invalid W re dies ein Angriffsversuch sollte das Ab lehnen eines solchen Paketes ber cksichtigt werden Hier kann dieser Zwischenpunkt aber die in den Endpunkten unterschiedlichen internen Zust nde nicht unterscheiden und dementsprechend keine eindeutigen Entscheidungen treffen hnliches kann auch passieren wenn Pakete asymmetrisch geroutet werden wo durch der Zwischenpunkt nur einen Teil der Kommunikation sieht Intern m ssen trotzdem innerhalb der Firewall Entscheidungen getroffen werden wie mit dem ak tuellen und den folgenden Paketen umgegangen wird Da die Firewall eine Schutz funktion umsetzt kann sie als diejenige Instanz betrachtet werden die die Situation bewerten und reglementieren muss also di
119. estpunkte die die Randwerte des jeweili gen Hyperrechtecks beschreiben F r die Teststrategie werden aber nicht Testpunkte sondern Testf lle aus den Vektoren erstellt Testf lle k nnen als ein teilweise fest be legter Testvektor verstanden werden der noch einige Variablen enth lt Ein Testfall dient als Schablone f r die Herstellung verschiedener Pakete eines Protokolls aus dem Testvektor unter Ber cksichtigung des gew hlten Testpunktes F r jedes im Testvek tor beschriebene Protokoll und f r jeden unterschiedenen Assoziationszustand wird ein Testfall vorbelegt Sind schlie lich alle Aspekte mit eindeutigen Werten belegt beschreibt ein Testfall einen eindeutigen Testpunkt der in ein Testpaket berf hrt werden kann Mehrere solcher Testpakete k nnen zu einem logischen Testpfad angeordnet wer den um einen kontextabh ngigen Zustand der Firewall zum Zweck der zustandsbe hafteten Filterung testen zu k nnen Die vorangegangenen Testpakete in einem Kon text werden als Vorgeschichte f r die nachfolgenden bezeichnet Dieser Kontext 12 7 1 Vereinfachter Testablauf f r einen Testpunkt kann entweder ber protokollabh ngige Pakete ausgel st oder nach berschreitung einer Firewall abh ngigen Zeitschranke engl Timeout automatisch erreicht wer den Das Konzept der Teststrategie in Abbildung 7 2 fasst die bisher eingef hrten Be griffe und Komponenten zusammen X gt User Admin A roto 4 Test User i env fw
120. ete Paketfilterung und ver nderung durchf hrt und der Cut Through Proxy der die Benutzerauthentifizierung durchf hrt Grundkonzept des ASA sind Sicherheitslevel Sie werden vom Administrator den Netzwerkadaptern zugeordnet wobei sie zur Umsetzung einer default Policy genutzt werden indem Netzwerkver kehr zun chst nur von einem h heren inside zu einem niedrigeren outside Level m glich ist Alle weiteren Zugriffe m ssen ber access lists und Adressumsetzung definiert werden Dabei wird die Adressumsetzung als die Ver ffentlichung von er reichbaren Adressen auf einer Netzwerkschnittstelle verstanden so dass selbst bei gleichbleibenden Adressen eine Adressbekanntgabe in den Zonen mit niedrigerem Sicherheitslevel stattfinden muss routing add state nat I ASA engine filter impl rules has NAT S nat to devices Abbildung 4 7 Paketfl sse durch die Cisco PIX Abbildung 4 7 zeigt die Interpretation des Paketflusses nach den genannten Quel len Die PIX unterscheidet zwei Zustandspeicher einen f r die Verbindungen conn table und einen f r die durchgef hrten NAP T Umsetzungen alate table Wird bei einem Vergleich des Paketes mit einer der Tabellen ein passender Eintrag gefunden dann wird ein Vergleich mit den Filterregeln bersprungen In jedem weiterleiten dem Fall werden die Pakete von dem ASA berpr ft der den Anwendungsbereich mit stat
121. eweiligen Standards oder BG92 B r94 als Sekund rliteratur verwiesen auf denen die folgenden Abschnitte basieren Nach I809646 wird ein getestetes System im OSI Kontext vgl Abbildung 2 1 als konform bezeichnet wenn es den Anforderungen der entsprechenden OSI Spezifika tionen bei der Kommunikation mit anderen Systemen entspricht Die Anforderungen werden in notwendige bedingte und optionale Anforderungen untergliedert die je weils als Gebote oder Verbote ausgedr ckt werden k nnen Schlie lich wird noch zwi schen statischen und dynamischen Konformit tsanforderungen unterschieden Erste re beschreiben die zugelassenen Kombinationen von F higkeiten insbesondere die kleinste Teilmenge die erforderlich ist damit die Zusammenarbeit zwischen Syste men m glich ist Die dynamischen Konformit tsanforderungen machen jeweils den gr ten Teil einer Protokollspezifikation aus und legen den Gesamtumfang des po tentiell m glichen und erlaubten Protokollverhaltens von Implementierungen fest Um diese Flexibilit t in der Spezifikation von Protokollen kontrollieren zu k nnen m ssen zur Planung und Durchf hrung von Tests Frageb gen vom Testkunden aus gef llt werden Das PICS Formular protocol implementation conformance state ment gibt an welche der Anforderungen und F higkeiten die zu testende Pro tokollimplementierung verspricht und dient dazu relevante Testf lle auszuw hlen Dar ber hinaus werden zus tzliche Informationen
122. geleitet mit dem drei ausgew hlte Paketfilter auf bereinstimmung vergli chen wurden Dabei wurden jeweils Abweichungen festgestellt die auf die Interpreta tion der Schutzfunktion des Paketfilters durch den jeweiligen Anbieter zur ckgef hrt werden konnten Der entwickelte TCP Automat kann durch das Hinzuf gen oder Entfernen von Transitionen auf ein konkretes Produkt eingestellt werden In IHASO05 wird eine neuartige Technik f r das effiziente und automatische Tes ten von Firewalls vorgestellt die spezielle Testf lle unter Ber cksichtigung der ein gesetzten Sicherheitsrichtlinie erstellen und testen kann Die Richtlinien basierende Segmentierung des Adressraumes kann die Testfallgenerierung auf potentiell fehler hafte Regionen in dem von der Firewall genutzten Eingaberaum reduzieren bzw konzentrieren was das Problem des automatischen Testens handhabbar macht und einen signifikant h heren Vertrauensgrad im Vergleich zum zuf lligen Testen gibt 115 10 Bewertung und Vergleich 10 3 Vergleich Aus der Sicht eines vollst ndigen Tests entsprechen Penetrationstests dem blinden Herumstochern in einer unbekannten Konfiguration mit der Absicht ausnutzbare Schwachstellen zu finden Bsp Hae97 Auch systematische Tests in einer einzigen statischen Umgebung wie sie f r verschiedene Zertifizierungen durchgef hrt werden verlieren in einem realen Netzwerk mit einer konkreten Konfiguration ihre Aussage kraft vgl Vig97 Die
123. gkeiten die in Tabelle 9 3 zusammengefasst sind sind in einer Spezifikation zu finden Daraus folgt aber nicht dass in netfilter iptables keine Fehler bzw Unstetigkeiten zu finden oder dass die Anforderungen und Spezifikatio nen vollst ndig umgesetzt sind Protokoll Eigenschaft Policy Reaktion Begr ndung all src 0 0 0 0 REJECT DROP RFC1812 Sektion 5 3 all src 255 255 255 255 REJECT DROP RFC1812 Sektion 5 3 ICMP redirect message to fw 5 all DROP RFC1122 Sektion 3 2 ICMP error message 3 4 11 12 REJECT DROP RFC1812 Sektion 4 3 ICMP reply message 0 14 16 18 SNAT unver ndert INVALID kein Kontext TCP flags PUFARS XMas SNAT unver ndert INVALID kein Kontext Tabelle 9 3 Auflistung der entdeckten Abweichungen im netfilter Verhalten 106 9 3 Erkenntnisse aus der Untersuchung von iptables Die Analyse verschiedener Versionsst nde des iptables Paketfilters zeigte Unter schiede auf die sich dazu nutzen lassen spezielle Testkonfigurationen zu erstellen mit denen sich die Versionen unterscheiden lassen Damit w re hnlich einem Finger abdruck eine Identifikation des Paketfilters in einem vermittelnden Knoten m glich Folgende Abweichungen wurden zwischen mehreren netfilter Versionen festgestellt Unterschiedliche Bedeutung von syn im iptables frontend iptables interpretiert die Angabe der Konfigurationsoption syn zur berpr fung der TCP Flags bis zur Version 1 3 8 als nur SYN aus FIN SYN RST ACK gesetzt Mi
124. gsunterschiede auf bei denen sie sich nicht gleich verhalten Der Umkehrschluss gilt nicht Werden keine Abweichungen festgestellt so ist es kein Nachweis dass die Wirkung beider Paketfilter im gesamten Testraum gleich ist Sollte der FWA in Zukunft weitere Konfigurationssprachen unterst tzen so w re es m glich die Strategie zu erweitern und auch Vergleiche zwischen verschiedenen Paketfiltern durchzuf hren 9 2 Beispiele der Testabdeckung Die Qualit t der entwickelten Teststrategie kann anhand der erreichten Testabde ckung gemessen werden Auch wenn die Teststrategie nur prototypisch umgesetzt wurde k nnen bereits Ans tze und Tendenzen identifiziert werden Im Folgendem werden Auswertungen der Testabdeckung von vier Konfigurationen vorgestellt F r die Auswertung wurden zwei reale Konfigurationen und zwei Testkonfigura tionen ausgew hlt Die Konfiguration Uniseb2 geh rt zu der ersten Kategorie und wird f r die Anbindung eines Arbeitsraumes im Fachbereich KBS der Fakult t IV an das Uni interne Netz verwendet Gleichzeitig ist das auch die gr te untersuchte Konfiguration Rusty 2 ist eine reale Minimalkonfiguration zur Verbindung eines pri vaten Netzwerks mit einem ffentlichen unter Verwendung von Masquerading Die letzten beiden clean und ICMP sind einfache Konfigurationen die zum Testen der Strategie erstellt wurden Die Konfigurationen sind zustandsbehaftet und reglemen tieren die drei Protokolle TCP UDP und ICMP Unise
125. gsverfolgung Im Abschnitt 2 1 wurden Firewalls als reglementierende Beobachter von Kommuni kationsabl ufen definiert Sie sind vermittelnde Knoten zwischen den Endpunkten die die Kommunikation beobachten k nnen sie bewerten und gegebenenfalls ent sprechend ihrer Konfiguration eingreifen sollen In diesem Abschnitt wird zuerst die grundlegende Notwendigkeit die Protokollzust nde der Endpunkte zu verfolgen und die damit verbundene problematische Aufgabenstellung eingef hrt Danach werden die Umsetzungen der untersuchten Firewalls vorgestellt die durch eine Analyse iden tifiziert wurden In ihrer beobachtenden Position zwischen den eigentlichen Endpunkten stehen die Firewalls in einer ung nstigen Position in der sie nur eine ungef hre Vorstellung von den Protokollzust nden der Endpunkte haben blicherweise werden Protokol labl ufe f r die miteinander kommunizierenden Endpunkte spezifiziert wodurch sich nur indirekt und gegebenenfalls uneindeutig eine Protokollbeschreibung f r den Zwi schenpunkt ableiten l sst Zwischen den beiden Kommunikationspartnern k nnen mehrere solcher reglementierenden Instanzen positioniert sein wobei jede von ihnen ihre eigene Vorstellung vom aktuellen Zustand der Assoziation und ihre eigene Richt linie bzgl der Reglementierung hat Dadurch k nnen die nachgelagerten Instanzen nur einen Ausschnitt aus der tats chlichen Kommunikation beobachten wodurch u U Uneindeutigkeiten entstehen Von au en g
126. h aufgrund der internen Zustandsmaschine in den ESTABLISHED Zustand bringen Die Strategie beschr nkt sich darauf das SYN Flag zu setzen ESTABLISHED Voraussetzung f r das Ausl sen einer ESTABLISHED Regel ist ein vorhandener Eintrag in der Verbindungsverfolgung Das Paket muss mit dem gleichen Adress Port Tupel sowie einer geeigneten Flag Kombination ver schickt werden Nicht jedes Paket das als ESTABLISHED interpretiert wird ndert den inter nen Zustand der TCP Statemachine Implementierung der ICMP Tests Eine ICMP Assoziation wird im Netfilter eindeutig durch IP Adressen ICMP Type ICMP Code und Identifier definiert Der Identifier wird nur von bestimmten Typen verwendet Jeder Zustand der ICMP Assoziation kann nur mit Paketen mit bestimmten ICMP Typen erreicht werden In der Implementierung wurden ICMP Typen aus RFC792 RFC950 RFC1108 RFC2002 betrachtet Alle ICMP Typen die beim Testen ber ck sichtigt werden sind in fwt_constants py definiert Nicht alle ICMP Verbindungen lassen sich in der aktuell verwendeten Testumge bung testen Deshalb wurden einige aus den Tests ausgeschlossen ICMP type 5 Redirect message Hierbei handelt es sich um eine Aufforderung des Gateways an den Sender zur direkten Adressierung des Zielrechners Das 97 8 Proof of concept Gateway stellt dabei fest dass Sender und Empf nger sich im gleichen Adres sierungssegment befinden und eine Vermittlung nicht notwendig ist Nachrich
127. heitsziele und deren Bedrohungen muss einem Akteur zurechenbar und im strengeren Sinne sollte die Aktionsbelegung auch nicht anfechtbar sein Die Sicherheitsziele werden durch die Enth llung bzw Preisgabe von Informatio nen die Korruption bzw Ver nderung von Daten die Unterbrechung bzw St rung die T uschung und die widerrechtliche Aneignung bedroht Die Sicherheitsziele und dessen Bedrohungen werden in dieser Arbeit als Grundlage verwendet verschiedene Angriffsklassen vorzustellen und die Sicherheitsmechanismen der Firewalls vorzustel len Technische Bedrohungen Technische Sicherheits Verschleierung Abh ren Verletzung d Verlust Modifi F lschung Abstreiten Y Sabotage ziele Maskarade Autorisierung kation von Daten von Daten Kommunikation St rung Vertraulichkeit VA VA VA Integrit t WA y Z VA Verf gbarkeit vA VA Sf VA Zurechenbarkeit S YA Z Sf Zugriffskontrolle J Va v Angriffsbeispiele auf Netzwerk und Transportebene Adressf lschung Ma occa x e Pol eardrop 7 Netzwerken Flooding DoS Tabelle 2 2 Sicherheitsziele und Angriffsklassen IP Spoofing oder Adressf lschung bedroht unmittelbar die Zurechenbarkeit von Aktionen Indirekt hat die Verschleierung bzw Maskarade auch Auswirkungen auf die anderen Sicherheitsziele Auch das Abstreiten von Kommunikationsakten gef hrdet die Zurechenbarkeit Verschiedene Techniken zum Abh ren von Daten gef hrden die Ve
128. ht von einem Paket enthalten das bereits registriert wurde und der Verbindungsverfolgung bekannt ist Um eine ICMP Assoziation im RELATED Zustand aufzubauen muss zuerst ein geeignetes Paket gesendet werden das die Konfiguration passieren l sst und von der Firewall weitergeleitet wird Daraufhin kann in Gegenrichtung ein ICMP Paket von den genannten Typen mit dem zuvor gesendeten Paket zumindest der IP Header und 8 Byte der h heren Schicht in der Nutzlast gesendet werden INVALID Die INVALID Assoziation wird durch Senden eines Antwortpaketes er zeugt wenn keine entsprechende Anfrage gesendet wurde Alternativ ist es auch m glich eine ICMP Fehlermeldung zu senden die sich auf keine bekannte Assoziation bezieht 8 3 Ausblick auf k nftige Erweiterungen In diesem Abschnitt wird ein Ausblick auf die weiteren Entwicklungsm glichkeiten der FWTStrategy gegeben Es soll als eine technische Zusammenfassung der aktuellen Strategie und m gliche Erweiterungen vorstellen Als problematisch bei dem gew hlten Ansatz hat sich das Einlesen der Vektordatei herausgestellt Die ganze Datei wird auf einmal ber die Pythonfunktion ezecfle evaluiert wobei alle erstellten Objekte gleichzeitig im Speicher gehalten werden Dies f hrt bereits bei 1000 Listen mit je 1000 Elementen in der Vektordatei zu einem Speicherverbrauch von etwa 380MB und steigt fast linear im Verh ltnis zu der Anzahl der Listen an Diese Gr enordnung der Listen ist nicht nur th
129. hte berechnet Jeder der Pfade wird auf Testbarkeit berpr ft wobei er verworfen wird wenn e in einem der Vektoren die geforderten Eigenschaften nicht spezifikationskon form sind oder die berg nge keinen validen Protokollfluss etablieren k nnen in der Tabelle als skip Protokoll gekennzeichnet oder e die Vereinigung der definierten Adressen und Ports eine leere Menge ergibt also keine verwendbaren Elemente brig bleiben skip InterSection F r jeden verwendbaren Testpfad werden daraufhin zwei Testpunkte TP bestimmt die dann getestet werden k nnen Jeder Test der Testpunkte wird schlieflich als erfolgreich oder fehlgeschlagen bewertet Diese Auswertung wird dem Benutzer in komprimierter Form dargestellt Darauf basierend ist es m glich Aussagen ber die Qualit t des Regelwerks und der durch gef hrten Tests zu treffen Die fehlgeschlagenen Tests werden sofern ermittelbar in konfigurations spezifikations und implementierungsbedingte Ergebnisse kategori siert bertragung des einfachen Tests auf den vollst ndigen Testraum Nachdem der Testvorgang f r einen Testvektor vereinfacht beschrieben wurde wird jetzt das gleiche Verfahren auf den vollst ndigen Testraum bertragen Dabei wer TT 7 Allgemeine Teststrategie paths skip P skipIS test TP OK error Vektor 23 A2B TCP INV 1 0 0 1 2 2 0 NEW 1 0 0 1 2 2 0 EST 3 0 1 2 4 4 0 REL 3 3 0 0 0 0 0 UDP Vektor 42 B2A TCP Gesamt 168 323 97 348 696
130. http www algosec com Products FA besucht am 26 06 2007 Amap Firewalk FPA F Tester fwtest Hping IPF IPFW Netfilter Nmap PF Scapy Wireshark Hauser Van und DJ RevMoon Amap URL http www thc org thc amap besucht am 26 06 2007 Schiffman Mike D Firewalk URL http www packetfactory net projects firewalk besucht am 06 06 2007 Al Shaer Ehab und Hazem Hamed Firewall Policy Advisor URL http www mnlab cs depaul edu projects FPA index htm be sucht am 26 06 2007 Barisani Andrea FTester URL http dev inversepath com trac ftester besucht am 26 06 2007 Strasser Beat und Gerhard Zaugg fwtest ETH URL http www infsec ethz ch education projects archive besucht am 26 06 2007 Sanfilippo Salvatore hping URL http www hping org besucht am 26 06 2007 Reed Darren u a PFilter IPF URL http coombs anu edu au avalon ip filter html besucht am 26 06 2007 Handbuch der FreeBSD IP FireWall IPFW URL http www freebsd org doc en_US I808859 1 books handbook firewalls ipfw html besucht am 26 06 2007 Netfilter Core Team u a netfilter org URL http www netfilter org besucht am 26 06 2007 Fyodor u a Nmap URL http www insecure org nmap index html besucht am 26 06 2007 Hartmeier Daniel u a OpenBSD Packet Filter PF URL http ww benzedrine cx pf html besucht am
131. ial sowie die Testabdeckung aufzuzeigen 1 2 Vorgehen und Struktur Die Aufgabenstellung beinhaltet zwei Aspekte die zu untersuchen und zu bearbeiten sind die Untersuchung der Firewallsysteme und die Entwicklung der allgemeinen Teststrategie In Abschnitt 2 1 werden allgemeine Netzwerkknoten eingef hrt und von den auf Schutzfunktionen spezialisierten Firewallsystemen abgegrenzt In Abschnitt 2 3 wer den mehrere repr sentative Paketfilter ausgew hlt die in den Kapiteln drei bis f nf genauer analysiert werden In Kapitel 3 und Kapitel 4 werden die ausgesuchten Firewalls vorgestellt und ana lysiert Dabei werden im ersten Teil der Auswertung die unterst tzten Merkmale Dienste und Funktionen der Firewallsysteme betrachtet Abschnitt 3 3 vergleicht die M chtigkeit der Probanden und bewertet die Testbarkeit der einzelnen Komponenten sowie ihre Eigenschaften Der zweite Teil untersucht die Funktionsweise der Paket filter und konzentriert die Betrachtung in Abschnitt 4 2 auf die zustandsbehaftete Verbindungsverfolgung sowie die Paketfl sse innerhalb der Paketfilter Dabei wird die grundlegende Problematik der Verbindungsverfolgung zweier Endpunkte in ei nem Zwischenpunkt wie es die Firewall ist erkl rt In Kapitel 5 wird ein allgemeines Modell f r die zustandsbehaftete Paketfilterung 1 Einleitung und ver nderung entwickelt Die zuvor identifizierten Paketfl sse werden in mehrere Arbeitsschritte aufgeteilt und in Abschnitt 5
132. ie Ableitung der Regeln aus einer Richtlinie setzt letztere ebenfalls voraus Da eine Richtlinie allgemein und abstrakt definiert ist m ssen firewallspezifische Eigen schaften und Funktionen trotzdem manuell in die erstellte Konfiguration eingef gt werden was die Benutzbarkeit und die bereinstimmung der beiden einschr nkt Werden Firewalls aber schon eingesetzt so werden ihre Konfigurationen oftmals die ersten tats chlich vorhandenen formalen Beschreibungen der netzwerkbezogenen Sicherheitsrichtlinien sein Diese lassen sich sowohl zu einer Richtlinie verallgemei nern formal analysieren wie auch in eine Teststellung abbilden Gleich mehrere Werkzeuge und Arbeiten behandeln die berf hrung der konkreten Regeln in eine abstrakte Form eine interne Darstellung oder eine allgemeine Richt linie FANG der Lumeta Firewall Analyzer und der AlgoSec Firewall Analyzer ana lysieren das Regelwerk auf potentielle Sicherheitsprobleme dh evtl unerw nschte Kommunikationskan le MWZ00 Woo01 MWZ05 Eine Analyse auf Anomalien 116 10 3 Vergleich oder Inkonsistenzen des Regelwerks wird nicht durchgef hrt Einen hnlichen An satz verfolgen die Arbeit von Eronen und Zitting EZ01 und das Tool ITVal MK05 FIREMAN Yua06 kann neben einzelnen auch verteilte Firewallkonfigurationen auf Anomalien berpr fen Ebenfalls mehrere Arbeiten untersuchen die formale Richtlinie selbst oder eine Form eines abstrakten Regelwerks Mit FPA ASH03 ode
133. ie abgelegte Informationsmenge und Wirkung ist mit dem bereits vorgestellten conntrack Mechanismus bei netfilter iptables vergleichbar Allerdings hat bei IPFW der Benutzer keinen Zugriff auf die internen Zust nde bei der Verbindungverfolgung und kann sie auch nicht explizit in dem Regelwerk ansprechen nr in out rule 00100 0 0 check state 00200 674 57241 allow tcp from 10 0 1 0 24 to any keep state 00300 46 3674 allow udp from 10 0 1 0 24 to any keep state 00400 34 2856 allow icmp from 10 0 1 0 24 to any keep state 65535 42 4754 deny ip from any to any Dynamic rules 24 00400 5 420 5s STATE icmp 10 0 1 11 0 lt gt 10 0 1 1 0 00200 673 57181 300s STATE tcp 10 0 1 11 34022 lt gt 10 0 1 1 22 Listing 4 3 Beispiel f r IPFW Zustandsinformationen ber die internen Mechanismen zur Erstellung der dynamischen Regeln und der tats chlich ber cksichtigten Paketeigenschaften ist keine Dokumentation vorhanden IPFilter IPFilter kann bei jeder Regel angewiesen werden Zustands und Fragmentinformatio nen keep state und keep frags zu sammeln die anschlie end automatisch verwendet werden und dazu f hren dass folgende Pakete mit den gespeicherten Eintr gen ver glichen werden und eine erneute Regelauswertung bersprungen wird Beim Accounting und der Zustandsgenerierung werden sehr viele Informationen gesammelt die geloggt und abgerufen werden k nnen F r das Logging wird ipmon verwendet das separat aktuelle nder
134. ie hier nicht betrachtet wird 6Zur Konfigurationssprache der PF vgl die manpage pf conf 5 IPFilter ist in CF02 und in der manpage ipf 5 dokumentiert 22 3 2 Merkmale der Regelverarbeitungs und Filtereinheiten Struktur des Regelwerks Alle untersuchten Firewalls verwalten die Regeln in Listen oder Tabellen Bei der FW 1 sind sie jedoch nicht sichtbar da es nur eine grafische Ein und Ausgabem g lichkeit gibt blicherweise werden die Regeln sequentiell nach dem first match Prinzip bearbeitet Ausnahmen sind IPF und PF die standardm ig im last match Modus arbeiten aber auch regelweise umgeschaltet werden k nnen Diese M glichkeit f hrt zwar zu einer h heren M chtigkeit der Konfigurationssprache da die Abarbeitung der Regeln vorzeitig abgebrochen werden kann macht aber gleich zeitig die Benutzerschnittstelle im Mischbetrieb fehleranf lliger und vermindert die Benutzbarkeit Bei iptables gibt es f nf vorgegebene Zugriffspunkte auf Pakete im Paketfluss an denen der Benutzer seine Regeln in Abarbeitungsketten chains definieren kann Der Benutzer kann die Systemketten mit eigenen Ketten erweitern und in sie verzweigen Das Aufrufen weiterer Ketten kann bei bereinstimmenden Kriterien wahlweise die aktuell bearbeitete Kette ersetzen jump oder erweitern goto Die vorgegebene Aktion RETURN erlaubt einen R cksprung in der Abarbeitungskette und setzt die Ausf hrung in der letzten Kette aus der mit jump ver
135. igenschaften kapseln Verwaltung der Testpunkte Damit die Tests und die Pakete sich nicht gegenseitig beeinflussen m ssen die be nutzten Tupel aus IP Adresse und gegebenenfalls Port oder Typ f r die sendende und empfangende Seite reserviert werden Die Kombination von Quell IP Quell Port Ziel IP und Ziel Port sowie das Protokoll bilden einen Identifikationsschl ssel der den Verbindungskontext f r TCP und UDP eindeutig beschreibt Das ICMP Protokoll kann sofern der eigenst ndige Teil aus Anfragen und Antworten betrachtet wird eindeutig ber Quell IP Ziel IP sowie das Paar ICMP Typ und Code beschrieben werden Der kontextabh ngige Teil der ICMP Fehlermeldungen muss nicht separat 8l 7 Allgemeine Teststrategie algorithm vereinige Vektoren input Liste von Vektoren output Schnittvektor or null schnittvektor Vektor aus Vektorliste for vektor in Vektorliste if senderichtung vektor senderichtung schnittvektor then Richtung des vektors umdrehen schnittvektor src schneide schnittvektor src vektor src schnittvektor dst schneide schnittvektor dst vektor dst for feld in schnittvektor if Gr fe des Feldbereiches 0 then return null return schnittvektor Listing 7 3 Algorithmus vereinige Vektoren Bildet die Schnittmenge der Eigen schaften mehrerer Vektoren algorithm schneide input Bereich min max Bereich min maz output Bereich min max if min lt min then min Mi
136. im Paketfluss betrachtet aber aufgrund der Zielstellung dieser Arbeit nicht weiter untersucht Die Funktionen Paketfilterung und modifikationen sind bereits mit der Symboldar stellung in Abbildung 5 4 b gen gend beschrieben Interessant ist die Kombination dieser Funktionen mit der Verwendung von Zust nden f r Assoziationen Modifika tionen NAT IP Fragmente oder Statistikdaten Die NAT Funktion ist ein gutes Beispiel f r die Vorteile die sich aus der Aufspal tung der Regelwerk und Zustandstabellennutzung in die einzelnen Schritte erge ben Dadurch ist es m glich sowohl zustandsbehaftete wie auch zustandslose NAT Varianten zu modellieren Letztere haben aber inzwischen an Bedeutung verloren da sie eine eingeschr nkte Funktionalit t und weniger Einsatzm glichkeiten bieten vgl die Einf hrung zu NAT auf Seite 9 Die zustandslose Variante wird durch die zwei Arbeitsschritte Regelwerk konsul tieren und gegebenenfalls Regelwerk anwenden beschrieben Bei der Verwendung von Zustandseintr gen w rden noch die Arbeitsschritte Zustand anlegen Zustand konsultieren und Zustand l schen hinzukommen vgl Abbildung 5 5 Dabei w rde bei bereinstimmung Zustand konsultieren auch gleichzeitig das Anwenden der in den Zustandsdaten gespeicherten Transformationen beduten 7 has NAT state R NAT TABLE X es a einfache b NAT Funktion mit NAT Funktion Zustandsspeicher Abbildung 5 5
137. in Tabelle A 4 gelistet sind Switch Betriebsart Adresse Netzmaske vmnet1 Host Only 192 168 10 1 255 255 255 0 vmnet2 None vmnet3 None Tabelle A 4 Konfiguration der virtuellen Switche Die virtuellen Systeme werden jeweils mit zwei Netzwerkadaptern ausgestattet die wie in Tabelle A 5 angegeben mit den virtuellen Switches zu verkn pfen sind Die Adressen auf den virtuellen Systemen m ssen manuell konfiguriert werden Zus tzlich muss auf dem Firewallsystem die Weiterleitung von Paketen aktiviert werden was mit echo 1 gt proc sys net ipv4 ip forward eingestellt werden kann Adapter 0 Adapter 1 IP Adresse Switch IP Adresse Switch Agent A 192 168 20 2 vmnet2 192 168 10 2 vmnetl Agent B 192 168 30 2 vmnet3 192 168 10 3 vmnetl Firewall 192 168 20 1 vmnet2 192 168 30 1 vmnet3 Tabelle A 5 Netzwerkeinstellungen der virtuellen Systeme F r die korrekte Ausf hrung m ssen zuerst die Netzwerkumgebungen in den Agen ten definiert werden Diese Definitionen befinden sich in einer Konfigurationsdatei unter etc fwtest fwtest conf Der Abschnitt environment in der fwtest conf setzt die Grob und Feinfilter und hat zwei Angaben zur Netzwerkumgebung wovon eine von den f r Agent A und die andere f r Agent B zust ndig ist Die Syntax sieht wie folgt aus environment env tn A 10 1 0 0 10 1 255 255 env tn B 10 130 0 0 10 130 255 255 Bevor FW TStrategy aufgerufen wird m ssen die Agenten
138. inde Eintr ge f r Wurzel Protokoll Zustand in aList for element in teilliste vorelement ermittle Vorelement zu Element teilbaum generiere Baum vorelement aList h nge teilbaum an knoten return knoten Listing 7 2 Algorithmus generiere Baum Generiert Baumstruktur aus der Liste der Assoziationen tiert oder hergeleitet werden kann Dies kann passieren wenn die Schnittmenge der m glichen IP Adressbereiche und der Ports zwischen den ausgew hlten Vektoren im Testpfad leer ist was also abh ngig vom Regelwerk ist Die Algorithmen die diese berpr fung durchf hren sind in Listing 7 3 und Listing 7 4 angegeben Weiter hin k nnen die in den Vektoren geforderten Eigenschaften nicht spezifikationskon form sein so dass keine funktionierenden Pakete daraus erstellt werden k nnten Dann kann der Testpfad nicht berpr ft werden und der Benutzer wird entsprechend dar ber in Kenntnis gesetzt berpr fung des Testpfades Bevor ein Pfad tats chlich freigegeben wird und getestet werden kann muss er auf Konformit t zur Protokollspezifikation berpr ft werden Bei der berpr fung muss einerseits jeder Vektor im Testpfad f r sich dahingehend betrachtet werden ob die beschriebenen Eigenschaften spezifiziert sind und andererseits ob die berg nge zwischen den Elementen im Testpfad hergestellt werden k nnen Hierzu werden f r jedes Protokoll spezielle Pr ffunktionen implementiert die diese protokollabh ngigen E
139. ionen Gegeben seien zwei unterschiedlich formulierte Konfigurationen f r einen Paketfilter und die Behauptung dass die beobachtbare Wirkung beider Konfigurationen gleich sei Dann ist es mit FWTStrategy m glich diese Behauptung zu berpr fen Dazu sind folgende Konfigurationen zu testen 1 FWTStrategy mit Config A und Paketfilter mit Konfiguration A 2 FWTStrategy mit Config A und Paketfilter mit Konfiguration B 3 FWTStrategy mit Config B und Paketfilter mit Konfiguration A und 4 FWTStrategy mit Config B und Paketfilter mit Konfiguration B Werden bei den Testkonfigurationen Abweichungen zwischen den erwarteten und den beobachteten Ergebnissen festgestellt so ist die Behauptung falsifiziert Eine Verfifizierung ist aufgrund der unvollst ndigen Testabdeckung nicht m glich Aus den Meldungen von FWT Strategy ist es aber m glich einen Teil der Unterschiede zu identifizieren Vergleich von zwei Paketfilterversionen Gegeben sei eine Konfiguration f r einen Paketfilter Diese wird auf zwei verschiede nen Versionen des Paketfilters installiert FWT Strategy soll die Wirkungsunterschie de beider Paketfilter vergleichen Dazu sind folgende Konfigurationen zu testen 1 FWTStrategy mit Config A und Paketfilter 1 mit Konfiguration A 103 9 Ergebnisse 2 FW TStrategy mit Config A und Paketfilter 2 mit Konfiguration A Werden zwischen beiden Testkonfigurationen Abweichungen festgestellt so weisen beide Paketfilter Wirkun
140. irewallbetrieb Penetrations und Produktivumgebungstests Haeni Hae97 gibt in seiner Arbeit eine Anleitung und Empfehlungen f r das Vor gehen bei Penetrationstests in Produktivumgebungen Grofes Augenmerk legt er dabei auf die Festlegung des durchf hrenden Testers der daraus resultierenden Ver trauensstellung und Ergebnisqualit t Weder die Hersteller noch rekrutierte Hacker stellen f r ihn eine geeignete Auswahl dar und er empfiehlt ausgebildete und erfah rene Sicherheitsexperten damit zu beauftragen Die Methodologie selbst gliedert er in vier Phasen die indirekte und die direkte Erfassung von Informationen sowie die externen und die internen Angriffe auf das Zielobjekt Der Bericht ist eher prak tisch orientiert beschreibt aber sehr gut die typische manuelle Durchf hrung einer Sicherheitsuntersuchung Vigna Vig97 dagegen kritisiert die bliche Testpraxis bei Firewallprodukten und deren Einsatz Die oft angewandten Checklisten basierenden Produkttests Penetra tionstests oder gar berpr fungen f r die Vergabe von Sicherheitszertifikaten wie sie die NCSA ausstellt folgen alle der test once deploy many Strategie die in einer Produktivumgebung ihre Aussagekraft verliert Deswegen empfiehlt er Tests ausschlie lich unter Ber cksichtigung der konkreten Netzwerkstruktur einer Produk tivumgebung field testing durchzuf hren Die eigentliche berpr fung basiert auf einem formalen Modell das die Verbindungen zwischen
141. ischen Mustern vergleicht und gegebenenfalls das Paket verwirft oder modifi ziert Nach diesen berpr fungen wird DNAT angewendet ein Zustand erstellt das Routing und SNAT angewendet 36 4 1 Paketfl sse Checkpoint VPN 1 FireWall 1 Die Paketverarbeitung bei der FW 1 auf der SecurePlatform Linux wird in einem als Netzwerktreiber realisierten Hauptmodul das die inneren Funktionen auf Betriebs systemebene zusammenfasst durchgef hrt Dieses Hauptmodul greift je nach Konfi guration und Lizenzierung auf weitere Funktionsmodule zu die sich nach CPS03 wie in Abbildung 4 8 gezeigt anordnen ber die interne Verarbeitung konnten w hrend dieser Untersuchung kaum Informationen gefunden werden Zur weiteren Analyse w re es aber m glich die eingebauten Monitoring Funktionen die jeweils zwischen den Funktionsmodulen eingeschaltet werden k nnen zu nutzen ROUTING Monitoring Vii Re ae I i IP Acct i FG p i l l Filter VM f I VPN Policy la olicy N AT l l Accountin iO 2 Do VPN Policy S e NAT iB mi Filter VM i FGQoS S Zi Z T A VEM L ER i VPN encrypt i VPN decrypt i l l I Accounting pubem a i Wire Side Acct RT Monitoring l Layer 2 Abbildung 4 8 Paketfl sse durch FW 1 37 4 Funktionsweise der Paketfilter 4 2 Zustandsbehaftete Verbindun
142. it beeintr chtigt verf gt sie ber Mechanismen die im Falle einer besonderen Auslastung durch DoS Angriffe Ma nahmen einleiten Gil02 und Sch97 beschreiben solche Angriffe zu denen u a das Flooding der Verbin dungstabelle und der eingesetzten Authentifizierungs Proxies geh rt Gleichzeitig werden mehrere Gegenma nahmen vorgeschlagen die genutzt werden k nnen wenn die Verbindungstabelle n einen einstellbaren F llungsgrad erreichen Darunter ist es m glich e die Gr e der Tabelle dynamisch anzupassen e die am l ngsten inaktiven Verbindungen zu schlie en e die Timeouts der eingetragenen Verbindungen bzw die initialen Werte f r den Verbindungsaufbau dynamisch anzupassen und zu skalieren aggressive aging e TCP Verbindungsversuche nicht mehr zwischenzuspeichern und SYN Cookies einzusetzen Die Abwendung einer berm igen Auslastung kann mit einstellbaren Grenzwer ten f r die jeweils maximale Anzahl der zwischengespeicherten IP Fragmente die maximalen Verbindungsversuche pro Quelladresse die maximale Gesamtanzahl halb offener TCP Verbindungen oder die maximale Anzahl von Log Eintr gen das je weils mit der Begrenzung pro Zeiteinheit kombiniert werden Mechanismen zur Limitierung der verschiedenen Freignisse bieten alle Firewalls an Bei SYN Cookies werden Antwortpakete f r den 3 Wege Handshake so erstellt dass kein Zustand gespeichert werden muss aber eine legitime Antwort vom Initiator eindeutig
143. ition benutzt Bei der Besprechung der Protokolle und der Netzwerkkomponenten ist es notwen dig eine Relation zwischen den beiden Endpunkten zu betrachten Der intuitive Be griff Verbindung wird sehr stark mit verbindungsorientierten Protokollen wie TCP verkn pft und w re bei paketorientierten Protokollen wie UDP oder ICMP miss verst ndlich Deswegen wird hier protokoll bergreifend von Assoziation gesprochen Netzwerkknoten mit Schutzaufgaben Eine Firewall ist ein Netzwerkvermittlungsknoten der am Rand von zwei oder meh reren Netzwerken den durchgehenden Netzwerkverkehr reglementiert und Sicher heitsaufgaben bernimmt Zu den grundlegenden Aufgaben einer Firewall geh rt der Schutz der Netzwerkknoten die durch die Firewall verbunden sind und entsprechend der Sicherheitspolitik sch tzenwerten sind Die meisten Firewalls bernehmen auch Routing und Protokollumsetzungsaufgaben Eine Firewall ist aber nicht nur passi ver Beobachter mit Weiterleitungsfunktion sondern muss aufgrund seiner Aufgabe auch aktiv eingreifen Dabei dienen Protokollspezifikationen und die Konfiguration 2 1 Netzwerkfunktionen und Firewalltypen als Grundlage f r die Eingriffsentscheidungen Genauer betrachtet ist eine Firewall ein Firewallsystem das aus mehreren Kom ponenten besteht Deswegen m ssen die Begriffe Firewallsystem Firewall Software und Filtersoftware eingef hrt und unterschieden werden Firewallsystem bezeichnet das gesamte System bestehe
144. iziell in FreeBSD 2 0 eingef hrt und ist heute einer von drei Paketfiltern des Betriebssystems Im Sommer 2002 ist nach einer grundlegenden berarbeitung IPFW2 welches um IPv6 und zustandsbehaftete Filterung erweitert wurde erschienen Weiterhin basiert die in Mac OS X eingesetzte Filtersoftware ebenfalls auf IPFW2 In dieser Arbeit wird aufgrund der fehlenden Dokumentation der BSDi Version vorrangig die FreeBSD Variante vorgestellt Dort wo es m glich ist werden die Unterschiede der beiden gegen ber gestellt IPFilter IPF wurde im Jahre 1993 als alleinstehendes Projekt gestartet und zuerst 1996 in NetBSD 1 2 bzw FreeBSD 2 2 integriert l sst sich aber auch in zahlreiche 5Die Angaben sind ber http www channelpartner de news 207172 index html und http www channelpartner de news 205521 index html referenziert da der direkte Bezug von IDC kostenpflichtig ist Aktuellere Zahlen konnten nicht ermittelt werden 14 2 8 Auswahl und Klassifizierung repr sentativer Firewallsysteme weitere UNIX verwandte Systeme integrieren Es stellt u a die Basis f r die Fire wallsoftware in Sun Solaris 10 bzw OpenSolaris oder die kommerzielle Sidewinder G2 Security Appliance von Secure Computing dar Der Packet Filter PF wurde 2001 f r OpenBSD 3 0 entwickelt nachdem sich lizenztechnische Probleme mit dem bis dahin eingesetzen IPF ergeben hatten Sp ter wurde es auch nach FreeBSD und NetBSD portiert wo es als alternativer Paketfilt
145. ketfluss und die Zustandsverfolgung des Probanden zu erfassen welche f r die Steuerung der Tests verwendet werden F r eine funktionierende Nachbildung der Zustandsverfolgung m ssen weiterhin die Zustandsmaschinen der unterst tzten Protokolle abgebildet werden um verschiedene Phasen der Assoziationen gezielt er zeugen zu k nnen Dabei m ssen auch die Timeouts f r jede der Phasen ber cksich tigt werden um eine gegenseitige Beeinflussung der einzelnen Tests auszuschlie en und auch die Wiederholbarkeit der Tests zu erm glichen F r die Vorbereitung und die Auswertung der Tests m ssen die unterschiedlichen Arten der Paketfilterung und ver nderung des Testobjektes nachgebaut werden Die Firewallkonfiguration umfasst benutzerspezifische Einstellungen des Systems wie einstellbare Parameter und Regeln oder die verwendeten Netzwerkeinstellungen 70 Aus der eingestellten Konfiguration bzw dem Regelwerk ergeben sich die zu unter suchenden Testpunkte an denen das Verhalten des Probanden berpr ft wird F r die Konfigurationsanalyse soll laut Aufgabenstellung der Firewall Analyzer FWA verwendet werden da er bereits im Vorfeld dieser Arbeit mit dem Ziel diese Unter suchung zu unterst tzen konzipiert und implementiert wurde Der FWA kann ein Firewall Regelwerk analysieren und in eine produktunabh ngige Darstellung ber f hren Dabei zerteilt der FWA die im Regelwerk beschriebenen Filterkriterien und Aktionen in disjunkte Bereich
146. kommen im Gegenzug die Paketfl sse eine h here Bedeutung wobei die Pakete im Kontext zu einander betrachtet werden m ssen Daneben basieren alle Pro tokolle auf Assoziationen zwischen zwei oder mehreren Kommunikationspartnern weswegen die Adressierung der Partner und die dadurch entstehenden Kombinatio nen betrachtet werden m ssen Eine weitere Reduzierung des Testraums bringt die Auswertung der Konfigura tionssprachen der betrachteten Paketfilter Die in Tabelle 3 2 beschriebenen Filter kriterien geben einen berblick ber die Unterscheidungsmerkmale der Paketfilter wieder weshalb die Testgranularit t nur so genau sein muss wie es in der Konfigu ration eingestellt werden kann und der Filter eine Unterscheidung macht Schlie lich k nnen die Modellierung der internen Paketfl sse und die Erkenntnis se aus den gesammelten Daten zur Zustandsverfolgung dazu benutzt werden den zeitlichen Rahmen und die erlaubten Paketfolgen zu definieren Sie werden auch zur Entwicklung der Testf lle und der Strategie bei der Paketauswahl benutzt um die Laufzeit zu optimieren und Wiederholbarkeit zu erreichen 6 4 Reduzierung des Testraums Der Testraum der zustandsbehafteten Filterung ist trotz der hier angef hrten Redu zierungen immer noch zu gro um vollst ndig getestet zu werden Deswegen wird eine Strategie eingef hrt mit der die Menge der unterschiedlichen Testpunkte redu ziert werden kann Dazu wird der gesamte Testraum anhand der Unt
147. konfigurationen Yua06 Diese sehr aktuelle Arbeit baut auf den vorherigen Arbeiten u a A Wool auf und kombiniert sie FIREMAN eignet sich zur Analyse von einzelnen wie auch verteilten Firewall L sungen Es kann echte Konfigurationen parsen und in eine eigene interne BDD basierende Darstellung umwandeln Diese kann es auf Inkonsistenzen und Inneffizienzen innerhalb einer Fire wall zwischen den Firewalls und bei mehreren m glichen Pfaden untersuchen Zudem werden Abweichungen zwischen den Konfigurationen und den Sicherheitsrichtlinien anhand der vom Administrator erweiterbaren white und blacklists verglichen FACE die Firewall Analysis and Configuration Engine VPO05 ist ein Werk zeug das hilft in einer verteilten Firewallumgebung die Sicherheitsrichtlinien kor rekt zu verteilen Das Hauptaugenmerk liegt auf der Implementierung von vertrau ensw rdigen Knoten wolken in denen Adressf lschung nicht m glich ist und daraus die Reduzierung von unn tigem Netzwerkverkehr resultiert Nicht implementierbare Richtlinien sollen einfach identifiziert werden k nnen und der firewall analyzer kann Anfragen nach erlaubtem Verkehr Korrektheit und Konsistenz des Regelwerks beant worten sowie die Folgen von Konfigurations nderungen oder der Kompromitierung eines Systems einer Firewall aufzeigen Das Modell orientiert sich an netfilter ipta bles und erlaubt als eines der wenigen Modelle auch Zust nde und TCP Flags zu ber cksichtigen Fi
148. konsultieren an wenden und l schen nach Timeout sowie Fragmenten f r deren Weiterbehandlung zusammensetzen Die Zusammensetzung kann entweder nur tempor r f r die inter nen Abl ufe oder dauerhaft ber Systemgrenzen hinweg durchgef hrt werden Alle vorgestellten Abl ufe sind eine direkte oder indirekte Folge aus einer Regel und deren Entscheidung Dabei wird neben dem Paketfilter auch die dem Routingvor gang zugrunde liegende Routing Tabelle als Regelwerk verstanden und im folgenden Abschnitt entsprechend modelliert Pakete stellen das Basisobjekt f r alle Firewallfunktionen dar Sie werden oft in Paketverwaltungsbl cken PVB verwaltet die z B SocKet Buffer SKB bei Linux und memory buffer mbuf bei den BSD Systemen hei en Sie beschreiben die Ei genschaften des Pakets enthalten einen Verweis auf das Paket selbst sowie weitere implementierungsspezifische Informationen Kontext und verbindungsorientierte Paketverarbeitung ben tigt Zustandsinfor mationen um Abh ngigkeiten zwischen den einzelnen Paketen herstellen zu k nnen In Abschnitt 4 2 wurde f r die untersuchten Firewalls gezeigt dass diese Daten sehr unterschiedlich aussehen k nnen Neben den vordergr ndigen Verbindungszust nden k nnen auch Zust nde f r die aktiven Adressumsetzungen die durchgef hrten Paket modifikationen und die unvollst ndigen IP Fragmente angelegt werden Hinzu kom men noch statistische Daten oder weitere erg nzende Daten zu den vom Benu
149. kzeptierte Pakete gespeichert die als Zustand der Firewall bezeichnet werden Beim Eintreffen eines Paketes wird es um eine zus tzliche Markierung die aus dem aktuellen Zustand der Firewall be rechnet wird erweitert Im n chsten Schritt wird das Paket incl der Markierung mit den Regeln des zustandslosen Bereiches verglichen um die erste zutreffende Re gel zu finden die eine Reglementierung vorgibt Dieses Modell hat sich trotz sei ner Einfachheit als besonders geeignet erwiesen und kann auch eine Vielzahl von Zustands berwachungsverfahren abbilden Es baut auf vielen Erfahrungen mit zu standslosen Firewalls sowie deren Analysen auf und ist zu ihnen kompatibel so dass In der angegebenen Quelle werden prototypisch Cisco ACLs unterst tzt 114 10 2 Verwandte Untersuchungen sie auch mit diesem Modell spezifiziert werden k nnen Der Bericht stellt neben dem Modell selbst auch eine Analyse der Eigenschaften von zustandsbehafteten Fi rewalls vor Es werden u a eine Methode sowie Kriterien vorgestellt mit denen sich berpr fen l sst ob eine Firewall in der Tat zustandsbehaftet truly stateful ist Spezifikationsbasierendes Testen J rjens und Wimmel JWO01 schlagen eine Methode f r das spezifikationsbasierte Testen von Firewalls vor Sie erlaubt es die Firewalls zusammen mit dem umgeben den Netzwerk formal zu definieren und daraus automatisch Testf lle abzuleiten die die Firewall auf Schwachstellen vulnerabilities
150. lche mit berlappenden Bereichen Anzeichen f r einen Angriff Manchmal ist auch die wiederspr chliche Dont Fragment Markierung im IP Header von Fragmenten gesetzt Manche nicht standarkon formen IP Stacks verschicken jedoch unter bestimmten Umst nden solche Fragmente 26 3 3 Vergleich und Bewertung der Paketfilter IP Optionen Jede der Firewalls bietet M glichkeiten an IP Spoofing mehr oder weniger komfortabel zu verhindern 3 3 Vergleich und Bewertung der Paketfilter Die M chtigkeit der Paketfilter in den untersuchten Firewallprodukten ist vergleich bar auch wenn nicht bei allen die Abl ufe im Paketfilter aufgrund der unvoll st ndigen Dokumentation und Monitoringm glichkeiten sichtbar werden oder vom Benutzer einstellbar sind Die Unterschiede liegen vor allem in der Integration der verschiedenen Merkmale in ein f r die Aufgabe m glichst optimiertes Ger t und die dazu passende Software Dazu kommen noch Werkzeuge die dem Benutzer die Konfiguration die berpr fung der Funktionali t sowie die Diagnose erm glichen und vereinfachen Die Funktionsunterschiede ergeben sich aus den internen Design entscheidungen der gew hlten Firewall Architektur den durch die Hardware vorge gebenen Leistungsmerkmalen sowie k nstlichen Beschr nkungen um verschiedene Lizenzen bzw Produkte anbieten zu k nnen Bei weniger integrierten L sungen von denen eine h here Spezialisierung oder Leistung erwartet werden kann m ssen die
151. le der Testdaten und die Art des Interaktion mit dem System unter Test SUT unterschieden Werden die Testdaten live an einem System gewonnen spricht man von einem online Test 64 6 3 Testbarkeit von Protokollen und Protokollfl ssen Wurden die Daten zuvor gesammelt und vom System getrennt in einer Simulati on benutzt so handelt es sich um einen offline Test Beim online Test wird noch zwischen der passiven und der aktiven Variante unterschieden Bei der passiven Va riante wird das Verhalten lediglich beobachtet w hrend bei der aktiven Variante das SUT stimuliert wird um gew nschte Testdaten zu erhalten Die oft genannten Abtastungs und Penetrationstests w rden so in die Kategorie aktive online Tests bzw dynamischer funktionsorientierter Black Box Test eingeordnet werden 6 3 Testbarkeit von Protokollen und Protokollfl ssen Aufgrund der diskreten Natur und der beschr nkten L nge eines Datenpakets sind alle Eigenschaften die darin abgebildet werden endlich und bei der zustandslosen Betrachtung als Testeingaben verwendbar indem alle Wertmuster erstellt und ge testet werden Protokolle basieren aber auf dem Austausch zahlreicher Pakete die zusammen einen Zustand im Kontext des Paketflusses beschreiben F r jede Schicht verwaltet das jeweilige Protokoll seinen eigenen Kontext und die dazugeh renden Zust nde Betrachtet man einen realen Netzwerkknoten der viele Assoziation gleich zeitig vermittelt so hat je
152. len widmen aber dieser Untersuchung aus zeitlichen und finanziellen Gr nden verschlossen bleiben Netzwerkanalyse Penetration und Schwachstellenabtastung Die einfachste Art ein Netzwerk oder eine Firewall zu untersuchen ist es die beob achteten Pakete passiv zu protokollieren engl sniffing und zu analysieren Das be kannteste Werkzeug daf r ist Wireshark Wireshark ehemals ethereal Die Netz werkanalyse kann durch gezielte Injektion engl packet forging von Paketen erg nzt werden Daf r k nnen Scapy Scapy oder hping3 Hping verwendet werden Bei de k nnen Pakete erstellen senden sowie empfangen und verf gen jeweils ber eine Skriptingschnittstelle Scapy unterst tzt dabei mehr Protokolle als hping3 Hping wie auch Scapy und Wireshark sind f r viele verbreitete Plattformen als Open Source verf gbar Eine verbreitete Methode die Sicherheit von Netzwerken zu testen sind die so ge nannten penetration tests also der Versuch durch die Firewall durchzubrechen und Weitere Listen von relevanten Werkzeugen k nnen z B unter http dmoz org Computers Security Internet Products and Tools Security Scanners und http sectools org abgerufen werden 109 10 Bewertung und Vergleich in ein verwundbares System einzudringen Dazu geh rt zun chst die Erkundung des Netzwerks auf potentielle Ziele und Eindringungspunkte Zur ersten Gattung der un terst tzenden Werkzeuge geh ren Scanner und Netzwerkkartographen Da
153. lichen passiven Failover oder Standby Einheiten die erst beim Ausfall der aktiven Einheit den vollwertigen Betrieb aufnehmen k nnen Die Verf gbarkeit von Netzwerkdiensten muss nicht unbedingt durch Angriffe oder den Ausfall von Soft und Hardware gef hrdet werden Auch eine ung nstige Auslas tung des Netzwerkes kann dazu f hren dass Daten nicht schnell genug ausgeliefert werden und Verz gerungen oder Ausf lle entstehen Ebenso kann der Transport der Daten schneller sein als die Verarbeitung durch den Server Hier helfen Techniken zur Kontrolle der Server und Netzwerkauslastung die die Verf gbarkeit von Diensten verbessern k nnen F r diese Aufgaben existieren spezialisierte Ger te Rate Limiter Traffic Shaper Load Balancer sie werden aber auch von Firewalls zur Verf gung gestellt Bandbreitenmanagement Ratenbeschr nkung und Traffic Shaping sind solche Tech niken Mit ihnen kann einem Dienst oder einem System eine untere bzw eine obere Grenze also die mindestens zugesicherte bzw die maximal erlaubte Datenrate f r die Nutzung des Netzwerks zugewiesen werden Diese Funktionen k nnen sowohl als Sicherheits wie auch als Netzwerkfunktionen betrachtet werden Hier werden sie un ter der ersten Kategorie vorgestellt sollen aber unter beiden Kategorien eingeordnet werden Server load balancing sind Strategien nach denen Anfragen nach bestimmten Kri terien an mehrere gleichartige Server verteilt werden um die Auslastung der Die
154. licht benannt werden k nnen Die Anzahl der Phasen bestimmt wie oft Pakete vom Netzwerkstapel bzw Kernel an den Paketfilter bergeben werden Dementsprechend stellen die einzelnen Phasen Vgl hierzu die Einf hrung der Firewalltypen in Abschnitt 2 1 49 5 Allgemeines Modell f r zustandsbehaftete Paketfilter bergabepunkte zwischen den verarbeitenden Instanzen bzw Zugriffspunkte des Pa ketfilters auf die Pakete und die damit verbundenen Datenstrukturen dar INPUT ROUTING OUTPUT a 2 Phasen Modell PRE ROUTE ROUTING FORWARD ROUTING POST ROUTE INPUT OUTPUT processes b 5 Phasen Modell Abbildung 5 1 Zwei Modelle der Paketverarbeitungsphasen In jeder der Phasen werden verschiedene Arbeitsschritte der Paketverarbeitung ausgef hrt Wie aus der Zusammenfassung der Analyse in Abschnitt 3 3 hervor geht sind diese Funktionen und die M chtigkeit der einzelnen Firewallsysteme ver gleichbar Im Groben lassen sich diese Funktionen in die Funktionsgruppen Filterent scheidungen Re Routing Paketmodifikationen Adressumsetzung Markierungen Logging und Accounting sowie Weiterbehandlung durch weitere Prozesse unterteilen vgl auch Tabelle 3 3 Die Arbeitsschritte sind je nach Paketfilter unterschiedlich ausgepr gt und konfigurierbar Sie sind eine Verfeinerung der Kernfunktionen eines Paketfilters wie sie bereits in Abbildung 4 1 definiert wurden Eine
155. ltering postures Gut97 stellt eine einfache Lisp bzw Scheme hnliche Spra che f r das Beschreiben von globalen Netzwerkzugriffsrichtlinien vor Dazu wird ein Algorithmus gezeigt der f r eine gegebene Netzwerktopologie die Regeln f r die einzelnen Router errechnet Dadurch soll gew hrleistet werden dass die Regeln die Richtlinien korrekt umsetzen Zudem wird eine optimale und redundanzfreie Vertei BDD steht f r Binary Decision Diagram 113 10 Bewertung und Vergleich lung der Policy auf die Router und Firewalls in einer verteilten Umgebung erreicht Leider wird auf die Umsetzung auf den konkreten Ger ten nicht eingegangen In An expert system for analyzing firewall rules EZ01 wurde ein Expertensystem basierend auf Constraint Logic Programming CLP entwickelt mit dem sich ein Re gelwerk analysieren l sst Das Expertensystem enth lt eine Datenbank mit Fakten ber verschiedene Netzwerkprotokolle deren Sicherheitsmerkmale und h ufige Fehl konfigurationen Es ist m glich Anfragen bez glich einer eingelesenen Konfiguration zu stellen die die erwartete Reglementierung erlaubte bzw verbotene Verbindungen oder die Richtlinie bzgl eines Paketes enth lt Die in der Arbeit vorgestellten Fakten kennen zwar Protokollmerkmale bis hin zur Schicht 4 aber keine zustandsbehaftete Filterung oder Paketflussver nderungen wie NAT Auch werden nur einfache Regeln mit accept deny und einer geordneten Regelliste unter
156. lters der Teststrategie dem Paketfilter mehr als einem Teil Wenn alle Teile ordnungsgem arbeiten und die Teststrategie alle geforderten Eigenschaften testen konnte wird mit dem Existenzquantor nachgewiesen dass in den Randbereichen aller identifizierten Segmente die postulierte Aktion des Paket filters beobachtet werden konnte Dabei wird wie in Abschnitt 6 4 beschrieben ange nommen dass der Paketfilter sich innerhalb der Segmente stetig verh lt Aus dem Ergebnis l sst sich nicht schlie en dass der Paketfilter die zugrunde liegenden Pro tokollspezifikationen vollst ndig und konform umsetzt Werden am Ende einer Testdurchf hrung Abweichungen zwischen den erwarteten und den beobachteten Ergebnissen festgestellt so muss ein Fehler in den Testvekto ren dem Modell dem Paketfilter oder der Teststrategie vorliegen Eine fehlerhafte Berechnung der Vektoren durch den FWA kann zu Abweichun gen f hren Die Identifizierung und Beseitigung eines solchen Fehlers liegt in der Verantwortung des FWA Entwicklers Das Modell wird bei der Zusammenstellung des Testpfades verwendet um die spezifischen Eigenschaften der zustandsbehafteten Verbindungsverfolgung zu ber ck sichtigen Ein Fehler im Modell oder der Beschreibung des Paketfilters m sste gleich artige Symptome an mehreren kontextabh ngigen Testpunkten aufzeigen Die Teststrategie enth lt zwei potenzielle Fehlerquellen die Testdurchf hrung und die Testauswertung Bei der ers
157. lters und der Konfiguration weitaus strukturierter und gezielter vor als die anderen Ans tze F r die in der Analyse identifizierten Testvektoren kann jedoch bei einer entsprechenden Erweiterung der Teststrategie eine vollst ndige Testabdeckung erreicht werden Dabei wird durch die Teststrategie gleichzeitig versucht m glichst effizient vorzugehen und redundante Tests zu reduzieren Der Einsatz der FWTStra tegy und die Interpretation der Testergebnisse sind f r einen fachkundigen Benutzer ausgelegt der kein Experte sein muss Dadurch wird eine erh hte Benutzerfreund lichkeit des Testwerkzeugs erreicht und ein breiterer Benutzerkreis angesprochen 118 11 Zusammenfassung und Ausblick Die vorliegende Arbeit untersucht die Fragestellung wie sich die Konfiguration eines Paketfilters auf die von ihm akzeptierten bzw abgelehnten Protokollfl sse auswirkt und ob der Paketfilter sich konform zu den Protokollspezifikationen verh lt Der verfolgte Ansatz zur Beantwortung der Frage ist die Entwicklung einer all gemeinen Teststrategie f r zustandsbehaftete Paketfilter Bei der Betrachtung der Untersuchungsobjekte wurde in Kapitel 2 festgestellt dass es verschiedene Teilfunk tionen gibt und die jeweiligen Produkte sich in der Komposition dieser Funktionen unterscheiden F r die Eingrenzung der Untersuchung wurden die verschiedenen Fire walltypen kategorisiert und die weitere Betrachtung auf sechs f r die Marktverteilung repr sentative Paketfil
158. lung einer Teststrategie f r diese Damit soll es m glich werden genau berpr fen zu k nnen was mit einem Paket oder Datenstrom beim Passieren der Firewall geschehen wird Es soll auch helfen den Vorgang besser zu verstehen zu dokumentieren und den Administratoren ein fundiertes Werkzeug in die Hand zu geben um Fehler identifizieren und beseitigen zu k nnen 1 1 Ziel der Arbeit Im Rahmen dieser Diplomarbeit wird eine allgemeine Teststrategie f r zustandsbe haftete Paketfilter zur praktischen berpr fung ihrer spezifikationskonformen Funk tionsweise in Bezug auf ihre Konfiguration erarbeitet und prototypisch implemen tiert Die damit verbundene Fragestellung untersucht den Einfluss der Konfiguration eines Paketfilters auf die von ihm akzeptierten bzw abgelehnten Protokollfl sse Der allgemeine Ansatz soll sicherstellen dass die Teststrategie nicht nur auf aus gew hlte Paketfilter anwendbar sondern auf typische Paketfilter ausgelegt ist Die Auswahl der konkret untersuchten Paketfilter soll eine hohe Abdeckung der typischen Paketfilter aufweisen und dabei repr sentative kommerzielle und freie Paketfilter be r cksichtigen Die Untersuchung besch ftigt sich mit zustandsbehafteten Paketfiltern die auf den Schichten 3 und 4 des OSI Referenzmodells 507498 1 wirken Reine Applika tionsprotokollfilter also Filter auf Schicht 5 7 oder geb ndelte Schutzkomponenten sind nicht Bestandteil der Untersuchung da bereits die Schicht
159. n 44 4 5 Beispiel f r PF Zustandsinformationen 45 4 6 Beispiel f r Cisco PIX Zustandsinformationen 46 4 7 Beispiel f r Checkpoint VPN 1 FW 1 Zustandsinformationen 48 7 1 Algorithmus teststeuerung 22e 80 7 2 Algorithmus generiere Baum 000020 ue 8l 7 3 Algorithmus vereinige Vektoren nennen 82 7 4 Algorithmus schneide ir 25 uox d Sy eed OS Caes DA ale RS eye 82 7 5 Algorithmus suche Testpunkte aus Segment 83 7 6 Algorithmus entferne gesperrte Adressen 222 22 l l 84 7 12 uleorr his testene a sou ue a wun ee a de NDS AS 85 A 1 Hauptzugriffsstruktur einer Vektordatei 129 A 2 Deklaration der Vektordatenstruktur 130 A 3 Vektorbeispiele qas Te ta 02 a ee rh pes due Reh 130 AA association listetta a e a ars re ae a a Gh a 132 A 5 Ausgabe von FWTStrategy a u moo a 136 xi 1 Einleitung Das Internet hat sich von einem Forschungsnetzwerk zu einer weltweiten Kommunika tionsinfrastruktur entwickelt die zahlreiche kleinere Netzwerke miteinander verbin det Verschiedene kommerzielle freie private forschende staatliche oder milit rische Organisationen sind an das Internet angeschlossen um Dienste wie das World Wide Web Datentransfer sowie Kommunikationsm glichkeiten wie E Mail Instant Mes saging und neuerdings auch Telefonie zu nutzen All diese Dienste basieren auf dem TCP IP Pr
160. n Die Teststeuerung selbst kann auf dem Wirtssystem ausgef hrt werden F r die Installation der virtuellen Systeme kann ein aktuelles Linux System nach freier Wahl verwendet werden Eine minimale Installa tion ohne grafische Oberfl che wird empfohlen um Speicherplatz zu sparen Unter den zu installierenden Werkzeugen sollte sich ein SSH Server zur Fernbedienung ein Netzwerksniffer und die FWTest Agenten befinden 192 168 20 xx 192 168 30 xx AgentA 2 J gt AgentB 2 3 vmnet2 vmnet3 FWTest 192 168 10 xx 4 vmnet1 Abbildung A 2 Aufbau der Testumgebung Die Projektseite der Subversion Versionsverwaltung incl der Dokumentation und Links zu ver schiedenen Clients ist unter http subversion tigris org zu finden VMWare Server ist kostenlos von dem Hersteller ber http www vmware com zu beziehen 133 Anhang A Anhang F r die Verbindung der Netzwerke zwischen den Systemen werden drei Netzwerk bereiche verwendet die sich m glichst nicht mit den Netzwerken der zu testenden Konfigurationen berschneiden sollten Die Beispielskripte f r FW Test sind auf den privaten Bereich 10 xx 0 0 16 des Klasse B Netzwerkbereiches voreingestellt Des wegen werden f r die Netzwerke zwischen den Systemen Adressen aus den privaten Bereichen 192 0 yy 0 24 empfohlen Bei der Einrichtung der VMWare Server Umge bung werden drei virtuelle Switches konfiguriert die
161. n so wird ein geeigneter Test erstellt und ausgef hrt Nach jedem versendeten Paket muss die Reaktion des Paketfilters analysiert und im Hinblick auf die erwartete Reaktion bewertet werden Dabei k nnen vier Reakti onsklassen unterschieden werden e Es kommt kein Paket an e Nur der Sender erh lt ein Paket e Nur der Empf nger erh lt ein Paket e Sender und Empf nger erhalten je ein Paket Abh ngig von der erwarteten Reaktion und der Anzahl der erhaltenen Pakete m ssen die Pakete weiter untersucht werden wobei sowohl die erwartete Reaktion wie auch Fehlverhalten ber cksichtigt werden F r die Bewertung des Ergebnisses m ssen die versendeten und die empfangenen Pakete auf eine Korrelation untereinander unter sucht werden Darunter ist zu verstehen ob 75 7 Allgemeine Teststrategie e das empfangene Paket dem versendeten Paket entspricht und sich bei der Ubertragung konfigurations oder transferbedingte Felder ver ndert haben e cin falsches Paket aufgrund von Fehlverhalten oder konfiguration empfangen wurde e das auf Senderseite empfangene Paket eine Fehlermeldung ist und sich gegebe nenfalls auf das versendete Paket bezieht Dementsprechend werden auch mehrere Kategorien zur Bewertung des Endergeb nisses eingef hrt die grob in OK Warnung Fehler und Empfangsfehler unterteilt und mit folgenden Bedeutungen belegt werden k nnen OK Das Ereignis stimmt mit der Erwartung berein Warnung Das Ereignis stimmt
162. n Parametrisierung abgeleitet werden report Funktion zum Abrufen einer Statistik ber die gesendeten Pakete in Abh ngigkeit von der geforderten Phase der Assoziation Wird am Ende al ler Testl ufe von FW TStrategy benutzt um f r den Benutzer einen Bericht zu erstellen 8 2 Umsetzung der Protokolltests Implementierung der UDP Tests Der Prototyp der FWTStrategy ist in der Lage UDP Datenfl sse f r die von Netfilter unterschiedenen Zust nde INVALID NEW und ESTABLISHED zu erzeugen Der RELATED Zustand wurde nicht implementiert da hierf r ein Anwendungs protokoll implementiert werden m sste f r das Netfilter eine Verbindungsverfolgung anbietet In der betrachteten Version w ren das die UDP basierenden Protokolle TFTP SIP und Amanda INVALID In der Dokumentation zu Netfilter sind keine genauen Kriterien zum UDP INVALID Zustand gegeben die jedoch dem Quellcode entnommen wer den konnten Dort werden Pakete mit einer falschen Pr fsumme im UDP Header sowie unvollst ndige bzw zu kurze Pakete als INVALID Paket ein gestuft NEW Ein valides UDP Paket das zu keiner aktiven Assoziation geh rt Das erste Paket in einer Assoziation das Netfilter sieht wird als NEW Paket interpre tiert ESTABLISHED Ein Paket das zu einer der Verbindungsverfolgung bekannten As soziation geh rt Das bedeutet dass vor dem Testen eines ESTABLISHED Paketes eine entsprechende NEW oder ESTABLISHED Assoziation aufgebaut werden muss
163. n Programmierfehler hervorgerufen wird und unter bestimmten Bedingungen zu einer Fehlerwirkung f hrt Bei spiel eine falsche Anweisung in einem Computerprogramm mistake Fehlhandlung oder entscheidung Eine Fehlhandlung entsteht durch eine unsachgem e Bedienung des Systems eine menschliche T tigkeit die ein falsches Resultat produziert Beispiel eine falsche Eingabe durch einen Benut zer Zu jeder Fehlerklasse existieren verschiedene Gegenmafnahmen die die Fehler mi nimieren k nnen Fehlhandlungen k nnen durch Standards Vorschriften und Auf kl rung bzw Einweisung vermieden werden Fehlerzust nde und Abweichungen deu ten auf interne Defekte im System hin und k nnen durch Debugging aufgesp rt wer den Fehlerwirkungen schlie lich sind Fehlverhalten die durch das Testen gefunden werden k nnen Mit der Zeit und durch gegebene Anforderungen haben sich zahlreiche Testtech niken etabliert Sie lassen sich grob nach Testaspekt Testebene und Testzugang unterscheiden Testen als eine Ma nahme der Qualit tssicherung berpr ft verschiedene Aspekte der Qualit t die das Testziel festlegen k nnen Eine grobe Kategorisierung unter scheidet zwischen funktionalen und nicht funktionalen Eigenschaften Die ISO IEC 58 Norm 9126 509126 beschreibt Qualit tsmerkmale f r Software und definiert eine feinere Gliederung der Merkmale die sie den Gruppen e Funktionalit t functionality Korrektheit Angemessenhei
164. n nur grob definiert werden werden k nnen und aktive Antworten der Firewall auch nicht vorgesehen sind 10 2 Verwandte Untersuchungen Zu Beginn der Vorbereitungen f r diese Arbeit wurden zahlreiche verwandte Ar beiten gesucht und analysiert Diese Nachforschungen dienten der besseren Einarbei tung in das Thema und bieten die M glichkeit auf aktuellen Ergebnissen aufzubauen Die Arbeiten werden angelehnt an Abbildung 6 4 auf Seite 64 verschiedenen Ab straktionsebenen beim Testen von Firewalls zugeordnet und in diesen Kategorien vorgestellt Firewallsoftware Produkttests PBit ist eine Testmethodologie die auf Vorlagen basierend parametrisierte Testf lle f r Regressionstests des Paketfilters netfilter iptables erstellen kann Einige Vorlagen Algorithmen die diese kombinieren k nnen sowie eine grafische Oberfl che wurden mitentwickelt vgl DH04 Testing iptables HPS03 dagegen untersucht den Zusammenhang zwischen der Anzahl der Regeln und der Paketdurchsatzrate was einem reinen Leistungstest ent spricht Getestet wurden verschiedene Szenarien und die Leistung bei 10 100 und 1000 MBit s Die wenigsten Testf lle ber cksichtigten auch zustandsbehaftete Filte rung Zur Durchf hrung der Untersuchung wurde ein Framework mit erweiterbaren Testf llen entwickelt das auf dem Testsystem ein Regelwerk einstellt Pakete schickt 111 10 Bewertung und Vergleich und sie bei Eintreffen auf Unterschiede vergleicht F
165. nd aus allen Hard und Software Komponenten Kern eines Firewallsystems ist ein Paketfilter der f r die Reglementierung des Netzwerk verkehrs zust ndig ist Der Paketfilter wird f r die Filterung von unerw nschtem Datenverkehr zwischen Bereichen mit unterschiedlichen Sicherheitsanforderungen ge nutzt Neben ihm k nnen noch weitere Software Komponenten installiert sein die zus tzliche Dienste und Funktionen anbieten Eine Firewall kann ihre Schutzfunktion auf einem Endsystem oder einem vermit telndem System verrichten Dabei sind die Varianten die auf einem Endsystem zum Einsatz kommen zus tzlich zu unterteilen Die softwarebasierenden Personal Fire walls haben keine vermittelnden Funktionen und reglementieren vielmehr den ein gehenden sowie den von den lokalen Anwendungen ausgehenden Verkehr Zus tzlich werden sie auch zum Schutz vor Viren W rmern und Trojanern eingesetzt Auf Endsystemen kann aber auch die Firewallsoftware der vermittelnden Systeme laufen die die Funktionen der vermittelnden Firewalls bietet Im Folgenden werden nur noch vermittelnde Firewalls betrachtet Geschichtlich betrachtet basierten die ersten Firewalls auf intelligenten Routern die ausgew hlte Pakete weiterleiteten Die Router wurden immer weiter um ausge kl geltere Filtermechanismen erweitert Sp ter wurden spezialisierte Firewallsysteme entwickelt die notwendigerweise auch Routingaufgaben bernahmen Deswegen exis tiert keine eindeutige Grenze zwis
166. nde des Tests k nnen die Statistiken der Firewall mit den Z hlern der Strategie verglichen werden Damit kann der ordnungsgem e Ablauf des Tests gest tzt werden Jedes Modul hat eine nach au en hin definierte Schnittstelle und verwendet intern auch vergleichbare Hilfsfunktionen bzw Strukturierung isTestable testcase Diese Funktion wird von FWTStrategy mit einem testcase als Parameter aufgerufen um festzustellen ob sich aus den dort beschriebenen Eigenschaften ein testbares Paket ableiten l sst Hier werden erste berpr f ungen der Konformit t zur Spezifikation durchgef hrt checkTestpath testpath Diese Funktion wird von FWTStrategy mit dem Pa rameter testpath also der Zusammenfassung mehrerer Testf lle aufgerufen um festzustellen ob dieser Testpfad einen testbaren Protokollfluss darstellt Die berg nge zwischen den Paketen im Protokollfluss werden berpr ft 95 8 Proof of concept testPath testpath context Dies ist die eigentliche Funktion zur Herstellung des in testpath beschriebenen Protokollflusses unter Ber cksichtigung des Kon textes aus context testPath liefert eine Liste der Ergebnisinterpretation f r alle durchgef hrten Tests zur ck Daf r benutzt es die von interpret O zur Verf gung gestellte Schnittstelle sendPacket testcase Private Funktion zur Herstellung und zum Transfer der Pakete die aus dem testcase sowie gegebenenfalls einer weiteren protokoll spezifische
167. neue Strategie eingef hrt werden um trotzdem z gig weiter testen zu k nnen Die gew hlte Abarbeitung in der Reihenfolge in der die Vektoren in der Datei vorliegen k nnte die gegenseitige Beeinflussung der Testf lle weiter beg nstigen Eventuell l sst sich eine Reihenfolge finden die die Laufzeit und die Beeinflussung reduziert Der bisherige Testablauf setzt die Anforderung der effizienten Ressourcennutzung also ungen gend um und sollte optimiert werden 7 2 Entwicklung einer optimierten Teststrategie In diesem Abschnitt werden die Kritikpunkte aus dem vorherigen Abschnitt auf gegriffen und in einer neuen optimierten Teststrategie f r einen vollst ndigen Test umgesetzt In der Analyse wurden vier Ans tze zur Optimierung der Teststrategie aufgezeigt die Reduzierung der Mehrfachtests und des Leerlaufs Umgang mit verbrannten Testpunkten in der Zustandsverfolgung Umstellung der Testreihenfolge und die Par allelisierung der Tests Entwicklung der Testreihenfolge In der neuen Teststrategie werden die Testf lle im Kontext zueinander betrachtet und daf r verwendet die Vorgeschichte f r Testpunkte in h heren Zust nden herzustellen Das kann bei der Anordnung der Testf lle ausgenutzt werden indem die Tests vom h chsten zum niedrigsten Zustand abgearbeitet werden Durch diese Anordnung wird erreicht dass beim Aufbau der Vorgeschichte f r die ersten Tests zum Teil bereits Tests aus den anderen Teilmengen ben tigt we
168. ng Tabelle 7 1 FWTStrategy im Kontext von I809646 vektoren eine ausf hrbare Testsuite erecutable testsuite ergibt Aus der Sicht der Testmethodologie setzt FW TStrategy die transverse test method f r ein multi party system under test um Die Teststeuerung entspricht der test control procedure die zwei lower tester ansteuert vgl Abbildung 6 3 Jedes Unterscheidungsmerkmal aus der Sprache des Firewallregelwerks spannt eine Achse in einem mehrdimensionalen Raum auf der den Wirkungsraum der Firewall beschreibt Dieser wird weiter als Testraum bezeichnet Die Unterscheidungsmerk male entsprechen den durch eine Firewall untersuchten Filterkriterien bzw der postu lierten Firewallaktion Der Definitionsbereich jeder Achse wird durch die m glichen diskreten Werte des jeweiligen Unterscheidungsmerkmals definiert Der Testraum oder Ausschnitte davon k nnen durch einen Vektor beschrieben werden dessen Koordinaten durch die Unterscheidungsmerkmale vorgegeben sind Die hier betrach teten Vektoren beschreiben disjunkte Teilr ume des gesamten Testraums indem sie die Koordinaten als Tupel der Grenzen eines stetigen Abschnitts innerhalb der jewei ligen Achse angegeben Die aufsummierten Vektoren ergeben wieder den gesamten Testraum Ein Vektor mit einem eindeutigen Wert f r jede Koordinate definiert einen Testpunkt im Testraum Aus einem Testvektor kann eine Vielzahl von Testpunkten abgeleitet werden Ge testet wird jedoch nur eine Auswahl der T
169. ngen an An der Universit t DePaul Chicago USA ist im Rahmen mehrerer Arbeiten rund um die Erkennung und Behandlung von Anomalien in Firewall Policies der Fire wall Policy Advisor FPA FPA ASHO03 entstanden Der FPA kann in einer vereinfachten Notation des Regelwerks die das Protokoll IP Adressen TCP bzw UDP Ports und die Akion ber cksichtigt Anomalien auffinden und Korrekturvor schl ge machen Leider m ssen aber die echten Konfigurationen zuerst manuell in die vereinfachte Notation gebracht und anschlie end beide gepflegt werden Ebenfalls im Rahmen einer Forschungsarbeit ist an der University of Victoria Ca nada unter dem Namen Blowtorch ein C Framework f r die Automatisierung von Firewalltests entstanden Das Grundkonzept der Teststeuerung beruht auf ei nem Paketiterator der ereignis und zeitgesteuert Paketstr me erzeugen kann Die Bibliothek enth lt zahlreiche Funktionen zur Erstellung Analyse Manipulation Ent sendung und zum Empfang von Paketen sowie zum De Multiplexing von Daten str men Blowtorch ist nicht ffentlich verf gbar wurde laut HY05 aber erfolgreich f r die Durchf hrung von Tests an verschiedenen Firewalls benutzt Der Firewall Tester bzw FTester von Andrea Barisani F Tester ist ein Werk Ein Artikel zur Einf hrung in die Benutzung des F Testers kann unter http www tisc insight com newsletters 56 html abgerufen werden 110 10 2 Verwandte Untersuchungen zeug zum Testen
170. nisse aus der Entwicklung der Teststrategie und der Untersuchung des netfilter Paketfilters zusammen 9 1 Anwendungsf lle f r FWTStrategy Konzept und Design der entwickelten Teststrategie unterst tzen das Testen der Funk tionalit t und der Konformit t von vermittelnden Knoten mit dem Schwerpunkt Pa ketfilter Besonders interessant ist es damit verschiedene Konfigurationen von glei chen oder unterschiedlichen Produkten zu vergleichen aber auch ein Abgleich des Verhaltens mit der Spezifikation ist m glich Funktionale Tests Im einfachsten Anwendungsfall werden der Paketfilter und die Teststrategie mit der gleichen Konfiguration eingestellt Damit ist es m glich f r jeden vom FWA geliefer ten und testbaren Vektor eine Aussage ber den Vergleich der erwarteten und des beobachteten Ereignisses zu treffen Die Einschr nkung der Aussage auf testbare Vektoren schlie t folgende F lle aus 1 Der Vektor beschreibt Eigenschaften aus denen sich kein spezifikationskonfor mes Paket ableiten l sst Ein solches Paket kann nicht verschickt werden 2 Ein spezifikationskonformes Paket kann abgeleitet werden aber aus den vor handenen Vektoren l sst sich der notwendige Kontext nicht herstellen 3 Ein spezifikationskonformer Paketfluss kann abgeleitet werden aber die Im plementierung der Teststrategie ist nicht vollst ndig so dass die geforderten Eigenschaften nicht umgesetzt werden k nnen Eine Erweiterung der Teststra tegie ist
171. notwendig Die ersten beiden F lle entstehen durch die vollst ndige Berechnung des Testraums im FWA wodurch nicht nur Positiv Vektoren sondern auch die Negative entste hen Unter Positiv Vektoren werden diejenigen verstanden die sich aus expliziten 101 9 Ergebnisse Angaben der Konfiguration ergeben Die Negativ Vektoren entstehen durch die Ver vollst ndigung der expliziten Angaben auf den gesamten Testraum Die nicht spezifi kationskonformen und damit nicht testbaren Vektoren werden von der Teststrategie identifiziert und mit einer entsprechenden Begr ndung gemeldet Sie k nnen der Tes tabdeckung zugerechnet werden da sie im Betrieb nicht auftreten k nnen oder von anderen Routern bzw dem Protokollstapel verworfen werden Der dritte Fall kann durch die Eingabe einer Konfiguration entstehen die durch die Teststrategie nicht unterst tzte Filterekriterien bzw entscheidungen enth lt Dann kann zu den betroffenen Vektoren keine Aussage getroffen werden wodurch L cken in der Testabdeckung entstehen k nnen Die von der prototypischen Implementierung unterst tzten Eigenschaften und Funktionen sind in Tabelle 8 1 aufgef hrt Nach einem Testlauf von FWTStrategy stellt sich die Frage nach der Aussagekraft der gelieferten Ergebnisse Hierbei k nnen folgende F lle unterschieden werden e Teststrategie und Paketfilter arbeiten ordnungsgem e Fehlerfall in den Testvektoren dem Modell bzw der Beschreibung des Paketfi
172. nste zu optimieren und die Verf gbarkeit zu gew hrleisten Mit Quality of Service QoS k nnen Datenpakete einer Dienstklasse und Weiterlei tungsrichtlinie zugeordnet werden die anderen vermittelnden Gegenstellen mitteilt wie vorrangig sie behandelt werden sollen In IP Paketen ist daf r das Differen Mehrere Load Balancing L sungen sind unter http kb linuxvirtualserver org wiki Load balancing und http www inlab de balance html gelistet I9 3 Merkmale der Firewallsysteme System Komponente n traffic load QoS shaping balancing netfilter iproute2 u a 4 4 a IPFW dummynet 4 IPF altq rdr nat v 4 4 PF altq rdr nat V V v PIX integriert u ab ver 7 0 FW 1 floodgate v 7 v Tabelle 3 1 Unterst tzte traffic Regulierungen tiated Services Code Point DSCP bzw Type of Service TOS Feld vorgesehen Unterst tzende Firewalls k nnen darauf basierend filtern die Markierung ver ndern oder priorisiert weiterleiten Tabelle 3 1 gibt eine bersicht ber die Unterst tzung der einzelnen Mechanismen durch die Firewalls und benennt die zust ndigen Komponenten dazu AAA Authentication Authorization Accounting Bei der Authentifizierung von Benutzern gegen ber der Firewall haben sich in erster Linie die Protokolle RADIUS TACACS und zunehmend auch Kerberos etabliert Zus tzlich bieten manche Anbieter eine Authentifizierung ber eine gesicherte Webo berfl che oder verlangen eine
173. nte Assoziation treffen als auch zus tzliche berpr fungen umsetzen In Abbildung 5 6 werden die Paketfl sse f r ankommende und f r weitergeleitete Pakete dargestellt Der Paketfluss f r ausgehende Pakete wird nicht separat darge stellt da er im Vergleich zu den beiden gew hlten Paketfl ssen keine zus tzlichen Abl ufe oder Strukturen einf hren w rde Die m glichen Aktionen des Paketfilters werden in Tabelle A 1 den einzelnen Phasen sowie der jeweiligen Auswirkung auf den Paketfluss zugeordnet 59 5 Allgemeines Modell f r zustandsbehaftete Paketfilter l l l l NOTRACK rx od lee Lec un 3 PREROUTING r rw T pC NAT TABLE X STATE TABLE X has NAT stat Za x KRRRERX HR INPUT state a IPTables INPUT Paketfluss f r eingehende Pakete nr A PREROUTING FORWARD POSTROUTING e generate l l l l NOTRACK x 4d DN state mangle has NAT stat r rw STATE TABLE X qe un 9000 i D erem 8 NonTerm Action BHO Abbildung 5 6 Modellierung der Paketfl sse bei IP Tables 56 b IPTables FORWARD Paketfluss f r
174. nten Bei einer Umadressierung wur den die Pakete wieder an das Routing weitergereicht Im Gegensatz zu weitergeleite ten Paketen wurden ausgehende Pakete zus tzlich in der output Phase behandelt IPF IPFilter IPFilter l t sich unter zahlreichen Betriebssystemen einbinden weswegen eine ein deutige Positionierung der Paketverarbeitung im Kernel schwierig ist Interessant zu bemerken ist dass die IPFilter Funktionen unter Linux netfilter ber die Zugriffs 33 4 Funktionsweise der Paketfilter punkte PREROUTING und POSTROUTING auf die Pakete zugreifen Die folgende Darstellung basiert vorwiegend auf der Projektdokumentation sowie der Quellcode analyse kernel TCP IP processing mud oe ipf routing I l check auth logging add state pass OUTBOUND INBOUND filter o iS filter Dg i Sce add state accounting accounting i I nat check auth I I logging nat mio Y fr check rm to devices Abbildung 4 5 Paketfl sse durch IPFilter Der Paketfluss bei IPFilter dargestellt in Abbildung 4 5 betrachtet alle Pakete als ein oder ausgehend was sich auch jeweils in einer Regelliste f r input und output wiederspiegelt Weitergeleitete Pakete durchlaufen beide Bearbeitungsphasen Daf r gibt es aber die M glichkeit das Routing
175. nur der vermittelnde Aspket untersucht werden kann Dadurch entzieht sich der zur eingehende und von der Firewall ausgehende Ver kehr der Untersuchung Der Betrieb der Agenten auf einer Firewall oder Firewall Appliance bedarf einer Modifizierung der Agenten und sollte weiter verfolgt werden Schlie lich wird die Erweiterung der F higkeiten des FWAs die Ausweitung der Tests auf andere Paketfilter erm glichen Daf r muss eine Beschreibung und Mo dellierung der anderen Paketfilter vorliegen die in einem Projekt bearbeitet werden k nnte 121 Anhang A Anhang 123 Anhang A Anhang A 1 Modellierung von netfilter iptables phase chain task type next processing point PREROUTING raw ACCEPT forward PREROUTING add_state PREROUTING raw DROP stop PREROUTING raw LOG non term continue PREROUTING raw NOTRACK forward PREROUTING mangle PREROUTING raw ULOG non term continue PREROUTING add state add state forward PREROUTING mangle PREROUTING mangle ACCEPT forward PREROUTING nat PREROUTING mangle CONNMARK non term continue PREROUTING mangle CONNSECMARK non term continue PREROUTING mangle DROP stop PREROUTING mangle DSCP non term continue PREROUTING mangle ECN non term continue PREROUTING mangle LOG non term continue PREROUTING mangle MARK non term continue PREROUTING mangle SECMARK non term continue PREROUTING mangle TOS non term continue PREROUTING mangle TTL non term continue PREROUTING mangle ULOG non term continue
176. ny if mar lt maz then max MAL else max maux else min Ming if mar lt maz then Mare MATa else mar Maxy return min max Listing 7 4 Algorithmus schneide Bildet Schnittmenge von zwei Mengen 82 7 2 Entwicklung einer optimierten Teststrategie behandelt werden da er sich auf einen Kontext der bereits beschriebenen Tupel be zieht Deswegen werden das erste Paket das einen Kontext aufbaut und die umge kehrte Richtung f r die Antworten f r eine protokoll und zustandsabh ngige Dauer gespeichert algorithm suche Testpunkte input Testvektor output Tickets f r reservierte Testpunkte dim anzahl der eindeutigen Protokollmerkmale im Vektor for d in permutiere min max d inverses von d if d bereits benutzt or d bereits benutzt then next if testpunkt d gesperrt or testpunkt d gesperrt then stell d d in Warteschlange else registriere Ticket f r d und d if not Tickets then warte auf Entsperrung von min Warteschlange registriere Ticket f r d und d return Tickets Listing 7 5 Algorithmus suche Testpunkte Erstellt und reserviert Tickets f r einen Testpunkt aus einem Vektor F r die Verwaltung dieser Tupel wird ein einfaches Ticketsystem verwendet Dort k nnen Tickets f r die Tupel angefordert und beim Versenden von einem Paket verl ngert werden Unabh ngig davon wie viele Pakete versendet werden werden in einem Ticket
177. oduktivumgebungen wobei letztere durch ein reales Netzwerk mit weiteren Systemen zus tzlich zu der Testumgebung gekennzeichnet sind Um den Betrieb der sonstigen Systeme nicht zu beeinflussen aber auch den Testablauf selbst gegen St reinfl sse zu sichern werden die Testagenten f r jeden Testfall mit speziellen Eingangsfiltern konfiguriert die den Empfang von Fremdpaketen ausschlie Den sollen Gleichzeitig kann die Teststeuerung bei der Wahl der Testpunkte Adressen von Produktivsystemen oder spezielle Netzadressen auslassen Die Teststrategie muss sich beim Versand der Pakete nicht um die Zuordnung der Adressen zu den Schnitt stellen der Firewall k mmern da der FWA relative Routing Angaben liefert die die Richtung des zu transferierenden Pakets aus der Sicht des Testers und der Agen ten beschreiben Das Testskript kann also direkt auf eine A Seite und eine B Seite der fwtest Agenten referenzieren Weiterhin kann der zu untersuchende Adressbe reich ber einen Schalter beeinflusst werden indem der FWA bei der Transformation des Regelwerks angewiesen wird statt den gesamten m glichen Bereich 0 0 0 0 bis 255 255 255 255 nur die tats chlich verwendeten und adressierbaren Adressbereiche auszugeben Die Unabh ngigkeit von konkreten Produkten und von den betrachteten Protokol len kann dank der vorgestellten Modellierung und einem modularisierten Aufbau der Teststrategie bei dem die ger te und protokollspezifischen Eigenschaften gekapselt
178. olgende Anforderungen an die Teststrategie e Unabh ngigkeit von konkreten Produkten e Unabh ngigkeit von den betrachteten Protokollen e Einstellbarkeit der Tests f r eine konkrete Firewall e Bewertung der Relevanz und der Detailtiefe der Testf lle e Optimierung der Nutzung der Testressourcen e Durchf hrbarkeit der Tests unter Labor und Realbedingungen e Wiederholbarkeit der Tests Die Teststrategie wird ohne Einschr nkungen auf einen konkreten Paketfilter ent wickelt Sie soll auf beliebige Protokolle anwendbar sein auch wenn die betrachteten Systeme vor allem die Protokolle der IP Protokollsuite unterst tzen Zus tzlich wird durch die Betrachtung von mehreren repr sentativen Produkten und die Bewertung bzw Abgrenzung der Relevanz einzelner Funktionen eine hohe Abdeckung von im Einsatz befindlichen Systemen angenommen Die Detailtiefe und die M chtigkeit der Testf lle werden im Kontrast zu der Res sourcennutzung sowie ihrer Aussagekraft betrachtet und bewertet Dabei muss f r die Verifizierung der spezifikationskonformen Funktion eine realistische Balance zwischen 69 7 Allgemeine Teststrategie einem reduzierten und einem vollst ndigen Test gefunden werden Gew hlte Abwei chungen oder Einschr nkungen werden kenntlich gemacht um eine Einsch tzung der Ergebnisqualit t zu erm glichen Optimierungen sollen identifiziert und die Auswirkungen auf die Testergebnisse aufgezeigt werden Ziel ist es den Test auf einf
179. ort 80 und e 10 0 0 255 Port 32000 10 1 0 255 Port 80 gew hlt die jeweils f r beide Protokolle gelten sollen Dabei wird angenommen dass die gew hlten Adressen aus Routingsicht keine besondere Bedeutung haben und zur Adressierung von Endsystemen verwendet werden k nnen Ein Test f r den Zustand new also eine initiierende Assoziation ist ohne weite res m glich indem f r die zwei Testpunkte jeweils ein Paket versendet wird das die gew hlten Eigenschaften erf llt Komplizierter ist der Test f r den established Zustand der eine aufgebaute bidirektionale Assoziation erfordert Hierf r muss der Proband vorbereitet und ein entsprechender Kontext hergestellt werden Der Kontext wird durch den Versand von Paketen hergestellt die entsprechend der Protokollspezifikation f r die Verbindungsverfolgung des Probanden erstellt wer den Die Untersuchung der Verbindungsverfolgung in Abschnitt 4 2 hat f r den beispielhaft betrachteten netfilter Paketfilter ergeben dass bei TCP die TCP Flags ber cksichtigt und bei UDP lediglich ein erstes und die folgenden Pakete unter schieden werden Dieser Kontext wird hier vorbereitet Besonders zu ber cksichtigen sind F lle in denen keine geeignete Vorgeschichte existiert oder die gew hlte Vor geschichte nicht hergestellt werden kann Dann kann der Testpunkt nicht berpr ft werden was dem Benutzer mitgeteilt werden muss Konnte die Vorgeschichte erfolg reich hergestellt werde
180. otokollstapel der in den 70er Jahren im Rahmen eines Projektes bei der Defense Advanced Research Projects Agency DARPA in Zusammenarbeit mit dem Massachusetts Institute of Technology MIT entwickelt wurde um die aufkommen den Probleme und den Protokollwildwuchs im experimentellen ARPAnet Netzwerk zu beheben Das verfolgte Ziel der Neuentwicklung war es eine einfache effiziente und offene Infrastruktur f r eine freundliche und kooperative Umgebung zu schaf fen Viele der sp teren Einsatzszenarien waren damals noch nicht bekannt oder gar vorstellbar weswegen die Entw rfe noch kaum berlegungen zu Sicherheitsanfor derungen wie Authentifizierung Autorisierung Zuordenbarkeit Integrit t oder Ver traulichkeit die in der heutigen feindlichen Umgebung notwendig sind beinhalteten F r End zu End Kommunikation wurden viele dieser Merkmale durch verschiedene Erweiterungen oder h here Protokolle nachger stet Um jedoch die Infrastruktur und ihre jeweiligen Teilnetze zu sch tzen oder den Zugang zu ihnen zu beschr nken war es notwendig Schutzmafnahmen einzurichten und den Zugriff zu regeln Die regelnden Komponenten die eine Art Brand Schutzmauer zwischen Netz werken mit unterschiedlichen Sicherheitsanforderungen und Vertrauensstellungen dar stellen werden Firewalls genannt und vereinen eine Reihe von verschiedenen Tech niken und Mechanismen die die Regeln durchsetzen Die ersten kommerziellen Firewalls erschienen 1989 und waren
181. p aufgebaut mit dem durch die geeignete Verkn pfung der identifizierten Bausteine der Paketfluss und die Abh ngigkeiten der Funktionen f r einen allgemeinen Paket filter beschrieben werden k nnen Die Bausteine k nnen den Gruppen Funktionen Arbeitsobjekte Zustandsdaten und Zustandsfunktionen zugeordnet werden vgl Ab schnitt 5 1 F r die Modellierung der Funktionen wurden zwei weitere Kategorisie rungen eingef hrt die den Zweck bzw die Entscheidungsart der Funktionen erfassen Durch die Analyseergebnisse der Firewalls und Paketfilter stehen nun mehrere Klassifizierungen zur Verf gung mit denen sich Firewalltypen und Firewallfunktio nen beschreiben und vergleichen lassen Die neue Modellierung wurde beispielhaft auf die Funktionen und Paketfl sse des netfilter iptables Paketfilters angewendet vgl Abschnitt 5 2 und Abschnitt 5 3 Kapitel 6 legt die methodischen und theoretischen Grundlagen f r die Entwick lung einer Teststrategie f r die berpr fung der gesetzten Ziele Als Basis wurden zwei anerkannte Standards zum Testen der Konformit t von Protokollen und Netz werksystemen ISO9646 bzw X290 eingef hrt Weiterhin wurde die Testbarkeit von Protokollen und Protokollfl ssen untersucht Dabei wurde festgestellt dass die Kom plexit t die die heutigen Firewallsysteme bieten mit den zur Verf gung stehenden Ressourcen nicht mehr vollst ndig getestet werden kann Daf r wurden Strategien zur Reduzierung der Komplexit t un
182. port dport interface und im Falle von TCP die Flags als Repr sentanten f r den Zustand ber cksichtigt Andere Kriterien werden ignoriert oder zur Verringerung der Komplexit t vor dem Benutzer versteckt Dabei k nnen auch alle anderen Pa ketmerkmale wie z B die IP TTL die IP und TCP Optionen die Paketl nge die Fragmentierung die QoS Flags der Payload oder die Datenrate entscheidend f r eine feingranulare Reglementierung sein Als besondere Filterkriterien unterst tzen manche Paketfilter die Tageszeit FW 1 eine Betriebssystemerkennung PF sowie eine Trefferquote im Sinne von jedes n te Paket oder im Schnitt n iptables PF Nur netfilter iptables kann sich direkt auf den Zustand der Assoziation der nicht nur f r TCP angelegt wird beziehen und diesen in den Regeln verwenden Es kann noch mit vielen weiteren in offiziellen match Kriterien erg nzt werden Alle Firewallsysteme bieten die M glichkeit an IP Adressf lschungen IP Spoof ing zu verhindern Daf r wird bei den eingehenden Paketen die Quelladresse und die eingehende Netzwerkschnittstelle mit der Routingtabelle verglichen um zu ermitteln ob eventuelle Antwortpakete den gleichen Weg nehmen w rden source route verify 25 3 Merkmale der Firewallsysteme Gleichzeitig wird sicher gestellt dass die Quelladressen von ausgehenden Paketen entweder der Firewall oder einem System aus den angeschlossenen Netzwerken zuge ordnet werden k nnen Diese berp
183. pr ft werden Sollte diese berpr fung innerhalb des Zeitfensters stattfinden in dem die Verbindungsverfolgung noch einen Eintrag von dem fr heren Test enth lt w rde das Testergebnis verf lscht werden Bevor der Kontext f r einen neuen Testpunkt hergestellt werden kann muss also daf r gesorgt werden dass sich die einzelnen Testf lle nicht gegenseitig beeinflussen Hierzu k nnten der Probandenbeschreibung die Timeouts f r die Zustandsverfolgung entnommen und die folgenden Tests damit verz gert werden Analyse des Testablaufs Bei der direkten bertragung des einfachen Tests auf den vollst ndigen Testraum zeigen sich Schw chen des Testablaufs in Bezug auf die Testlaufzeit die auf mehrere 78 7 2 Entwicklung einer optimierten Teststrategie Ursachen zur ckgef hrt werden k nnen Die unabh ngige Herstellung des Kontextes f r jeden einzelnen Testpunkt f hrt dazu dass Testpunkte mehrfach getestet werden obwohl gerade die Reduzierung der notwendigen Testpunkte ein Ziel der Teststrategie ist Weiterhin verursacht das Abwarten der Timeouts wiederholend Leerlauf Das Abwarten w re auch nur bei kurzen Timeouts unkritisch Der PF Paketfilter z B speichert laut Tabelle 4 2 die Zustandseintr ge f r eine aufgebaute TCP Verbindung f r 86400 Sekunden bevor sie bei Leerlauf der Verbindung wieder gel scht werden Netfilter speichert laut Ab bildung 4 10 b die Eintr ge sogar f r bis zu 432000 Sekunden Hier muss eine
184. r fungen m ssen entweder manuell konfiguriert werden sind in einer Option zusammengefasst oder k nnen als eine Regel angegeben werden Um Missbrauch zu verhindern k nnen auf TCP zahlreiche berpr fungen an gewendet werden Durch strikte berpr fung der im Paket gesetzten TCP Flags und der aktuellen Phase der Verbindung k nnen viele Portscanarten z B Window Stealth oder Null Xmas Fin und ACK Scans geblockt werden Kombiniert mit ei ner Begrenzung maximaler Verbindungsversuche pro Quelladresse k nnen z B TCP half open und full connect Scans verlangsamt werden Die Art und Weise der zu standsbehafteten Untersuchung der Datenstr me durch die Firewall ist ein Gegen stand der vorliegenden Untersuchung Die berpr fungen lassen sich nur bei iptables vom Benutzer einstellen da die anderen Systeme das automatisch bernehmen Bei manchen Paketfiltern lassen sich neben der Adressumsetzung auch weitere Ver nderungen an den Paket Headern der Internet und Transport Schicht durchf hren bzw einstellen Um Systeme mit vorhersagbaren Identifikations oder Sequenznum mern zu sch tzen k nnen die TCP Sequenznummer die Identifikationsnummern in IP ICMP und DNS Paketen sowie der IP und TCP Zeitstempel mit einem zuf lligen Offset modizifiert werden Dadurch kann die Erkundung der Merkmale der gesch tzten Systeme erschwert werden Viele Angriffe nutzen Fehlinterpretation von IP Fragmenten aus weswegen der Paketfilter diese verwerf
185. r 1o3 g3ou 09 Ader u s mooy doy xoe1juuoo dr 1o3 g3ou 0 xXoe73sep 3nooum do3 e1juuoo dr 1o3 g3ou OZI jre ug 3noouin doy x e1juuoo dr 1o3 g3ou 000787 4 peusmqejse 3noourm doy 3perjuuoo dr 1o3 g3ou 09 EM oso jnoourty doy perjuuoo dr 1o3 g3ou OL aso a 3noourm doy xo er1uuoo dr 1o3 g3ou og jnooum dwor oe1juuoo dr 1o3 g3ou 009 jnoourr onus xoerjuuoo dr Joy you 00g sueijorxeur poom doy xoerquuoo dr 1o03 g3ou e suero r xeur doy xperquuoo dr Joy you Spid U qoeu Sup e1j MopurAa 4124S e osoo do3xpe1juuoo dr 1o3 g3ou SUDIO I1 SMODpUIA 0 e1oqip oq doy yorryuuoo dr 1o3 g3ou I umsxoouo xoerquuoo dr 1o3 g3ou SunqrerqQpsog WoMprepurys Joyeyps 128 A 2 Schnittstelle zum FWA A 2 Schnittstelle zum FWA Ausgehend von den Eingaben vom FWA ist das Format der die Daten beinhaltenden Dateien festzuhalten Aktuell ist daf r die Dateierweiterung vec vereinbart worden Diese Datei besteht aus f nf logischen Elementen einer gemeinsamen Deklaration der Struktur der Vektoren in Form von Python Klassen f r jede abgebildete Tabelle der Firewall eine Liste von Vektoren vl eine Liste von m glichen Relationen zwischen den Vektoren al sowie eine Beschreibung des jeweiligen Netzwerks in Form von einer Liste mit den zul ssigen Adressbereichen auf der A und B Seite der Firewall tn Die vorhandenen Tabellen und Beschreibungen sind in der Struktur Entries zusammengefasst class Entries fwa Entries entries p
186. r mit den in GL05b vor gestellten Algorithmen k nnen Anomalien und Redundanzen in einer vereinfachten Notation der Sicherheitsrichtlinien bzw des Regelwerks gefunden werden und gege benenfalls Korrekturvorschl ge gemacht werden FPA kann zus tzlich Modifikatio nen auf der internen BDD basierenden Darstellung interaktiv durchf hren Filtering postures Gut97 und FACE VP05 konzentrieren sich dagegen auf die richtlinien konforme Verteilung der Konfiguration auf die Knoten einer verteilten Firewall und die Analyse der m glichen Zugriffspfade Firmato wurde als einziges vorgestelltes Werkzeug f r die Verwaltung und die berf hrung einer Richtlinie in eine konkrete Konfiguration entwickelt Bar99 Am hnlichsten zu der vorliegenden Arbeit ist die Untersuchung von Specification based Firewall Testing BS06 die sich mit der Abbildung einer Sicherheitsrichtlinie in Testf lle unter Ber cksichtigung der Zielfirewall und des Netzwerks besch ftigt Die daf r notwendige berf hrung der Richtlinien in ein Regelwerk wird erw hnt aber nicht gel st Durch die Ableitung der Testserien aus der allgemeinen Richtli nie werden keine Eigenheiten der jeweiligen IUT ber cksichtigt und sind auf einen sehr einfachen Paketfilter beschr nkt Paketver nderungen oder NAT k nnen nicht berpr ft werden Stattdessen muss den Testgeneratoren eine Beschreibung der spe zifischen TCP Zustandsmaschine zugef hrt werden mit welcher dann f r jeden Te
187. rden und im Nachhinein nicht mehr zus tzlich getestet werden m ssen es sei denn sie werden wieder zur Herstellung einer Vorgeschichte ben tigt Die Definition der Zust nde und deren Reihenfolge wird der Firewallbeschreibung entnommen Danach wird die Teststeuerung wie in Listing 7 1 dargestellt mit dem zu testenden Protokoll und Zustand aufgerufen Ermittlung der Abh ngigkeiten zwischen den Vektoren F r die Bestimmung der Verzahnung und der Abh ngigkeiten zwischen den Vekto ren wird der FWA verwendet Dieser liefert in der sogenannten association list eine 79 7 Allgemeine Teststrategie algorithm teststeuerung input protokoll zustand vektorliste Liste der Assoziationen aList output teststatistik testListe finde Vektoren mit protokoll zustand in vektorliste for vektor in testListe baum generiere Baum vektor protokoll Zustand aList if baum is leer then melde Keine Vorgeschichte zum Vektor next vektor tpfad neue Liste for pfad in baum for testschritt in pfad testfall erstelle Testfall aus testschritt h nge testfall an tpfad an if not tpfad ist Testbar then melde Pfad ist nicht testbar next pfad vorlage vereinige Vektoren im tpfad if not vorlage then melde Pfad ist nach Vereinigung der Vektoren nicht testbar next pfad pfad abbrechen testpunkte suche Testpunkte nach vorlage for tpunkt in testpunkte bertrage tpunkt auf vorlage teste tpfad mit vorlage erstelle Tes
188. rden zum Beispiel ICMP Fehlernachrichten oder ein FTP Datenkanal im Kontext einer FTP Kontrollverbindung eingestuft INVALID Das ist ein Spezialzustand der f r unerwartete Pakete benutzt wird Das k nnten z B ICMP Fehlernachrichten ohne Kontext oder fehlerhafte Pakete sein UNTRACKED Dieser Zustand ist mit der raw Tabelle hinzugef gt worden um Pa kete zu markieren die durch entsprechende Regeln von der Verbindungsver folgung ausgeschlossen wurden Dies erm glicht Ressourcen zu sparen falls f r bestimmte Assoziationen keine detaillierten Sicherheitsanforderungen bestehen Ack Fi Rst m9 S 7 7 S SynAck C Syn T 10 S SynAck Le T 120 T 60 C Ack C Syn or ai None i S SynAck None Ack Fin C Syn Rst ML Est S SynAck T 432000 DIUI S SynAck gt Rst 5 E _ Finwait J 7 k l FinWait T 120 Ack C Syn s ae S SynAck A Rst 3 Fin CloseWait SSS T 60 CloseWait Syn C Syn Fin Fin S SynAck Rat M LastAck I ra LastAck Ack Fin Ack 1 Rst k TimeWait imeWait T 420 r r S Synack E S Server S Server C Client C Client T Timeout in seconds ignored ignored normal transitions normal transitions a Vereinfachte Zustandsmaschine mit b Vollst ndige Zustandsmaschine mit Uberg ngen durch Senden von TCP Flags
189. ressen der Firewall bzw zu den sogenannten NAT Adresspools und der konfigurierten Portbereiche notwendig Sollte eine Fire wall eine getrennte Verbindungsverfolgung f r NAT verwenden so m ssten auch 94 8 1 Modulkonzept hier die Zust nde mit ihren berg ngen und den Timeouts spezifiziert werden Die ses Szenario wird aber von FW TStrategy aktuell nicht unterst tzt Alle anderen NAT Angaben sind dem Regelwerk direkt zu entnehmen und k nnen getestet wer den Die Angaben zu den Adressbereichen und den Firewalladressen werden aktuell in der FW Test eigenen Konfiguration hinterlegt und von der Teststrategie verwendet 8 1 4 Protokollmodule Jedes Protokollmodul enth lt Funktionalit ten und Wissen die f r das Verbin dungsmanagement des jeweiligen Protokolls erforderlich sind Im Allgemeinen l sen die Module folgende Aufgaben e Pr fen der Korrektheit des Testpfades e Anpassen des Paketformates zu dem getesteten Verbindungszustand e Pakettransfer zwischen den Agenten e R ckgabe der Auswertung des Tests e Speichern der Statistiken ber alle gesendeten Paketen Die Protokollmodule test TCP test UDP und testICMP enthalten Funktionalit ten die f r die folgenden Aufgaben zust ndig sind e Pakettransfer zwischen zwei Agenten e Pr fen der Korrektheit des Testpfades Zuvorstehende Testf lle m ssen eine spezifikationskonforme Vorgeschichte f r den Nachfolger herstellen e Alle gesendete Pakete z hlen Am E
190. rfen Des wegen wird eine Beschreibung der Ports und Daten nicht ben tigt F r UDP wurden beispielhaft Nutzlasten f r einfache Request Reply basierte Protokolle wie DNS oder NTP hinterlegt die bei Bedarf von der Strategie verwendet werden ICMP tr gt in der Regel keine Nutzlast oder bezieht sich auf einen vorhandenen Kontext so dass auch hier keine eigene Nutzlast ben tigt wird F r die gezielte Herstellung von bestimmten Zustandseintr gen sowie zum Zwecke der Bestimmung von Timeouts werden die Anzahl die Art sowie die berg nge zwi schen den Zust nden ben tigt Unterschieden wird dabei zwischen den Zust nden der jeweiligen Protokollzustandsmaschinen z B TCP oder UDP DNS und den Zust nden der abstrakteren Verbindungsverfolgung z B NEW ESTABLISHED RELATED Die Abh ngigkeiten zwischen den Zust nden der Verbindungsver folgung werden indirekt durch die association list vom FWA vorgegeben Lediglich die Reihenfolge der Abarbeitung wird in der Probandenbeschreibung hinterlegt Bei iptables wird die Reihenfolge 1 ICMP REL ICMP EST ICMP NEW ICMP INV 2 TCP REL TCP EST TCP NEW TCP INV 3 UDP REL UDP EST UDP NEW UDP INV verwendet Die Beschreibung der TCP Zustandsmaschine ist mittels der vorgestellten conntrackStateMachine realisiert und mit den in Abbildung 4 10 beschriebenen berg ngen parametrisiert F r die Interpretation der SNAT Variante Masquarading Hide NAT sind Anga ben zu den konfigurierten externen Ad
191. rieb von VLANs 3 2 Merkmale der Regelverarbeitungs und Filtereinheiten Bei der Untersuchung der Firewallsysteme wurden unterschiedliche Abbildungen des Regelwerks dessen Abarbeitung und Voreinstellungen identifiziert Ziel der folgenden Darstellung ist die Vorstellung der Besonderheiten und der M chtigkeit der jewiligen Konfigurationssprachen Durch die Kategorisierung der verf gbaren Sprachbefehle soll zudem eine Trennung zwischen den Strukturierungsmitteln der Sprache und den Anweisungen f r den Paketfilter erleichtert werden Letztere sind f r die Bewertung der M chtigkeit und der Testbarkeit eines Paketfilters relevant Bei allen untersuchten Firewalls ist die Syntax der Konfigurationssprachen doku mentiert Bei der PF und bei IPF ist sie sogar in Backus Naur Form BNF spe zifiziert wodurch Uneindeutigkeiten verhindert werden Die Semantik die genau en Auswirkungen einer Einstellung und die Interpretation von m glichen Ausgaben werden aber oft nur in Kurzform gehalten Das Handbuch der Cisco PIX ist ein typi sches Beispiel in dem Befehlsoptionen h ufig nur in Satzform benannt die Auswir kungen jedoch nicht erl utert werden Fehlende uneindeutige oder widerspr chliche Dokumentation f hrt dazu dass der Benutzer raten muss Die berpr fung oder Erg nzung der Dokumentation liefert eine Motivation f r diese Arbeit und f r das Testen von Firewalls 5Cisco PIX unterst tzt den Bridgemodus ab der Softwareversion 7 0 d
192. rohungen gegen Netzwerkknoten vor Die Sicherheitsziele und m gliche Bedrohungen werden zur Bewertung und Einordnung der Firewalldienste und merk male verwendet Im letzten Abschnitt 2 3 werden typische bzw repr sentative Paketfilter aus gew hlt Sofern der Paketfilter nur ein Bestandteil des Systems ist wird das Produkt den vorgestellten Firewalltypen zugeordnet 2 1 Netzwerkfunktionen und Firewalltypen Netzwerke wie sie hier betrachtet werden bestehen aus adressierbaren Netzwerk ger ten die untereinander Daten austauschen k nnen Die Kopplung der verschie denen Teilnehmer und Bereiche kann gem dem Open Systems Interconnection OSI Referenzmodell ISO7498 1 das ein geschichtetes und abstraktes Modell zur herstellerunabh ngigen Beschreibung von Kommunikations und Computernetzwerk protokollen beschreibt auf den Schichten 1 bis 4 geschehen Dementsprechend existie ren auch schichtspezifisch unterschiedliche Ger te die diese Aufgabe erf llen In Ab bildung 2 1 wird das OSI Referenzmodell dem TCP IP Modell RFC1122 gegen ber gestellt Obwohl die hier behandelten Protokolle treffender dem TCP IP Modell zu zuordnen w ren wird f r die Diskussion das allgemeinere OSI Referenzmodell ver wendet F r die folgenden Betrachtungen und die Einf hrung in Firewalls sind die Schich ten 3 Vermittlung und 4 Transport des OSI Referenzmodells interessant Ger te der unteren Schichten zu denen z B Hubs Repeater Bridges
193. rt werden k nnen filter Die Tabelle filter ist f r die Paketfilterung zust ndig und wird an den Zugriffs punkten INPUT FORWARD und OUTPUT registriert nat In der Tabelle nat k nnen Regeln zur Ver nderung der Quell und Zieladresse der Pakete angegeben werden Sie wird an den Zugriffspunkten PREROUTING OUTPUT und POSTROUTING registriert 30 4 1 Paketfl sse kernel processing t Be pss n ES raw UE DUE el input 5 ae 3 no new conn gt no filter yes nat filter Fe a del le En ied it Ci oni kernel routing decision I ZEUF J E le 2 QoS ingress 3 S l E filter o nat yes mangle Dx 9 gen state p AE o c pre routing li E post routing to devices Abbildung 4 2 Entscheidungspunkte f r den Paketfluss bei iptables mangle In der Tabelle mangle k nnen nderungen an Inhalten und Markierun gen der Pakete vorgenommen werden Dazu z hlen Ver nderungen von QoS und ToS Feldern oder systeminterne Markierungen f r das Bandbreitenmana gement mangle wird an allen f nf Zugriffspunkten registriert conntrack Die Tabelle conntrack steht dem Benutzer nicht zur Verf gung und wird vom System intern benutzt um zustandbehaftete Verbindungsverfolgung zu realisieren Sie wird in PREROUTING und OU
194. rtraulichkeit von Informationen Als vertraulich und sicherheitsrelevant k nnen z B Informationen ber die Netzwerkinfrastruktur eingestuft werden Deswegen ist auch die Netzwerk und Systemerkundung zu der das Sammeln von IP Adressen das Scannen nach of fenen Ports oder die Feststellung der eingesetzten Software geh ren dieser Kategorie zuzuordnen Der Akt des Belauschens kann auch eine Verletzung der Autorisierung bedeuten Der Verlust die Modifikation oder die F lschung von Daten gef hrden die Inte grit t Gleichzeitig sind dar ber auch widerrechtliche Zugriffe m glich die nicht mehr korrekt zuordenbar sind Dadurch kann auch die Verf gbarkeit gest rt werden Das am meisten bedrohte Sicherheitsziel in Netzwerken ist die Verf gbarkeit von Systemen und Diensten Sie kann durch pr parierte Pakete die die Systeme zum Stillstand oder Absturz bringen oder die berlastung der verf gbaren Ressourcen angegriffen werden Die Angriffe gegen die Verf gbarkeit werden als Denial of Service DoS bezeichnet Gezielt eingef gte Fehler in den Protokollen IP TCP UDP oder ICMP lassen sich f r betriebssystemspezifische DoS Angriffe nutzen Dazu z hlen u a Ping of Death PoD die Teardrop Attacke oder WinNuke Vel hierzu http de wikipedia org wiki Denial of Service 11 2 Firewalls Die berdurchschnittliche Beanspruchung der Ressourcen wird i d R erreicht wenn mehr Anfragen generiert werden als der Dienst bearbeiten
195. s Modells len 49 5 2 Anwendung auf Firewallfunktionen 54 5 3 Anwendung auf den Paketfilter netfilter iptables 55 6 Testen 57 6 1 Netzwerk und Protokolltests lr 60 6 2 Testen von Firewalls 2 6 Sse ad Gee oS Re ee Rene 63 6 3 Testbarkeit von Protokollen und Protokolll ssen 65 6 4 Reduzierung des Testraums ouo eue ee ae 67 7 Allgemeine Teststrategie 69 7 1 Vereinfachter Testablauf f r einen Testpunkt 73 7 2 Entwicklung einer optimierten Teststrategie 79 Inhaltsverzeichnis Proof of concept 8 1 Modulkonzept 2 5 ost onc e ee erue C erg aet at Ob recie Bea y Sq Wieketsyst nin is s ho PS ea de eus deua A eet de OR dee 8 1 2 Automat zur Beschreibung der Zustandsverfolgung 8 1 8 Beschreibung des Probanden 8 1 4 Protokollmodule Du ar RUE EG ek pom Ae ufi 8 2 Umsetzung der Protokolltests u rie ore 28 ves 08 ven Ra 8 3 Ausblick auf k nftige Erweiterungen Ergebnisse 9 1 Anwendungsf lle f r FWTStrategy 00 9 2 Beispiele der Testabdeckung 9 3 Erkenntnisse aus der Untersuchung von iptables 10 Bewertung und Vergleich 10 1 TOSDSVOTEZGUPO Lh ium E W uos x EEWI BEEN bx i veru 10 2 Verwandte Untersuchungen lll TO 3e CI LEEREN 11 Zusammenfassung und Ausblick A Anhang A
196. s bekann teste unter ihnen d rfte nmap Nmap sein Es kann durch amap Amap unterst tzt werden das sich auf die Erkennung von Dienstanwendungen spezialisiert hat selbst wenn sie auf einem un blichen Port betrieben werden Beide Anwendungen sind f r viele Umgebungen als freie Open Source Programme verf gbar firewalk Firewalk kann die vom Paketfilter weitergeleiteten Ports herausfinden Die Funktionsweise wurde in GS98 beschrieben und publiziert Firewalltest und analyse Der AlgoSec Firewall Analyzer AFA AFA ist ein kommerzielles Werkzeug das das Regelwerk vieler Firewalls analysieren sowie potentielle Konflikte zwischen den Regeln und sicherheitskritische Einstellungen finden kann Dies wird durch voll st ndige offline Analyse mit einem auf der Firewall ANalysis enGine kurz FANG basierenden Simulationsmodell das auf Seite 112 bei den verwandten Arbeiten vor gestellt wird erreicht Bei der offline Analyse findet keine Interaktion mit der Fi rewall statt und das Regelwerk wird in einer Simulation analysiert Dies hat einer seits den Vorteil dass der Betrieb der Firewall nicht gest rt wird anderseits aber auch den Nachteil dass die Analyse nur so genau ist wie das Simulationsmodell es erlaubt und abweichende Verhaltensweisen des Systems nicht gefunden werden k nnen Neben der reinen Analyse bietet der AFA auch weitere Managementfunk tionen wie nderungsverfolgung automatische berpr fungen oder Regelwerkopti mieru
197. s der Kategorie der dynamischen Tests zugeordnet Weiterhin ist es auch m glich diversi fizierende Tests durchzuf hren um mehrere Paketfilterversionen zu vergleichen Bei beiden Arten k nnen Abweichungen und St rungen bzw Symptome ermittelt wer den Ein hier angestrebter Test des extern beobachtbaren Systemverhaltens geh rt den Black Box Tests an Da das Verhalten jedoch unter Ber cksichtigung der Kon figuration und einer Modellierung des internen Paketflusses berpr ft wird muss der Test schlie lich den Grey Box Tests zugeordnet werden Die Testebene kann als Systemtest klassifiziert werden F r die Beschreibung des Konzeptes der Teststrategie sollen die im Folgenden verwendeten Begriffe eingef hrt und definiert werden In Abschnitt 6 1 wurden be reits die Einheiten einer ISO9646 Testsuite eingef hrt die in Tabelle 7 1 den weiter verwendeten Begriffen gegen ber gestellt werden Die Teststeuerung die die Strategie umsetzt wird unter der Bezeichnung FWT Strategy entwickelt Im ISO9646 Kontext stellt sie eine abstract testsuite dar die zusammen mit der Parametrisierung durch die Firewallbeschreibung und die Test 71 7 Allgemeine Teststrategie IS09646 Einheit Einheit in FWTStrategy ATS FWTStrategy PETS FWTStrategy mit Firewallbeschreibung und Vektoren test group Vektor test case Testfall test step Schritte im Testpfad test event empfangenes Paket oder Zeit berschreitung LT FW Test Agenten TCP Teststeueru
198. shed 1997 URL http citeseer ist psu edu 279361 html besucht am 26 06 2007 Verma Pavan und Atul Prakash FACE A Firewall Analysis and Configuration Engine In SAINT 05 Proceedings of the The 2005 Symposium on Applications and the Internet SAINT 05 Washing ton DC USA IEEE Computer Society 2005 ISBN 0 7695 2262 9 DOI 10 1109 SAINT 2005 28 pp 74 81 Welte Harald netfilter iptables in embedded devices Pers nliche Email lt laforge gnumonks org gt 07 Juli 2007 Wool Avishai Architecting the Lumeta Firewall Analyzer In Proceedings of 10th Usenix Security Symposium Washington DC USA Usenix Association 2001 pp 85 97 Wool Avishai A Quantitative Study of Firewall Configuration Er rors In Computer 37 6 2004 pp 62 67 ISSN 0018 9162 DOT 10 1109 MC 2004 2 International Telecommunication Union Telecommunication Stan dardization Sector X 290 OSI Conformance Testing Methodology and Framework 1995 Yuan Lihua u a FIREMAN A Toolkit for FIREwall Modeling and ANalysis In SP 06 Proceedings of the 2006 IEEE Symposium on Security and Privacy S amp P 06 Washington DC USA IEEE Computer Society 2006 ISBN 0 7695 2574 1 DOI 10 1109 SP 2006 16 pp 199 213 Zwicky Elizabeth D Simon Cooper und D Brent Chapman Building Internet Firewalls 2 Aufl O Reilly Media 2000 Projektseiten AFA 142 AlgoSec Inc AlgoSec Firewall Analyzer URL
199. spiel f r eine behindernde Reglementierung ist die Filterung von ICMP Fehlernachrichten 9Vgl auch die Einf hrung der Firewalltypen auf Seite 7 39 4 Funktionsweise der Paketfilter tionen Informationen die diese eindeutig beschreiben gesammelt werden Im Re gelfall sind das bei TCP und UDP Assoziationen die Richtung die ein und oder ausgehende Schnittstelle Quelladresse und port Zieladresse und port sowie eine Repr sentation f r die Phase der Assoziation und eine G ltigkeitsdauer Bei ICMP Nachrichten werden Typ und Code statt der Ports hinterlegt Ein m gliches Beispiel f r diese Zustandsinformationen ist in Listing 4 1 zu sehen out tcp 6 timeout 431976 ESTABLISHED src 192 168 1 1 dst 10 1 2 3 sport 50754 dport 5222 pkts 1 bytes 313 out tcp 6 timeout 431981 ESTABLISHED ASSURED src 192 168 1 1 dst 192 168 1 2 sport 42666 dport 1863 pkts 2 bytes 109 in udp 17 timeout 22 UNREPLIED src 192 168 1 2 dst 255 255 255 255 sport 138 dport 138 pkts 1 bytes 242 Listing 4 1 Beispiel f r Zustandsinformationen Optional k nnen noch weitere Informationen abgelegt werden Dazu z hlen die erwarteten Antwortpakete bei TCP die Angaben zu Sequenznummern und Flags die traversierten Netzwerkschnittstellen Informationen zu durchgef hrten Adress transformationen oder relevante Daten aus den Anwendungsschichten Bei der weiteren Verbindungsverfolgung sollten neben den IP Adressen und den Ports auch die Sequenznummern
200. st punkt als Repr sentation aller spezifizierten Protokollfl sse die Zustands berg nge vollst ndig getestet werden Dies f hrt zu einer sehr gro en Test und Paketanzahl sowie auch bedingt durch eine fehlende Ber cksichtigung der Zustandsverfolgung zu manchen false positives und false negatives Die Betrachtung der Protokollfl sse von den Endpunkten aus und die darauf basie rende berpr fung der Konformit t kann die Frage beantworten ob ein bestimmter Protokollfluss von einem Paketfilter zugelassen oder unterdr ckt wird Um die Frage zu beantworten welchen Einfluss eine Konfiguration des Paketfil ters auf die zugelassenen oder unterdr ckten Protokollfl sse hat m ssten s mtliche denkbaren Protokollf sse die im Paketfilter potenziell konfigurierbar sind getestet werden Die berpr fung des TCP Automaten im Paketfilter wird zur Bewertung der allgemeinen Konformit t zur Protokollspezifikation durchgef hrt Fine Aussage ber die Konfiguration wird nicht getroffen Die vorliegende Arbeit geht einen neuen Weg bei dem die produktspezifischen Regeln zun chst vollst ndig in eine abstrakte Form berf hrt und dann analysiert werden Die Testbeschreibung basiert auf den Analyseergebnissen Die Fragestellung der Tests bezieht sich auf eine Aussage ber den Einfluss einer Paketfilterkonfigurati on auf die zugelassenen oder unterdr ckten Protokollfl sse Deshalb wird ausgehend von der Konfiguration bzw deren Repr sentation die
201. st tzt Gouda und Liu GLO5b besch ftigen sich mit dem Problem der Aufdeckung al ler redundanten Regeln einer Konfiguration Zun chst werden die Voraussetzungen f r die Entdeckung aller solcher Regeln vorgestellt aufgrund derer die Regeln in aufw rts redundante und abw rts redundante Regeln klassifiziert werden Schlie lich werden auf firewall decision trees FD T arbeitende Methoden vorgestellt die beide Redundanztypen entdecken k nnen Die Arbeit zielt auf die Optimierung eines Regelwerks und bleibt abstrakt auf der Modellebene ohne eine konkrete Anwendung vorzustellen IT Val ist ein Open Source Werkzeug das die Konfigurationsanalyse von netfil ter iptables Firewalls hnlich der Funktionalit t von FANG und LFA erm glicht Die Basis von ITVal ist eine Funktionsbibliothek f r die effiziente Manipulation von multi way decision diagrams die zur Darstellung der Regeln und der Anfragen ber die Konfiguration genutzt werden Neben der Betrachtung des Designs und der Im plementierung von ITVal werden auch Beispiele vorgestellt wie h ufige Konfigurati onsfehler entdeckt und korrigiert werden k nnen vgl MK05 Firewallmodellierung Von Gouda und Liu stammt auch das erste Modell f r zustandsbehaftete Firewalls GL05a Die Basis des Modells ist die Auftrennung einer zustandsbehafteten Fire wall in zwei Bereiche einen zustandsbehafteten und einen zustandslosen Bereich Im ersten Bereich werden Informationen ber bereits a
202. sting 4 2 Beispiel fiir iptables Zustandsinformationen umformatiert Das Kommandozeilenprogramm iptables wird nur zur Konfiguration des Regel werks selbst verwendet Statusinformationen Parameter und Schalter zur Steuerung des Verhaltens von netfilter und des Netzwerkstapels werden dagegen im virtuellen proc Dateisystem abgebildet Bei Linux ist es standardm ig unter proc eingebun den Unterhalb von proc net werden nur lesbare Statusinformationen hinterlegt 42 4 2 Zustandsbehaftete Verbindungsverfolgung und in proc sys net befinden sich auch modifizierbare Parameter die mit Stan dardwerten vorbelegt sind Besonders interessant ist hier die conntrack Tabelle die die gerade aktiven Assoziationen beinhaltet und wie eine Datei ausgelesen werden kann Eine beispielhafte Ausgabe ist in Listing 4 2 zu sehen IPFW IP FireWall Die zustandbehaftete Verbindungsverfolgung bei IPFW wird ber dynamische und zeitlich begrenzte Regeln die sich auf die im Paket beschriebenen Endpunkte bezie hen beim Filtern realisiert Zustandsinformationen werden bei jeder akzeptierenden Regel mit einem der Schl sselw rter keep state oder limit erstellt und beim ersten Auftreten von keep state oder check state berpr ft Somit kann der Zeitpunkt der berpr fung eingeschr nkt beeinflusst werden In Listing 4 3 ist ein Ausschnitt aus einem Regelwerk incl aktiver dynamischer Regeln darsgestellt der mit dem Befehl ipfw ad show erzeugt wurde D
203. t Interoperabilit t Ordnungsm igkeit Si cherheit e Zuverl ssigkeit reliability Reife Fehlertoleranz Wiederherstellbarkeit Robustheit Verf gbarkeit e Benutzbarkeit usability Verst ndlichkeit Bedienbarkeit Erlernbarkeit e Effizienz efficiency Wirtschaftlichkeit Zeitverhalten Verbrauchsverhalten e Wartungsfreundlichkeit maintainability Analysierbarkeit nderbarkeit Stabilit t Testbarkeit e bertragbarkeit portability Anpassbarkeit Installierbarkeit Austauschbarkeit zuordnet Zus tzlich zu den genannten Merkmalen kann in jeder der Gruppen die Konformit t conformity mit der Spezifikation berpr ft werden Abh ngig vom Testaspekt muss eine geeignete Testmethode gew hlt werden aus der sich die Testebene der Testzugang sowie die ben tigte Informationsmenge er geben Liggesmeyer Lig02 S 34 schl gt eine Klassifizierung vor die hier verk rzt wiedergegeben wird e statisch Test ohne Programmausf hrung verifizierend analysierend e dynamisch Test w hrend der Programmausf hrung strukturorientiert Ma f r die berdeckung des x Kontrollflusses x Datenflusses funktionsorientiert Test gegen eine Spezifikation 1 International Organization for Standardization ISO und International Electrotechnical Com mission IEC 59 6 Testen Funktionale quivalenzklassenbildung Zustandsbasierter Test Ursache Wirkungs Analyse
204. t da die zugrunde liegende Vorgehensweise bereits in dem Abschnitt zur Abbildung 7 3 beschrieben ist Die restlichen Module werden nur als Hilfsfunk tionen betrachtet und deswegen nicht weiter beschrieben 8 1 1 Ticketsystem Das Ticketsystem besteht aus den vier Klassen ticketing eventlog logItem und timedRingBuffer Ersteres ist die Hauptklasse die in der Teststrategie ver wendet wird und die anderen dienen zur Verwaltung der Tickets Die Klassen sind in Abbildung 8 2 dargestellt ticketing eventlog shared state items timedRingBuffer log eventlog eventlog reserved int append logtype timeout data getItems getLast event elem ticketing initTimeout 5 startup shutdown save filename register proto args contains elem update pkt timeout ticket toString genUUID obj getPktExpire time elem getConnExpire time elem toLogFmt testcase entry logltem logltem event object tstamp timestamp timedRingBuffer timeout int age max int data object data list logItem event tstamp timeout data t imedRingBuffer age max hasExpired append x match event data cleanExpired toString iterate equals other toList Abbildung 8 2 Klassen des Ticketsystems 90 8 1 Modulkonzept class ticketing shared state Die Klasse ticketing is
205. t der Identifikationsnummer der Anfrage berein stimmen Andernfalls kann Netfilter das Paket keinem bekannten Datenstrom zuordnen und wertet es als INVALID ICMP Anfragen werden in der Verbindungsverfolgung gez hlt so dass die An zahl der Antworten mit der Anzahl der Anfragen bereinstimmen muss Das be deutet dass eine Anfrage den Z hler inkrementiert und ein erwartetes Antwort paket den Z hler dekrementiert Stehen noch mehrere Antworten aus so kann ein ESTABLISHED Eintrag in der Verbindungsverfolgung beobachtet werden Erreicht der Z hler die Nullposition wird der Verbindungseintrag gel scht Der Timeout des ESTABLISHED Zustands f r ICMP betr gt 0 Sekunden was bei gleichverteilten Anfragen und Antworten dazu f hrt dass der ESTABLISHED Zustand nicht beobachtet werden kann 8 3 Ausblick auf k nftige Erweiterungen RELATED Eine der Hauptaufgaben von ICMP ist die Fehlerbenachrichtigung und Kontrolle der Verbindungen Dadurch werden ICMP Pakete in bestimmten F llen als RELATED also einem anderen Datenstrom zugeh rend interpre tiert Netfilter betrachtet alle ICMP vom Typ error message als RELATED Dazu geh ren e ICMP type 3 Destination unreachable message e ICMP type 4 Source quench message e ICMP type 5 Redirect message e ICMP type 11 Time exceeded message e ICMP type 12 Parameter problem message Zus tzlich m ssen sie in der Nutzlast den IP Header und mindestens 8 Byte der h heren Protokollschic
206. t der neuen Version wurde das FIN Flag entfernt Fehler bei der Auswertung des RST Flags in Linux 2 6 10 folgt das RST Flag in der genannten Linux Version direkt auf ein Paket mit gesetztem ACK Flag wird es ignoriert Dies hat zur Folge dass der Timeout nicht verk rzt wird und der Eintrag in der Verbindungsverfolgung weiterhin G ltigkeit beh lt Ver nderungen der als g ltig deklarierten TCP Flags die von der Verbindungs verfolgung akzeptierten und ausgewerteten TCP Flags wurden mehrfach erg nzt Die Kombination SYN ACK PSH wird seit dem 25 04 2005 akzeptiert SYN PSH seit dem 12 11 2005 und SYN URG seit dem 05 03 2007 Ge nderter Timeout f r die TCP Verbindungsverfolgung bei Linux Versionen vor 2 6 1 war der Timeout f r den Zustand close_wait in der TCP Verbindungsver folgung auf drei Tage eingestellt Am 3 12 2003 wurde dieser Timeout auf 60 Sekunden verk rzt nderungen der Verbindungsverfolgung f r TCP ein Zustands bergang scheint immer wieder neu interpretiert worden zu sein so dass dieser mehrfach ge ndert wurde Die folgende Tabelle fasst die Anderungen in einer bersicht zusammen Datum Version Zustand TCP Flag Reaktion heute lt 2 6 22 SynSent serverack IGNORE 01 12 05 lt 2 6 14 4 SynSent server ack INVALID DROP 10 03 05 lt 2 6 11 3 SynSent serverack IGNORE SynRecv server ack SynRecv vorher INVALID 14 12 04 2 6 10 SynSent serveriack INVALID DROP Tabelle 9 4 nderungen der berg nge
207. t nach dem Monostate Pattern modelliert da mit alle Protokollmodule auf ein gemeinsames Ticketsystem zugreifen k nnen In der Klassenvariablen shared state wird eine Referenz auf den gemeinsa men Zustand gespeichert ticketing Konstruktorfunktion Kann optional mit dem initialen Timeout f r neue Tickets parametrisiert werden startup L dt gespeicherten Zustand aus einer Datei um die Tickets zu ber ck sichtigen und Kollisionen bzw Einfl sse aus fr heren Aufrufen zu verhindern shutdown Speichert den aktuellen Zustand in einer Datei getStatus proto args berpr ft evtl ein Ticket das f r das Protokoll proto und die Eigenschaften args ausgestellt wurde Falls ein noch g ltiger Eintrag exis tiert wird eine verbleibende G ltigkeitsdauer die gr er Null ist zur ckgeliefert register proto args Fordert ein initiales Ticket ausgestellt f r das Protokoll proto und die Eigenschaften args an Die Anzahl und Art der Argumente ist varia bel Falls bereits ein Ticket das f r die gleichen Parameter ausgestellt wurde noch g ltig ist wird aktiv abgewartet Andernfalls wird ein neues Ticket mit der voreingestellten G ltigkeitsdauer ausgestellt update pkt timeout ticket Aktualisiert ein ausgestelltes Ticket mit dem Paket und setzt einen neuen Timeout genUUID obj Private Funktion Erstellt einen eindeutigen Identifier f r ein als Parameter bergebenes Objekt Wird als Teil des Tickets ver
208. tablauf f r einen Testpunkt Dabei gibt es f r die Ablehnung des Paketes bzw der Assoziation durch den Paketfil ter REJECT protokollabh ngige Mechanismen zur Benachrichtigung des Senders Allgemein sieht das Internet Protokoll generische Mitteilungen ber ICMP vor z B destination unreachable F r TCP kann aber auch ein TCP Paket mit gesetztem RST Flag verwendet werden In jedem Fall muss berpr ft werden ob ein empfan genes Paket sich tats chlich auf das gesendete Paket bezieht Im ACCEPT Fall wird das empfangene Paket auf Ver nderungen untersucht Hier sind sowohl die vom Paketfilter beschriebenen Modifikationen z B NAPT wie auch die regul ren und bertragungsbedingten Ver nderungen z B IP TTL zu berpr fen Die erwarteten Ver nderungen werden von den Vektoren vorgege ben Die vorgegebenen Aktionen werden auf firewallspezifische Vergleichsfunktionen abgebildet die in Tabelle 7 3 ausschnittweise aufgef hrt sind nat ipt DNAT ipt SNAT ipt MASQ mangle ipt T TL ipt ECN filter ACCEPT DROP REJECT Tabelle 7 3 Beispiele und Kategorisierung der Auswertungsfunktionen Nach der Auswertung aller Tests ergibt sich eine Hierarchie der Ergebnisse wie sie in Tabelle 7 4 dargestellt sind Aus jedem Vektor wird f r jede Kombination aus Pro tokoll und Zustand ein Testfall abgeleitet z B TCP EST F r jeden Testfall werden aus der association list alle m glichen Pfade paths zur Herstellung der Vorgeschic
209. tbericht return teststatistik Listing 7 1 Algorithmus teststeuerung Hauptmethode der Teststeuerung Vorauswahl von m glichen Vektoren die sich zur Herstellung einer Vorgeschichte eig nen Diese Vorauswahl beruht auf der alternierenden relativen Senderichtung und der notwendigen Voraussetzung dass der angegebene Kandidat den gleichen oder einen niedrigeren Zustand in seiner Definition miteinschlie t Die berpr fung der Kandi daten mit der Protokollspezifikation wird aber von FW TStrategy bernommen Aus der Kandidatenliste in der association list wird eine Baumstruktur mit dem Zielvektor an der Wurzel erstellt Jeder Pfad von der Wurzel bis zum letzten Knoten stellt einen m glichen Testpfad dar der eine Kette vom h chsten zum niedrigsten Zustand aufbaut Jeder dieser Testpfade muss auf Testbarkeit im Sinne der Proto kollspezifikation berpr ft werden bevor er freigegeben wird Andernfalls wird der n chste Pfad berpr ft Nach M glichkeit wird dabei auch versucht bereits verwen dete Vektoren nicht mehrfach zu testen indem ein alternativer Pfad gesucht wird Es gibt F lle in denen keine geeignete Vorgeschichte f r den Zielvektor exis 80 7 2 Entwicklung einer optimierten Teststrategie algorithm generiere Baum input Wurzelvektor Protokoll Zustand Liste der Assoziationen aList output Baum Eintrag in aList Element gt Vorelement knoten neuer Knoten target proto state teilliste f
210. ten notwendig werden und eine technische Umsetzung nicht vorgege ben wird Trotz der Allgemeinheit sind Sanktionen ein essentieller Bestandteil solcher Richtlinien wobei auch eine Balance zwischen dem finanziellem Aufwand und der 12 2 3 Auswahl und Klassifizierung repr sentativer Firewallsysteme Sicherheitssteigerung erreicht werden soll Detaillierter als die Leitlinie wird die allge meine Sicherheitskonzeption gefasst Sie beschreibt die ausf hrlichen Anforderungen und die dazugeh renden Mafnahmen Durch den h heren Detaillierungsgrad sind nderungen h ufiger m glich In der dritten Ebene werden technische Details kon krete Ma nahmen und produktspezifische Einstellungen beschrieben Sie enth lt vie le Dokumente die regelm ig ge ndert und typischerweise nur von den zust ndigen Fachpersonen gelesen werden Darunter f llt auch ein Firewall Regelwerk das sehr konkret formuliert und an eine Netzwerkstruktur bzw ein Ger t gebunden ist Detaillierungsgrad nderungen niedrig niedrig Leitlinie allgemeine Sicherheitsziele allg Sicherheitskonzeption ausf hrliche Anforderungen zugeh rige Massnahmen hoch hoch detaillierte Regelungen konkrete Produkteigenschaften verwendete Mechanismen Abbildung 2 3 Hierarchischer Aufbau von Richtlinien nach IT Grundschutzkatalo gen Ma nahme M2 338 2 3 Auswahl und Klassifizierung repr sentativer Firewallsysteme Bei d
211. ten von diesem Typ werden vom lokalen IP Stack der Firewall spezifikations konform verworfen falls sie eine Netzsegmentgrenze berschreiten sollten vgl Abschnitt 3 2 2 2 in RFC1122 ICMP type 9 10 Router Advertisement Selection message mit diesen ICMP Typen wird Kommunikation zwischen Routern realisiert mit der sie sich ge genseitig durch Advertisement Selection Nachrichten suchen k nnen Die Kon struktion einer funktionierenden Router Advertisement Nachricht ist nicht tri vial und ben tigt ein komplexeres Szenario vgl RFC1256 In der Entwick lungsumgebung war es nicht m glich diesen Fall nachzubilden wobei die Pakete bei den Versuchen von der Firewall verworfen wurden NEW Der NEW Zustand kann nur mit ICMP Paketen vom Typ request message aufgebaut werden Dazu geh ren e ICMP type 8 Echo request message e ICMP type 13 Timestamp request message e ICMP type 15 Information request message e ICMP type 17 Address mask request message ESTABLISHED Der ESTABLISHED Zustand in der ICMP Assoziation wird durch 98 das Senden einer Antwort auf eine ICMP Anfrage erzeugt die zu der Anfrage passt Zu den Antworttypen geh ren folgende Typen e ICMP type 0 Echo reply message e ICMP type 14 Timestamp reply message e ICMP type 16 Information reply message e ICMP type 18 Address mask reply message Fiir eine korrekte Zuordnung der Pakete in der Verbindungsverfolgung muss der Identifier im Antwortpaket mi
212. ter eingeschr nkt In Kapitel 3 wurden die Funktionen der Firewalls in Gruppen eingeordnet die aus der Analyse von Sicherheitszieles abgeleitet wurden Auch bei hnlichen angebote nen Funktionen wurden in der internen Umsetzung Unterschiede festgestellt Dies konnte darauf zur ck gef hrt werden dass es keine Musterfirewall gibt an der sich alle orientieren k nnen sondern vielmehr unterschiedliche Architekturen und Strate gien eingesetzt werden Gemeinsam ist allen jedoch die hnliche u ere Schnittstelle also das Verhalten bei der Vermittlung und der Reglementierung der Protokollfl sse Ausgehend von der Vielf ltigkeit der Firewalls mussten die internen Abl ufe und Strukturen analysiert werden Bei der Betrachtung der Konfigurierbarkeit der Paketfilter wurde die Struktur der Regelwerke die M glichkeiten zur Strukturierung des Regelwerks und zur Erh hung der Wartbarkeit sowie die M chtigkeit der Paketfilter und der Paketver nderungen untersucht Dabei wurde der Paketfilter netfilter iptables als die flexibelste L sung identifiziert mit dem sich ein Gro teil der Funktionen der anderen Paketfilter ver gleichbar realisieren lassen Aus diesem Grund wurde dieser f r die weitere Model lierung und Umsetzung der Teststrategie ausgew hlt Die Filterkriterien und die Filteraktionen von iptables wurden zu funktionell vergleichbaren Gruppen zusam mengefasst und die Relevanz der Merkmale f r eine allgemeine Repr sentativit t bewertet
213. teren k nnen die erstellten Pakete von einer Spezifika tion abweichen die bei der Implementierung nicht gen gend ber cksichtigt wurde 102 9 1 Anwendungsf lle f r FWTStrategy Die Abweichungen k nnen durch einen Abgleich zwischen der Implementierung under Spezifikation gefunden werden Der Einsatz eines Netzwerksniffers zum Aufzeichnen der gesendeten Pakete kann dabei hilfreich sein Es kann aber auch vorkommen dass der Test spezifikationskonform und erwartungsgem durchgef hrt wurde aber die Testauswertung das Ergebnis nicht korrekt zuordnen konnte Dieser Fehlerfall kann durch den Vergleich der Vorgabe des protokollierten Ergebnisses und der Fehler meldung identifiziert werden Weiterhin wird in der Testauswertung versucht die Fehlerart zu klassifizieren Sollten die behandelten Ma nahmen nicht zur L sung beigetragen haben so er h rtet sich der Verdacht eines Fehlers im Paketfilter Hierzu ist die Dokumentation bzw die Spezifikation des Paketfilters oder der Hersteller zu konsultieren Abweichungen in mehreren Komponenten k nnen m ssen aber nicht sichtbar werden Fehler k nnen sich berdecken oder summieren Zur weiteren Entlastung eines der Beteiligten kann der abweichende Teil der Test konfiguration mit einer anderen Produktversion oder einem anderen Produkt ma nuell wiederholt und verglichen werden Die differenzierenden Testkonfigurationen werden im Folgenden beschrieben Vergleich von zwei Konfigurat
214. term continue FORWARD mangle TTL non term continue FORWARD mangle ULOG non term continue FORWARD filter ACCEPT forward POSTROUTING mangle FORWARD filter DROP stop FORWARD filter REJECT stop FORWARD filter LOG non term continue FORWARD filter TCPMSS non term continue FORWARD filter ULOG non term continue OUTPUT raw ACCEPT forward OUTPUT add_state OUTPUT raw LOG non term continue OUTPUT raw TCPMSS non term continue OUTPUT raw NOTRACK forward OUTPUT mangle OUTPUT raw ULOG non term continue OUTPUT add state add state forward OUTPUT mangle OUTPUT mangle ACCEPT forward OUTPUT nat OUTPUT mangle CLASSIFY non term continue OUTPUT mangle CONNMARK non term continue OUTPUT mangle CONNSECMARK non term continue OUTPUT mangle DROP stop OUTPUT mangle DSCP non term continue OUTPUT mangle ECN non term continue OUTPUT mangle LOG non term continue OUTPUT mangle MARK non term continue OUTPUT mangle SECMARK non term continue OUTPUT mangle TCPMSS non term continue OUTPUT mangle TOS non term continue OUTPUT mangle TTL non term continue OUTPUT mangle ULOG non term continue OUTPUT nat ACCEPT forward OUTPUT Alter OUTPUT nat DNAT forward OUTPUT Alter 125 Anhang A Anhang phase chain task type next processing point OUTPUT nat DROP stop OUTPUT nat LOG non term continue OUTPUT nat NETMAP forward OUTPUT Alter OUTPUT nat REDIRECT forward OUTPUT filter OUTPUT nat TCPMSS non term continue OUTPUT nat ULOG non term continue OUTPUT
215. tes hnlich verh lt es sich mit fwtest von der ETH Z rich Es sind nicht alle Protokollfelder ma nipulierbar und keine Nutzdaten definierbar es ist keine bedingte Ablaufsteuerung m glich es werden nur die versendeten oder keine Pakete erwartet und die Abwei chungen zwischen den gesendeten und den empfangenen Paketen k nnen nur grob definiert werden Die in dieser Arbeit entwickelte FW TStrategy ist als Werkzeug flexibler einzuset zen und m chtiger in der zur Verf gung gestellten Funktionalit t Der Testablauf ist nicht fest durch eine Konfiguration oder einen Ablaufplan vorgegeben sondern wird durch die Firewallbeschreibung und die Konfiguration bestimmt Die Tests k nnen bereits im Prototyp mehrere Aktionen der Firewall auswerten und sind nicht nur auf ACCEPT oder DROP beschr nkt Die Pakete werden anhand der vorgegebe nen Testvektoren erstellt und bei Empfang des Paketes mit dem gesendeten Paket verglichen Paketver nderungen k nnen erkannt und bewertet werden Damit wurde auch die Unterst tzung f r das Testen von NAT umgesetzt Ebenfalls ausgewertet werden eventuelle Fehlermeldungen der vermittelnden Knoten die auf eine Korrela tion zu den gesendeten Paketen berpr ft werden Damit ist es m glich verschiedene REJECT Arten und Fehlernachrichten zu erkennen Die erreichte Testabdeckung ist zwar bezogen auf den gesamten Testraum eben falls unvollst ndig sie geht aber aufgrund der Orientierung an der Modellierung des Paketfi
216. the Internet Protocol 1991 URL http www rfc editor org rfc rfc1108 txt besucht am 26 06 2007 Internet Engineering Task Force Network Working Group RFC1122 Requirements for Internet Hosts Communication Layers 1989 URL http www rfc editor org rfc rfcii22 txt besucht am 26 06 2007 Internet Engineering Task Force Router Discovery Working Group RFC1256 ICMP Router Discovery Messages 1991 URL http www rfc editor org rfc rfci256 txt besucht am 26 06 2007 Internet Engineering Task Force Network Working Group RFC1812 Requirements for IP Version 4 Routers 1995 URL http www rfc editor org rfc rfci1812 txt besucht am 26 06 2007 Perkins Charles RFC2002 IP Mobility Support 1996 URL http ww rfc editor org rfc rfc2002 txt besucht am 26 06 2007 Srisuresh Pyda und Matt Holdrege RFC2663 IP Network Address Translator NAT Terminology and Considerations 1999 URL http ww rfc editor org rfc rfc2663 txt besucht am 26 06 2007 Srisuresh Pyda und Kjeld Borch Egevang RFC3022 Traditional IP Network Address Translator Traditional NAT 2001 URL http ww rfc editor org rfc rfc3022 txt besucht am 26 06 2007 Srisuresh Pyda und Matt Holdrege RFC3027 Protocol Compli cations with the IP Network Address Translator 2001 URL http ww rfc editor org rfc rfc3027 txt besucht am 26 06 2007 Rosenberg Jonathan u a RFC3489 STUN Simple Traversal of
217. tion ersichtlich sind so k nnen diese durch die hier entworfene Strategie nicht gefunden werden Zum Auffin den dieser Art von Unterscheidungen w re der Zugriff auf den Quellcode notwendig und Debugging statt Testen die geeignetere Methode 68 1 Allgemeine Teststrategie In diesem Kapitel wird ein Konzept f r eine allgemeine Teststrategie entwickelt Da bei werden Arbeit und Ergebnisse der vorangegangenen Abschnitte verwendet In Kapitel 3 wurden Merkmale und Funktionen der Firewalls identifiziert die in Kapi tel 5 dazu verwendet wurden ein Modell der jeweiligen Paketfl sse zu erstellen In Kapitel 6 wurden Grundlagen und die Methodologie des Testens vorgestellt die nun dazu verwendet werden eine Teststrategie zu entwickeln und sie in die bekannten Techniken einzuordnen F r die Interaktion mit der Firewall werden insbesondere die in Abschnitt 4 2 er rterten Mechanismen der Zustandsverfolgung bei der Test durchf hrung verwendet Ziel der Teststrategie ist das Verhalten eines typischen zustandsbehafteten Paket filters in Bezug auf seine Konfiguration seine Voreinstellungen die Produktspezi fikation bzw dokumentation sowie die Protokollspezifikationen zu berpr fen und eventuell vorhandene Abweichungen festzustellen Die Ergebnisse sollen dazu genutzt werden die Modellierung und die Dokumentation mit dem Realsystem abzugleichen sowie zustandsbehaftete Paketfilter vergleichbar zu machen Die gesetzte Aufgabenstellung stellt f
218. tionalit t und Dynamik des Systems entsteht erst durch die Konfiguration und Parametrisierung durch den Benutzer Die Konfiguration heutiger Firewalls ist mit den vielen Eigenschaften und Funktionalit ten sehr komplex gewor den Einfache Regelwerke k nnen bereits ber 100 Regeln enthalten und im profes sionellen Bereich sind 10 000 Regeln auch nicht ungew hnlich Die Zuverl ssigkeit 63 6 Testen Konsistenz und Widerspruchsfreiheit dieser Konfigurationen nachzuvollziehen und zu gew hrleisten ist h ufig nur mit Einsatz von unterst tzenden Werkzeugen m glich In Abbildung 6 4 wird zwischen produktgebundener Konfiguration fw specific rules und einer abstrakten produkt bergreifenden Form abstract fw rules unterschieden high level formal policy formal policy abstract fw rules fw specific rules firewall software Slave firewall hardware Abbildung 6 4 Abstraktionsebenen beim Testen von Firewalls Die Konfiguration kann aber nicht nur allein betrachtet werden sondern soll die Sicherheitsrichtlinien umsetzen Die Konsistenztests einer Konfiguration sagen aber noch nichts aus ber die bereinstimmung mit den Richtlinien Diese zu berpr fen ist allerdings bis jetzt nicht so einfach da sie meist informeller Natur sind und sprach lich festgehalten werden informal policy Deswegen bed rfte es einer weiteren for maleren Form formal policy mit festgelegter Syntax und Semantik vgl Definition der Sich
219. tru sion Prevention Systeme IPS W hrend die ersteren einen erfolgten Angriff fest stellen und dar ber informieren k nnen sind letztere in der Lage gerade auftreten de Angriffsmuster zu erkennen und sie mit Hilfe des Paketfilters zu unterbrechen ID amp P Systeme setzen zwei Klassen von Techniken ein Zur Angriffserkennung ver gleichen sie den Datenverkehr mit bekannten Signaturen Bei der Anomalieerkennung untersuchen sie die Daten auf Abweichungen zu den gesammelten netzwerkspezifi schen Daten ID amp P Systeme werden in netzwerk und hostbasierte Systeme unter teilt Netzwerkbasierte Systeme sch tzen die verbundenen Systeme und letztere das eigene Wirtssystem Die neueste Generation von Sicherheitsprodukten vereinigt alle bisherigen Funktio nen zusammen mit einer Anti Viren Komponente in einem Produkt und wird unter der Bezeichung Unified Threat Management UTM beworben Network Address and Port Translation Bei der Recherche zu dieser Arbeit hat sich Network Address Translation NAT als eines der un bersichtlichsten Netzwerkkonzepte herausgestellt Obwohl die Kern funktionalit t berall gleich vorgestellt wurde weichen die gew hlten Bezeichnun gen der einzelnen Varianten stark voneinander ab Um eine Vergleichbarkeit zu gew hrleisten werden die verschiedenen Varianten und Bezeichnungen aus RFC2663 RFC3022 zusammengefasst vorgestellt RFC3489 f hrt eine abstraktere Sicht auf die NAT Arten ein die in dieser Arbeit ab
220. tseite und die R ckrichtung beschreiben Nur die eingehende Assoziation vom Client erzeugt einen regul ren Eintrag und die anderen verweisen jeweils darauf AT 4 Funktionsweise der Paketfilter 00000001 d4968d33 000003fc d496cldc 00000801 00000011 00020001 00020001 06000000 00000028 00000000 3bb7aea0 00000001 d4968d33 000007b6 ffffffff ffffffff 00000001 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 27 40 00000000 d496cldc 00000801 d4968d33 000003fc 000000112 00000001 d4968d33 000003fc d496cldc 00000801 00000011 00000006 Listing 4 7 Beispiel f r Checkpoint VPN 1 FW 1 Zustandsinformationen 48 5 Allgemeines Modell f r zustandsbehaftete Paketfilter In diesem Kapitel wird ein allgemeines Modell f r zustandsbehaftete Paketfilter ent wickelt Unter allgemein wird dabei ein Modell verstanden das nicht nur spezifische oder gezielt ausgew hlte Objekte abbilden kann Deswegen wurden in Abschnitt 2 3 mehrere Firewallsysteme ausgew hlt die f r die in der Praxis typisch eingesetzten Systeme repr sentativ sind Weiterhin wurden in Kapitel 3 die Merkmale der aus gew hlten Systeme betrachtet und in Abschnitt 3 3 eine Bewertung sowie eine erste Klassifizierung der angebotenen Funktionen getroffen Dadurch konnten die Merkma le in typische und weniger verbreitete Funktionen bzw Auswahlkriterien unterteilt werden In Kapitel 4 wurde di
221. tside 192 150 49 10 31649 inside 10 1 1 15 1028 flags dD Listing 4 6 Beispiel f r Cisco PIX Zustandsinformationen Listing 4 6 zeigt die Ausgabe der Zustands und Verbindungsinformationen die ber alphabetische Flags gekennzeichnet werden Demnach w rde ein TCP Hand shake von inside nach outside nach dem SYN als saA nach dem SYN ACK als A nach dem ACK als U gekennzeichnet werden Nachdem erfolgreich Daten ausge tatauscht worden w ren w rden noch T bzw O hinzugef gt werden Leider ist aus der Dokumentation nicht ersichtlich wie weit die interne Darstellung von der hier gezeigten abweicht und es konnten keine weiteren Daten ermittelt werden W hrend der Untersuchung wurde beobachtet dass die Cisco PIX f r ber VPN Verbindungen authentifizierte Endpunkte dynamisch Regeln erstellt die in der aus f hrlichen Regelausgabe in der Form access list dynacl lt num gt permit ip any host lt vpnhost gt sichtbar sind 46 4 2 Zustandsbehaftete Verbindungsverfolgung Checkpoint VPN 1 FireWall 1 Die Zustandsinformationen werden bei der FW 1 im Hexadezimalformat dargestellt wodurch sie f r den Benutzer schwer zu interpretieren sind Zudem m ssen manche Felder als Ganzes und andere als zusammengesetztes Feld interpretiert werden Die Beschreibung des Formats basiert im Folgenden auf CPS03 und kann im Bedarfsfall dort detailliert nachgelesen werden Die Ausgabe erfolgt ber fw tab s state Die ersten
222. tzer 52 5 1 Bausteine des Modells definierten Objektgruppen Die Daten werden in unterschiedlichen Ausf hrungsbereichen verarbeitet Damit sind die ausf hrenden Instanzen Betriebssystem bzw Netzwerkstapel Paketfilter Anwendungsinspektion und Benutzerprozess gemeint Dadurch unterscheiden sie sich in ihrer Lebenszeit und ihrer Wirkungsreichweite nderungen am PVB sind nur in nerhalb des Systems bzw innerhalb des Kernels g ltig und gelten nur f r das eine re ferenzierte Paket Informationen zum Verbindungszustand sind weiterhin auf das Sys tem beschr nkt betreffen aber alle zur Verbindung geh renden Pakete nderungen am Paket sind dauerhaft f r alle folgenden Verarbeitungsphasen sichtbar und gelten ber Systemgrenzen hinweg Die Entscheidungen m ssen aber f r jedes Paket einer Verbindung neu evaluiert werden F r Regelwerke Aktionen Zustandsdaten modifikationen und abfragen werden im Folgenden Abbildungen eingef hrt die f r die symbolische Modellierung aller Ar beitsschritte genutzt werden Sie erg nzen die bereits in Abbildung 4 1 eingef hrten Symbole STATE TABLE X X XXXXXXX OO ROUTE I SEITE H FREIE a b Firewallfunktion c Zustandstabelle Routing Funktion mit Regelwerk Abbildung 5 4 Symbole zur Modellierung der Arbeitsschritte Zusammengefasst besteht die Modellierung der Firewallsysteme aus Funktionen Arbeitsobjekten Zustandsdaten und Zustandsfunktionen die in T
223. ub Network 2 Sub Network 1 Sub Network 2 a loop back test method b transverse test method Abbildung 6 3 Testmethoden nach ISO IEC 9646 f r vermittelnde Systeme Da der Quellcode bei Black Box Tests unber cksichtigt bleibt kann ein durch gef hrter Test Aussagen liefern was die IUT falsch gemacht hat aber nicht wo im Programmcode diese Fehler zu finden sind Fehlerlokalisierung und Fehlerbehebung werden aus den genannten Gr nden in der ISO Norm 9646 nicht geregelt und bleiben Angelegenheiten des Testkunden bzw Entwicklers 6 2 Testen von Firewalls Netzwerkkomponenten wie Firewalls sind Systeme die sowohl aus spezieller Software wie auch aus spezieller Hardware bestehen Das erwartungsgem e Zusammenspiel dieser Komponenten ist f r ihre Zuverl ssigkeit Sicherheit und Leistung verantwort lich Dementsprechend kann auch jeder Bestandteil eines Netzwerkger tes getestet wer den Bei der Hardwareplattform firewall hardware in Abbildung 6 4 k nnen auf grund der speziell ben tigten Messger te vor allem durch den Hersteller die physi schen Eigenschaften berpr ft werden Auf Bausteinebene k nnen weiter die Schal tungen die Signalverarbeitung die implementierte Logik oder die Empfindlichkeit auf Umweltfaktoren getestet werden Die Betriebssoftware firewall software kann von den Entwicklern mit den blichen Mitteln und Werkzeugen der Softwareentwick lung auf Fehler oder Probleme berpr ft werden Die eigentliche Funk
224. ucts secureplatform index html 15 3 Merkmale der Firewallsysteme In diesem Kapitel werden die in Abschnitt 2 3 ausgew hlten Firewallsysteme wei ter analysiert Aus allen Merkmalen werden hier vor allem die Sicherheits und die Netzwerkfunktionen Abschnitt 3 1 betrachtet Weitere zus tzliche Sicherheitsdiens te wie Authentifikation ID amp P Systeme Proxy Funktionen Content Filter oder Anti Viren Programme werden aufgrund des Betriebes auf der Anwendungsschicht nicht weiter klassifiziert Bei den kommerziellen Anbietern kann aber die Art und Anzahl solcher integrierten Dienste und der Managementfunktionen als weiteres Unterschei dungsmerkmal herangezogen werden Die vorgestellten freien Produkte sind nicht weniger m chtig die einzelnen Komponenten m ssen aber seperat ausgesucht und in Betrieb genommen werden Im Hinblick auf die Tests der Paketfilter werden in Abschnitt 3 2 die Merkmale der Regelverarbeitungs und Filtereinheiten vorgestellt Die Testbarkeit der vorgestellten Merkmale wird in Abschnitt 3 3 erl utert und bewertet 3 1 Sicherheits und Netzwerkfunktionen Die Klassifizierung und Vorstellung der Sicherheitsfunktionen der Firewallsysteme orientiert sich an den in Abschnitt 2 2 vorgestellten Sicherheitszielen Die meisten Merkmale unterst tzen die Sicherung der Verf gbarkeit Dies wird vor allem durch verschiedene Mechanismen der Zugriffskontrolle erreicht Vertraulichkeit Integrit t und Zurechenbarkeit werden vor
225. ungen der Zustands und NAT tabelle sowie die Filterentscheidungen ausgeben kann Eine Beispielausgabe ist in Listing 4 4 zu se 43 4 Funktionsweise der Paketfilter hen Detaillierte Zustandsinformationen k nnen zus tzlich mit dem Befehl ipfstat sl angezeigt werden und sind in Tabelle 4 1 veranschaulicht IPFilter war einer der f hrenden Paketfilter der erweiterte Eigenschaften des TCP Protokolls in die zustandsbehaftete Verbindungsverfolgung eingebracht hat Dazu geh rt das Verfolgen der g ltigen und noch unbest tigten Sequenznummern inner halb des aktiven TCP Fensters Die Basis f r diesen Mechanismus wurde in der Untersuchung von Guido van Rooij Roo00 beschrieben ipmon o S tstamp STATE NEW 10 1 1 1 53 10 2 2 15 53 PR udp tstamp STATE EXPIRE 10 1 1 1 53 10 2 2 15 53 PR udp Pkts 4 Bytes 356 tstamp STATE NEW 10 2 2 13 1119 gt 10 1 1 10 22 PR tcp tstamp STATE EXPIRE 10 2 2 13 1119 10 1 1 10 22 PR tcp Pkts 63 Bytes 4604 ipmon o N tstamp 92 NAT RDR 10 2 2 25 113 lt gt 10 2 2 25 113 10 1 1 13 45816 tstamp 2 NAT EXPIRE 10 2 2 25 113 lt gt 10 2 2 25 113 10 1 1 13 45816 Pkts 10 Bytes 455 ipmon o I tstamp ppp0 0 2 b 10 1 1 103 443 gt 20 2 2 10 4923 PR tcp len 20 1488 A tstamp x10 0 1 S 10 2 2 254 gt 255 255 255 255 PR icmp len 20 9216 icmp 9 0 Listing 4 4 Beispiele f r IPF Zustandsinformationen Art gesammelte Informationen
226. ungsrichtlinie aus normal high latency aggressive und conserva tive sowie die Bindung an eine konkrete Netzwerkschnittstelle eine Gruppe z B alle PPP Schnittstellen oder keine Bindung gew hlt werden 45 4 Funktionsweise der Paketfilter Cisco PIX Alle Informationen zu durchgef hrten Adress und Portumsetzungen werden vom ASA in der xlate Tabelle gespeichert Die Verbindungsinformationen werden in einer Zustandstabelle abgelegt Die Zustandsverfolgung vom ASA ist verbindungsorien tiert weshalb bei TCP auch die Sequenznummern abgelegt und verglichen werden was die externe Manipulation von Zustandsdaten erschwert Die initialen Sequenz nummern werden standardm fig vom ASA randomisiert pixfirewall config show conn detail 2 in use 2 most used Flags A awaiting inside ACK to SYN a awaiting outside ACK to SYN B initial SYN from outside C CTIBQE media D DNS d dump E outside back connection f inside FIN F outside FIN G group g MGCP H H 323 h H 255 0 I inbound data i incomplete k Skinny media M SMIP data m SIP media O outbound data P inside back connection q SQL Net data R outside acknowledged FIN R UDP RPC r inside acknowledged FIN S awaiting inside SYN S awaiting outside SYN T SIP t SIP transient U up TCP outside 192 150 49 10 23 inside 10 1 1 15 1026 flags UIO UDP ou
227. usatzkomponenten F r je den Eintrag in der Liste werden die Zielsysteme definiert auf denen diese Regeln installiert und durchgesetzt werden Die interne Abbildung des Regelwerks konnte nicht ermittelt werden Die Firewalls IPFW und PIX erstellen auch dynamisch neben dem vom Benut zer vorgegebenen Regelwerk Regeln IPFW erstellt Regeln als Repr sentation der Zustandsinformationen Die Cisco PIX erstellt dynamisch Regeln f r eingehende VPN Verbindungen Sie erlaubt auch eine bedingte Reglementierung ber den Befehl established der Assoziationen in Abh ngigkeit von einer anderen bereits bestehenden Assoziation erlauben kann Objektgruppen Bis auf IPFilter bieten alle untersuchten Firewalls eine M glichkeit Regeln zusam menzufassen indem sie sich nicht auf einzelne Eigenschaften bzw Objekte sondern auf Objektgruppen beziehen Linux netfilter kann besonders schnell auf Gruppen von IP Adressen und Ports zugreifen die mit dem Werkzeug ipset verwaltet werden IP FireWall bietet gleich mehrere M glichkeiten an Objektgruppen zu verwalten Mit or blocks Bsp x or not y or z lassen sich Alternativen zusammenfas sen Adressen k nnen mit Address Sets zusammengefasst Bsp 1 2 3 4 24 128 35 55 89 oder in Lookup Tables als ein Schl ssel Wert Paar gespeichert werden Der Schl ssel wird durch IP Adresse Maske gebildet und der Wert kann als Para meter f r weitere Regeln benutzt werden Or blocks und Address Sets lassen sich in Vari
228. usf hrung des Tests Der Ablauf der Testausf hrung ist in Listing 7 7 beschrieben Aus dem erstellten Testpfad und den reservierten Adressen in den Tickets wird eine Vorlage mit den gemeinsamen Eigenschaften f r die folgenden Testf lle erstellt Die Vorlage kann auf jedes Element des Testpfads angewendet werden woraufhin parametrisierte Testf lle 84 7 2 Entwicklung einer optimierten Teststrategie entstehen Jeder Testfall wird aus einem Vektor abgeleitet und beschreibt dann ein deutige Eigenschaften eines Testpaketes Diese werden an die Protokollmodule wei tergereicht die daraus Pakete generieren und verschicken k nnen algorithm testen input testvorlage testpfad output Liste von Testergebnissen kontext neuer TestKontext teile trenne testpfad nach protokollen for teilpfad in teile pfad neue Liste for testvektor in teilpfad test erstelle testvorlage aus testvektor h nge test an pfad an teste Pfad pfad protokoll kontext if test fehlgeschlagen then melde Fehler Herstellung der Vorgeschichte fehlgeschlagen abbrechen else kontext ergebnisse return ergebnisse Listing 7 7 Algorithmus testen Steuert die Durchf hrung eines Testlaufs Jedes Protokollmodul implementiert eine Funktion zur berpr fung eines Teilpfa des welcher nur das jeweilige Protokoll enth lt Von dort aus werden aus jedem Test fall im Testpfad entsprechende Pakete erstellt versendet und ausgewertet
229. uter Society 1997 pp 120 129 Haeni Reto E Firewall Penetration Testing Techn Ber Wa shington DC USA The George Washington University Cyberspace Policy Institute 1997 URL http citeseer ist psu edu haeni97firewall html Hoffman Daniel Durga Prabhakar und Paul Strooper Testing ip tables In CASCON 03 Proceedings of the 2003 conference of the Centre for Advanced Studies on Collaborative research Toronto On tario Canada IBM Press 2003 pp 80 91 Hoffman Daniel und Kevin Yoo Blowtorch a framework for firewall test automation In ASE 05 Proceedings of the 20th IEEE ACM international Conference on Automated software engineering New York NY USA ACM Press 2005 ISBN 1 59593 993 4 Dor 10 1145 1101908 1101925 pp 96 103 Institute of Electrical and Electronics Engineers Std 610 12 1990 IEEE Standard Glossary of Software Engineering Terminology New York NY USA 1990 por 10 1109 M S 1989 10025 Ingham Kenneth und Stephanie Forrest A History and Survey of Network Firewalls TR CS 2002 37 Techn Ber University of New Mexico Computer Science Department 2002 Ibrahim Adel El Atawy K Hamed und H Ehab Al Shaer Poli cy segmentation for intelligent firewall testing In Secure Network Protocols 2005 NPSec 1st IEEE ICNP Workshop on 2005 ISBN 0 7803 9427 5 DOI 10 1109 NPSEC 2005 1532056 pp 67 72 International Organisation for Standardization International Electro
230. viert werden Kernel IP Routing f routed by PF l scrub pf routing I state check logging I l binat or nat queue tagging 5 I l e filter H o ia 8 5 3 2 a SYN Proxy gt S e scrub TCP state TCP modulation a os o I I a 2 2 SYN Proxy l l scrub TCP state Z as a TCP modulation nu DS S 9 filter a Qo i R I l queue tagging rdr or binat 5 I logging state check L pf routing scrub l pf test 3 altq pf_test Layer 2 Abbildung 4 6 Paketfl sse durch die PF Firewall Obwohl der OpenBSD Packet Filter syntaktische Ahnlichkeiten zum IPFilter auf weist hat die fastroute Option jeweils verschiedene Bedeutungen Bei PF wird ein so markiertes Paket trotzdem nochmals in der Ausgangsrichtung verarbeitet Bei IPFil ter werden alle weiteren Schritte bersprungen und das Paket direkt weitergeleitet Analysiert wurden src sys net pf norm c rev 1 109 und src sys net pf c rev 1 550 35 4 Funktionsweise der Paketfilter Cisco PIX Die Analyse der Cisco PIX basiert auf dem offiziellen Handbuch und wurde mit Informationen aus BCD04 Pru04 erg nzt Hauptmerkmale der PIX sind der Adaptive Security Algorithm ASA der die zustandbehaft
231. wallsysteme Paket Paket length string hexstring unclean fragmented Zustand Verbindung Association state NEW EST REL INV UNTRACKED TCP state Ebene der Assoziation childlevel Markierungen Paket mark Verbindung connmark Spezialkriterien Zustand recent condition from file Port Scan Detector Andere nt random OS fingerprint owner time Tabelle 3 2 Filterkriterien von iptables Filterentscheidung passiv ACCEPT DROP aktiv REJECT tarpit Verlangsamt TCP basierte Spoofing Angriffe delegiert nfqueue Weitergabe an Benutzerprozess z B IDS transparent proxy inoff Erweiterung Reroute 1 Ziel DNAT SAME n Ziele balance DNAT ClusterIP Route Paket oder Kopie lokal local redirect transparent proxy Paketmodifikationen Adressen SNAT DNAT MASQ sowohl im IP TCP und UDP Header als auch f r Anwendungsprotokolle IP und TCP TTL IP Optionen TCP MSS Markierungen Paket TOS DSCP ECN Paketbeschreibung IP mark CLASSIFY CBQ mark notrack Verbindungseintrag connection mark Gruppen ipset Logging und Accounting log ulog account nicht unterstiitzt Modifikationen DF MF Flags ID IP DNS TCP Sequenznr IP und TCP Timestamp Anti DoS SYN Proxy Tabelle 3 3 M gliche Aktionen des iptables Paketfilters 28 4 Funktionsweise der Paketfilter In diesem Kapitel wird die Analyse der betrachteten Firewalls fortgesetzt Dies mal stehen nicht mehr die Merkmale sondern die Funktionsweise
232. weitergeleitete Pakete 6 Testen In den vorangegangenen Kapiteln wurden repr sentative Firewalls und Paketfilter untersucht um die verschiedenen Typen von Firewalls und deren Funktionen von einander abzugrenzen Damit ist es m glich die zustandsbehafteten Paketfilter zu definieren und eine repr sentative Auswahl der gebotenen Funktionen zu treffen In diesem und den folgenden Kapiteln wird darauf basierend eine allgemeine Teststra tegie f r zustandsbehaftete Paketfilter entwickelt Daf r werden zun chst in diesem Kapitel die Grundlagen des Testens vorgestellt zu denen eine Definition des Begriffes und die gegenseitige Abgrenzung verschiedener Testarten geh rt In Abschnitt 6 1 werden die Vorgehensweisen und Grundlagen der Netzwerk und Protokolltests vorgestellt und in Abschnitt 6 2 wird das Testen auf Firewalls fokus siert Abschnitt 6 3 behandelt die Testbarkeit von Protokollen und Protokollfl ssen und die daraus resultierenden Folgen f r die geplannte Teststrategie Testen ist ein Oberbegriff f r Verfahren deren Ziel es ist durch die berpr fung eines Systems seine charakteristischen Merkmale zu best tigen nicht beabsichtigte bzw nicht erwartete Eigenschaften aufzufinden und sie gegebenenfalls zu beseitigen Es ist eine Form der Qualit tssicherung die Fehlverhalten im Betrieb sowie die dar aus resultierenden Konsequenzen f r Hersteller und Betreiber minimieren und das Vertrauen in ein System st rken kann Tests k nn
233. wendet getPktExpire time elem Private Funktion Sucht ein Ticket das f r das in elem beschriebene Element ausgestellt wurde und liefert die verbleibende G ltig keitsdauer getConnExpire time elem Private Funktion Liefert die verbleibende G ltigkeit in Sekunden des Elements elem zum Zeitpunkt time class eventlog Das eventlog speichert die Tickets die von dem Ticketsystem ausgestellt werden eventlog Konstruktorfunktion Hier wird ein Beh lter f r die Logeintr ge als timedRingBuffer angelegt append logtype timeout data F gt dem eventlog einen neuen Eintrag vom Typ Logtype einer G ltigkeit f r die Dauer von timeout und dem Inhalt data hinzu Der Typ wird f r die Unterscheidung der Ereignisse Registrierung lock 91 8 Proof of concept Paket gesendet send Paket empfangen received und die Abfrage any ver wendet getltems Liefert eine Liste aller Logbucheintr ge zur ck getLast event elem Liefert den neuesten Eintrag f r das Ereignis event elem event kann ein konkreter Ereignistyp oder der Abfragetyp any sein save filename Speichert den Inhalt des Logs in die Datei filename contains elem Private Funktion zur Feststellung ob ein Eintrag f r das Element elem bereits vorhanden ist class logltem Die Eintr ge des Logbuchs werden in Objekten vom Typ logItem abgelegt logltem event tstamp timeout data Konstruktorfunktion Erstellt einen Log bucheintr
234. www algosec com abgerufen werden 112 10 2 Verwandte Untersuchungen einzulesen um daraus einen Bericht ber potentielle Sicherheitsprobleme zu erstellen Ebenfalls von A Wool stammt eine manuelle Analyse von typischen Konfigurations fehlern in produktiven Umgebungen Woo04 bei der er prinzipiell Handlungsbedarf und Verbesserungsm glichkeiten durch Einsatz von geeigneten Konfigurations und Testwerkzeugen sieht Der Firewall Policy Advisor FPA ist ein grafisches Werkzeug das die konflikt und fehlerfreie Verwaltung von Firewallregeln unterst tzen soll ASH03 Darin ent halten sind Algorithmen zur automatischen Entdeckung von Anomalien und Konflik ten in bestehenden Firewallregelwerken sowie Regelwerkmodifikationen Unter An omalien verstehen die Autoren Regeln die sich berdecken in Beziehung zu einander stehen sich komplett widersprechen oder redundant sind Aufbauend auf diesen Er kenntnissen erweiterten die Autoren die Funktionalit t und die zugrunde liegenden Techniken auf verteilte Firewalls und beschreiben sie in ASH04 Dank dieser Arbeit ist es zwar m glich Richtlinien zu entwerfen und zu berpr fen die Umsetzung in ein reales Regelwerk muss jedoch weiterhin manuell durchgef hrt werden was u U eine neue Fehlerquelle einf hrt und keine Aussage ber die tats chliche Wirkung des Regelwerks trifft FIREMAN steht f r das FIREwall Modelling and ANalysis toolkit und beherrscht die statische Analyse von Firewall
235. x min max max min max min min max max max max min min min max min min max min max max min max min max max min max min min max max min max min min max min max max max max min min min Tabelle 7 5 Beispiel f r die Wahl von Testpunkten Die Testpunkte werden aus den Eigenschaften Quell IP Ziel IP Quellport und Zielport gebildet algorithm entferne gesperrte Adressen input min und max eines Adressbereiches Liste mit gesperrten Adressen output neuer Adressbereich if min in Liste mit gesperrten Adressen then inkrementiere min if max in Liste mit gesperrten Adressen then dekrementiere max if min ver ndert or max ver ndert then wiederhole enferne gesperrte Adressen mit neuem min max else return min max Listing 7 6 Algorithmus entferne gesperrte Adressen Entfernt IPs von Produk tivsystemen aus dem Testbereich gurierbaren Zeitfenster so wird abgewartet andernfalls wird der Testpfad in einer Warteschlange abgelegt und ein weiterer Testpfad untersucht Anschlie end wird die Warteschlange immer wieder konsultiert um die dort abgelegten Tests abzuarbeiten Diese Phase wird ebenfalls dazu benutzt den Betrieb in einer Realumgebung zu erlauben und Adressen von realen Systemen von den Testpunkten auszuschliefen Dazu werden die gesperrten Adressen in der Testkonfiguration beschrieben und mit den Testpunkten abgeglichen Der Algorithmus in Listing 7 6 beschreibt die Vorge hensweise A
236. zierungs auch Autorisierungs und Accounting Dienste von einem separaten Server durchleiten bzw benutzen http www nufw org 20 3 1 Sicherheits und Netzwerkfunktionen Checkpoint FW 1 unterscheidet zwischen Benutzer Client und Session Authen tifizierung und bietet daf r jeweils unterschiedliche Methoden an F r eine detaillierte Aufschl sselung wird auf das Handbuch verwiesen Vertraulichkeit und Integrit t H ufig werden die AAA Funktionen mit Virtual Private Network VPN Diens ten und kryptographischen Verfahren verkn pft Verschl sselung kann einer erh hte Form der Authentifikation unterst tzen Vertraulichkeit gew hrleisten und Integrit t der Daten sicherstellen Die einzelnen Produkte unterscheiden sich in den unterst tzten VPN Techniken den Betriebsmodi der maximalen Anzahl gleichzeitiger Verbindungen oder dem zu gesicherten verschl sselten Datendurchsatz Bei den Betriebsmodi handelt es sich um die Anzahl der Endpunkte auf beiden Seiten des gesicherten Tunnels n m bzw Site to Site 1 1 alias End to End und 1 n im so genannten Roadwarrior Szenario Je nach verwendetem VPN Verfahren werden unterschiedliche Modi unterst tzt VPNs k nnen auf mehreren OSI Schichten realisiert werden Auf Schicht 2 kann PPP mit Verschl sselung PPTP und L2TP eingesetzt werden IPSec ist der bekannteste Ver treter der Schicht 3 Auf Anwendungsebene k nnen Tunnel mit SSL bzw TLS oder mit SSH aufgebaut werden
237. zweigt wurde fort F r die vorgegebenen Systemketten kann eine Standardentscheidung eingestellt werden die sich auch auf die jeweils verkn pften benutzerdefinierten Ketten auswirkt IP FireWall arbeitet mit 32 durchnummerierten Sets die jeweils 65535 Regelbl cke unterscheiden k nnen bietet daf r aber nur ein gemeinsames Regelwerk f r alle Flussrichtungen an Mehrere Regeln k nnen pro Regelnummer angegeben werden Sie werden dann sequentiell in der Reihenfolge ihrer Erstellung abgearbeitet ber das Schl sselwort skipto kann der Benutzer zu einer weiter vorne liegenden Regel nummmer verzweigen wodurch die Abarbeitung von unzutreffenden Regeln umgan gen werden kann Sets k nnen manuell ein und ausgeschaltet werden Die Regel nummer 65535 im letzten Set bernimmt die Rolle einer default policy Die Konfiguration des IPFilters erlaubt es gleichzeitig eine aktive und eine in aktive Regelliste anzulegen was die unterbrechungsfreie Pflege bzw den atomaren Austausch des Regelwerks erm glicht Eine Besonderheit bei IPF ist die Reihenfolge der Regelbearbeitung die von vorne nach hinten durchl uft wobei die letzte passende Regel angewendet wird ber das Schl sselwort quick kann bei bereinstimmung der Bedingungen die Anwendung der aktuellen Regel erzwungen werden Regeln k nnen auf mehreren Ebenen hierarchisch gruppiert werden indem die einer Gruppe zu geordneten Regeln Schl sselwort group ber eine Kopfregel head angesprungen

Entwicklung einer allgemeinen Teststrategie für zustandsbehaftete

Contents

Download Pdf Manuals

Related Search

Related Contents

Entwicklung einer allgemeinen Teststrategie f&uuml;r zustandsbehaftete

Contents

Download Pdf Manuals

Related Search

Related Contents

Entwicklung einer allgemeinen Teststrategie für zustandsbehaftete