23.08.2013 Aufrufe

Öffentliche Netzzugänge an der Uni Hamburg Inhalt - DFN-CERT

Öffentliche Netzzugänge an der Uni Hamburg Inhalt - DFN-CERT

Öffentliche Netzzugänge an der Uni Hamburg Inhalt - DFN-CERT

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

<strong>Öffentliche</strong> <strong>Netzzugänge</strong><br />

<strong>an</strong> <strong>der</strong> <strong>Uni</strong> <strong>Hamburg</strong><br />

Dr. Carsten Benecke<br />

Regionales Rechenzentrum<br />

<strong>Uni</strong>versität <strong>Hamburg</strong><br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

• Motivation<br />

25./26. Februar 2003 in <strong>Hamburg</strong><br />

Dr. Carsten Benecke Carsten.Benecke@rrz.uni-hamburg.de<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

<strong>Inhalt</strong><br />

• Anfor<strong>der</strong>ungen <strong>an</strong> öffentliche <strong>Netzzugänge</strong><br />

• Lösungs<strong>an</strong>sätze<br />

• Technische Umsetzung <strong>an</strong> <strong>der</strong> <strong>Uni</strong> <strong>Hamburg</strong><br />

• Erweiterungsmöglichkeiten<br />

• Zusammenfassung<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

1


Motivation<br />

• Dramatische Zunahme mobiler Rechner (Laptops)<br />

• Zugriff auf Netzressourcen <strong>der</strong> <strong>Uni</strong> erwünscht:<br />

+ Arbeitserleichterung für Studenten<br />

+ Arbeitserleichterung für PC-Pool-Personal<br />

+ Flächenversorgung mit Arbeitsplätzen<br />

• Aber: z.Z. keine (offiziellen) <strong>Netzzugänge</strong> für<br />

private Rechner „öffentliche <strong>Netzzugänge</strong>“<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Motivation<br />

„<strong>Öffentliche</strong>r Netzzug<strong>an</strong>g“, was ist das?<br />

• Neuer Dienst <strong>an</strong> öffentlichen Orten <strong>der</strong> <strong>Uni</strong><br />

- Bibliotheken, Eing<strong>an</strong>gsbereiche, Hörsäle<br />

• Für Studierende und MitarbeiterInnen<br />

• Kabel-basierter und kabelloser (WLAN) Zug<strong>an</strong>g<br />

• Anschluß eigener Geräte mit eigener Hardware<br />

(Schnittstellen werden nicht bereitgestellt!)<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

2


Anfor<strong>der</strong>ungen <strong>an</strong> öffentliche<br />

<strong>Netzzugänge</strong><br />

• <strong>Uni</strong>versitätsübergreifende Lösung<br />

– Unabhängig von <strong>der</strong> dezentralen Campusstruktur<br />

– Unabhängig von <strong>der</strong> jeweiligen Fachbereichsstruktur<br />

• „Skalierbarkeit“<br />

– Potentiell hohe Anzahl von Benutzern<br />

– Ständig wechselnde BenutzerInnen<br />

• Neueinschreibungen<br />

• Exmatrikulation<br />

• Hohe Mitarbeiterfluktuation (z.B. befristete Stellen)<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Anfor<strong>der</strong>ungen <strong>an</strong> öffentliche<br />

<strong>Netzzugänge</strong><br />

• Unabhängigkeit von <strong>der</strong> Netztechnologie<br />

– Zug<strong>an</strong>gsbereich („Access-Bereich“):<br />

• Kabel-basierte Zugänge<br />

– Strukturierte Verkabelung<br />

– „Legacy“-LANs (BNC/„CheaperNet“)<br />

• Kabellose Zugänge (Funkzugänge)<br />

– Wireless LAN (z.Z. IEEE 802.11b)<br />

– Kernnetz („Backbone“)<br />

• Subnetz-Routing vs. „VLAN-Switching“<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

3


Anfor<strong>der</strong>ungen <strong>an</strong> öffentliche<br />

<strong>Netzzugänge</strong><br />

• Kontrollierter Zugriff auf das Internet<br />

– Zugriff erst nach erfolgreicher Authentifikation<br />

• Nur für Studierende und MitarbeiterInnen<br />

– Zugriff nur auf bestimmte Dienste<br />

• Sicherheitsaspekte beachten<br />

–Z.B. keine „Filesharing“-Protokolle“<br />

• Leistungsengpässe vermeiden<br />

–Z.B. keine „P2P“-Protokolle<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Anfor<strong>der</strong>ungen <strong>an</strong> öffentliche<br />

