Security Patterns - HS2015. Tobias Stauber Ueli Bosshard Felix Morgner

Transkript

1 Security Patterns - HS2015 Tobias Stauber Ueli Bosshard Felix Morgner 11. August 2015

2 I think the problem, to be quite honest with you, is that you ve never actually known what the question is. Deep Thought 1

3 Inhaltsverzeichnis 1 Authorization 4 2 Role Based Access Control 6 3 Multi Level Security 8 4 Reference Monitor 10 5 Role Rights Definition 12 6 Identification and Authentication Intro 14 7 Identification and Authentication Requirements 16 8 Access Control Requirements 19 9 Single Access Point Check Point Security Session Full Access With Errors Limited Access Packet Filter Firewall Proxy Based Firewall Stateful Firewall Information Obscurity Secure Channels Known Partners Demilitarized Zone Authenticator Controlled Process Creator Controlled Object Factory Controlled Object Monitor 58 2

4 25 Controlled Virtual Address Space Execution Domain Controlled Execution Environment File Authorization Protection Reverse Proxy Integration Reverse Proxy Frontdoor 74 3

5 Kapitel 1 Authorization 1.1 Summary Beschreibt für jede Entität einzeln, wie (lesend, schreibend, ausführend) auf welche Ressource zugegriffen werden darf. 1.2 Context Einsatz bei sicherheitskritischen Ressourcen, auf die nicht jeder Benutzer oder Prozess beliebig Zugriff erhalten soll. 1.3 Problem Aus Gründen der Vertraulichkeit oder Integrität. ist es manchmal wünschenswert, dass Ressourcen für bestimmte Benutzer oder Prozesse nicht frei verfügbar sind. Folgende Probleme müssen angegangen werden: Die aktiven Benutzer und Prozess müssen Unterschieden werden können. Die Authorization muss unabhängig von den Ressourcen sein. Die Authorization sollte flexibel im Umgang mit Subjekten, Objekten und Rechten sein. Die Rechte von Benutzern und Prozessen sollen einfach modifiziert werden können. 1.4 Solution Jeder Subject (User, Prozess, usw.) zu Protection Object Verbindung ist ein Recht-Objekt zuweisen, welches Zugriffs- Typen und ZugriffsRechte verwaltet und auch die Rechte beim Zugriff überprüft. Abbildung 1.1: Strukturdiagramm für Authorization 4

6 Es kann viel Aufwand kosten alle Rechte immer richtig zu vergeben. Dies ist vorallem bei grösseren Organisationen nicht zu unterschätzen. Zudem sind viele dieser Recht-Objekte zu verwalten und zu speichern. 1.5 Known Uses Ein gutes Beispiel ist die Zugriffsrechtsverwaltung in einem Betriebssystem. Oder auch in einer Datenbank oder einer Firewall. Jedoch sind zumeist Patterns eingesetzt, welche auf diesem Aufbauen. 1.6 Relationships Das Pattern steht in einer engen Beziehung zum Role-Based Access Control Pattern. 5

7 Kapitel 2 Role Based Access Control 2.1 Summary Dieses Pattern beschreibt wie man in einem komplexen System mit vielen Benutzern, den Zugriff auf Resourcen klären kann. Die Zuweisung der Berechtigungen erfolgt auf Grund der Funktionen oder Aufgaben, welche einem Benutzer (z.b. einem Angestellten oder einem Subsystem) zugewiesen sind. 2.2 Context Das Pattern setzt auf dem Context des Authorization Patterns auf. Zusätzlich existieren eine grosse Menge von Resourcen und Benutzern, deren Berechtigungen verwaltet werden müssen. 2.3 Problem Die Verwaltung von Berechtigungen in einem grossen System ist mit grossem Aufwand verbunden. Da viele Benutzer und viele Resourcen existieren, gestalltet sich das verteilen von Berechtigugen als zeitaufwändige, monotone und dadurch fehleranfällige Arbeit (Copy-Paste-Fehler). Noch schlimmer wird es, wenn es zu häufigen Änderungen in den Anforderungen der Benutzern kommt. Oftmals haben unterschiedliche Benutzer jedoch ähnliche bis identische Anforderungen um ihre Aufgaben erfüllen zu können. 2.4 Solution Häufig ist es der Fall, dass sich Angestellte oder andere Benutzer, auf Grund ihrer Arbeitstelle oder Aufgaben, gruppieren lassen. Diese Gruppierung entspricht dem Need-to-know-Prinzip (jeder Benutzer kann oder weiss nur das was er zur Erfüllung seiner Aufgaben benötigt). Wir machen uns diese Eingenschaft zu Nutze, in dem wir Rollen definieren welche Anforderungsbezogene Berechtigungen zusammen fassen. Ein Benutzer kann dann in einer oder mehreren dieser Rollen auftreten. Somit müssen nicht mehr auf Benutzerebene einzelne Berechtigungen vergeben werden. 6

8 Abbildung 2.1: Strukturdiagramm für role based access control 2.5 Consequences pro Reduktion des administrativen Aufwands, da es weniger Rollen als Benutzer gibt. Es gibt keine riesigen Berechtigungslisten mehr. pro Es entsteht eine bessere Abbildung der Unternehmensstruktur auf die Vergabe von Rechten anhand der Rollen. pro Personalfluktuationen sind leicht erfassbar, da nicht mehr viele Regeln sondern nurnoch die Zuteilung zu Rollen geändert werden muss. pro Das Pattern erlaubt eine Delegation der Administration von Rollen. con Es wird grosse Disziplin und eine saubere Struktur benötigt um sinvolle Rollen festzulegen. con es entsteht eine zusätzliche Abstraktionsebene. 2.6 Known Uses Windows-Benutzerverwaltung / Active Directory SELinux PostgreSQL Branchenlösungen, Bsp. SAP 2.7 Relationships COMPOSITE AUTHORIZATION ROLE ABSTRACT SESSION 7

9 Kapitel 3 Multi Level Security 3.1 Summary Dieses Pattern beschreibt, wie man sensible Daten kategorisieren kann um ihre Veröffentlichung zu verhindern. Zur Verwaltung des Zugriffs werden den Benutzern des Systems Freigaben (clearances) und den Dokumenten Klassifikationen (classifications) zugeteilt. 3.2 Context Wir befinden uns in einer Umgebung welcher es Resourcen gibt deren Veröffentlichung zu grossen Problemen führen könnte (z.b Übernahmeplan) und welche speziell geschützt werden müssen. 3.3 Problem In oben genanntem Kontext ist es extrem wichtig, dass keine der besonders schützenswerten Daten exfiltriert werden können. Will man dieses Problem lösen, müssen folgende Anforderungen erfüllt werden: Die Vertraulichkeit der Daten muss aufgrund ihrer Sensibilität geschützt werden Benutzer müssen in der Lage sein, Dokumente für welche sie, auf Grund von Rang oder Arbeitsposition, autorisiert sind zu lesen Es muss möglich sein, die Erlaubniss-Stufen von Benutzern zu ändern, damit sie bei Beförderung oder Degradierung nur die für sie bestimmten Dokumente lesen können. 3.4 Solution Benutzern und Daten werden Klassen (clearance bei Benutzern, classification bei Daten) zugewiesen. Bekannte Beispiele für Klassifikationen von Daten sind "Geheim", ßtreng Geheim", etc. Bei Benutzern bietet sich ein Gruppenoder Rollenbasiertes Modell an (siehe RBAC). Die Vertraulichkeit von Daten wird duch Richtlinen, wie im Bell- LaPadula-Modell definiert, sichergestellt. Integrität von Daten wird mitttels Biba-Modell Richtlinen sichergestellt. Ein vertrauenwürdiger Prozess stellt die Einhaltung der Richtlinen sicher und ist für die Klassifikation von Daten und Nutzern zuständig. 3.5 Consequences pro Oft können vorhandene Organisationsrichtlinen zur Klassifikation verwendet werden. 8

