Entwurf und Implementierung von Regelstufen für eine
Werbung
Bachelor-Arbeit Entwurf und Implementierung von Regelstufen für eine Hardwarefirewall Vladyslav Altman 23. September 2008 i Inhaltsverzeichnis Inhaltsverzeichnis ii Abkürzungsverzeichnis iv Abbildungsverzeichnis iv Tabellenverzeichnis v Aufgabenstellung vi 1. Einleitung 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2. Stand der Technik 2.1. Grundlagen . . . . . . . . . . . . . . 2.2. Netzwerksicherheit . . . . . . . . . . 2.3. Firewall . . . . . . . . . . . . . . . . 2.4. Firewalltypen . . . . . . . . . . . . . 2.4.1. Paketfilter . . . . . . . . . . . 2.4.2. Stateful Packet Inspection . . 2.4.3. Application Layer Firewall . . 2.4.4. Network Address Translation 2.4.5. Weitere Funktionen . . . . . . 2.5. Intrusion Detection Systeme . . . . . 2.6. Anforderungen an moderne Firewalls 2.7. iptables/Netfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 5 6 8 8 8 9 9 10 10 12 14 3. Regelstufen im Secure Access Node 3.1. Konzept . . . . . . . . . . . . . . . . 3.2. Modellrealisierung . . . . . . . . . . . 3.2.1. Aufbau der Regelstufen . . . . 3.2.2. Arbeitsweise einer Regelstufe 3.3. IP-Antispoofing Regelstufe . . . . . . 3.3.1. Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 21 24 24 25 30 30 Inhaltsverzeichnis 3.3.2. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Source- und Destination-MAC Regelstufen . . . . . . . . . . . . . . . . . 3.5. Source- und Destination-IP Regelstufen . . . . . . . . . . . . . . . . . . . 4. Auswertung der Ergebnisse ii 32 35 35 37 5. Diskussion 40 5.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Literaturverzeichnis A. Anhang I II iii Abkürzungsverzeichnis ARP . . . . . . . . . . . . . . . . . . . . BRAS . . . . . . . . . . . . . . . . . . DNS . . . . . . . . . . . . . . . . . . . . DoS . . . . . . . . . . . . . . . . . . . . . DSLAM . . . . . . . . . . . . . . . . . FIFO . . . . . . . . . . . . . . . . . . . FPGA . . . . . . . . . . . . . . . . . . FSM . . . . . . . . . . . . . . . . . . . . FTP . . . . . . . . . . . . . . . . . . . . HIDS . . . . . . . . . . . . . . . . . . . HTTP . . . . . . . . . . . . . . . . . . IDS . . . . . . . . . . . . . . . . . . . . . IP . . . . . . . . . . . . . . . . . . . . . . ISP . . . . . . . . . . . . . . . . . . . . . MAC . . . . . . . . . . . . . . . . . . . MSRPC . . . . . . . . . . . . . . . . . NAPT . . . . . . . . . . . . . . . . . . NAT . . . . . . . . . . . . . . . . . . . . NeRS . . . . . . . . . . . . . . . . . . . NIDS . . . . . . . . . . . . . . . . . . . OSI . . . . . . . . . . . . . . . . . . . . . P2P . . . . . . . . . . . . . . . . . . . . . POP . . . . . . . . . . . . . . . . . . . . QoS . . . . . . . . . . . . . . . . . . . . . RSM . . . . . . . . . . . . . . . . . . . . SecAN . . . . . . . . . . . . . . . . . . SMTP . . . . . . . . . . . . . . . . . . SPoF . . . . . . . . . . . . . . . . . . . SQL . . . . . . . . . . . . . . . . . . . . TCP . . . . . . . . . . . . . . . . . . . . TLV . . . . . . . . . . . . . . . . . . . . URL . . . . . . . . . . . . . . . . . . . . VLAN . . . . . . . . . . . . . . . . . . VoIP . . . . . . . . . . . . . . . . . . . . WL . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol Broadband Remote Access Server Domain Name System Denial of Service Digital Subscriber Line Access Multiplexer First In – First Out Field Programmable Gate Array FIFO State Machine File Transfer Protocol Host Intrusion Detection System Hypertext Transfer Protocol Intrusion Detection System Internet Protocol Internet Service Provider Media Access Control Microsoft Remote Procedure Call Network Address Port Translation Network Address Translation Next Rule Set Network Intrusion Detection System Open Systems Interconnection Peer-to-Peer Post Office Protocol Quality of Service Read State Machine Secure Access Node Simple Mail Transfer Protocol Single Point of Failure Structured Query Language Transmission Control Protocol Type-Length-Value Uniform Resource Locator Virtual Local Area Network Voice over IP White List iv Abbildungsverzeichnis 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. Ethernetframe nach IEEE 802.3 . . . . . . . Internet Datagram Header . . . . . . . . . . Firewall . . . . . . . . . . . . . . . . . . . . NIDS leitet gesamten Netzwerkverkehr durch NIDS erhält eine Kopie von Traffic . . . . . Failoverbetrieb . . . . . . . . . . . . . . . . Load Balancing . . . . . . . . . . . . . . . . Aufbau von iptables . . . . . . . . . . . . . . Durchlaufen der Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . sich hindurch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 7 11 12 13 14 15 16 3.1. Zugangsnetzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Hardwarefirewall im Secure Access Node . . . . . . . . . . . . . . . . . . 3.3. Struktur der Konfigurationsdaten . . . . . . . . . . . . . . . . . . . . . . 3.4. Regelstufenflussdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5. Regelstufenaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6. Grundstruktur eines Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . 3.7. Aufbau des Rule Set Headers . . . . . . . . . . . . . . . . . . . . . . . . 3.8. Struktur des Control-Feldes im Rule Set Header . . . . . . . . . . . . . . 3.9. Struktur einer Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10. Aufbau von Drop-Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11. Flussdiagramm der IP-Antispoofing Regelstufe . . . . . . . . . . . . . . . 3.12. Blockschaltbild der IP-Antispoofing Regelstufe . . . . . . . . . . . . . . . 3.13. Ruleaufbau der IP-Antispofing Regelstufe . . . . . . . . . . . . . . . . . . 3.14. Aufbau der Statistikdaten der IP-Antispoofing Regelstufe . . . . . . . . . 3.15. Aufbau der Rule bei der Source- und Destination-MAC Regelstufe . . . . 3.16. Aufbau von Drop-Data bei der Source- und Destination-MAC Regelstufe 3.17. Aufbau der Rule bei der Source- und Destination-IP Regelstufe . . . . . . 3.18. Aufbau von Drop-Data bei der Source- und Destination-IP Regelstufe . . 19 20 20 23 24 25 26 26 27 29 31 32 34 35 35 36 36 36 v Tabellenverzeichnis 3.1. Werte für das Type-Feld der Konfigurationsframes . . . . . . . . . . . . . 3.2. Mögliche FlowID-Parameter für den Parser . . . . . . . . . . . . . . . . . 3.3. Dropidentifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 21 29 4.1. Testfälle und Ergebnisse für die IP-Antispoofing Regelstufe . . . . . . . . 4.2. Taktfrequenzen und Ressourcenverbrauch der Regelstufen . . . . . . . . . 38 39 A.1. A.2. A.3. A.4. Testfälle Testfälle Testfälle Testfälle und und und und Ergebnisse Ergebnisse Ergebnisse Ergebnisse für für für für Source-MAC Regelstufe . . . Destination-MAC Regelstufe Source-IP Regelstufe . . . . Destination-IP Regelstufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III . IV . V . VI Aufgabenstellung Entwurf und Implementierung von Regelstufen für eine Hardwarefirewall Seit mehreren Jahren steigt die Zahl der Internetbreitbandanschlüsse. Damit einhergehend erhöht sich das Datenvolumen und die Gefahr, von Viren-, Spam- und PhishingAttacken betroffen zu sein. Vielen Internetnutzern sind diese Gefahren bewusst. Mit einer Vielzahl von Programmen ergreifen sie Präventionsmaßnahmen. Dazu gehören Virenscanner, Firewalls oder auch Intrusion Detection Systems (IDS). Die dabei zu erfüllenden Konfigurationsaufgaben sind relativ komplex und führen bei Fehlkonfiguration zu einem großen Gefahrenpotential. Vor diesem Hintergrund ist es vorteilhaft, grundlegende Sicherheitsfunktionen bereits im Zugangsbereich bereitzustellen, zu denen z.B. Paketfilter gehören. Ein weit verbreitetes Linux-Werkzeug zur Paketfilterung und zum Schutz des Nutzers ist iptables. Diese Software kann vom Nutzer eingesetzt werden, um vorkonfigurierte Regeln auf Datenframes anzuwenden und damit Bedrohungen zu detektieren und Gegenmaßnahmen einzuleiten. Im Rahmen dieser Arbeit soll der Nutzer von Konfigurationsaufgaben entlastet bzw. das Netzwerk vor schädlichen Einflüssen bewahrt werden. Die dazu notwendige Sicherheitsstufe wird sich im Zugangsnetzwerk unter der Kontrolle des Netzbetreibers befinden. Da das Datenvolumen innerhalb eines Zugangspunktes um ein Vielfaches größer ist als beim Endkunden, reichen Software-Lösungen nicht aus. Die anfallenden Datenmengen können nur durch Hardwaresysteme verarbeitet werden. Ein solches Hardwaresystem besteht aus Regelstufen, in denen Regeln ähnlich wie bei iptables abgearbeitet werden. Diese Arbeit zielt darauf ab, die Netzwerksicherheit im Zugangsnetz zu etablieren. Grundvoraussetzung ist eine Einarbeitung in das Thema Netzwerksicherheit, Anforderungen an moderne Firewalls und Erkennungsmechanismen von IDS. Zur Erfüllung des praktischen Teils dieser Arbeit ist es weiterhin erforderlich, sich in die Funktionsweise von iptables einzuarbeiten. Mit dem erlangten theoretischen Wissen soll eine generische Regelstufe für eine Hardwarefirewall entwickelt und in VHDL implementiert werden. Desweiteren soll mindestens eine spezifische Regelstufe implementiert werden, die ähnlich wie bei iptables Regeln verarbeiten kann. Zusammenfassend sind folgende Aufgaben zu lösen: • Einarbeitung in Sicherheitsprinzipien von Firewalls und Erkennungsmechanismen von Intrusion Detection Systems • Ausarbeitung eines Konzeptes für eine generische Regelstufe und Implementierung dieser Regelstufe in VDHL • Funktionale Verifikation der Regelstufe durch Implementierung zweier konkreter Beispiele • Ausführliche Dokumentation aller Arbeitsschritte Betreuer: Dipl.-Ing. Jens Rohrbeck Tag der Ausgabe: 04.08.2008 Tag der Abgabe: 06.10.2008 Prof. Dr. D. Timmermann Betreuender Hochschullehrer 1 1. Einleitung Das Internet ist ein weltweites Netzwerk, das Austausch der Daten und Informationen erlaubt. Heutzutage sind mehr als 1 Mrd. Nutzer ans Internet angeschlossen [4]. Es wird eine Vielzahl an Diensten angeboten wie z.B. E-Mail, VoIP, Gaming, Tauschbörsen usw. Jeder Rechner, der sich im Netwerk befindet, kann im Prinzip von jedem anderen Rechner erreicht werden. Die Daten, die zwei Rechner austauschen, können auch getarnte schädliche Programme enthalten - Viren. Fast jedes E-Mail-Konto leidet unter unerwünschter Werbung und einige Interneitseiten versuchen an private Nutzerdaten über gefälschte WWW-Adressen zu gelangen. Deswegen gibt es viele unterschiedliche Maßnahmen, die den Nutzer vor schädlichen Einflüssen bewahren. 1.1. Motivation Die Anzahl der Internetnutzer steigt immer weiter an [3]. Mit der rasanten Entwicklung des Internets steigt auch das Datenvolumen, das über das weltweite Netzwerk transportiert wird. Dieses kann auch Gefahren wie Viren, Spam und Phishing mit sich bringen. Viele Internetnutzer sind sich dieser Gefahren bewusst und setzen Präventionsmaßnahmen ein. Dazu gehören Virenscanner, Firewalls oder auch Intrusion Detection Systeme (IDS). Manche solcher Programme haben jedoch eine Menge an Konfigurationen, die vom Nutzer selbst gemacht werden sollen. Das kann oft umständlich sein sowie Kenntnisse im Sicherheitsbereich erfordern. Fehlkonfiguration führt zu einem großen Gefahrenpotential. Vor diesem Hintergrund ist es vorteilhaft, grundlegende Sicherheitsfunktionen bereits im Zugangsbereich bereitzustellen. Diese befinden sich im Zugangsnetzwerk und werden von Internetbetreibern bedient. Dadurch werden Internetnutzer vom Konfigurationsaufwand entlastet und das gesamte lokale Netwerk vor schädlichen Einflüssen geschützt. 1.2. Aufbau der Arbeit Diese Arbeit ist der Netzwerksicherheit, den Anforderungen an moderne Firewalls und Erkennungsmechanismen von IDS gewidmet. In Kapitel 2 werden verschiedene Ansätze für Firewalls und Intrusion Detection Systeme untersucht. Speziell wird auf die unter Linux verwendete Firewall mit iptables eingegangen. In Kapitel 3 wird eine eigene Hardwarelösung für die Firewall präsentiert, da Hardware einen höheren Datendurchsatz 1. Einleitung 2 ermöglicht. Diese nutzt ähnlich wie iptables Regelstufen. Zunächst wird ein allgemeingültiges Konzept einer Regelstufe vorgestellt und anschließend das spezielle Konzept für IP-Anti-Spoofing, Source-MAC, Destination-MAC, Source-IP und Destination-IP Regelstufe. Die Regelstufen werden in VHDL implementiert. In Kapitel 4 werden die Ergebnisse ausgewertet und in Kapitel 5 diskuttiert. 3 2. Stand der Technik 2.1. Grundlagen Bevor Informationen und Daten über das Netz geschickt werden, werden sie in Ethernetframes unterteilt. Die Struktur von Ethernetframes ist im Standard IEEE 802.3 festgelegt. Jeder Ethernetframe besitzt den Aufbau, wie in Abbildung 2.1 dargestellt. Die maximale Größe der Nutzdaten ist auf 1500 Byte maximal und 46 Byte minimal beschränkt. Die Erklärung einzelner Felder: • Zieladresse: Hardwareadresse des Empfängers • Quelladresse: Hardwareadresse des Absenders • Typ: Protokoll der nächsthöheren Schicht, z.B. Internet Protocol (IP) • Daten: Nutzdaten • Prüffeld: CRC-Prüfsumme Abbildung 2.1.: Ethernetframe nach IEEE 802.3 Das meist verwendete Protokoll zur Datenübertragung über das Internet ist Internet Protocol (IP). Heutzutage gibt es zwei Versionen IPv4 und IPv6. Im Rahmen dieser Arbeit wird nur IPv4 betrachtet. IP stellt die erste physikalisch unabhängige Schicht dar. Jedem Rechner wird eine IP-Adresse zugeteilt, durch die er eindeutig in einem Netzwerk identifiziert werden kann. Mit Hilfe von Netzmasken können Teilnetze gebildet werden. Die logische Adressierung stellt eine Grundlage fürs Routing dar und ist somit eine 4 2. Stand der Technik Abbildung 2.2.: Internet Datagram Header Grundlage für das Internet. Die Spezifikation von IP ist durch Standard RFC 791 festgelegt. In Abbildung 2.2 ist der IP-Header dargestellt. Das Versionsfeld bezeichnet die Version des IP. Im Fall von IPv4 ist das eine dezimale 4. IHL steht für Internet Header Length und gibt die Länge des Headers in 32 Bit Worten an. Minimaler Wert für die Länge des Headers ist 5. Type of Service ermöglicht die Angabe abstrakter Parameter für die gewünschte Quality of Service (QoS). Total Length ist die Länge des Pakets, gemessen in Bytes, einschließlich Internet Header und Daten. Alle Hosts müssen Datagramme mit einer Länge von mindestens 576 Bytes verarbeiten können. Der Identification-Wert wird vom Absender zugewiesen, um fragmentierte Teile einem Paket zuordnen zu können. Flags werden auch für die Fragmentierung benötigt und besagen z.B., ob ein Paket fragmentiert werden darf oder nicht oder ob es schon fragmentiert wurde. Fragment Offset wird ebenfalls für die Fragmentierung benötigt. Er bezeichnet die Position im Datagramm, an der das Fragment eingefügt werden soll. Die drei oben genannten Felder sind für das Zusammensetzen von zuvor fragmentierten IP-Datenpaketen bestimmt. Time to Live bezeichnet die Lebensdauer eines Pakets im Internet. Jede Station verringert diesen Wert um 1. Wenn der Wert 0 erreicht, wird das Paket verworfen. Das verhindert, dass die Pakete im Netz endlos herumkreisen. Das Protocol-Feld gibt das Protokoll der nächsthöheren Schicht an. Header Checksum ist die Prüfsumme des Headers. Source Address ist die logische Adresse des Absenders und Destination Address - die logische Adresse des Empfängers. Options ist ein variables Feld, um mögliche Zusatzinformationen hinzuzufügen. Es muss aber die maximal mögliche Länge des IP-Headers von 60 Byte berücksichtigt werden. Falls Options kein ganzzahliges Vielfaches von 32 Bit sind, werden Padding Zeros eingefügt. 2. Stand der Technik 5 2.2. Netzwerksicherheit Netzwerksicherheit ist ein wichtiger Aspekt für Banken, Unternehmen sowie Internetnutzer. Sie umfasst alle Maßnahmen zur Planung, Ausführung und Überwachung der Sicherheit in Netzwerken [12]. Eine der wichtigsten Aufgaben besteht darin, vertrauliche Daten vor unbefugten Zugriffen zu schützen. Wegen des Ausbaus der Kommunikationsverbindungen sowie ständiger technologischer Weiterentwicklung müssen Sicherheitsmaßnahmen immer gewartet und angepasst werden. Anwender müssen die Ressourcen des Netzwerks erst nach einer Identifizierung und einer anschließenden Authentifizierung und Autorisierung nutzen können. Potentieller Datenverlust durch fehlerhafte Software, Fehlbedienung, Fahrlässigkeit oder Altersverschleiß der Hardware wird durch eine Datensicherung verhindert, die dann separat gelagert wird. Sicherheitslücken in Software können durch das rechtzeitige Einspielen von Software-Aktualisierungen entgegengewirkt werden. Um die Sicherheit eines Netzwerks zu gewährleisten, ist der Einsatz von Software- und Hardware-Firewalls unumgänglich. So vielfältig wie Netze sind, so vielfältig sind auch die Angriffsmöglichkeiten auf diese. In vielen Fällen werden mehrere Angriffe kombiniert, um ein Ziel zu erreichen. Die Angriffe können sowohl von außerhalb des Netzwerks, z.B. aus dem Internet, als auch von innerhalb des Netzwerkes kommen. Angriffe von außen richten sich meist gegen Programme, die Netzwerkdienste anbieten. Hierbei zielen viele Angriffe auf Schwächen in der Software ab. Eine bekannte Angriffsmöglichkeit ist der Pufferüberlauf. Dabei wird über das Fassungsvermögens des Speichers hinausgeschrieben, wobei Daten oder Kontrollinformationen überschrieben werden. Dabei kann es zum Absturz des betreffenden Programms, zur Verfälschung von Anwendungsdaten oder zur Beschädigung von Datenstrukturen der Laufzeitumgebung des Programms führen. Durch Letzteres kann die Rücksprungadresse eines Unterprogramms mit beliebigen Daten überschrieben werden. Dadurch kann übermittelter Maschinencode mit den Privilegien des für den Pufferüberlauf anfälligen Prozesses ausgeführt werden. Auch eine andere Angriffsmethode ist möglich. Falls keine gegenseitige Authentifizierung durchgeführt wird, täuscht ein Angreifer dem Kommunikationspartner jeweils den anderen vor. Das Fälschen von Absenderadresse zum Verschleiern der Herkunft von Paketen wird Spoofing genannt. Im Allgemeinen existieren [5]: • ARP-Spoofing (Address Resolution Protocol Spoofing) • DNS-Spoofing (Domain Name Server Spoofing) • IP-Spoofing (Internet Protocol Spoofing) • MAC-Spoofing (Media Access Control Spoofing) • Mail-Spoofing • URL-Spoofing (Uniform Resource Locator Spoofing). 2. Stand der Technik 6 Das Ziel des ARP-Spoofing ist es, den ARP-Cache zu manipulieren. Dazu manipuliert der Angreifer den Cache seines Opfers durch den Versand falscher Zuordnungsinformationen. Verläuft sein Angriff erfolgreich, werden von nun an alle Pakete vom Ziel an die Hardwareadresse des Angreifers geleitet. Als DNS-Spoofing wird ein Angriff bezeichnet, bei dem es einem Angreifer gelingt, die Zuordnung zwischen einer URL und der zugehörigen IP-Adresse zu fälschen. IP-Spoofing bezeichnet das Versenden von IP-Paketen mit gefälschter Quell-IP-Adresse. MAC-Spoofing bezeichnet ähnlich wie IP-Spoofing das Fälschen der MAC-Adresse des Absenders. Unter Mail-Spoofing ist das Benutzen gefälschter Email-Adressen zu verstehen. URL-Spoofing bezeichnet das Fälschen von URLs in den Webpages oder HTML-Emails. Eine weitere Attacke wird durch einen Überlastungsangriff, einer sogenannten Denial of Service (DoS) Attacke, realisiert. Das Ziel ist es, einen bestimmten Dienst des attackierten Rechners mit Anfragen zu überschwemmen, sodass dieser Rechner lahmgelegt oder vom Netz getrennt wird. Eine Möglichkeit auf private Informationen des Nutzers zu kommen, erlaubt Phishing. Eine dem Nutzer bekannte Internetseite, auf der die Eingabe von privaten Informationen wie z.B. Login und Passwort notwendig sind, wird optisch vorgetäuscht. Hier wird die Gutgläubigkeit der Nutzer ausgenutzt. Angriffen von innen geht meist das Herunterladen schädlicher Programme voraus. Diese tarnen sich in sinnvollen Tools und Programmen. Ein solches Programm heißt Trojaner, in Analogie zum Trojanischen Pferd. Nach Ausführung des Programms wird eine sogenannte Backdoor eingerichtet, durch die der Angreifer den betroffenen Rechner manipulieren kann. Um eine Firewall zu umgehen, kann das Programm die Verbindungen eines anderen vertraunswürdigen Programms nutzen wie z.B. Browser. Diese Methode wird Durchtunnelung genannt und stellt eine große Gefahr dar. 2.3. Firewall Die Firewall ist eine der Maßnahmen, die einen Rechner oder eine Gruppe von Rechnern von äußeren Einflüßen schützen soll. Die Firewall überwacht den durch sie hindurch laufenden Datenverkehr und entscheidet anhand festgelegter Regeln, ob bestimmte Netzwerkpakete durchgelassen werden oder nicht. Auf diese Weise versucht die Firewall, das private Netzwerk bzw. das Netzsegment vor unerlaubten Zugriffen zu schützen [2]. Die Aufgabe einer Firewall besteht nicht darin, die Angriffe zu erkennen oder zu vermeiden, sondern lediglich die Pakete nach Quell- und Zieladresse, Quell- und Zielport, Diensten usw. zu filtern. Für das Aufspüren von Angriffen sind so genannte IDS-Module zuständig, welche durchaus auf einer Firewall aufsetzen können. Es existieren zwei Arten von Firewalls: Hardware- und Softwarefirewall. Eine Softwarefirewall ist ein Programm, das auf einem Rechner läuft und eine Ergänzung für ein Betriebssystem zum Schutz vor äußeren Einflüssen darstellt. Diese läuft meistens auf einem Host und trägt nur zu seiner Sicherheit bei. Der Nachteil besteht darin, dass 7 2. Stand der Technik Abbildung 2.3.: Firewall Firewallsoftware selber das Angriffsziel sein kann. Der Angreifer kann versuchen, das Programm zum Abstürz zu bringen oder den Firewalldienst zu beenden, seine Mechanismen zu umgehen, um einen vollen Zugriff auf den Rechner zu erreichen. Der Vorteil der Softwarefirewall besteht darin, dass sie weiß, welche Applikation über das Netzwerk kommunizieren will. Dieser Anwendung kann der Zugriff erlaubt oder verweigert werden. Somit sind applikationsspezifische Filter möglich [11]. Eine weitere mögliche Funktion ist das Sandboxing. Die Software wird vom Rest des Systems abgeschirmt. Sie kann einerseits keinen Schaden anrichten, aber andererseits können die Wirkungen der Software aufgezeichnet werden. Einem Programm, das in einer Sandbox läuft, werden Zugriffe auf bestimmte Systemressourcen verweigert. Es soll dadurch verhindert werden, dass eine kompromittierte Anwendung Schaden am Betriebssystem anrichtet. Die meisten Softwarefirewalls verfügen über automatische Aktualisierung, sobald ein Update vom Hersteller zur Verfügung gestellt wird. Das hilft die Firewall immer auf dem aktuellsten Stand zu halten. Eine Hardwarefirewall hat sowohl eine Hardware- als auch eine Softwarekomponente. Die Hardware stellt die Funktionalität der Firewall dar und die Software bietet die Konfigurationsmöglichkeit an. Der Vorteil der Hardware ist, dass sie höhere Geschwindigkeiten bei der Verarbeitung der Daten ermöglicht. Der Erwerb der Hardware ist jedoch oft mit höheren Kosten verbunden. Außerdem soll die Hardwarelösung flexibel sein, um die Fire- 2. Stand der Technik 8 wall an die sich ändernden Anforderungen anzupassen. Daher ist eine Implementierung auf einer FPGA-Plattform sinnvoll. Die meisten Firewalls, die in Zugangsnetzen eingesetzt werden, verfügen über Network Address Translation (NAT). Zusätzlich dazu werden temporäre IP-Adressen vergeben. Diese sind nur für eine Sitzung gültig. Oft werden die Firewalls von Internet Service Provider (ISP) dazu benutzt, um bestimmte Ports zu sperren. Mit wachsender Popularität der Tauschbörsen setzten die ISPs auch Deep Packet Inspection (Content Filter) ein, um P2P-Traffic zu reduzieren oder ganz zu blockieren. 2.4. Firewalltypen Eine Firewall kann auch begrenzte Funktionalität anbieten. Im Weiteren werden unterschiedliche Firewalltypen untersucht. 2.4.1. Paketfilter Der wichtigste Firewalltyp ist der Paketfilter. Er stellt die Basisfunktion jeder Firewall dar. Ein Paketfilter untersucht jedes einzelne Paket und vergleicht, ob eine Regel darauf anwendbar ist. Die Filterung kann nach folgenden Kriterien geschehen: • Quell- und Ziel-MAC Adresse • Quell- und Ziel-IP-Adresse • Protokoll • Quell- und Zielport Die Entscheidung basiert nicht auf dem Inhalt des Paketes. Alle Regeln werden vom Firewall-Administrator festgelegt und sind statisch. Ein Paketfilter ist „stateless“, wenn er die aktuellen Verbindungen nicht überwacht, sondern für jedes Paket einzeln entscheidet, ob es weitergeleitet werden soll oder nicht. 2.4.2. Stateful Packet Inspection Bei der stateful Inspection wird der Status einer Verbindung berücksichtigt. Somit kann ein Paket einer Verbindung zugeordnet werden. Das Weiterleiten eines Pakets ist davon abhängig, welche Pakete vorher untersucht wurden. Die Regeln werden hier dynamisch erzeugt, abhängig vom Verbindungsstatus. Solche Firewall bietet mehr Schutz als ein einfacher Paketfilter. Um einer Verbindung einen Status zuzuordnen, werden auch Flags und IP-Header-Optionen geprüft. Die Paketfilter-Firewall kann z.B. über die Flags die Richtung des TCP-Verbindungsaufbaus unterscheiden [1]. 2. Stand der Technik 9 2.4.3. Application Layer Firewall Application Layer Firewall, auch Proxy Firewall genannt, arbeitet auf dem Layer 7 des OSI Schichtenmodells. Ihre wichtigste Aufgabe ist das Filtern von Applikationsdaten aus den Netzwerkpaketen. Dieses Verfahren sorgt für doppelte Sicherheit: Die Verbindung wird nur aufgrund der definierten Sicherheitsregeln zugelassen und muss darüber hinaus die korrekten Befehle und Spezifikationen des Anwendungsprotokolls ausführen. Meistens ist es aber nur möglich, wenn der Inhalt nicht verschlüsselt ist. Die Erkennung erfolgt durch die Suche nach bestimmten Mustern. Es ist daher möglich, Schadsoftware wie z.B. Viren, Trojaner aufzuspüren, ActiveX oder JavaScript aus angeforderten Webseiten herauszufiltern, unerwünschte Protokolle zu erkennen. Es erlaubt auch das Filtern von vertraulichen Informationen oder Spam-Mails, das Sperren von unerwünschten Webseiten anhand von Schlüsselwörtern. Die Erkennung von Mustern ist allerdings sehr komplex. Vor allem, weil die Daten über mehreren Paketen verteilt sein können. Es kann also vorkommen, dass Daten aus mehreren Paketen zusammengesetzt werden müssen, um den Inhalt zu interpretieren. Die meisten Application Layer Firewalls besitzen integrierte Proxys. Diese erlauben, die interne Struktur eines lokalen Netzes zu verbergen. Die Rechner fordern die Informationen beim Proxy an und dieser holt sie bei Bedarf aus dem Internet oder direkt aus seinem Cache. Nach außen sind also nur die Adresse und die Ports des Proxys sichtbar. Da die Inhalte dabei vollständig auf dem Proxy zwischengespeichert werden, können sie entsprechend analysiert werden, z.B. durch Virenscanner und Content-Filter. Firewallsysteme unterscheiden sich stark in Anzahl und Art der von Proxys unterstützten Protokollen (z. B. FTP, DNS, HTTP, SMTP, SQL*Net, POP3, MSRPC usw.) sowie ggf. in den vorhandenen Konfigurationsmöglichkeiten für diese Proxys. Ohne Proxy-Konzept sind die Möglichkeiten der Protokollauswertung sehr begrenzt, da sich ein aktives Eingreifen in den Datenstrom auf Verbindungsabbruch/Blacklisting beschränkt [9]. 2.4.4. Network Address Translation Network Address Translation ist eine Möglichkeit, über einen Router bzw. eine IPAdresse ein lokales Netzwerk mit dem Internet zu verbinden. Die Übersetzung der Adresse erfolgt mit Hilfe des Ports. Der Router ordnet bei dem Verbindungsaufbau einen noch freien Port eine IP-Adresse und einen Port eines lokalen Hosts zu. Nach außen ist nur eine einzige IP-Adresse sichtbar. Wenn ein Paket den Router erreicht, wird anhand des Ports, auf den das Paket geschickt wurde, ein Rechner im lokalen Netzwerk bestimmt, an den das Paket weitergeleitet wird. Im Unterschied zu einem Proxy werden hierbei die Pakete einfach nur weitergeleitet und können inhaltlich nicht analysiert werden. 2. Stand der Technik 10 2.4.5. Weitere Funktionen Eine wichtige Funktion ist IP-Anti-Spoofing. Dabei wird geprüft, ob eine IP-Adresse zu einer MAC-Adresse gehört. Da die Filterung sich wesentlich an den IP-Adressen orientiert, muss so gut wie möglich sichergestellt werden, dass diese nicht gefälscht sind. Die gefälschten IP-Pakete werden protokolliert und verworfen. Dadurch wird vermieden, dass ein Angreifer einen anderen Rechner vortäuscht, um den Datenverkehr zwischen zwei Hosts in einem Computernetz abzuhören oder zu manipulieren. Für erhöhte Sicherheit kann die Authentifizierung von Bedeutung sein. Da der Filterung anhand von IP-Adressen wegen potenziellem IP-Spoofing niemals vollständig vertraut werden kann, bieten manche Firewalls die Möglichkeit, sich authentifizieren zu lassen und erst dann bestimmte Regeln zeitbeschränkt freigeschaltet zu bekommen. Die meisten Firewalls sind in der Lage, während der Paketverarbeitung Log-Daten zu sammeln. Diese Log-Daten lassen sich zu Statistiken zusammenfassen. Diese helfen, die Regeln besser anzupassen oder Fehler aufzuspüren und zu korrigieren. 2.5. Intrusion Detection Systeme Die Aufgabe eines Intrusion Detection Systems (IDS) ist es, Benutzer zu entdecken, die sich auffällig verhalten. Es ist mit einer Alarmanlage vergleichbar, deren Aufgabe es ist, unbefugten Zugriff zu melden oder ihn zu blockieren. Das IDS hält nach unautorisierten Versuchen Ausschau, sich Zugang zu einem System zu verschaffen, zulässige Rechte auf einem autorisierten System zu überschreiten oder die Verfügbarkeit eines Systems zu verringern, sei es von innerhalb der Organisation aus oder über das Internet [10]. Intrusion Detection Systeme müssen in der Lage sein, einen zulässigen Datenverkehr von einem unerwünschten zu unterscheiden. Es gibt eine Vielzahl an Methoden und Herangehensweisen um den verdächtigen Traffic zu detektieren. Grundsätzlich sind zwei IDS Typen zu unterscheiden: Signatur-basierte Erkennung und Anomalie-basierte Erkennung. Die Signatur-basierte Erkennung ist in der Lage, Angriffe zu erkennen, die eine bestimmte bekannte Zeichenfolge haben oder nach einem bekannten Muster ablaufen. Diese sind sehr effektiv gegen bereits bekannten Angrifftechniken, erfordern jedoch eine ständige Aktualisierung, um das System vor neuen Angriffsmethoden schützen zu können. In der Realität gibt es immer eine Zeitlücke nachdem eine neue Angriffstechnik zum ersten Mal entdeckt und bevor eine Signatur dafür abgeleitet wurde. In dieser Zeit ist das IDS nicht in der Lage, die neue Gefahr zu erkennen. Die Anomalie-basierte Erkennung sucht nach ungewöhnlichem Verhalten im Netzwerk. Zuerst muss ein Normalzustand gemessen werden, wie z.B. die Bandbreite, welche Protokolle und Ports benutzt werden, welche Geräte miteinander kommunizieren. Ein Datenstrom, welcher sich von dem normalen Zustand/Verhalten unterscheidet, wird als verdächtig angesehen. Das Hauptproblemm ist, den Normalzustand für ein System oder Netzwerk eindeutig zu bestimmen. Der Vorteil solcher IDS besteht darin, dass sie auch 2. Stand der Technik 11 unbekannte Angriffstechniken erkennen können. Je nachdem, was ein IDS überwacht, wird es zwischen Network Intrusion Detection Systeme (NIDS) und Host Intrusion Detection Systeme (HIDS) unterschieden. NIDS werden an wichtigen Stellen des Netzes platziert, um evtl. das ganze Netz überwachen zu können (vgl. Abbildung 2.4). Es wird das gesamte ein- und ausgehendes Datenvolumen untersucht. Der Vorteil besteht darin, dass wenige NIDS das gesamte Netzwerk überwachen können, das System selber ist transparent. Der Nachteil des NIDS besteht darin, dass es zu einem Flaschenhals werden kann. Bei hoher Auslastung kann das System die Angreifer evtl. nicht erkennen oder einige Funktionen nicht nutzen. Verschlüsselter Datenverkehr kann nicht analysiert werden. In einem vollständig geswitchten Netzwerk kann es unter Umständen schwierig sein, alle Daten einzufangen, es sei denn, man konfiguriert die Switches so, dass sie eine Kopie des gesamten Datenverkehrs an einen speziellen Port für das IDS schicken (vgl. Abbildung 2.5). Abbildung 2.4.: NIDS leitet gesamten Netzwerkverkehr durch sich hindurch Im Gegensatz zu NIDS arbeitet ein HIDS auf einem Host. Es überwacht Netzwerkpakete, Verbindungsversuche oder Login-Versuche bzw. Zugriff auf wichtige Systemdateien und Veränderungen an diesen sowie Änderungen an Benutzerberechtigungen und beobachtet, was auf dem Computer passiert. Ein HIDS muss somit auf jedem zu überwachenden System installiert werden. Es erhält seine Informationen aus Log-Dateien, Kernel-Daten und anderen Systemdaten wie etwa der Registry unter Windows. Die Vorteile des HIDS sind: eine Verschlüsselung sowie ein geswitchtes Netzwerk stellt kein Problemm mehr dar. Jedoch muss es auf jedem Computer installiert und gewartet werden. HIDS können den Alarm auf einer zentralen Konsole auslösen. Der Traffic zwischen der Konsole und dem HIDS-Collector kann verschlüsselt werden oder für vollständige Sicherheit über ein 2. Stand der Technik 12 Abbildung 2.5.: NIDS erhält eine Kopie von Traffic separates Netzwerk laufen. HIDS kann selbst zum Ziel eines Angriffs werden und z.B. mit einer DoS-Attacke überschwemmt werden. Weiterhin beansprucht HIDS Ressourcen und Leistung des Rechners, auf dem es installiert ist. Die Reaktion auf einen Angriffsversuch kann passiv oder aktiv sein. Im passiven Fall wird ein Alarm ausgelöst bzw. der Netzwerkadministrator benachrichtigt, damit er auf den Angriff reagieren kann. Im aktiven Fall wird nicht nur der Administrator benachrichtigt, sondern das IDS wird selbst versuchen, den Angriff zu stoppen, indem es den Angreifer oder seine IP-Adresse blockiert. Im Extremfall kann das IDS einen Gegenangriff starten. 2.6. Anforderungen an moderne Firewalls Eine wichtige Anforderung an die modernen Firewalls ist neben dem Schutz des Netzwerks die Hochverfügbarkeit. Damit die Firewall nicht zu einem Single Point of Failure (SPoF) wird, werden verschiedene Techniken eingesetzt, um das Risiko eines Ausfalls zu reduzieren. Zu diesen gehören Load Balancing und Failoverbetrieb. Bei Failoverbetrieb wird ein Primärrechner mit einem Standby-Rechner im Hintergrund betrieben (vgl. 13 2. Stand der Technik Abbildung 2.6). Fällt der Primärrechner aus, übernimmt der Standby-Rechner seine Aufgaben. Da einer von den Rechnern abgeschaltet werden kann, während der andere läuft, ermöglicht das die Durchführung von Reparaturen oder Aktualisierungen der Software ohne Ausfall des Systems. Bei Ausfall des Primärrechners gibt es zur Übernahme seiner Aufgaben prinzipiell zwei Möglichkeiten. Die erste Möglichkeit, die Rechner synchronisieren sich im laufenden Betrieb. Dadurch können beim Ausfall die Verbindungen richtig zugeordnet werden. Die zweite Möglichkeit, sieht keine Synchronisation vor. Die Verbindungen werden beim Ausfall durch den Standby-Rechner noch einmal gegen das Regelwerk geprüft. Diese Möglichkeit ist einfacher zu realisieren, kann aber bei Protokollen, die zufälligen Ports benutzen, Probleme bereiten, da die Pakete evtl. keiner Regel zugeordnet werden können. In dem Fall werden die Pakete verworfen. Abbildung 2.6.: Failoverbetrieb Mit Load Balancing wird die Last auf mehrere Firewalls verteilt (vgl. Abbildung 2.7). Ein Load Balancer überwacht die Auslastung und Bereitschaft der Firewalls. Antwortet eine Firewall nicht, wird die Anfrage an eine andere geschickt. Der Load Balancer wird auch redundant aufgebaut, um die Verfügbarkeit bei seinem Ausfall nicht zu reduzieren. Bei hohem Datenverkehrsaufkommen wird also eine einzige Firewall nicht mit dem ganzen Traffic überschwemmt. Genau wie beim Failoverbetrieb gibt es bei Load Balancing sowohl eine synchrone als auch eine asynchrone Variante. In unterschiedlichen Bereichen sind verschiedene Sicherheitsanforderungen gefragt. Bei Militär und Banken sind diese am höchsten. Deswegen kommen hier mehrstufige Sicherheitslösungen zum Einsatz. Ein Paket passiert mehrere, hintereinander geschaltete Firewalls, die oft gleiche Regeln darauf anwenden. Die Hardware- bzw. Softwarekomponenten 14 2. Stand der Technik Abbildung 2.7.: Load Balancing sind unterschiedlich implementiert, besser von unterschiedlichen Teams unabhängig voneinander entwickelt. Das hilft, die systematischen Programmier- und Produktionsfehler unwirksam zu machen. Beim Einsatz von Open-Sourceprodukten sind eigenes Audit und Übersetzung des Quellcodes hilfreich, um evtl. Hintertüren auszuschließen. 2.7. iptables/Netfilter Netfilter ist die Software zum Filtern der Netzwerkpakete, die innerhalb des LinuxKernels implementiert ist. Die Software, die damit grundsätzlich in Verbindung kommt, ist iptables. Das Programm iptables kommuniziert mit dem Linux-Kernel und weist diesen an, Pakete nach bestimmten Regeln zu filtern. iptables übernimmt also unter anderem das Einfügen, Löschen und Manipulieren von Regeln in die Filtertabellen des Kernels sowie das Setzen der Filterpolitik. Beide bilden das Herzstück der Linux Firewall. Die Filterung ist auf dem Network, Transport und teilweise Application Layer des OSIModells möglich. Wichtige iptables Funktionen sind [8]: • stateless Packetfilterung (IPv4 und IPv6) • stateful Packetfilterung (IPv4 und IPv6) • alle Arten von Network Address Translation/Network Address Port Translation • flexible und erweiterbare Infrastruktur • Vielzahl von Modulen und Plugins 15 2. Stand der Technik Netfilter besteht aus mehreren Kernel-Modulen, die sich bei Bedarf ein- und ausschalten lassen. Netfilter und iptables gehören zum Lieferumfang aller neueren Linux-Distributionen und sind der Standard für Firewalls unter Linux. Es wird vom netfilter.org-Projekt [8] unterstützt und weiterentwickelt. Die Software unterliegt, wie der Linux-Kernel insgesamt, der GNU General Public License. Ein Paket durchläuft auf seinem Weg durch den Paketfilter sogenannte Ketten (Chains). Um bestimmte Ziele zu erreichen, sind in jeder Kette Regeln definiert. Regeln werden auf definierte Teile des Frames angewendet, wenn er durch diese Kette läuft. Die Kette ist eine Regelliste. Der Flow ist in Abbildung 2.8 dargestellt. Jede Kette (INPUT, OUTPUT, FORWARD, PRE- und POSTROUTING) entscheidet anhand von Regeln, ob ein Paket gelöscht oder akzeptiert wird. Wird es akzeptiert, dann reist es weiter durch den Paketfilter, bis es letztendlich den Rechner über den Ausgang verlassen kann. Abbildung 2.8.: Aufbau von iptables Jede Kette beinhaltet eine Checkliste von Regeln, die folgenden Aufbau besitzen: WENN (Filteroption) DANN Aktion (Löschen, Akzeptieren des Paketes) Die Regeln werden nacheinander solange durchlaufen, bis eine Regel auf das eingegangene Paket zutrifft. Wird eine passende Regel gefunden („first match“), wird die weitere Suche abgebrochen und die Aktion ausgeführt (vgl. Bild 2.9). Besagt z.B. die erste Regel, alle FTP-Verbindungen aus dem Uni-Netz zulassen, und die zweite Regel, alle FTP-Verbindungen blockieren, so werden nur die FTP-Verbindungen blockiert, die nicht aus dem Uni-Netz kommen. Werden die Regeln getauscht, dann werden alle FTPVerbindungen blockiert, da die zweite Regel nicht mehr geprüft wird, wenn die erste zutrifft. Trifft keine Regel zu, so entscheidet die Policy, was mit dem Paket geschieht. In den meisten Fällen wird das Paket verworfen. Jetzt soll noch einmal der Weg der Pakete durch den Paketfilter im Detail betrachtet werden: Nach Eingang eines Paketes an einer Netzwerkschnittstelle (a) wird dessen 16 2. Stand der Technik Abbildung 2.9.: Durchlaufen der Regeln 2. Stand der Technik 17 Zieladresse ausgewertet (Routing). Ein Paket mit Zieladresse dieses Rechners (b) wird anschließend durch die INPUT-Kette geprüft. Diese kann das Paket entweder verwerfen oder für die weitere Verarbeitung durchlassen. Wird das Paket durchgelassen, kann eine Anwendung die empfangenen Daten dem Nutzer zur Verfügung stellen. Ein lokaler Prozess (z.B. Browser) ist in der Lage, ein neues Paket (Anforderung einer Webseite) zu erzeugen und dieses ins Netzwerk zu versenden (d). Die OUTPUT-Kette leitet nach einer erfolgreichen Prüfung das Paket weiter zur gewünschten Netzwerkschnittstelle (z.B. eth0/ppp0). Kommunikationsserver oder Router verbinden meist ein inneres (privates) Netzwerk mit einem äußeren (öffentlichen) Netz, zum Beispiel dem Internet. Dafür wird die Paketweiterleitung von einer Netzwerkschnittstelle (Eingang) zu einer anderen (Ausgang) benötigt. Die FORWARD-Kette prüft in diesem Fall die Pakete, die vom inneren ins äußere Netz oder umgekehrt (e), (f) übertragen werden sollen [7]. Wie bereits erwähnt, ist mit iptables auch Network Address Translation möglich. Einige möglichen Aktionen sind: • ACCEPT - Das Paket wird durchgelassen • DROP - Das Paket wird verworfen, ohne den Absender zu benachrichtigen • REJECT - Das Paket wird verworfen und der Absender wird benachrichtigt • MASQUERADE - Die Quell-Adresse des Paketes wird durch die IP-Adresse der Schnittstelle ersetzt, auf welcher es den Rechner verlassen wird Wie der Name bereits sagt, arbeitet iptables mit Tabellen. Die Tabellen haben den Zweck, die verschiedenen Arten der Paketbehandlung auf Ketten verteilen zu können und nur die Ketten zu laden, die im Augenblick bzw. für die gestellte Anforderung benötigt werden. Deshalb erscheinen die Tabellen in Abbildung 2.8 nicht, da sie nur gruppierenden Charakter haben. Die Regeln werden entsprechend ihrer Funktion in drei Tabellen gruppiert: • filter - Die Standard-Tabelle, die immer dann verwendet wird, wenn keine Tabelle explizit angegeben wird. Diese Tabelle besteht aus den Ketten INPUT, FORWARD und OUTPUT. Eventuell lassen sich in dieser Tabelle weitere benutzerdefinierte Ketten unterbringen. • nat - Diese Tabelle ist für alle Arten von Adress-Umsetzungen oder Port-Forwarding verantwortlich und besteht aus den Ketten PREROUTING, OUTPUT und POSTROUTING. Die in dieser Tabelle befindlichen Ketten werden für jedes erste Paket einer neuen Verbindung aufgerufen und führen entsprechende Änderungen an den Port- oder IP-Adressen der Pakete durch. • mangle - In dieser Tabelle existieren die Ketten PREROUTING und OUTPUT. Hier werden spezielle Änderungen an Paketen vorgenommen, wie z.B. Änderung des Type-of-Service-Feldes oder der TCP-Flags. 2. Stand der Technik 18 Die einzelnen Tabellen existieren nur, wenn Regeln in diesen Tabellen angelegt worden sind. Entsprechend hoch ist die Effizienz eines Paketfilters, wenn z.B. nur einfache Filterfunktionen benutzt werden. Die nicht vorhandenen Tabellen müssen gar nicht durchlaufen werden [6]. 19 3. Regelstufen im Secure Access Node Wie wir im Fall von iptables/Netfilter gesehen haben, kann die Konfiguration einer Firewall für unerfahrene Internetnutzer recht kompliziert sein. Um den Nutzer zu entlasten, wollen wir eine Firewall bereits im Access Node einsetzen. Diese trägt nicht nur zur Sicherheit einzelner Nutzer bei, sondern auch des Netzwerks im Ganzen. An einem Access Node, der sich im Zugangsbereich befindet, sind mehrere Nutzer angeschlossen und somit muss er eine hohe Bandbreite gewährleisten (vgl. Abbildung 3.1). Da wir im Gi- Abbildung 3.1.: Zugangsnetzwerk gabitbereich arbeitet wollen, ist eine Softwarelösung ungeeignet. Eine Softwarefirewall wäre dafür zu langsam. Aus diesem Grund setzen wir eine Hardwarelösung ein. Diese erlaubt eine schnellere Abarbeitung der Pakete und ermöglicht somit den gewünschten Durchsatz. Der Prototyp wurde auf Xilinx Virtex-4 ML405 Board mit 2 Gbit Interfaces realisiert. Die Firewall stellt den Secure Access Node (SecAN) dar. Der interne Aufbau der Hardwarefirewall ist in Abbildung 3.2 dargestellt. Es werden am Ein- und Ausgang Sync-FIFOs zum Einsynchronisieren verwendet. Die Regelstufen befinden sich im Downstream. Der Upstream wird im Prototyp unverändert durchgeleitet, außer wenn es sich um einen Konfigurationsframe handelt. Als Konfigurationsframes für den SecAN werden typische Ethernet-Frames verwendet (vgl. Abbildung 2.1). Sie werden durch eine Software erstellt und über eine gültige Ethernet-Schnittstelle versendet. Der Demux erkennt anhand einer 3. Regelstufen im Secure Access Node 20 definierten Destination-MAC-Adresse, dass es sich bei dem aktuellen Frame um einen Konfigurationsframe handelt. Diese Frames werden durch die Hardware gesondert ver- Abbildung 3.2.: Hardwarefirewall im Secure Access Node arbeitet. Als Destination-Mac ist die „01:01:01:01:01:01“ zu verwenden. Der Ethertype entspricht „FFFF“. Im Anschluss an den Ethertype folgen in der Payload die Konfigurationsdaten. Die Konfigurationsdaten haben den Type-Length-Value-Aufbau (TLV) und werden in 8 Bit Type-, 8 Bit Length- und n Bit Value-Feld unterschieden. Die Grundstruktur eines Konfigurationsframes ist in Abbildung 3.3 dargestellt. In Abhängigkeit Abbildung 3.3.: Struktur der Konfigurationsdaten der zu konfigurierenden Komponente wird der Wert des Type-Feldes angepasst. Derzeit 21 3. Regelstufen im Secure Access Node stehen die in Tabelle 3.1 definierten Werte für dieses Feld zur Verfügung. Auf das TypeFeld folgt das Length-Feld. Dieses Feld enthält die Längeninformation der aktuellen Konfigurationsdaten. Die Konfigurationsdaten befinden sich im Value-Feld. Type Bedeutung 1 SRAM-Konfigurationsframe 2 DDR-SDRAM-Konfigurationsframe 3 Parser-Konfigurationsframe 4 Regelstufen-Konfigurationsframe Tabelle 3.1.: Werte für das Type-Feld der Konfigurationsframes Die Rules (Regeln), die später von der Regelstufen ausgewertet werden, werden zu einem Rule Set (Regelsatz) zusammengefasst. Dieser wird mit einem Konfigurationsframe übertragen und in DDR SDRAM gespeichert. Aus einem ankommenden Datenframe wird im Parser mit Hilfe eines Vergleichsmusters die aktuelle FlowID bestimmt. Aus der FlowID wird mit CRC32-Algorithmus die RuleID berechnet. Diese entspricht einem Hashwert für die Startadresse im Speicher. FlowID und RuleID werden an den Controller übergeben. Der generiert entsprechend ein Rule Set und liefert es dem Parser zurück. Die zu parsenden Werte befinden sich im Datenframe in OSI Layer 2 bis OSI Layer 4. Die Werte, die der Parser verarbeiten kann, sind in Tabelle 3.2 dargestellt. Frameparameter Destination MAC Source MAC VLAN 1 VLAN 2 Ethertype Source IP Destination IP Protokoll Source Port Destination Port Bitanzahl 48 48 12 12 16 32 32 8 16 16 Tabelle 3.2.: Mögliche FlowID-Parameter für den Parser 3.1. Konzept Die Regelstufen sind das Herzstück einer Hardwarefirewall. Das Prinzip soll dem von iptables ähnlich sein. Die Pakete werden mit Hilfe von Rules manipuliert. Eine Rule 3. Regelstufen im Secure Access Node 22 sieht grundsätzlich so aus: Wenn Bedingung, dann Aktion. Trifft die Bedingung zu, wird die Aktion ausgeführt. Wenn die Bedingung nicht zutrifft, wird ein Frame aus Sicherheitsgründen verworfen. Im Folgenden werden nur zwei Aktionen betrachtet: Accept und Drop. Accept bedeutet, ein Frame soll weitergeleitet werden und Drop - er soll verworfen werden. Jede Regelstufe kann nur eine für sie bestimmte Rule-Art verarbeiten. Eine Regelstufe, die z.B. für IP-Antispoofing bestimmt ist, kann nur prüfen, ob Frame-MAC-Adresse und Frame-IP-Adresse zusammenpassen. Die Regelstufen werden in Reihe geschaltet und somit wird jeder Frame eine Reihe von Stationen durchlaufen, wo er auf verschiedene Eigenschaften untersucht wird. Die Reihenschaltung erlaubt auch eine Priorisierung. Entscheidet eine Regelstufe, den Frame zu verwerfen, so muss er nicht die weiteren Regelstufen durchlaufen. Zusätzlich soll jede Regelstufe Statistikwerte sammeln, wie z.B.: • Die Anzahl aller Frames, welche die Regelstufe erreichen • Welche IP zu welchem VLAN gehört • Violation Zähler (wie oft konnte die Regelstufe die Rule nicht verarbeiten) • Wie oft trat ein bestimmtes Folgeprotokoll auf • Wie oft wurde ein bestimmter Destination Port verwendet • Die Anzahl aller Frames, die durch die Regelstufe verworfen wurden – der Grund des Verwurfs – Frameparameter – Anzahl Bytes, die verworfen wurden – welche Regelstufe den Verwurf ausgelöst hat Die Auswertung der Rule soll bei allen Regelstufen einheitlich erfolgen. Die Regelstufe bekommt ein Rule Set, einen Frame und geparste Framevariablen. Die Rule-Bedingung wird mit den Variablen verglichen. Wenn diese stimmt, wird die Aktion ausgeführt, wenn nicht, werden der Frame, das Rule Set und geparste Framevariablen verworfen. Die gesammelten Statistikdaten können jederzeit angefordert werden. Abbildung 3.4 verdeutlicht nochmal den Datenfluss. Es wurden fünf Regelstufen implementiert. Die erste Regelstufe ist für IP-Antispoofing bestimmt. Ihre Aufgabe besteht darin, die Gültigkeit der Source-MAC- und Source-IP-Adresse zu überprüfen. Die nächsten vier Regelstufen können Source-MAC, Source-IP, Destination-MAC und Destination-IP unabhängig voneinander überprüfen. Entsprechend der Rule-Aktion kann ein Paket weitergeleitet oder verworfen werden. Zu protokollieren ist die Anzahl aller Frames und Bytes, die eine Regelstufe verworfen hat. Im Fall eines Verwurfs wird zusätzlich der Grund und evtl. die MAC- und/oder IP-Adresse, die den Verwurf verursacht haben, zwischengespeichert. 3. Regelstufen im Secure Access Node Abbildung 3.4.: Regelstufenflussdiagramm 23 3. Regelstufen im Secure Access Node 24 3.2. Modellrealisierung 3.2.1. Aufbau der Regelstufen Die Grundstruktur aller Regelstufen ist konstant. In Abbildung 3.5 ist die Grundstruktur dargestellt. Eine Regelstufe erhält ein Frame, ein Rule Set und geparste Framevariablen. Abbildung 3.5.: Regelstufenaufbau Alle Daten werden wortweise eingelesen. Start of Frame Bit kennzeichnet nicht nur den Anfang eines Frames, sondern auch den Anfang eines Rule Sets. Da Frame, Rule Set und Variablen gleichzeitig eintreffen, bedeutet Start of Frame auch, dass die Framevariablen gültig sind. End of Frame Bit kennzeichnet das Ende von Frame. Das Data Valid Signal ist solange aktiv, wie das Rule Set gültig ist. Die Länge eines Frames wird byteweise angegeben. Da die Regelstufe mit jedem Takt 4 Byte einliest, muss sie wissen, welche von den 4 Byte noch gültig sind. Dafür dient der Byte Valid-Eingang. Alle Daten werden 3. Regelstufen im Secure Access Node 25 über entsprechende Ausgänge weitergeleitet (vgl. Abbildung 3.5), wenn der Frame nicht verworfen werden soll. Der Log-Eingang wird verwendet, um Statistikdaten anzufordern, die dann über Statistikausgänge: drop_frames_cnt, drop_bytes_cnt und drop_values herausgeschickt werden. End of Stats kennzeichnet dabei das Ende der Statistikdaten. Über den Config-Eingang ist die interne Konfiguration der Regelstufe möglich. 3.2.2. Arbeitsweise einer Regelstufe Um die Arbeitsweise einer Regelstufe besser zu verstehen, wird zunächst der Aufbau des Rule Sets, der Framevariablen und der Statistikdaten erklärt. Aufbau des Rule Sets Ein Rule Set stellt eine Kette von einer oder mehreren Rules dar (vgl. Abbildung 3.6). Diese Rules werden in den entsprechenden Regelstufen verarbeitet, wobei für jede Rule eine separate Regelstufe existiert. Das Rule Set besteht aus einem Header und einem Value-Teil. Im Header werden Status- und Längeninformationen gespeichert. Damit besitzt ein Rule Set den typischen Type-Length-Value-Aufbau (TLV), wobei der Header die Werte für Type und Length umfasst. Die verschiedenen Rules werden durch den Value-Teil dargestellt. So wie das gesamte Rule Set besitzt auch jede Rule den TLVAufbau. Im Folgenden wird auf den Rule Set Header sowie den Aufbau der Rules näher eingegangen. Abbildung 3.6.: Grundstruktur eines Rule Sets Aufbau des Rule Set-Headers Der Rule Set Header ist den Rules im Rule Set vorangestellt. Er ist in ein Control- und ein Length-Feld unterteilt. Der Rule Set Header hat eine feste Länge von 32 Bit (vgl. Abbildung 3.7). Die in einem Rule Set vorhandenen Rules besitzen eine variable Länge. Die Gesamtlänge des Rule Sets ist im Header angegeben und umfasst die Länge des Headers sowie die Länge aller Rules. Die Längenangabe ist als ganzzahliger Wortwert zu interpretieren. Ein Wort entspricht dabei 4 Byte. Das Control-Feld (24 Bit) enthält Steuerinformationen für die folgenden Regelstufen bzw. dem auf die letzte Regelstufe folgenden Demultiplexer. Derzeit werden von den 24 Bits je eins als White-List-Bit (WL) bzw. Request-Next-Rule-Set-Bit (NeRS) verwendet (vgl. Abbildung 3.8). Die 22 derzeit nicht verwendeten Bits werden für zukünftige Kontrollfunktionalitäten bereitgestellt. Das White-List-Bit sagt aus, dass der Frame unabhängig von der Rule weitergeleitet 3. Regelstufen im Secure Access Node 26 Abbildung 3.7.: Aufbau des Rule Set Headers werden soll. Das Req-Next-Rule-Set-Bit wird von dem auf die letzte Regelstufe folgenden Demultiplexer ausgewertet und besagt, dass ein neues Rule Set angefordert werden muss. Abbildung 3.8.: Struktur des Control-Feldes im Rule Set Header Aufbau der Rules im Rule Set Die Rules folgen dem Rule Set Header. Jede Rule hat einen einheitlichen TLV-Aufbau (vgl. Abbildung 3.9). Das 8 Bit Type-Feld beinhaltet die ID-Nummer einer Regelstufe, für die die Rule bestimmt ist. Jede Regelstufe prüft das Type-Feld und kann anhand dessen schließen, ob die Rule von ihr ausgewertet werden soll. Stimmt der Ruletype mit der Regelstufe-ID überein, so wird die Rule-Bedingung geprüft. Anderenfalls werden der Frame, das gesamte Rule Set und die aktuellen Framevariablen unverändert an die nächste Verarbeitungseinheit geschickt. Die Rule-Bedingung und die Aktion stehen im Value-Feld der Rule. Die Länge dieses Feldes kann sich für jede Regelstufe unterscheiden. 3. Regelstufen im Secure Access Node 27 Das Length-Feld gibt die Länge der aktuellen Rule vom Type-Field über das LengthField bis einschließlich Value-Feld in 4 Byte an. Abbildung 3.9.: Struktur einer Rule Die Länge einer Rule stellt also ein ganzzahliges Vielfaches von 32 Bit dar. Wenn die Regelstufe eine Rule anwendet, muss diese aus dem Rule Set entfernt und die Lücke zwischen dem Header und der nächsten Rule geschlossen werden. Das Length-Feld im Rule Set Header muss dann entsprechend angepasst werden. Wenn eine Rule entfernt wird, bleibt die Länge des Rule Sets immer noch ein ganzzahliges Vielfaches von 32 Bit. Es wird dafür also keine zusätzliche Logik benötigt und somit werden FPGA-Ressourcen gespart. Wenn die Länge einer Rule kein ganzzahliges Vielfaches von 32 Bit darstellt, werden „padding zeros“ eingefügt. Die Reihenfolge der Rules im Rule Set muss der Reihenfolge der Regelstufen entsprechen. Weiterhin soll beachtet werden, dass im Rule Set nicht zwingend eine Rule für jede Regelstufe vorhanden sein muss. Aufbau der Current Frame Values Die Regelstufen vergleichen Referenzwerte aus dem Rule Set mit verschiedenen Parametern aus dem aktuellen Frame. Um eine schnelle Abarbeitung zu gewährleisten, müssen die Frameparameter mit dem ersten Byte des eintreffenden Frames zur Verfügung stehen. Diese Aufgabe übernimmt das Parser-Modul. Das Parser-Modul scannt den einkommenden Frame und filtert verschiedene Werte heraus. Diese Werte werden mit NullVektoren vorinitialisiert. Existiert einer oder mehrere dieser Werte nicht im aktuell zu verarbeitenden Frame, so besitzen diese weiterhin einen Null-Wert. Es werden folgende Frameparameter herausgefiltert: • Destination MAC • Source MAC 3. Regelstufen im Secure Access Node 28 • VLAN ID 1 • VLAN ID 2 • Ethernet Type • Source IP • Destination IP • Folgeprotokoll • Source Port • Destination Port Zusätzlich zu den Frameparametern wird noch der Port der Line Card angegeben. Aufbau der Statistikdaten Jede Regelstufe soll in der Lage sein, Statistiken aufzuzeichnen. Dazu wird eine zusätzliche Komponente in jeder Regelstufe instanziiert. Diese Komponente kann verschiedene Zähler erfassen, die für diese Regelstufe relevant sind. Per Triggersignal werden Statistikdaten angefordert. Das Triggersignal wird über den 8 Bit breiten Log-Eingang geschickt (vgl. Abbildung 3.5). Jedes Bit des Log-Signals entspricht einem Zähler oder Data-FIFO. So können nur bestimmte Statistiken angefordert werden. Die Statistikdaten werden über den Statistikausgang versendet. Zunächst sind folgende Parameter für das Statistikmodul vorgesehen: • Frame-Drop-Counter: zählt alle von der Regelstufe verworfene Ethernetframes • Bytes-Drop-Counter: zählt alle von der Regelstufe verworfene Bytes • Drop-Data: Dropidentifier und zugehörige Framewerte Dropidentifier bezeichnet den Grund, aus welchem der Frame verworfen wurde. Stimmt ein Frameparameter nicht mit dem zugehörigen Wert der Rule überein, wird dieser Framewert zu Drop-Data-FIFO hinzugefügt. Es können auch mehrere Parameter einen DROP auslösen. Die Aktion der Rule kann ebenfalls den Grund für den Verwurf darstellen, wenn sie auf DROP gesetzt ist. Die Frameparameter werden durchnummeriert und sind in Tabelle 3.3 aufgelistet. Der auslösende Identifier und die dazugehörigen Framewerte werden in einem FIFO-Puffer zwischengespeichert. Die Werte liegen nach dem in Abbildung 3.10 vorgestellten Aufbau vor. Der Dropidentifier ist ein 16 Bit breiter Vektor und kann somit 65536 verschiedene Dropidentifier aufnehmen. Die FramevalueFelder können in Abhängigkeit von der Regelstufe unterschiedlich lang sein. Aufgabe der 3. Regelstufen im Secure Access Node 29 Identifier Frameparameter 1 Destination MAC 2 Source MAC 3 VLAN 1 4 VLAN 2 5 Ethertype 6 Source IP 7 Destination IP 8 Protokoll 9 Source Port 10 Destination Port 11 S_MAC & S_IP 12 Rule-Aktion Tabelle 3.3.: Dropidentifier auswertenden Software wird es also sein, aufgrund des Wertes des Dropidentifers den folgenden Bit-Strom richtig zu interpretieren. In der prototypischen Entwicklungsphase werden die Statistikwerte an einen Collector geschickt. Dieser stellt den Statistikwerten einen speziellen Ethernet-Header voran und gliedert sie in den Datenpfad ein. In einer späteren Entwicklungsphase werden die Statistikdaten an den auf dem ML405 Board befindlichen PowerPC versandt und durch das interne Linux-System verarbeitet. Der Collector erzeugt das Triggersignal, um Statistikdaten anzufordern. Die Counter in den Regelstufen können sofort übergeben werden. Drop-Data wird so lange ausgelesen, bis der Puffer leer ist. Abbildung 3.10.: Aufbau von Drop-Data Arbeitsweise Die Regelstufe wird in einem Wartezustand initialisiert. Sie wartet auf ein Triggersignal, welches das Einlesen der Daten startet. Dieses Triggersignal ist das Start of Frame Bit. Wenn das Signal empfangen wurde, beginnt die Regelstufe, den Frame, das Rule Set und die Variablen einzulesen. Diese kommen zuerst in einen Puffer, bevor sie verarbeitet werden. Wie bereits erwähnt, kann eine Regelstufe nur eine für sie bestimmte Rule verarbeiten. Auf Grund der Rule wird entschieden, ob ein Frame weitergeleitet oder verworfen 3. Regelstufen im Secure Access Node 30 werden soll. Die Verarbeitung beginnt mit der Auswertung des Rule Sets. Die Regelstufe sucht nach der für sie bestimmten Rule. Diese soll immer die erste Rule im Rule Set sein. Anhand des Type-Feldes in der Rule erkennt die Regelstufe, ob die Rule für sie bestimmt ist. Dabei wird der Wert des Type-Feldes mit der ID-Nummer der Regelstufe verglichen. Stimmen diese überein, ist diese Rule für die Regelstufe bestimmt. Ist die erste Rule nicht für die Regelstufe bestimmt, bedeutet dies, dass keine Rule für die Regelstufe im Rule Set vorhanden ist. Es kann also maximal eine Rule für jede Regelstufe im Rule Set geben. Alle Daten wie der Frame, das Rule Set und die Framevariablen werden dann unverändert weitergeleitet. Findet die Regelstufe ihre Rule, wird zuerst geprüft, ob WLoder NeRS-Bit gesetzt ist. Ist mindestens eins von beiden gesetzt, müssen der Frame, das Rule Set und die Variablen weitergeleitet werden. Anderenfalls wird die Rule-Bedingung geprüft. Die Bedingung ist z.B. im Fall von IP-Antispoofing, ob Source-MAC-Adresse und Source-IP-Adresse zusammenpassen. Diese Daten stehen im Value-Feld der Rule. Die Regelstufe vergleicht die Bedingung mit den aktuellen Framevariablen. Wenn die Bedingung nicht zutrifft, werden der Frame, das Rule Set und die Framevariablen verworfen und nicht an die nächste Regelstufe weitergeleitet. Zusätzlich werden die Statistikdaten aufgenommen. Die Regelstufe zählt, wie viele Frames und Bytes sie verworfen hat sowie den Grund des Verwurfs. Wenn die Bedingung erfüllt ist, wird das Aktionsfeld der Rule ausgewertet. Wenn ein Frame akzeptiert wird, wird er, ob durch die Regelstufe manipuliert oder nicht, an die folgende Verarbeitungseinheit weitergeleitet. Gleichzeitig werden die aktuellen Framevariablen an die folgende Regelstufe bzw. an den, auf die letzte Regelstufen folgenden Demultiplexer weitergegeben. Wenn ein Frame durch die Regelstufe verändert wurde, müssen ggf. auch die Framevariablen angepasst werden. Das Rule Set wird ebenfalls weitergeleitet. Jedoch kann es, in Abhängigkeit davon, ob die aktuelle Regelstufe eine Rule des Rule Sets verwendet hat, manipuliert werden. Wie bereits erwähnt, kann in einem Rule Set maximal eine Rule für jede Regelstufe existieren. Diese soll immer an der ersten Stelle im Rule Set stehen. Wenn Identifierer der Rule mit dem Identifier der Regelstufe übereinstimmt, wird die Rule angewendet. Diese soll anschließend aus dem Rule Set entfernt werden. Im Anschluss rücken die folgenden Rules auf, sodass die Lücke geschlossen wird. Dadurch wird gewährleistet, dass die nächste Regelstufe ihre Rule wieder an der ersten Position im Rule Set finden kann. Falls erforderlich, werden im Header des Rule Sets Zusatzinformationen in Form einzelner Bits (White-List-Bit, Request-Next-Rule-Set-Bit) gespeichert. Die Länge des Rule Sets muss ebenfalls angepasst werden. 3.3. IP-Antispoofing Regelstufe 3.3.1. Funktionsweise Diese Regelstufe realisiert IP-Antispoofing. Als Spoofing werden alle Täuschungsversuche bezeichnet, die zur Verschleierung der eigenen Identität führen. Der Angreifer 3. Regelstufen im Secure Access Node 31 täuscht dabei einen vertrauenswürdigen Host vor. Dies gibt ihm evtl. die Möglichkeit, auf bestimmte Netzwerkressourcen zuzugreifen, die sonst nur vertrauenswürdigen Rechnern zur Verfügung stehen. Beim IP-Spoofing wird die Quell-IP-Adresse gefälscht. Bei IP-Antispoofing werden MAC- und IP-Adressen des Absenders auf Gültigkeit überprüft. Die Firewall besitzt eine Liste, in der alle MAC-IP Paare eines Netzwerks eingetragen sind. Wenn ein Paket die Regelstufe erreicht, soll es auf IP-Spoofing überprüft werden, bevor es weitergeleitet wird. Diese Aufgabe übernimmt die IP-Antispoofing Regelstufe. Die Regelstufe ist, wie in Abschnitt 3.2 beschrieben, aufgebaut. Sie bekommt den Frame, das Rule Set und die geparsten Framevariablen. In Abbildung 3.11 ist das Flussdiagramm dargestellt. Zuerst untersucht die Regelstufe das Rule Set. Ist die erste Rule Abbildung 3.11.: Flussdiagramm der IP-Antispoofing Regelstufe für IP-Antispoofing bestimmt, werden dann die MAC- und IP-Adresse der Rule mit der 3. Regelstufen im Secure Access Node 32 MAC- und IP-Adresse des Absenders verglichen. Stimmen diese überein, wird die Aktion ausgeführt. Diese kann entweder ACCEPT oder DROP sein. Zusätzlich kann auch das WL Bit oder NeRS Bit gesetzt sein. In diesem Fall wird der Frame unabhängig von der Rule weitergeleitet, da die Control-Bits höherpriorisiert sind. Die verarbeitete Rule wird aus dem Rule Set entfernt und alle Daten werden weitergeleitet. Trifft die Bedingung der Rule nicht zu oder ist die Aktion der Rule DROP, werden das Rule Set, der Frame und damit auch die Variablen verworfen. Der Grund des Verwurfs und die zugehörigen Frameparameter werden in den Puffer gespeichert. Wenn die Regelstufe ihre Rule nicht findet, werden sämtliche Daten unverändert weitergeleitet. Die Statistik kann jederzeit angefordert werden. 3.3.2. Implementierung Die Regelstufe wurde in VHDL implementiert. Referenzboard diente ML405 von Xilinx. Als Entwicklungsumgebung wurden ISE WebPACK 10.1 und als Simulator ModelSim 6.3 SE benutzt. In Abbildung 3.12 ist das Blockschaltbild der IP-Antispoofing Regelstufe dargestellt. Sie besteht aus 4 FIFO-Speicher, die als Puffer verwendet werden, Abbildung 3.12.: Blockschaltbild der IP-Antispoofing Regelstufe und 4 Zustandsautomaten. Die gesamte Regelstufe wurde nach der 2-Prozessmethodik entwickelt, sodass alle ankommenden und abgeschickten Daten immer mit dem Takt synchronisiert sind. Die Regelstufe erhält ihre ID über dem Config-Eingang. Das geschieht nur beim Reset. Die ID kann im laufenden Betrieb nicht mehr geändert werden. 3. Regelstufen im Secure Access Node 33 Die Frame FIFO State Machine (Frame FSM) und Rule Set FIFO State Machine (Rule Set FSM) sind für das Einlesen der Daten verantwortlich. Die beiden FSMs werden im Wartezustand initialisiert. Sobald das Start-of-Frame Bit die Regelstufe erreicht, beginnen sie ihre Arbeit. Die Frame FSM steuert das Schreiben des Frames und der Framevariablen in die entsprechende FIFOs. Die Rule Set FSM steuert das Schreiben des Rule Sets in FIFO. Die beiden FSMs ändern dabei keine Daten. Ein Frame wird solange in die Frame FIFO geschrieben, bis das End of Frame Bit gesetzt wird. Die Gültigkeit des Rule Sets wird durch Data Valid signalisiert. Das Rule Set wird solange in die Rule Set FIFO geschrieben, wie Data Valid auf 1 ist. Der Puffer wird verwendet, weil die Bearbeitung der Daten und das Treffen einer Entscheidung mehrere Takte dauert. Während der Bearbeitung kann ein nächster Frame eintreffen. Dieser wird dann zuerst in den Puffer gespeichert und wartet, bis der vorheriger Frame vollständig abgearbeitet wurde. Die maximale Länge eines Ethernet Frames beträgt 1522 Byte. Diese setzt sich aus Ethernet-Header und Ethernet-Payload zusammen (vgl. Kapitel 2.1). Die Größe der Frame FIFO wurde auf 1024 Worte begrenzt. Ein Wort in unserem Fall entspricht 4 Byte. Der maximal lange Frame besteht aus 381 Worten und der minimal lange Frame (60 Byte) aus 15 Worten. Bevor ein Frame in den Puffer geschrieben wird, wird kontrolliert, ob ausreichend Speicherplatz in der FIFO zur Verfügung steht, um einen maximal langen Frame zu speichern. Die Verzörung für das „FIFO prog_full“ Signal dauert einen Takt. Das heißt, der Puffer wird als voll angezeigt, wenn die Schwelle von 643 Worten erreicht wurde. Wenn nicht ausreichend Speicher vorhanden ist, wird der Frame verworfen. Das Speichern erfolgt immer wortweise. Somit kann die Frame FIFO 2 maximal lange Frames oder 43 minimal lange Frames komplett speichern. Für die minimal langen Frames gilt die Formel: 642 div 15 + 1 . Die Tiefe der Rule Set FIFO wurde ebenfalls auf 1024 Worte gesetzt. Die Tiefe der Variablen-FIFO wurde auf 64 Worte gesetzt, um das Speichern der Variablen aller minimalen Frames zu ermöglichen. Die komplexeste Funktionalität enthält die Read State Machine (RSM). Diese kann die Daten aus den FIFOs herauslesen und verarbeiten. Die RSM beginnt mit dem Auslesen des Rule Sets und der aktuellen Framevariablen. Das Lesen der Variablen dauert nur einen Takt, da diese mit dem ersten Wort komplett herausgelesen werden. Damit stehen die aktuellen Framevariablen für den Rule-Vergleich sofort zur Verfügung. Mit dem ersten Takt werden der Rule Set Header sowie die Framevariablen und mit dem zweiten Takt das Type Feld und das Length Feld der Rule ausgelesen. Anhand des Rule-Type kann die RSM erkennen, ob die Rule für sie bestimmt ist. Dafür wird Rule-Type mit der intern gespeicherten ID-Nummer der Regelstufe verglichen. Stimmen Rule-Type und Regelstufe-ID nicht überein, werden die Daten weitergeleitet. Die RSM beginnt dann, den Frame und die Variablen zu lesen. Das Rule Set wird dabei ebenfalls weitergelesen. Wenn die RSM das End of Frame Bit erkennt, wird das Lesen des Frames beendet. Das Ende eines Rule Sets wird aufgrund der Längenangabe im Rule Set Length Feld bestimmt. Die RSM arbeitet solange, bis Frame und Rule Set komplett aus der FIFO herausgelesen und weitergeleitet wurden. Dann geht die RSM wieder in den Anfangszu- 3. Regelstufen im Secure Access Node 34 stand und wartet auf den nächsten Frame. Stimmt das Type Feld der Rule mit der Regelstufe-ID überein, muss die Rule ausgewertet werden. Die Rule für die IP-Antispoofing Regelstufe besitzt den Aufbau, wie in Abbildung 3.13 dargestellt. Wie bereits erklärt wurde, muss die Rule-Länge ein ganzzah- Abbildung 3.13.: Ruleaufbau der IP-Antispofing Regelstufe liges Vielfaches von 32 Bit betragen. Aus diesem Grund wurden den Nutzdaten der Rule Padding Bits in Form von Nullen nachgestellt. Diese Rule ist also 128 Bit lang. Die RSM braucht somit 4 Takte, um die Rule vollständig auszulesen. Die MAC- und IP-Adresse der Rule-Bedingung werden mit der Source-MAC- und Source-IP-Adresse des Frames verglichen. Stimmen diese nicht überein, werden der Frame, die Framevariablen und das Rule Set verworfen. Wenn die Bedingung erfüllt ist, muss die Aktion ausgeführt werden. Die Aktion kann entweder ACCEPT oder DROP sein. Wenn jedoch im Rule Set Header WL oder NeRS Bit gesetzt ist, muss der Frame weitergeleitet werden. Dabei werden die Aktion und Bedingung der Rule nicht berücksichtigt, weil der Rule Set Header eine höhere Priorität hat. Ähnlich wie bei einem Verwurf liest RSM den Frame und das Rule Set solange aus, bis das Ende des Frames bzw. des Rule Sets entsprechend erreicht ist. Die IP-Antispoofing Regelstufe soll wie auch jede andere Regelstufe Statistikdaten sammeln. Wenn ein Frame verworfen wird, wird der Drop-Counter inkrementiert. Der BytesDrop-Counter zählt, wie viele Bytes dabei verworfen wurden. Beide Zähler sind 32 Bit lang. Bei einem Verwurf wird der Grund des Verwurfs und der zugehöriger Frame Parameter in der Statistik-FIFO gespeichert. In Abbildung 3.14 ist der Aufbau der Statistikdaten dargestellt. Die Drop-Data-FIFO kann 16 Einträge speichern. Wenn diese voll ist und ein neuer Frame verworfen wird, wird der älteste Eintrag gelöscht und der neue Eintrag hinzugefügt. Das Log-Signal wird von der Stats FIFO State Machine ausgewertet. Diese sendet die angeforderten Statistikdaten an den Collector. Bei Counter-Abfrage werden diese von der Stats FSM zurückgesetzt. Wenn die Drop-Data Statistik angefordert wird, wird die FIFO solange gelesen, bis diese leer ist. Enthält die FIFO keine Daten mehr, wird von ihr ein Empty-Signal gesetzt. Dieses wird an den Collector als End of Stats weitergeleitet. Die Statistik setzt sich also aus dem Frame-Drop-Counter, 3. Regelstufen im Secure Access Node 35 Abbildung 3.14.: Aufbau der Statistikdaten der IP-Antispoofing Regelstufe dem Bytes-Drop-Counter und den Verwurfsinformationen zusammen. 3.4. Source- und Destination-MAC Regelstufen Diese zwei Regelstufen sollen die Source- bzw. Destination-MAC-Adressen überprüfen. Wenn die MAC-Adresse in der Rule-Bedingung mit der entsprechenden MAC-Adresse des Frames übereinstimmt, wird die Rule-Aktion ausgeführt. Der interne Aufbau dieser Regelstufen entspricht vollständig der IP-Antispoofing Regelstufe und wurde bereits in Kapitel 3.3 beschrieben. Der Ruleaufbau dieser Regelstufen ist in Abbildung 3.15 dargestellt. Abbildung 3.15.: Aufbau der Rule bei der Source- und Destination-MAC Regelstufe Die Rule ist 96 Bit lang. Das Lesen dieser Rule dauert also 3 Takte. Diese Regelstufen sind in der Lage, die gleichen Statistikdaten wie die IP-Antispoofing Regelstufe aufzunehmen. Dabei werden die Drop-Data in folgender Form in die FIFO geschrieben: Grund des Verwurfs, MAC (vgl. Abbildung 3.16). 3.5. Source- und Destination-IP Regelstufen Die folgenden zwei Regelstufen sind in der Lage, die Source- bzw. Destination-IP-Adressen zu überprüfen. Stimmen diese mit der Rule-Bedingung überein, wird die entsprechende 3. Regelstufen im Secure Access Node 36 Abbildung 3.16.: Aufbau von Drop-Data bei der Source- und Destination-MAC Regelstufe Rule-Aktion ausgeführt. Der interne Aufbau entspricht dem der IP-Antispoofing Regelstufe (vgl. Kapitel 3.3). Der Rule-Aufbau ist in Abbildung 3.17 dargestellt. Die Rule ist Abbildung 3.17.: Aufbau der Rule bei der Source- und Destination-IP Regelstufe 64 Bit lang. Um diese aus der FIFO auszulesen, braucht die Regelstufe 2 Takte. Die Statistikdaten werden in der Form, wie in Abbildung 3.18 dargestellt, gespeichert. Abbildung 3.18.: Aufbau von Drop-Data bei der Source- und Destination-IP Regelstufe 37 4. Auswertung der Ergebnisse Um die Regelstufe zu testen, wurde eine Test Bench geschrieben. Diese kann IPv4 Frames sowie Rule Sets erzeugen. Variablen werden aus dem Frame automatisch generiert. Weiterhin können die Statistikdaten zu jedem Zeitpunkt abgefragt werden. In Tabelle 4.1 sind die Testfälle und Ergebnisse zum Testen der IP-Antispoofing Regelstufe aufgeführt. Testfall Die erste Rule ist nicht für die Regelstufe bestimmt Es gibt keine Rules im Rule Set Ergebnis Frame, Rule Set und Framevariablen werden weitergeleitet Frame, Rule Set Header und Framevariablen werden weitergeleitet WL im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung ist erfüllt, Ak- stufe wird aus dem Rule Set entfernt tion DROP NeRS im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung erfüllt, Aktion stufe wird aus dem Rule Set entfernt DROP Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Rule-Bedingung erfüllt, Aktion werden weitergeleitet, Rule der RegelACCEPT stufe wird aus dem Rule Set entfernt Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Rule-Bedingung erfüllt, Aktion werden verworfen, Statistik: Grund DROP 12 in FIFO eingetragen, Frame-DropCounter inkrementiert, Bytes-DropCounter um Anzahl verworfener Bytes erhöht Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, MAC Mismatch, Aktion AC- werden verworfen, Statistik: Grund 2 CEPT und MAC in FIFO eingetragen, FrameDrop-Counter inkrementiert, BytesDrop-Counter um Anzahl verworfener Bytes erhöht 4. Auswertung der Ergebnisse 38 Testfall Die erste Rule ist für die Regelstufe bestimmt, IP Mismatch, Aktion ACCEPT Ergebnis Frame, Rule Set und Framevariablen werden verworfen, Statistik: Grund 6 und IP in FIFO eingetragen, FrameDrop-Counter inkrementiert, BytesDrop-Counter um Anzahl verworfener Bytes erhöht Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, MAC und IP Mismatch, Akti- werden verworfen, Statistik: Grund on ACCEPT 11, MAC und IP in FIFO eingetragen, Frame-Drop-Counter inkrementiert, Bytes-Drop-Counter um Anzahl verworfener Bytes erhöht Die erste Rule ist für die Regelstufe be- Frame, Rule Set Header und Framevastimmt und es gibt keine weiteren Ru- riablen werden weitergeleitet les im Rule Set, Rule-Bedingung erfüllt, Aktion ACCEPT 20 x Frames, die erste Rule ist für die 20 Frames verworfen, Statistikeinträge Regelstufe bestimmt, Rule-Bedingung der letzten 16 Frames an Collector weinicht erfüllt, Drop-Data anschließend tergeleitet angefordert 150 x minimal lange Frames (60 Byte), 150 Frames wurden verarbeitet die erste Rule ist für die Regelstufe bestimmt, Rule-Bedingung nicht erfüllt 300 x minimal lange Frames (60 Byte), 257 Frames wurden verarbeitet (FIFOdie erste Rule ist für die Regelstufe be- Kapazität erschöpft) stimmt, Rule-Bedingung nicht erfüllt 100 x maximal lange Frames (1522 100 Frames wurden verarbeitet Byte), die erste Rule ist für die Regelstufe bestimmt, Rule-Bedingung nicht erfüllt 600 x maximal lange Frames (1522 592 Frames wurden verarbeitet (FIFOByte), die erste Rule ist für die Regel- Kapazität erschöpft) stufe bestimmt, Rule-Bedingung nicht erfüllt Tabelle 4.1.: Testfälle und Ergebnisse für die IP-Antispoofing Regelstufe Die erzielten Ergebnisse stimmen mit den erwarteten überein. Die Testfälle und Ergebnisse für die Source-MAC, Destination-MAC, Source-IP und Destination-IP Regelstufe 39 4. Auswertung der Ergebnisse sind im Anhang in den Tabellen A.1 - A.4 zu finden. In Tabelle 4.2 sind die erreichten Taktfrequenzen sowie der Ressourcenverbrauch aller Regelstufen dargestellt. Regelstufe Taktfrequenz (MHz) IP-Antispoofing 107,012 Source-MAC 107,912 Destination-MAC 107,912 Source-IP 102,009 Destination-IP 102,009 Ressourcenverbrauch (Slices) 556 528 528 514 514 Tabelle 4.2.: Taktfrequenzen und Ressourcenverbrauch der Regelstufen 40 5. Diskussion 5.1. Zusammenfassung Im Rahmen dieser Arbeit wurde die Netzwerksicherheit im Zugangsbereich diskutiert. Die wichtigsten Schutzmaßnahmen stellen Firewall und IDS dar. Die dabei zu erfüllenden Konfigurationsaufgaben sind relativ komplex und führen bei Fehlkonfiguration zu einem großen Gefahrenpotential. Vor diesem Hintergrund ist es vorteilhaft, grundlegende Sicherheitsfunktionen bereits im Zugangsbereich bereitzustellen. Es wurde ein Konzept von SecAN vorgestellt, welches das Ziel verfolgt, den Nutzer von komplizierten Firewalleinstellungen zu entlasten. Die vorgeschlagene Hardwarefirewall soll von ISPs betrieben und bedient werden. Diese kann den Nutzer und das gesamte lokale Netzwerk vor negativen Einflüßen schützen. Ein weit verbreitetes Linux-Werkzeug zur Paketfilterung und zum Schutz des Nutzers ist iptables. Es wurden fünf Regelstufen präsentiert, die auf Grundlage von iptables arbeiten. Die IP-Antispoofing Regelstufe hat die Aufgabe, die IP-Spoofing-Versuche zu erkennen und zu blockieren. Die weiteren vier Regelstufen können anhand von Source-MAC, Source-IP, Destination-MAC oder Destination-IP die Entscheidung über das Weiterleiten eines Frames treffen. Alle Regelstufen wurden in VHDL implementiert und anschließend mit einer geeigneten Test Bench getestet. Die erzielten Testergebnisse stimmen mit den erwarteten Ergebnissen überein. Die Regelstufen erreichen die geforderten Geschwindigkeiten, um einen GBit-Betrieb zu gewährleisten. Diese können im SecAN eingesetzt werden und die Sicherheit erhöhen. 5.2. Ausblick Um eine erweiterte Sicherheit zu gewährleisten, müssen zusätzliche Regelstufen entwickelt und implementiert werden. Eine Möglichkeit wäre eine Port-Regelstufe. Diese kann die verwendeten Ports des Transport Layers überprüfen. Mit Hilfe der Ports können unerwünschte Anwendungen wie z.B. P2P blockiert werden. Voraussetzung dafür ist, dass die Anwendung konstante Ports oder Portsbereiche verwendet. Eine weitere Regelstufe könnte nach Protokollen filtern. So kann z.B. ARP-Spoofing erkannt und blockiert werden. Weiterhin ist die Filterung nach bestimmten VLAN-Tags mit einer zusätzlichen Regelstufe denkbar. I Literaturverzeichnis [1] Paketfilter-Firewalls. http://www.nm.ifi.lmu.de/ sicherheitsbuch/Paketfilter.pdf. [2] Cisco: Evolution of the Firewall Industry. http://www.cisco.com/univercd/ cc/td/doc/product/iaabu/centri4/user/scf4ch3.htm, 2002. [3] ClickZ: Stats - Web Worldwide. http://www.clickz.com/showPage.html?page=151151, 2008. [4] Computer-Industry-Almanac: Worldwide Internet Users Top 1.2 Billion in 2006. http://www.c-i-a.com/pr0207.htm, 2007. [5] Freaks, T. G. C.: Spoofing-FAQ. http://www.gcf.de/papers/spoofingfaq.html, 2003. [6] Kinkeldei, W.: iptables - Die Firewall des Kernels 2.4. linux.de/t_netzwerk/iptables.html, 2001. http://www.pro- [7] Linux-Compendium: Linux Firewall mit iptables. http://de.wikibooks.org/wiki/Linux-Kompendium:_Linux-Firewall_mit_IPTables, 2007. [8] netfilter.org. http://www.netfilter.org/. Proxy und Content-Filtering. [9] Peritus-GmbH-Consulting: http://www.peritus.de/itservice/betrieb/sicherheitskomponenten/ 76583c98550fd3f07.html, 2008. [10] Shell, M.: Intrusion Detection-Systeme: eine Einführung. ZDNet Security, 2005. [11] Software-Marktplatz: Firewall Software. http://www.softwaremarktplatz.de/software/firewall_software/index.php, 2008. [12] Wikipedia: Netzwerksicherheit. http://de.wikipedia.org/wiki/Netzwerksicherheit, 2008. II A. Anhang Source-MAC Regelstufe Testfall Die erste Rule ist nicht für die Regelstufe bestimmt Es gibt keine Rules im Rule Set Ergebnis Frame, Rule Set und Framevariablen werden weitergeleitet Frame, Rule Set Header und Framevariablen werden weitergeleitet WL im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung ist erfüllt, Ak- stufe wird aus dem Rule Set entfernt tion DROP NeRS im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung erfüllt, Aktion stufe wird aus dem Rule Set entfernt DROP Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Rule-Bedingung erfüllt, Aktion werden weitergeleitet, Rule der RegelACCEPT stufe wird aus dem Rule Set entfernt Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Rule-Bedingung erfüllt, Aktion werden verworfen, Statistik: Grund DROP 12 in FIFO eingetragen, Frame-DropCounter inkrementiert, Bytes-DropCounter um Anzahl verworfener Bytes erhöht Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Source-MAC Mismatch, Akti- werden verworfen, Statistik: Grund 2 on ACCEPT und MAC in FIFO eingetragen, FrameDrop-Counter inkrementiert, BytesDrop-Counter um Anzahl verworfener Bytes erhöht Die erste Rule ist für die Regelstufe be- Frame, Rule Set Header und Framevastimmt und es gibt keine weiteren Ru- riablen werden weitergeleitet les im Rule Set, Rule-Bedingung erfüllt, Aktion ACCEPT III A. Anhang Testfall 20 x Frames, die erste Rule ist für die Regelstufe bestimmt, Rule-Bedingung nicht erfüllt, Drop-Data anschließend angefordert Ergebnis 20 Frames verworfen, Statistik Einträge der letzten 16 Frames an Collector weitergeleitet Tabelle A.1.: Testfälle und Ergebnisse für Source-MAC Regelstufe Destination-MAC Regelstufe Testfall Die erste Rule ist nicht für die Regelstufe bestimmt Es gibt keine Rules im Rule Set Ergebnis Frame, Rule Set und Framevariablen werden weitergeleitet Frame, Rule Set Header und Framevariablen werden weitergeleitet WL im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung ist erfüllt, Ak- stufe wird aus dem Rule Set entfernt tion DROP NeRS im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung erfüllt, Aktion stufe wird aus dem Rule Set entfernt DROP Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Rule-Bedingung erfüllt, Aktion werden weitergeleitet, Rule der RegelACCEPT stufe wird aus dem Rule Set entfernt Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Rule-Bedingung erfüllt, Aktion werden verworfen, Statistik: Grund DROP 12 in FIFO eingetragen, Frame-DropCounter inkrementiert, Bytes-DropCounter um Anzahl verworfener Bytes erhöht Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Destination-MAC Mismatch, werden verworfen, Statistik: Grund 1 Aktion ACCEPT und MAC in FIFO eingetragen, FrameDrop-Counter inkrementiert, BytesDrop-Counter um Anzahl verworfener Bytes erhöht IV A. Anhang Testfall Die erste Rule ist für die Regelstufe bestimmt und es gibt keine weiteren Rules im Rule Set, Rule-Bedingung erfüllt, Aktion ACCEPT 20 x Frames, die erste Rule ist für die Regelstufe bestimmt, Rule-Bedingung nicht erfüllt, Drop-Data anschließend angefordert Ergebnis Frame, Rule Set Header und Framevariablen werden weitergeleitet 20 Frames verworfen, Statistik Einträge der letzten 16 Frames an Collector weitergeleitet Tabelle A.2.: Testfälle und Ergebnisse für Destination-MAC Regelstufe Source-IP Regelstufe Testfall Die erste Rule ist nicht für die Regelstufe bestimmt Es gibt keine Rules im Rule Set Ergebnis Frame, Rule Set und Framevariablen werden weitergeleitet Frame, Rule Set Header und Framevariablen werden weitergeleitet WL im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung ist erfüllt, Ak- stufe wird aus dem Rule Set entfernt tion DROP NeRS im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung erfüllt, Aktion stufe wird aus dem Rule Set entfernt DROP Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Rule-Bedingung erfüllt, Aktion werden weitergeleitet, Rule der RegelACCEPT stufe wird aus dem Rule Set entfernt Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Rule-Bedingung erfüllt, Aktion werden verworfen, Statistik: Grund DROP 12 in FIFO eingetragen, Frame-DropCounter inkrementiert, Bytes-DropCounter um Anzahl verworfener Bytes erhöht A. Anhang Testfall Die erste Rule ist für die Regelstufe bestimmt, Source-MAC Mismatch, Aktion ACCEPT Ergebnis Frame, Rule Set und Framevariablen werden verworfen, Statistik: Grund 6 und MAC in FIFO eingetragen, FrameDrop-Counter inkrementiert, BytesDrop-Counter um Anzahl verworfener Bytes erhöht Die erste Rule ist für die Regelstufe be- Frame, Rule Set Header und Framevastimmt und es gibt keine weiteren Ru- riablen werden weitergeleitet les im Rule Set, Rule-Bedingung erfüllt, Aktion ACCEPT 20 x Frames, die erste Rule ist für die 20 Frames verworfen, Statistik EinträRegelstufe bestimmt, Rule-Bedingung ge der letzten 16 Frames an Collector nicht erfüllt, Drop-Data anschließend weitergeleitet angefordert Tabelle A.3.: Testfälle und Ergebnisse für Source-IP Regelstufe Destination-IP Regelstufe Testfall Die erste Rule ist nicht für die Regelstufe bestimmt Es gibt keine Rules im Rule Set Ergebnis Frame, Rule Set und Framevariablen werden weitergeleitet Frame, Rule Set Header und Framevariablen werden weitergeleitet WL im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung ist erfüllt, Ak- stufe wird aus dem Rule Set entfernt tion DROP NeRS im Rule Set Header auf 1 gesetzt, Frame, Rule Set und Framevariablen die erste Rule ist für die Regelstufe be- werden weitergeleitet, Rule der Regelstimmt, Rule-Bedingung erfüllt, Aktion stufe wird aus dem Rule Set entfernt DROP Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Rule-Bedingung erfüllt, Aktion werden weitergeleitet, Rule der RegelACCEPT stufe wird aus dem Rule Set entfernt V A. Anhang Testfall Die erste Rule ist für die Regelstufe bestimmt, Rule-Bedingung erfüllt, Aktion DROP Ergebnis Frame, Rule Set und Framevariablen werden verworfen, Statistik: Grund 12 in FIFO eingetragen, Frame-DropCounter inkrementiert, Bytes-DropCounter um Anzahl verworfener Bytes erhöht Die erste Rule ist für die Regelstufe be- Frame, Rule Set und Framevariablen stimmt, Destination-IP Mismatch, Ak- werden verworfen, Statistik: Grund 7 tion ACCEPT und MAC in FIFO eingetragen, FrameDrop-Counter inkrementiert, BytesDrop-Counter um Anzahl verworfener Bytes erhöht Die erste Rule ist für die Regelstufe be- Frame, Rule Set Header und Framevastimmt und es gibt keine weiteren Ru- riablen werden weitergeleitet les im Rule Set, Rule-Bedingung erfüllt, Aktion ACCEPT 20 x Frames, die erste Rule ist für die 20 Frames verworfen, Statistik EinträRegelstufe bestimmt, Rule-Bedingung ge der letzten 16 Frames an Collector nicht erfüllt, Drop-Data anschließend weitergeleitet angefordert Tabelle A.4.: Testfälle und Ergebnisse für Destination-IP Regelstufe VI Eidesstattliche Versicherung Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken habe ich als solche kenntlich gemacht. Rostock, 23. September 2008 Vladyslav Altman