<strong>Netzzugänge</strong><br />

• Aufw<strong>an</strong>dsarme Administration<br />

– Vorh<strong>an</strong>dene Benutzerdatenb<strong>an</strong>ken benutzen<br />

• Vermeiden von zusätzlicher Verwaltung<br />

– Einfaches Authentifikationsverfahren<br />

• Vermeiden von Beratungsaufw<strong>an</strong>d<br />

– Unkomplizierte Technik(en) verwenden<br />

• Vermeiden von Spezialwissen<br />

• Erhöhen <strong>der</strong> Robustheit <strong>der</strong> Infrastruktur<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

4


Anfor<strong>der</strong>ungen <strong>an</strong> öffentliche<br />

<strong>Netzzugänge</strong><br />

• Kosteneffizienz<br />

– Kosten pro Anschluß müssen gering sein<br />

– Beschaffungskosten<br />

– Installationskosten<br />

• WLAN vs. Kabel<br />

• „Vermessen vs. Verlegen“<br />

– Betriebskosten<br />

– Migrationskosten<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Anfor<strong>der</strong>ungen <strong>an</strong> öffentliche<br />

<strong>Netzzugänge</strong><br />

• Herstellerunabhängigkeit<br />

¡<br />

– Vermeiden von proprietären Lösungen<br />

– Vermeiden <strong>der</strong> Präjudiz durch Erstbeschaffung<br />

– Vermeiden von Vorgaben für die Anwen<strong>der</strong><br />

– Offenbleiben für neue St<strong>an</strong>dards/Technologien<br />

Gewichtung aus Sicht des Betreibers<br />

– Aufw<strong>an</strong>dsarme Administration<br />

– Sichere Authentifikation, Herstellerunabhängigk.<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

5


Lösungs<strong>an</strong>sätze (für Authentifikation)<br />

• Medium-spezifische Authentifikation<br />

– WEP-Verschlüsselung (Schlüsselkenntnis)<br />

– IEEE 802.1x (z.B. Radius-Abfrage)<br />

• VPN-Techniken<br />

– RAS, L2TP, PPTP, IPSec<br />

• Authentifikation auf <strong>der</strong> Anwendungsebene<br />

– WEB-basierte Authentifikation am Firewall<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Medium-spezifische Authentifikation<br />

– Hauptnachteil: Mehrere Techniken erfor<strong>der</strong>lich!<br />

– WEP ist unsicher<br />

– Schwache Verschlüsselung<br />

– Symmetrischer Schlüssel für alle Benutzer?<br />

– Proprietäre Ansätze unbrauchbar<br />

– IEEE 802.1x nur für strukturierte Verkabelung<br />

– Keine Verschlüsselung<br />

– Was tun bei „shared Medium“ LANs ?<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

6


VPN-Techniken<br />

– Häufig proprietär (PPTP und RAS)<br />

– Funktioniert (gut) mit Windows<br />

– Was tun wir mit Mac- und <strong>Uni</strong>x-Benutzern?<br />

– Erheblicher Verwaltungsaufw<strong>an</strong>d<br />

– IPSec erfor<strong>der</strong>t PKI<br />

–viel Arbeit für Inbetriebnahme (PKI-Konzept)<br />

–viel Arbeit im laufenden Betrieb (Zertifikate)<br />

+ IPSec: „unschlagbare Sicherheit“<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

VPN-Techniken<br />

– Erheblicher Aufw<strong>an</strong>d für VPN-Gateways<br />

– Neue/unbek<strong>an</strong>nte aktive Komponenten<br />

–„Kryptoboxen“ für Ver-/Entschlüsselung<br />

–Verzeichnisdienste (Zertifikate verwalten)<br />

– Zusätzliche Komponenten (Portpreise!)<br />

–Spezialhardware („Appli<strong>an</strong>ces“) ist teuer<br />

–M<strong>an</strong>agement <strong>der</strong> neuen Komponenten<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

7


Authentifikation auf<br />

Anwendungsebene<br />

+ Geringer Administrationsaufw<strong>an</strong>d<br />

+ Keine Benutzerzertifikate<br />

+ Verwendet vorh<strong>an</strong>dene Benutzerdatenb<strong>an</strong>ken<br />

+ Abstrahiert von Netzeigenschaften<br />

+ Geeignet für WLAN und kabel-basierte Zugänge<br />

+ Geeignet für „shared“ und strukturierte Netze<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

+ Geringe Kosten<br />

Authentifikation auf<br />

Anwendungsebene<br />