10 pro MLS erlaubt einen höheren Grad von Isolation. con Es wird ein vertrauenwürdiger Prozess für die Verwaltung benötigt. con Es muss möglich sein Daten hierarchisch und Benutzer in Freigaben zu strukturieren. 3.6 Known Uses SELinux Datenbanken 3.7 Relationships REFERENCE MONITOR ROLE BASED ACCESS CONTROL 9

11 Kapitel 4 Reference Monitor Auch bekannt als POLICY ENFORCEMENT POINT 4.1 Summary Dieses Pattern erzwingt deklarierte Zugriffseinschränkungen während dem Zugriff auf eine Ressource. Es beschreibt den abstrakten Prozess, der den Zugriff auf eine Ressource abfängt und ihn auf Einhaltung der Autorisierung überprüft. 4.2 Context Rechenumgebung in welcher Benutzer oder Prozesse eine Anfrage für Daten oder Ressourcen machen. 4.3 Problem Wenn Zugriffsbeschränkungen nicht durchgesetzt werden, dann ist es so, als würde es sie nicht geben. Prozesse oder Benutzer könnten alle Arten von unerlaubten Aktionen durchführen. Beispiel: Jeder Benutzer könnte jede Datei lesen. Folgende Probleme müssen also abgedeckt werden: Die Definition der Autorisierung ist nicht genug, sie muss bei Zugriffen von Prozessen oder Benutzern für jede Anfrage überprüft werden. Es gibt viele mögliche Wege den Zugriff zu beschränken, es braucht aber eine abstraktes Modell zur Authorisierungsdurchsetzung, das auf jede Ebene eines System anwendbar ist. 4.4 Solution Es wird ein Prozess definiert, der den Zugriff auf Ressourcen abfängt und sie auf Einhaltung der Autorisierung überprüft. Abbildung 4.1: Strukturdiagramm für Reference Monitor 10

12 Abbildung 4.2: Sequenzdiagramm für Reference Monitor 4.5 Consequences pro Wenn alle Zugriffe abgefangen werden, kann sichergestellt werden, dass die Regeln erfüllt werden. pro Implementierungen werden nicht durch den beschriebenen Prozess eingeschränkt con Implementierungen sind für alle typen von Ressourcen nötig. Beispielsweise ein Dateimanager muss den Zugriff auf Dateien überprüfen. con Jeden Zugriff zu kontrollieren kann das System drastisch ausbremsen. Es kann sinnvoll sein, die Überprüfung zur Compiler-Zeit zu machen, damit wird der wiederholte Zugriff zur Ausführungszeit nicht mehr ausgebremst. 4.6 Known Uses Die meisten Betriebsysteme (Bsp: Linux, MacOS X, Windows NT/2000/XP/Vista/8/9/10... ) Java Security Manager Datenbanksysteme Firewalls 4.7 Relationships Reference Monitor ist ein Spezialfall von Check Point Implementierung: concrete Reference Monitor Interceptor (POSA2) 11

13 Kapitel 5 Role Rights Definition 5.1 Context Applikationen, welche aus mehreren unterschiedlichen Rollen bestehen, welchen nicht sauber Rechte zugewiesen werden können. 5.2 Problem Das RBAC-Model wird inzwischen in allen Arten von Systemen eingesetzt. Jedoch sind die Rollen oft nicht sprechend genug, es ist nicht klar, wieso Rolle X genau die Rechte R, S, T benötigt. Das Problem ist es also eine sinnvolle Zuweisung der Rechte zu finden, welche die Ëin Minimum an RechteRegelung einhält. Es müssen dabei folgende Bedingungen eingehalten werden: Rollen sollten realen Tätigkeiten im Unternehmen zugeordnet werden können und die zur Ausführung deren nötigen Rechte beinhalten. Jede dieser Rollen kriegt nur so viel Rechte, dass sie gerade alle in ihren Tätigkeitsbereich fallende Aufgaben erfüllen kann. Änderungen an Rollen und deren Rechte sollten einfach durchführbar sein. Die Rechtezuweisung sollte von der Implementation des Systems unabhängig sein. 5.3 Solution Entwickle Usecases für alle Tätigkeitsabläufe in der Organisation. Alle Aktoren, welche darin vorkommen können auf Rollen abgebildet werden. Wenn man für die Usecases SSD s entwickelt, zeigen diese auf, auf was für Ressourcen der entsprechende Aktor zugreifen muss. Dieses Entwickeln kann bei seriöser Durchführung echt zeitintensiv sein. 5.4 Consequences pro Weil Rechte wirklich auf einer Analyse der Tätigkeiten basieren, kann ein Minimum an Rechte verteilt werden. pro Da in den SSD s die benötigten Ressourcen ermittelt worden sind, können dafür einfach Rechte geschrieben werden. pro Neue UC s definieren also nur neue Rechte, welche einfach hinzugefügt werden können. pro Der gesamte Ansatz ist unabhängig von der zugrundeliegenden Implementation. Deshalb müssen nur die Interaktionen zwischen Aktor und System autorisiert werden, nicht hingegen die internen Zugriffe auf die Objekte. 12

14 Solange sich also die externe Sicht auf das System nicht verändert (z.b. Usecases benötigen immer noch File X,Y,Z) muss die Rolle oder ihre Rechte nicht verändert werden, auch wenn die zugrundeliegende Implementation ändert. con Das Erstellen von geeigneten Usecases und zugehörigen SSD s benötigt eine gewisse Erfahrung. Dies ist eine Humanressource, über die nicht jedes Unternehmen verfügt. 5.5 Relationships ROLE BASED ACCESS CONTROL 13

