Ö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
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