+ Spezialisierte Hardware ist nicht erfor<strong>der</strong>lich<br />

+ Herkömmliche FWL-Technik auf <strong>Uni</strong>versal-HW<br />

+ Leicht zu skalieren (Neue <strong>Uni</strong>versal-HW)<br />

+ Alternative Authentifikationsverfahren (freie SW!)<br />

+ „WWW-Authentifikation“<br />

+ „SSH-Authentifikation“<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

8


Authentifikation auf<br />

Anwendungsebene<br />

– Ambivalente Sicherheit<br />

– Schutzniveau ist abhängig von Anwendung<br />

– Einsatz unsicherer Dienste/Protokolle?<br />

– Nicht alle Dienste/Protokolle verwendbar<br />

+ Möglicher Ausweg<br />

+ STunnel für beliebte Dienste (z.B. Druckdienst)<br />

± Dienst<strong>an</strong>gebot abhängig vom Medium?<br />

iBook<br />

Laptop<br />

Kabel<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Authentifikation auf<br />

Anwendungsebene<br />

Access Point<br />

<strong>Öffentliche</strong>s Netz<br />

(z.Z. 134.100.23.0/24)<br />

Gateway<br />

DNS/Radius/Mail/Proxy<br />

IP-Backbone<br />

<strong>der</strong> <strong>Uni</strong><br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

zum Internet<br />

9


Authentifikation auf<br />

Anwendungsebene<br />

Gründe für Authentifikation auf Anwendungsebene<br />

+ Plattformunabhängigkeit, Mediumunabhängigkeit<br />

+ Herstellerunabhängigkeit<br />

+ Geringe Kosten<br />

+ <strong>Uni</strong>versalhardware für Authentifikation/Gateway<br />

+ Freie Software (OpenSSH, PAM-Radius, s.u.)<br />

+ Gute Skalierbarkeit, Erweiterbarkeit, Migrationsfähigkeit<br />

+ Software liegt im Quellcode vor (auch das OS!)<br />

+ Hardware (<strong>Uni</strong>versalrechner) „wird von alleine schneller“<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Grundsätzlich gilt:<br />

Authentifikation auf<br />

Anwendungsebene<br />

– Benutzer verbindet sich mit dem Gateway<br />

– Gateway befragt vorh<strong>an</strong>dene Benutzerdatenb<strong>an</strong>k<br />

– Bei gültigem Namen/Passwort:<br />

– Gateway autorisiert IP-Adresse des Benutzers<br />

– Gateway überprüft Erreichbarkeit des Benutzers<br />

– Gateway hebt ggf. Autorisation wie<strong>der</strong> auf<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

10


Technische Umsetzung <strong>an</strong> <strong>der</strong> UHH<br />

• Zu lösende Probleme<br />

– Plattformunabhängigkeit (WIN, MAC, UNIX)<br />

– Zugriff auf vorh<strong>an</strong>dene Benutzerdatenb<strong>an</strong>k<br />

– Sichere Authentifikation<br />

– Autorisation (kontrollierte Dienstfreigabe)<br />

– <strong>Uni</strong>versitätsübergreifende Lösung<br />

– Vermeiden von administrativem Aufw<strong>an</strong>d<br />

– Migrationstr<strong>an</strong>sparenz<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Technische Umsetzung <strong>an</strong> <strong>der</strong> UHH<br />

Ablauf <strong>der</strong> Anmeldung<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

11


Technische Umsetzung <strong>an</strong> <strong>der</strong> UHH<br />

Benutzer schließt das Gerät <strong>an</strong><br />

• Bereiche sind durch Plakate markiert<br />

• Blau markierte Dosen ¡<br />

<strong>Öffentliche</strong> Anschlüsse<br />

+ Einheitliche Markierung<br />

• SSID: UHH-- ¡<br />

AP <strong>der</strong> UHH<br />

+ Einheitliche Namenskonvention<br />

• Netzkonfiguration mittels DHCP<br />

+ Ortsunabhängigkeit<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Technische Umsetzung <strong>an</strong> <strong>der</strong> UHH<br />

Benutzer baut SSH-Verbindung auf<br />

• Gateway mit zusätzlicher privater Adresse<br />

+ Kennung und Passwort werden gesichert<br />

(trotz Funk o<strong>der</strong> <strong>an</strong><strong>der</strong>er Broadcast-Medien)<br />

+ Einheitliche Adresse (VLAN vs. Routing)<br />

+ Identisches Zertifikat<br />

¡<br />

Ortsunabhängige Einstellungen beim Benutzer<br />