15 Kapitel 6 Identification and Authentication Intro Das Ziel der Identifizierung ist es, den externen Nutzer eines Systems so zu erkennen, dass er vom System eindeutig einem Nutzer im System zugeordnet werden kann. Die Authentisierung beschreibt dabei für den Nutzer den Prozess des Vorweisens von Merkmalen, welche es dem System ermöglichen ihn zu identifizieren. Ist dieser Vorgang abgeschlossen können ihm z.b. von einem anderen System jene Rechte, welche für den Systemnutzer vorgesehen sind, zugewiesen werden. 6.1 Individual I&A Die Frage welche gestellt wird ist in etwa diese: Welcher der Aktoren, die ich kenne bist du? Es wird also direkt darauf geprüft, ob der Nutzer auch der ist, den er vorgibt zu sein Example Ein Postbote der ein eingeschriebenes Paket höchstpersönlich abliefern muss, darf das Paket, obwohl ich zu der Gruppe von Leute gehöre, welche Zugang zum Milchkasten haben, nicht in den Milchkasten an dieser Adresse einwerfen. Er ist vielmehr dazu verpflichtet mich durch Prüfen von Authentisierungsmittel, welche ich vorweise, zu identifizieren und erst bei erfolgreicher Identifizierung die vorgesehene Handlung vornehmen (Paket übergeben). 6.2 Group I&A Zu welcher der Gruppen die ich kenne gehörst du? Meistens für Gruppen von Personen verwendet Example Major Bell verdonnerte den Soldaten Ive Subvers dazu die Wache zu übernehmen. Da die Stellung im Wald auf einer Kreuzung von Feldwegen liegt, erwartet Bell, dass der Durchgang streng kontrolliert wird. Abends beschliesst Major Bell Joggen zu gehen und als er loszieht scheint alles in Ordnung zu sein. Allerdings ändert sich dies schnell als er zur Stellung zurück kommt und Soldat Subvers schon von weitem grinsen sieht. Dieser verweigert dem Major prompt den Zugang, da sich dieser in seiner Joggingkleidung nicht als AdA ausweisen kann. Fazit: Obwohl Ive den Major sofort erkannte, verweigerte er ihm den Zutritt, weil diesem die notwendigen Authentisierungsmittel fehlten um sich als Angehöriger der Schweizer Armee auszuweisen. 14

16 6.3 Goal I&A übernimmt nichts weiter als Bestätigen einer erfolgreichen Authentisierung zu einem Zeitpunkt. Um die Zugriffe auf Ressourcen zu ermöglichen wird eine externe Funktionen benötigt. Beispielsweise um den Nutzer, welcher Identifiziert wurde mit den ihm zugehörigen Rechten auszustatten. 15

17 Kapitel 7 Identification and Authentication Requirements 7.1 Summary Ein Ïdentification and Authentication (I&A) servicemuss eine Auswahl an Anforderungen an den Service und an die Verfügbarkeit des Services erfüllen. Es ist die Aufgabe von I&A Individuen zu erkennen und deren Identität zu bestätigen. Zwar ist jede Anfrage individuell, aber es existieren dennoch allgemeingültig Anforderungen. Die Ï&A Requirements"bietet eine allgemeingültige Auswahl von Anforderungen und helfen die relative Wichtigkeit von konkurrierenden Anforderungen zu ermitteln. 7.2 Context Eine Organisation oder ein Projekt, wo bewusst I&A eingesetzt wird. Hier wird nur der Bereich behandelt, wo Identifikation und Authentifikation eingesetzt werden. 7.3 Problem Anforderungen von I&A stehen oft in Konflikt miteinander. Oft ist es nötig diese Anforderungen aufeinander abzustimmen. Beispielsweise stehen die Sicherheit des Systems der einfachen Benutzbarkeit gegenüber. Folgende Situationen sollten adressiert werden: Besitzer von I&A Services möchten, dass dieser korrekt funktioniert. Der Service soll erkennen ob ein Actor mit einem Identifier verbunden ist. Falsche Rückmeldung bei einem Betrugsfall, kann zu Leaksführen. Die Produktivität wird negativ beeinflusst, wenn ein ermächtigter Actor fälschlicherweise äusgepserrt"wird. Benutzer verlangen I&A Services mit guter Qualität: Schnelle Antwortzeiten, Korrekte Funktionalität, Einfach zu verstehen, Sicher, Passend zur Kategorie eines Benutzers Für Unternhehmungen sollen I&A Services kosteneffektiv sein und einen gute ROI liefern. Der I&A Service soll vor gestolenen Identitäten schützen. 7.4 Solution Spezifizieren von I&A Requirements für die vorliegende I&A Domain. Dabei muss die Wichtigkeit jeder dieser Anforderung untersucht werden. Die Lösung hat zwei Aspekte: Einen Anforderungs Prozess bzw. einen generellen Anforderungskatalog. 16

18 Zuerst wird die Domain festgelegt, für welche die I&A Anforderungen spezifiziert werden. Daraus ergeben sich Faktoren, welche die Spezialisierung beeinflussen, sowie die Wichtigkeit der Anforderung definieren. Danach werden die Anforderungen spezifiziert General Requirements Betrüger genau identifizieren Legitime Akteuere genau identifizieren Minimiere Unterschiede in den Usercharakteristiken Minimieren Zeitaufwand um den Service zu nutzen Minimiere das Benutzerrisiko Minimiere Benutzerkosten für die Installation Minimiere Veränderungen an existierenden System Infrastrukturen Minimiere Wartungs-, Management- und Overhead-Kosten Schütze den I&A Service und seine Daten Unterschiede zwischen Requirements 7.5 Consequences pro Erzwingt eine klare Definition der I&A Domains, was das Verständniss der nötigen I&A Domains und den konkreten Anforderungen fördert. pro Führt zu klaren Begründungen für die Wahl der I&A-Anforderungen. pro Regt eine explizite Analyse der I&A-Requirements an und führt so zu einer besseren Wahl der I&A-Mechanismen pro Es ergibt sich eine klare Dokumentation der I&A-Anforderungen. con Die Umsetzung benötigt Zeit und Personal. Es ist möglich, dass die Kosten die Nutzen überwiegen. con Kann zu Overengineering führen. Ein weg das zu vermeiden ist nur die Teile des Patterns zu verwenden welche für die konkrete Anwendung den grössten Nutzen bringen. con Spezialfälle können von den generischen I&A-Requirements nicht abgedeckt werden. Hier empfiehlt es sich, selber neue Anforderungen zu spezifizieren. con Die Anforderungen können sich über die Lebenszeit des Systems ändern, somit muss auch die Dokumentation aktualisierbar gestaltet sein. con Verschiedene Mitarbeiter/Abteilungen haben verschiedene Auffassungen der Wichtigkeit der Anforderungen, was es schwierig macht die Anforderungen abzuwägen. Das kann auch ein Vorteil sein, da es intensievere Diskussionen und bewusstere Entscheidungen fördert. 17

19 7.6 Known Uses OMB2003 Eine Regelung zur elektronischen Authentisierung von Personen welche (staatliche) Online Angebote nutzen. ISO15408 Internationaler Standard der Evaluationskriterien für IT Sicherheit definiert. Firesmith2003 Beschreibung funktionaler I&A-Requirements und Diskussion von I&A Domain im Zusammenhang mit diesen. 18

