1 / 22

Policy-basiertes Management für Netzsicherheit mit Flexibilität

Policy-basiertes Management für Netzsicherheit mit Flexibilität. Matthias Müller Willi Fries Reinhard Strebler Hannes Hartenstein Universität Karlsruhe. Vorstellung. Dipl.-Inform. Matthias Müller Studium: Informatik an der Universität Karlsruhe (TH)

harlan-paul
Download Presentation

Policy-basiertes Management für Netzsicherheit mit Flexibilität

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Policy-basiertes Management für Netzsicherheit mit Flexibilität Matthias Müller Willi Fries Reinhard Strebler Hannes Hartenstein Universität Karlsruhe

  2. Vorstellung • Dipl.-Inform. Matthias Müller • Studium: Informatik an der Universität Karlsruhe (TH) • Seit 1999 am Rechenzentrum der Universität Karlsruhe beschäftigt • Abteilung Netze und Kommunikation • Netzwerksicherheit • Policy Management • 802.1X • VPN • E-Mail: matthias.mueller@rz.uni-karlsruhe.de • http://www.rz.uni-karlsruhe.de/personen/matthias.mueller.php

  3. Einleitung und Historie • Ziel: „angemessenes“ Sicherheitsniveau • Riskio <-> Kosten <-> Aufwand • Sehr viele Einrichtungen mit unterschiedlichsten Anforderungen • Erste Angriffe: Einführung von Blacklists am Internetzugang • Eindeutiger Perimeter verschwimmt immer mehr • WLAN • VPN • Individuelle Anforderungen angeschlossener Einrichtungen • Don‘t Care • Dedizierte Firewalls wegen Industrieprojekten • Reine Clientnutzung • Serverdienste nur für einzelne andere Einrichtungen

  4. Gliederung • Anforderungen und Ziele • Architektur • Frontend • Datenhaltung • Netzwerkumsetzung • Umsetzung • Frontend • Datenhaltung • Schnittstelle zur Netzebene • Netzwerk • Erfahrungen und Bewertung • Ausblick

  5. Sicherheitsniveau Dedizierte Firewallsysteme ?? Stufe 3 Private IP Adressen mit NAPT und NAT Stufe 2 Standardfilter am Uplink-Router Stufe 1 Stufe 0 Universität gegenüber Welt Einrichtung gegenüber Welt+Universität

  6. Einleitung und Historie • „Stufe 0“ • Kontrolle über Standardfilter am Uplink-Router • Hoher administrativer Aufwand • „Stufe 1“ • Private IP Adressen mit NAPT und NAT • Konfiguration über Webfrontend • Eingeschränkte Regeldefinition • Automatisches Regelupdate • „Stufe 3“ • Dedizierte Firewallsysteme • Zentrale Administration durch Netzbetreiber • Hoher administrativer Aufwand • Hohe Kosten

  7. Anforderungen und Ziele „Stufe 2“ • Anforderungen aus Sicht des Netzbetreibers • Sicherheitsniveau zwischen reinem Perimeterschutz und dedizierten Firewalls • Herstellerunabhängigkeit • Gemeinsame Komponentennutzung durch mehrere Einrichtungen • Skalierbar für beliebig viele Einrichtungen • Sicherheitsniveau ausreichend für 90% der Einrichtungen • Hierarchische Policydefinition • Policydefinition durch Betreuer der Einrichtung • Durchsetzung zentraler Policies • Minimierung des Migrationsaufwands

  8. Anforderungen und Ziele • Anforderungen aus Sicht des Netznutzers • Self-Service mit definierten Umsetzungszeiten • Absicherung an der Einrichtungsgrenze • Ease of Use • Flexible Einstellungsmöglichkeiten • Einheitliche Policydefinition unabhängig von der Umsetzung • VPN Zugang ins eigene Netze mit Definition der Zugangsberechtigten

  9. Architektur • Trennung • Frontend zur Policydefinition User-/Adminfrontend + Skripting • Datenhaltung Abstrakte Policydefinition • Netzwerkumsetzung Umsetzung der Sicherheits-policies • Orientiert sich am „IETF/DMTF Policy Model“ • Schnittstellen • Feste Schnittstellendefinition • Schichten agieren unabhängig voneinander • Authentisierung und Autorisierung

  10. Architektur: Frontend • Rollenverteilung: Administrator und Betreuer • Betreuer: • Definition der Policy nur für den eigenen Bereich • Kein Überschreiben zentraler Policy-Vorgaben • Administrator: • Definition zentraler Policy-Vorgaben • Ausnahmen für einzelne Einrichtungen • Kontrolle der Zugangsberechtigungen an der Schnittstelle zur Datenhaltung

  11. Architektur: Datenhaltung • Modellierung der Netzsicherheitspolicy unabhängig von • Benutzerfrontend • Netzwerkimplementierung • Dienst als zentrales Element: • Wird von einer Einrichtung • Angeboten • Genutzt • Gesperrt • Charakterisiert durch Dienstparameter • Hierarchische Organisation der Einrichtungen • Vererbung von Policy-Vorgaben

  12. Architektur: Netzwerkumsetzung • Kontrolle am Uplink der Einrichtung • Bezeichnet als „Stufe 2“ • Angestrebtes Sicherheitsniveau zwischen „Stufe 1“ und „Stufe 3“ • Einsatz vorhandener Hardware: • Cisco Router Catalyst 6500 • Cisco VPN-Konzentratoren VPN 3060 • Linux basierte NAT-Router

  13. Umsetzung: Frontend • Webbasiertes Frontend • Barrierefreiheit • Dreiteilung: • Verwaltung der VPN-Benutzer • Nutzung/Verbot von Diensten: • Übersicht aktuell genutzter/gesperrter Dienst • Übersicht angebotener Dienste • Einschränkung von Nutzung/Verbot auf Teilbereiche des Netzes • Anbieten von Diensten: • Dienstmodellierung (TCP/IP Parameter) • Definition wer Dienste nutzen/nicht nutzen darf

  14. Umsetzung: Datenmodell • Dienst als zentrales Element • Von Einrichtung betrieben, definiert und zur Verfügung gestellt • Flexible Modellierung der Dienstparameter • TCP/IP, QoS, IPv6 • Dienst von genau einer Einrichtung definiert • Hierarchische Ordnung der Einrichtungen • Einrichtungen sind Subnetze, Benutzer und Gruppen zugeordnet • Einrichtung erlaubt und sperrt eigene Dienste für andere • Einrichtung nutzt oder sperrt fremde Dienste • Benutzer- und Rechteverwaltung über Kopplung an bestehendes DB-System (DNSVS)

  15. Umsetzung: Datenmodell

  16. Umsetzung: Schnittstelle zur Netzebene <policydef><policy> <policyname>uni</policyname> <subnet><net>129.13.0.0/16</net><subnetname>uni/1</subnetname></subnet> <rule type="acl" action="deny" direction="out" class="200" seq="1001" src="localnets" dst="any" proto="ospf"/> <rule type="acl" action="deny" direction="out" class="200" seq="1003" src="localnets" dst="any" proto="udp" dstport="snmp"/> <policy> <policyname>rz-netze-s1</policyname> <subnet><net>172.21.100.0/25</net><subnetname>rz-netze-s1/1</subnetname></subnet> <group> <groupid><groupname>rz-netze-s1</groupname><subnet>172.21.133.16/28</subnet></groupid> <userid><user>rz123</user><ip>172.21.133.17</ip></userid> </group> <rule type="acl" action="permit" direction="out" class="100" seq="1000" src="localnets" dst="any" proto="udp" dstport="snmp"/> <rule type="acl" action="permit" direction="out" class="500" seq="1000" src="localnets" dst="uni" proto="any"/> <rule type="acl" action="permit" direction="out" class="500" seq="1001" src="localnets" dst="any" proto="any"/> <rule type="napt" action="permit" direction="out" class="900" seq="1000" src="localnets" dst="any" proto="any"/> </policy></policy></policydef> • XML Format mit RELAX NG definiert • Kernelement: Policydefinition • Basisblöcke pro Policydefinition: • Gültigkeitsbereich (Subnetze, Benutzer, Gruppen) • Regeln (ACL, NAT, NAPT) • Policy kann weitere Sub-Policies enthalten • Referenzierung anderer Gültigkeitsbereiche

  17. Umsetzung: Netzwerk (1. Ansatz) • Realisierung mit NAT/NAPT an Bereichsgrenze • Analog zu „Stufe 1“: • NAT-Router an Bereichsgrenze • IP-Addressumsetzung auch zur Universität • Probleme: • Mangelnde NAT-Transparenz • Teilweise lösbar über direktes Routing • DNS-Problematik • => erfüllt die Anforderungen nicht

  18. Umsetzung: Netzwerk (Implementierung I) • NAT/NAPT nur noch bei Bedarf zum Internet • Linux-Router für NAT/NAPT am zentralen Internet-Uplink • Durchsetzung der Filterregeln nur auf Zugangsinterface • Vereinfachung des Designs • NAT-Router treffen keine Filterentscheidung Cisco-Router beherrschen keine Statefull Packet Inspection • Reflexive ACLs für nicht TCP-Verbindungen (max 96k) VPN-Zugang über zentrale VPN-Konzentratoren • Pro Einrichtung eine Gruppe • Gleiche Regeln für VPN-Benutzer wie für die Einrichtung

  19. Umsetzung: Netzwerk (Implementierung II)

  20. Umsetzung: Netzwerk (Implementierung III) • Automatisierte Konfigurations-erstellung aus XML-Definition • Zusätzlich Topologie-informationen aus DB • Übertragung der eigentlichen Konfiguration über geräte-spezifische Mechanismen: • telnet/tftp • ssh/scp • Geplant: einheitliche Konfiguration über NETCONF

  21. Erfahrungen und Bewertung • Policy-basiertes Management steigert das Netzwerksicherheitsniveau deutlich • Absicherung an Bereichsgrenze • Erreicht nicht das Sicherheitsniveau dedizierter Firewalls • Self-Service für den Benutzer im Vordergrund: • Eigenständige Definition der eigenen Policy • Garantierte Reaktionszeit durch Automatismus • Einfache Definition zentraler Policies durch Administrator • Verringerung des Migrationsaufwands: • Kein Wechsel des IP-Bereichs nötig • Wechsel zwischen verschiedenen Netzimplementierungen einfach (NAT <-> Filter) • Gute Skalierbarkeit: • 75 Bereiche pro Catalyst 6500 mit Sup720 • 150 Bereiche pro VPN-Konzentrator Paar

  22. Ausblick • Einsatz für alle Bereiche: • Ersatz von „Stufe 0“ und „Stufe 1“ • Auch für dedizierte Firewalls einsetzbar? • Automatische Konfiguration  hohe Sicherheitsanforderungen • Vereinfachte Policydefinition  hohe Komplexität • Migration auf Standards (NETCONF, COPS), sobald • Benötigte Funktionalität vorhanden • In den Netzkomponenten implementiert • Ausweitung auf Layer 2 Zugangspunkt: • 802.1X • NAC

More Related