(trotz potentiell multipler Gateways)<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

12


Technische Umsetzung <strong>an</strong> <strong>der</strong> UHH<br />

PAM verwaltet Benutzerauthentifikation<br />

• Modular aufgebaut<br />

+ Modul für „nologin“-Sem<strong>an</strong>tik (alle sperren)<br />

+ Modul für Sperrliste (Individuen sperren)<br />

+ Module für LDAP- und <strong>an</strong><strong>der</strong>e Formate<br />

+ Modul für Radius-Anfrage und –Accounting<br />

• Zur Laufzeit adaptierbar!<br />

¡<br />

Flexibilität bei allen „AAA“-Aufgaben<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Technische Umsetzung <strong>an</strong> <strong>der</strong> UHH<br />

Shell für Autorisation und Interaktion<br />

• Automatisiert die Autorisation<br />

• Interagiert mit dem Benutzer (individuell o<strong>der</strong> alle)<br />

– Bei geglückter Anmeldung (individuell)<br />

– Bei m<strong>an</strong>ueller Abmeldung (individuell)<br />

– Bei administrativer Vorgabe (individuell o<strong>der</strong> alle)<br />

• Zeigt sich beim „ps“-Komm<strong>an</strong>do mit<br />

– Benutzerkennung und zugewiesener IP-Adresse<br />

¢ Erleichtert die Administration<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

13


Technische Umsetzung <strong>an</strong> <strong>der</strong> UHH<br />

Zugriffskontrolle mit Firewall-Techniken<br />

+ Aufw<strong>an</strong>dsarme, gut verst<strong>an</strong>dene Technik<br />

• Allgemeine Filterregeln und Client-spezifische Filterregeln<br />

– <strong>Uni</strong>versell für alle konfiguriert<br />

• DHCP, DNS, Zugriff auf WWW-Proxy mit HTTP(s),<br />

SSH ins Internet, Zugriff auf Mail-Server <strong>der</strong> UHH<br />

(nur SSL-Ports: IMAPs, POPs, SMTPs)<br />

– Individuell durch Shell für jeweiligen Client konfiguriert<br />

• Aktuelle IP-Adresse des autorisierten Benutzers<br />

¢ Flexibilität beim Dienst<strong>an</strong>gebot, gute Skalierbarkeit<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Beispiel/Anmeldung 1/4<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

14


Beispiel/Anmeldung 2/4<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Beispiel/Anmeldung 3/4<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

15


Beispiel/Anmeldung 4/4<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Erweiterungsmöglichkeiten<br />

• Weitere Dienste freischalten<br />

– Unkritische Dienste direkt freischalten<br />

– Kritische Dienste z.B. über „STunnel“<br />

• Verhin<strong>der</strong>n von ClientClient-Kommunikation<br />

(UHH soll nicht zur Spieleplattform werden!)<br />

• Einführen von Flusskontrolle (Intr<strong>an</strong>et vs. Internet)?<br />

• Einführen von Audit-Funktionen<br />

– Bald vom Gesetzgeber vorgegeben?<br />

– Zum Auffinden von Problemen/Hackern?<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

16


Zusammenfassung<br />

• „<strong>Öffentliche</strong> <strong>Netzzugänge</strong>“ <strong>an</strong> <strong>der</strong> UHH sind:<br />

+ Ein neuer Dienst für Studierende und MAs<br />

+ Unabhängig von <strong>der</strong> Übertragungstechnik<br />

+ <strong>Uni</strong>versitätsübergreifend realisierbar<br />

+ Kostengünstig und pflegeleicht<br />

• Nur sichere o<strong>der</strong> öffentliche Anwendungen erlaubt<br />

+ Zugriffskontrolle mit Firewall-Techniken<br />

± Freischalten von sicheren Anwendungen<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

Zusammenfassung<br />

• Einsatz von SSH ermöglicht:<br />

+ Unabhängigkeit von Client-Zertifikaten<br />

+ Sichere Passwort-Abfrage über unsichere Netze<br />

+ Nachrichtenvers<strong>an</strong>d <strong>an</strong> die Benutzer<br />

• Einsatz von PAM ermöglicht:<br />

+ Flexible Konfiguration von „AAA“-Aktionen<br />

+ Zugriff auf vorh<strong>an</strong>dene Benutzerdatenb<strong>an</strong>ken<br />

10. Workshop „Sicherheit in vernetzten Systemen“<br />

<strong>Uni</strong>versität <strong>Hamburg</strong> Regionales Rechenzentrum<br />

17

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!