20 Kapitel 8 Access Control Requirements 8.1 Summary Die Funktion des äccess security serviceïst das erlauben oder verweigern von Aktionen wie anlegen, lesen, modifizieren oder löschen. Während in jeder Situation die Anfrage einmalig ist, gibt es trotzdem allgemeingültig Anforderungen, die auf alle Arten von Zugriffen anzuwenden sind. Die Requirements erfasst sowohl die Zugriffskontrolle als auch Eigenschaften des äccess control service". Das Pattern gilt auch generelle Anforderungen auf die spezifische Situation anzuwenden und hilft die relative Wichtigkeit von widersprüchlichen Anforderungen zu finden. 8.2 Context Wir befinden uns in einer Organisation welche den Einsatz von Zugriffskontrolle plant. Bekannt sind bereits actors, assets und actions, welche bei der Zugriffskontrolle verwendet werden. Eine access control rule erlaubt einen actor eine action auf einem asset. Zum Beispiel kann A die Datei F modifizieren. 8.3 Problem Es braucht eine Auswahl von Anforderungen um sicherzustellen, dass die Strategie für die Zugriffsberechtigung die Bedürfnisse der Organisation oder des Systems erfüllt. Die Anforderungen für Zugriffskontrolle kollidieren oft miteinander, Kompromisse sind oft nötig. Auch hier gilt das Beispiel, dass die Sicherheit sich mit der Zugänglichkeit beisst. Wie kann die spezifische Anforderung für ein Zugriffskontrolle Service anhand der relativen Wichtigkeit gefunden werden? Der Prozess zur Auswahl und Gewichtung der äccess control requirementsmuss folgende Kräfte aufeinander abstimmen: Die Zugriffskontrolle schützt die gewünschten Sicherheitseigenschaften, insbesondere die Vertraulichkeit und die Integrität. Zugriffskontrolle ist mit Kosten verbunden, nicht nur finanziell, sondern auch mit Support-Personal, Softwareentwicklung, Zugriffszeit, Zufriedenheit der Benutzer usw. Zugriffskontrolle erhöht die Komplexität der Software für das System, Benutzer und Administratoren Zugriffskontrolle soll konsistent zu den Firmenrichtlinien sein. Die Komplexität darf nicht zu Fehlbedienung führen. Die Zugriffskontrolle ist nicht nur lokal, sondern muss auch im Zusammenspiel mit anderer Software funktionieren. Extrem angewendete Zugriffsbeschränkungen führen zwar meist zu wenig ungewollten Zugriffen, aber die Gewährung der Rechte ist mit hohem Aufwand verbunden. 19

21 Wenig fein eingestellte Zugriffskontrolle erleichtert den Zugriff, aber gibt meist mehr Informationen als gewollt preis. 8.4 Solution Definieren einer Auswahl von access control requirements für eine sepzifische Domäne und stelle ihre spezifische Wichtigkeit fest. Die Umsetzung erfolgt in einem requirement Prozess und setzt auf eine Liste von generischen Anforderungen. Verweigere unberechtigten Zugriff Erlaube berechtigten Zugriff Begrenze den Schaden falls unberechtigter Zugriff zustande gekommen ist Vermeide Zugriffsverweigerung bei berechtigtem Zugriff Minimiere die Systemlast durch Zugriffskontrolle Ermögliche Umsetzung von geforderten Sicherheitsrichtlinien Mache den Zugriffskontrollservice flexibel 8.5 Implementation Die Implementation des ACCESS CONTROL REQUIREMENTS Patterns erfolgt in mehreren Schritten: a. Festlegung der Domain b. Festlegung von Faktoren welche die Requirements beeinflussen c. Eine oder mehrere Access Control Policies auswählen d. Granularität der Zugriffskontrolle festlegen e. Requirements festlegen f. Wichtigkeit der Requirements festlegen Die wichtigsten Reuqirements auf einen Blick (mehr im Buch auf Seite 273): Tabelle 8.1: My caption Requirement Deny unauthorized access Limit blockage Minimize burden Make access control flexible Faktor Sensibilität der Schutzobjekte Benutzerzufriedenheit Performance & Availability Mehrere Modi (Normal, lock-down, etc.) 20

22 8.6 Consequences Die Konsequenzen sind ählich wie letzte Woche: pro Access Control Requirements müssen bewusst bestimmt werden pro Tradeoffs müssen explizit erwogen werden pro Es wird eine Dokumentation erstellt welche die Interessen der beteiligten Parteien darlegt und Audits unterstützen kann pro Erzeugung eines klaren Zusammenhangs zwischen Reuqirements und Policies con Die Kosten können hoch sein und im Extremfall die Nutzen überwiegen con Gefahr der Komplexität und von Over-Engineering con Es kann sehr lange dauern ( -> hohe Kosten ) con Spezialfälle können nicht mit generischen Requirements gehandhabt werden 8.7 Known Uses RFC2820 Access Control Requirements for LDAP Eve04 Fallstudie in Bezug auf Gesundheits-Informationen ISO15408 Common Criteria for Information Technology Security Evaluation 21

23 Kapitel 9 Single Access Point 9.1 Context Man will externen Clients Zugriff auf ein System gewähren, jedoch muss sichergestellt sein, dass das System nicht gefährdet ist. 9.2 Problem Da eine Interaktion eines Externen Clients z.b. eines Users mit dem System immer eine Gefährdung darstellt, sollten Zugriffe autorisiert werden können. Es ist jedoch äusserst unpraktikabel wenn jede Funktion zuerst den Client fragt, ob er das überhaupt darf. (Ich öffne Filebrowser: System bittet mich mich zu authentisieren, damit es weiss, dass ich dieses Programm ausführen darf. Ich tippe Pfad ein: System bittet mich mich zu authentisieren, damit es weiss, dass ich diesen Ordner öffnen darf. Und so würde das weiter gehen.) Es müssten also alle Programme, die irgend ein Recht erfordern, mit mir eine Authentifizierung vornehmen. Durch die Implementation in jedem Programm besteht die Gefahr, dass die Implementationen sehr stark voneinander abweichen und womöglich sogar unterschiedliche Schwachstellen aufweisen. Wer jemals Windows Vista nutzen musste, weiss wie nervend dauernde Anfragen, ob das System jetzt dies und jenes als Administrator ausführen soll, da man im Moment nicht die Rechte dafür hat, sein können. Die dauernde Notwendigkeit sich zu authentisieren kann User stark belasten. Geschichte dazu: In einem mittelalterlichen Dorf muss jeder sein eigenes Heim vor Einbrecher schützen und bei seinem Laden kontrollieren, ob die Person welche soeben eingetreten ist ein ehrbarer Kunde oder ein Dieb ist. Durch diesen Aufwand wird viel Zeit verbraucht und die vielen einzelnen Kontrollen sind mühsam. 9.3 Solution Ein System sollte einen zentralen Eintrittspunkt haben. Dieser Eintrittspunkt kann zum Beispiel ein Loginscreen oder ähnliches sein. Nachdem der User sich daran angemeldet hat, darf er alle Tätigkeiten im System drin ausführen, für welche seine Rechte ausreichen. Dazu muss der Rest der Systemgrenze so geschützt werden, dass das Umgehen des SAP nicht möglich ist. Das System verweigert einfach alle Aktivitäten von nicht angemeldeten Benutzern. Der SAP sollte also leicht erkennbar sein, hier ein theoretisches Gegenbeispiel: Windows bootet und geht direkt auf einen defaultaccount, man erkennt aber beim Probieren, dass nichts funktioniert. Darauf muss man den Benutzer wechseln, damit man arbeiten kann. Geschichte dazu: Um das Dorf wird eine Palisade mit nur einem Eingang errichtet. Jetzt können die Dorfbewohner einen Wachmann bezahlen, welcher Fremde die in das Dorf wollen kontrolliert. Das Stadttor muss dabei klar erkennbar sein. Die Besucher wären bestimmt verwirrt, wenn sie auf dem Weg, welcher zum Dorf führt, entlanggehen und dieser an einer Palisade endet, worauf sie halb um das Dorf gehen müssen, bis sie ein kleines Türchen mit der Beschriftung <STADTTOR> treffen, welches ihnen Einlass gewährt. 22

24 Irgendwie muss ich Zugriffe auf das System handhaben, ansonsten ist das System nutzlos Heutzutage sind viele Systeme untereinander vernetzt, die Zugangswege dazu sollten bekannt sein um eine Zusammenarbeit zu ermöglichen. Das Pattern kann in einen vernünftigen Umfang im System selbst weiter geführt werden. (Auch die Häuser im Dorf könnten das Pattern umsetzen (nur einen Eingang)) Die Komplexität und Unsicherheit, welche durch viele unterschiedliche Kontrollen entstehen werden vermieden. Abbildung 9.1: Strukturdiagramm für Single Access Point 9.4 Consequences pro Die Zutrittskontrolle liegt an einer Stelle und ist deren Hauptkompetenz. pro Die Überprüfung welcher Nutzer wann angemeldet war ist ziemlich einfach (Man muss nur den Wachtposten fragen) pro Einheitlicher Zugang zu einem System ist einfacher zu handhaben pro Nutzer werden nicht durch dauernde Kontrollen genervt. con Wenn der SAP nicht leistungsfähig genug ist, kann er einen Flaschenhals an einem ansonsten leistungsfähigeren System bilden. con Einheitliche Zugangskontrollen können nicht flexibel genug sein, z.b. Passwort-only Zugang auf einem Tablet. 9.5 Known Uses Ein Funktionseintrittspunk mit Precondition Überprüfung (z.b. in Eiffel) Unix User-Login Eine Firewall über die alle Zugriffe auf ein dahinter liegendes Netz gehen. Eine Vereinzelung für den Zugang zu sicherheitskritischen Bereichen z.b. Arbeitsplätze Flugsicherung usw. Disco-Türsteher 23

25 Kapitel 10 Check Point 10.1 Summary Im Allgemeinen jedes System, welches vor unberechtigtem Zugriff geschützt werden muss. (Das schliesst z.b. Single Access Point mit ein) 10.2 Context Wenn man ein System schützt, ist es oftmals von Interesse mehrere mögliche Arten der Zugangskontrolle zu haben. Kleine Änderungen wie neue I&A Möglichkeiten sollten einfach implementierbar sein. Grosse Änderungen wie das Austauschen von kompletten SAP sollten möglich sein. Zum Beispiel kann ein Entwickler während dem Entwickeln und Testen keine Authentisierung am laufen haben, jedoch müssen im Betrieb User authentisiert und autorisiert werden. Dies kann durch austauschen dieses Software-Blocks erreicht werden. Wie kann also eine Architektur errichtet werden, welche es ermöglicht das System effektiv zu schützen und dabei die Möglichkeit der effizienten Modifikation an der I&A aufrecht zu erhalten und das ohne Beeinträchtigung der Sicherheit Problem Die Lösung besteht daraus das Strategy Pattern auf SAP anzuwenden, damit das Verhalten des SAP verändert werden kann. Check Point definiert somit die Schnittstelle zwischen dem SAP und den einzelnen I&A Implementationen. Check Point kann neben I&A auch noch weitere Features bereitstellen z.b. das direkte starten einer Security-Session, das loggen von (Sicherheitsrelevanten) Aktionen, oder auch das Detektieren von Angriffsmustern bei wiederholten unberechtigten Zugriffsversuchen. Ein gutes Beispiel dafür sind die Pluggable Authentication Modules (PAM) in Linux welche es ermöglichen die Art der Authentisierung durch simples Austauschen von Modulen zu ändern Solution Die Lösung besteht daraus das Strategy Pattern auf SAP anzuwenden, damit das Verhalten des SAP verändert werden kann. Check Point definiert somit die Schnittstelle zwischen dem SAP und den einzelnen I&A Implementationen. Check Point kann neben I&A auch noch weitere Features bereitstellen z.b. das direkte starten einer Security-Session, das loggen von (Sicherheitsrelevanten) Aktionen, oder auch das Detektieren von Angriffsmustern bei wiederholten unberechtigten Zugriffsversuchen. Ein gutes Beispiel dafür sind die Pluggable Authentication Modules (PAM) in Linux welche es ermöglichen die Art der Authentisierung durch simples Austauschen von Modulen zu ändern. 24

26 Abbildung 10.1: Strukturdiagramm für Check Point 10.5 Implementation Folgende Aufgaben müssen erledigt werden: Interface für CheckPoint definieren Den ëntry checkäm single entry point implementieren Ein Konfigurationsmechanismus für den konkreten CheckPoint zur Verfügung stellen Konkrete CheckPoints implementieren Umgang mit Client Fehlern definieren Stelle eine API für den CheckPoint zur Verfügung 10.6 Consequences pro Die I&A ist unabhängig von dem Rest der Software, dies ist in der Entwicklungsphase sehr wichtig. pro Die Implementierung der sicherheitstechnischen Abläufe können separat getestet werden. pro Die Art der Authentisierung kann schnell und mit geringem Aufwand verändert werden (z.b. Password Smartcard) con Check Point Implementationen sind sicherheitskritisch und müssen entsprechend entworfen und getestet werden. con Das Implementieren von Angriffsmustererkennungsalgorithmen (Tolles Wort) ist ziemlich kompliziert. con Eine zukunftssichere Schnittstelle für I&A Module kann schwierig zu implementieren sein. 25

27 10.7 Known Uses LinuxPAM Rechte mit steigenden Authentisierungsmitteln erweitern (lesen z.b. nur mit Passwort, schreiben hingegen nur mit SmartCard) Transport von sperrigen Geräten in einen Bereich, der sonst nur per Vereinzelung erreichbar ist. (Es gibt für bestimmte Aktionen eine andere Art des Zugangs) 10.8 Relationships Single Access Point I&A Strategy 26

28 Kapitel 11 Security Session 11.1 Summary Um die Verifikation von Rechten in einem System zu erleichtern, wird jedem Benutzer eine Session zugeordnet. Dadurch muss der Benutzer nicht immer wieder authentisiert werden, und alle Anfragen betreffend Berechtigungen werden an seine Session gestellt Context Wir betrachten ein System mit mehreren Benutzern. Die Komponenten des Systems brauchen eine Moeglichkeit um sie die Sicherheitsdaten welche mit einem Benutzer assoziiert sind zu teilen Problem Computersysteme werden im Normalfall von verschiedenen Benutzern verwendet. Es ist wichtig, sicher zu stellen, dass ein Benutzer nur auf Bereiche (Files, Prozesse, etc.) Zugriff hat, fuer welche er Berechtigungen besitzt. Deshalb muss ein Benutzer identifiziert und authentisiert werden. Wenn jede Resource im System den Benutzer einzeln authentisieren wuerde waere das nervig und aufwendig. In einem Web-Shop will man zum Beispiel einen eigenen Ëinkaufswagen"haben und sich nicht andauernd neu anmelden muessen wenn man ein weiteres Produkt in den Wagen legt. HTTP ist aber stateless und kann somit diese Session verwaltung nicht uebernehmen. Man will auch, dass die verwendeten Credentials vergessen werden, wenn die Transaktion beendet ist Solution Wir erschaffen ein SESSION Objekt, in welchem alle mit dem Benutzer assoziierten Daten (besonders sicherheitsrelevante Daten) gespeichert werden. Jede Aktion welche der Benutzer durchfuehrt wird mit seiner SESSION assoziiert. Meistens wird am CHECK POINT des Systems die SESSION aufgebaut. Zusaetzlich zu sicherheitsrelevanten Daten, koennen Programme eigene Daten in dem SESSION Objekt speichern. Diese Daten koenne Programme nutzen um Daten untereinander auszutauschen, welche zu der momentanen SESSION des Benutzers gehoeren. Meistens wird ein MANAGER eingesetz um die SESSIONs zu verwalten. 27

29 Implementation Abbildung 11.1: Strukturdiagramm für Security Session a. Ein SESSION Objekt erzeugen, welches die Berechtigungen, die Identifikation und moeglicher Weisse die Rolle des Benutzers speichert (ROLE BASED ACCESS CONTROL). Es kann nuetzlich sein auch Timestamps und weitere Daten zu speichern, welche zur Verarbeitung der Session benoetigt werden. Eine Moeglichkeit die Erweiterbarkeit sicherzustellen ist es, fuer zusaetzliche Daten PROPERTY LIST zu verwenden. b. Einen Manager einfuehren, welcher die SESSION des Benutzers verwaltet. Zusaetzlich werden Session-Identifiers benoetigt, um die SESSIONs eindeutig identifizieren zu koennen. c. Festlegen von Time-Outs. Eine SESSION sollte nach einer gewissen Zeit ablaufen, um so zu verhindern, dass sie von Fremden"benutzt werden oder zuviel Speicher benutzt wird. Der Manager soltle die SESSIONs regelmaessig aufraeumen. d. Festlegen von Reauthentication-Time-Outs. Der MANAGER sollte den Benutzer dazu zwingen, sich regelmaessig erneut beim CHECK POINT anzumelden wenn die SESSION von laengerer Dauer ist. Damit wird verhindert, das eine offene SESSION missbraucht wird. Erlaube dem Benutzer, sich am CHECK POINT an- und abzumelden Consequences pro Es gibt genau einen Ort an welchem sicherheitsrelevante Daten gespeichert werden. => Das System muss nur die SESSION weiterreichen. pro Das Session Objekt kann erweitert werden ohne die restlichen System-Komponenten zu beeinflussen. 28

30 pro SESSION Objekte koenne gecached werden. pro Es ist leicht festzustellen, ob die gleichen Credentials mehrfach gleichzeitig verwendet werden. con Es muss geprueft werden, ob man aus Versehen eine versteckte Kopplung einfuehrt. con SESSION Objekte muessen regelmaessig abgeraeumt werden. con In einem verteilten System koennen Session-Identifiers gefaelscht werden. => Es muss sichergestellt werden, dass die Identifiers nicht leicht zu erraten sind. con Bei der Verwendung von Cookies muss sichergestellt werden, dass die Cookies verschluesselt und signiert sind Known Uses Cookies UNIX und Windows SSL 29

31 Kapitel 12 Full Access With Errors 12.1 Context Beim Designen von Interfaces eines Systems, in welchem Zugriffsbeschränkungen wie z.b. Nutzer Autorisation, auf Teile des Interfaces angewandt werden. Die meisten davon sind in GUI s, es können aber auch andere Interfacetypen sein Problem Wenn man ein UI für ein System mit teilweiser Zugriffsbeschränkung erstellt, muss man entscheiden, ob man dem User Funktionalitäten, welche er mit der momentan von ihm eingenommenen Rolle nicht wahrnehmen kann, anzeigen will und wenn ja, wie? Dabei wird die Entscheidung erschwert, indem nicht bekannt ist, welche Rechte oder Kombinationen davon genutzt werden. Wie wird also momentan nicht verfügbare Funktionalität dargestellt? 12.3 Solution Das System sollte so entworfen werden, dass jegliche Funktionalitäten im Interface ersichtlich sind. Wenn dann eine Funktion aufgerufen oder auf Daten zugegriffen wird, prüft das System zuerst die Rechte. Wenn der Zugriff gewährt wird, ist alles in Ordnung. Bei fehlenden Rechten wird eine Error-Nachricht erstellt und dem Nutzer angezeigt. Dabei kann die Nachricht dem Nutzer auch gleich eine Möglichkeit zum Upgrade oder Ändern seiner Rechte angeboten werden (z.b. Windows "Du bist kein AdministratorError, welcher auch gleich ein Äls Administrator ausführenbutton hat.) Sehr komplizierte an mehrere Bedingungen geknüpfte Rechte können geprüft werden: The implementation of access right checks that are closely related to the function to be performed allows implementation of more sophisticated authorization schemas that depend on more than just a flag for an access right, such as data values used in the current transaction. For example, a bank might withhold the account statements of their bosses or of very rich clients from regular clerks, who could otherwise look at almost all accounts within their range of duty. Solch komplexe Rechtelogik ist in einem generischen Rechteverwaltungssystem beinahe nicht realisierbar Struktur Bevor die tatsächliche Operation ausgeführt wird, wird überprüft ob der User auch Zugriff hat. 30

32 Abbildung 12.1: Strukturdiagramm für Full Access With Errors Implementation Nutzer sollten keine Daten sehen, oder Operationen vornehmen können, auf welche sie keinen Zugriff haben. Bei GUI-Anwendungen sollten dem Nutzer verfügbare und zugängliche Aktionen nicht versteckt werden. In GUI s sollten sich Menü-Punkte auch bei einer Änderung der Rechte des Nutzers nicht nicht verschieben, damit "blindes"benutzern möglich ist. Im Fall von kommerziellem Interesse: Das Anzeigen von Pay-Functions kann den Nutzer dazu verleiten seine Rechte zu erweitern (die Software zu kaufen, Abo abzuschliessen) Consequences pro Es ist ein konsistenter Error-Handling Mechanismus verfügbar für Entwickler und die Errors sind dem Nutzer bekannt. pro Dokumentation und Trainingsmaterial für eine solche Software ist konsistent für alle Nutzungsbereiche (Manager und Angestellter kann dieselbe Software nutzen) pro Gut wenn der Nutzer seine Rechte on the fly updaten kann. pro Gut wo Kenntnis alleine nicht ausreicht (z.b. ein Downloadlink, der nur für eingeloggte Benutzer sein sollte) con Das Try and Error Prinzip kann echt an den Nerven zerren (Astah) con Jede Kleinigkeit muss Rechte prüfen, dies kostet Rechenzeit und kann zu duplicate Code oder sogar Sicherheitslücken führen. con Das Anzeigen aller Funktionen kann zu extrem unübersichtlichen GUI s führen Known Uses Überschreiben einer Datei, dabei wird dem Nutzer die Nachricht präsentiert, dass benanntes File bereits existiert, und nachgefragt, ob er selbiges überschreiben will (Upgrade der Rechte des Editors) Windows Rechte-Upgrade prompt 31

33 Astah Community Edition Unix jedes Programm kann auf "beinahe"jedes File angewandt werden, oftmals hat man einfach keine Rechte auf das Programm oder das File. Für stabile download URL s, wobei z.b. auf ein Cookie geprüft wird, welches nur eingeloggte User haben, anstatt anzunehmen, dass nur legitime Nutzer den Link kennen. Toiletten in Frankreich, die keinen Besetztindikator aufweisen Relationships SAP & Check Point (kann für Full Access With Errors verwendet werden) Minimize Human Intervention (wird durch error-messages direkt angegriffen) 32

34 Kapitel 13 Limited Access Auch bekannt als: Limited View Blinders Child Proofing Invisible Road Blocks Hiding the cookie jars Early Authorization 13.1 Summary LimitedAccess ist sehr nah mit Full Access with Errors"verwandt. LimitedAccess sagt aber, dass nur die verfügbaren Funktionen anhand der Rechte angezeigt werden sollen Context Interfacedefinition von Systemen bei denen unterschiedliche Zugriffsrechte vergeben werden. Dieses Pattern ist eher im Bereich Userinterface anzusiedeln Problem Einem Benutzer allen potentiell verfügbaren Funktionen anzuzeigen kann ein Sicherheitsproblem sein. Es ist nicht gewollt, dass der Benutzer Zugriff auf Funktionen hat oder dass er überhaupt weiss, das es die Funktion gibt. Wird ein System von Benutzern mit unterschiedlichen Fähigkeiten und Zugriffsrechten benutzt, so führt es zu Schwierigkeiten, falls jede Funktion jedem Benutzer angezeigt wird (vgl. Full Access with Errors). Es ist sehr viel benutzerfreundlicher, wenn nur angezeigt wird, was wirklich möglich ist. Folgende muss beachtet werden: Benutzer sollen keine Operationen oder Daten sehen, für die sie nicht berechtigt sind. Benutzer sollen nicht andauernd mit Meldungen über Zugriffsbeschränkungen belästigt werden. Input validation ist einfacher, wenn der Benutzer nur sieht wozu er berechtigt ist. Wenn sich das Userinterface ändert, weil Berechtigungen hinzukommen oder entfernt werden, so kann das die Benutzer verwirren und die Produktivität wird verringert. 33

35 13.4 Solution Den Benutzer nur sehen lassen, wozu er Rechte hat. In einem GUI nur die Auswahl und Menus Zeigen, wozu er Berechtigt ist. Zum Beispiel, wenn ein Benutzer nicht berechtigt ist die Daten zu ändern, dann sollen die Daten nur in einem ReadOnly-Feld angezeigt werden und kein Button zum editieren sichtbar sein. Das Pattern geht nicht näher auf konkrete Umsetzung ein, aber die Idee ist, dass im Interface-Builder nur gezeichnet wird, auf was auch zugegriffen werden kann. Es können die selben Mechanismen benutzt werden, die auch oft zum vorübergehenden deaktivieren von Schaltflächen benutzt werden. Zum Beispiel wenn kein Text ausgewählt ist, dann kann auch nichts ausgeschnitten oder kopiert werden Structure Im Unterschied zu Full Access with Errors"werden die Berechtigungen VOR dem zeichnen des Userinterfaces ausgewertet um entscheiden zu können, WAS überhaupt gezeichnet wird. Abbildung 13.1: Strukturdiagramm für Limited Access Implementation Als erstes muss es eine Implementation der Zuordnung von Benutzern zu Rechten geben. Hier bieten sich SECU- RITY SESSION und CHECK POINT an. Jetzt muss festgelegt werden, wie bestimmte Rechte im User-Interface abgebildet werden. Welche UI-Elemente kann ein Benutzer mit den jeweiligen Rechten sehen. Wenn die Logik um zu entscheiden, was ein Benutzer sehen darf sehr komplex ist, bietet sich entweder SECURITY SESSION als Pufferän, oder man kann FULL ACCESS WITH ERRORS verwenden. Es ist auch möglich rollenspeziefische UI zu verwenden, wenn ROLE BASED ACCESS CONTROL eingesetzt wird. Es muss entschieden werden, wie nicht-zugreifbare Elemente dargestellt werden. Für Daten empfiehlt es sich ganz auszublenden. Bei Menüelementen und Knöpfen ist es empfehlenswert die meistens eingebaute Enabled/Disabled Funktionalität zu nutzen. Zu letzt muss sichergestellt werden, dass man sich bei verteilten Systemen zu sehr auf da UI verlässt. Beispielsweisse könnte ein MitM einen GUI Zugriff simulieren, welcher durch die Checks im GUI verhindert worden wäre, 34

36 ohne jemals das GUI zu "berühren" Consequences pro Der Benutzer sieht Daten für die er nicht authorisiert ist gar nicht erst. pro Der Entwickler muss sich nicht darum kümmern ob ein Zugriff erlaubt ist. ACHTUNG: z.b. bei Web-UIs muss trotzdem der Zugriff Serverseitig geprüft werden. pro Benutzer-Frustration wird verringert. con Durch das fehlen von UI-Elementen kann der Benutzer verwirrt werden. con Das UI kann "kaputtgehen"wenn Elemente entfernt werden. Deshalb bietet es sich an, diese Elemente auszugrauen. con Retrofitting kann sich schwierig gestallten, wenn der Code für das UI stark verteilt ist Known Uses In den meisten Betriebssystemen wird LIMITED ACCESS eingesetzt. Beispielsweise in den Sytemeinstellungen von OS X sind gewisse Bedienelemnte wie zum Beispiel die Firewall-Steuerung ausgegraut, bis sich der Benutzer authentisiert hat. Firewalls selber setzen ähnliche Mechanismen ein. Beispielsweise können sie so konfiguriert werden, dass sie nichtautorisierte Pakete einfach verwerfen, statt mit TCP REJECTED oder ähnlichem zu antworten Relationships CHECK POINT SECURITY SESSION ROLE BASE ACCESS CONTROL 35

37 Kapitel 14 Packet Filter Firewall 14.1 Context Verbindungen zwischen Netzen, welche nicht die gleiche ßicherheits- oder Vertrauensstufe"besitzen. Ein Client im Netz sendet und empfängt diverse Pakete über die Netzgrenze hinaus Problem Clients müssen über die Netzgrenze hinaus kommunizieren können. Was kann unternommen werden, wenn ein fremder Host als bösartig identifiziert wurde? 14.3 Solution Der Einsatz einer Firewall, welche auf einem Port P"jedes Paket anschaut und danach mittels Regeln entscheidet, was z.b. mit Paketen von/an Adresse Ä"geschehen soll. Die Regeln werden dabei in einer Kaskade abgearbeitet, dabei sollte die spezifischste zuerst und die generischste zuletzt angeführt werden. Die letzte Regel ist die Defaultregel, welche zumeist entweder Älles Blockierenöder Älles Erlaubenënthält Structure Abbildung 14.1: Strukturdiagramm für Packet Filter Firewall 36

38 Dynamics Das Sequenzdiagramm zeigt einen fremden Client, welcher durch die PF-FW kommunizieren möchte. Auf den Request werden beim Passieren der Firewall die Regeln angewendet. Abbildung 14.2: Sequenzdiagramm für Packet Filter Firewall Implementation Die Implementation dieses Patterns erfolgt in verschiedenen Schritten: a. Die Unternehmens-Policies auf das Internet äbbilden", es also in "böseßeiten und "guteßeiten unterteilen. b. Firewallregeln daraus erstellen, dies kann manuell oder automatisch (z.b. mit Solsoft) geschehen. c. Firewalls installieren. Dabei muss bedacht werden, dass es nicht immer einen Single Access Point gibt, sondern auch mehrere zu kontrollierende Grenzen existieren können. d. Die Regeln in den Firewalls installieren, auch hier manuell oder automatisch (z.b. mit Solsoft) e. Die Firewalls mit der entsprechenden Standardarchitektur konfigurieren Consequences pro Der IP-Verkehr wird an den Netzgrenzen gefiltert. Dies reduziert das Risiko mit gefährlichen Netzen oder Hosts zu kommunizieren. pro Regeln können einfach erstellt, installiert und angepasst werden. pro Bei einer Umsetzung in Hardware zeigt diese Lösung eine hohe Performance und ermöglicht eine Aufzeichnung jeglicher empfangenen Pakete und den dafür gefällten Entscheidungen. con Level-3 Firewalls können keine Angriffe auf höheren Schichten verhindern. con Verteilte Angriffe können nicht mittels IP matching verhindert werden. con Alle Grenzen müssen mit Firewalls gesichert werden. Es dürfen keine andere Wege ins und aus dem Netz geben, also keine unvorhergesehene Tunnels oder VPN s wie Hamachi. 37

39 14.5 Known Uses IPTables ist sowohl eine Packet Filtering als auch eine Stateful Firewall IPFW ist sowohl eine Packet Filtering als auch eine Stateful Firewall PF ist sowohl eine Packet Filtering als auch eine Stateful Firewall 38

40 Kapitel 15 Proxy Based Firewall 15.1 Context Wir befinden uns in einem Netzwerk in welchem Computersysteme vorhanden sind, die mit Netzwerken vebunden sind, für welche eine höhere Sichrheit benötigt wird als sie PACKET FILTER FIREWALL gewähren kann. Es ist wichtig dass wir die Layer 7 Nachrichten inspizieren können Problem PACKET FILTER FIREWALL überprüft nur die Addressen von Requests. Wenn es einem Angreifer gelingt eine vertrauenswürdige Adresse zu spoofen können wir diese Attacke nicht bemerken. Wir können auch Angriffe welche in den Daten eines Pakets eingebettet sind nicht bemerken. Wir haben folgende Anforderungen: Zugriff von aussen muss möglich sein. Wir müssen eine Vielzahl von verschiedenen Systemen schützen können. Es muss ein klares Modell geben, welches die eingesetzen Schutzmechanismen beschreibt. Die Schutzvorkehrungen müssen die Sicherheits Vorschriften einer Organisation wiedergeben können. Das System muss leicht zu ändern sein um auf neue Angriffe reagieren zu können. Zugriffe müssen geloggt werden können Solution Wir lassen externe Clients nur mit einem Prozy Service kommunizieren. Der Proxy kommuniziert dann mit dem zu schützenden Host. Damit kann der Client nur Daten erhalten, wenn es einen Proxy für das angefragte System gibt. Jeder Proxy hat sein eigenes Regelset. 39

41 Structure Abbildung 15.1: Strukturdiagramm für Proxy Based Firewall Implementation Folgende Schritte werden benoetigt um das System zu implementieren: Festlegung der freigegebenen Dienste Einen Proxy vor jeden Host stellen der erreichbar sein soll Regeln fuer den Zugriff festlegen Regeln in der Rule-Base des Proxys ablegen 15.4 Consequences pro Die Firewall inspiziert und filtert jeden Request. pro Der Lokale Rechner wird vor seinem Client versteckt. pro Jeder Request kann aufgezeichnet werden. pro Es werden nicht mehr nur die Adressen sondern auch Struktur un Inhalt der Pakete untersucht. con Möglicherweisse hohe Kosten auf Grund von Anschaffung und Konfiguration der Proxies. con Verminderte Performance, da jedes Paket untersucht werden muss. con Höhere Komplexität 40

42 Kapitel 16 Stateful Firewall 16.1 Summary Eine Stateful Firewall filtert einkommenden und ausgehender Netzwerk-Verkehr aufgrund von Statusinformationen die auf bisheriger Kommunikation basiert. Statusinformationen beschreiben, ob das Paket Teil einer neuen oder bestehenden Verbindung ist. Der Status beschreibt also den Kontext eines Pakets Context Systeme eines lokalen Netzwerks, die mit dem Internet oder anderen externen Netzwerken verbunden sind und Paket Filter für die Sicherheit nicht ausreichen Problem Wie können eingehende Pakete korrelieren werden? 16.4 Solution Generiere eine Liste mit den Verbindungen die geöffnet wurden und korreliere den gesendeten oder empfangenen Nachrichtentyp. Das bietet die Möglichkeit, dass die Pakete einer bereits geöffneten Verbindung nicht inspiziert werden müssen Implementation Generiere eine Liste mit den Attacken-Typen, welche verhindert werden sollen. Implementiere das Rule-Set so, dass die oben definierten Pakete mit ihm korrelieren Consequences pro Es ist relativ einfach, die Statustabelle aufzubauen, wenn die zu erwarteten Attacken bekannt sind. pro Die Implementationskosten sind relativ gering. pro Da nur die Paket-Header analysiert werden müssen und für bestehende Verbindungen nur in die Statustabelle geschaut werden muss, wird eine gute Performance erreicht. pro Mit einer Stateful Firewall kann die Sicherheit von anderen Firewall-Typen erhöht werden, da Informationen auf verschiedenen Levels hinzugefügt werden. 41

43 pro Bei neuen Attacken werden lediglich zusätzliche Wege benötigt, um auch diese Pakete korrelieren zu können. pro Connectione-based Logging wird unterstützt. Das kann nützlich sein, um neue Arten von Attacken zu erkennen. con Attacken könnten sich die Problematik einer vollen Statustabelle zu Nutze machen con Patterns zu Attacken müssen definiert und implementiert werden, damit sie erkannt und verhindert werden können Relationships PACKET FILTER FIREWALL PROXY-BASED FIREWALL 42