Vor einem Monat haben wir einen Blogeintrag veröffentlicht, in dem wir eine Analyse zur Sicherheit deutscher Krankenhaus-Webserver vorgestellt haben. Die Ergebnisse zeigten, dass ein Großteil jener Server, die ihre Versionsnummer offenlegten, eine beachtliche Zahl bekannter Schwachstellen aufwies. In diesem Beitrag widmen wir uns nicht den Resultaten, sondern der Methodik: Wie wurden die Daten erhoben, welche Schritte waren nötig und welche Herausforderungen traten dabei auf?
Datenbasis
Der erste Schritt bestand darin, eine verlässliche und möglichst vollständige Liste deutscher Krankenhäuser zu erstellen. Eine intuitive Quelle sind offene Kartendienste wie OpenStreetMap (OSM). Mit der Overpass API zum Beispiel, lassen sich von dort Daten in strukturierter Form abfragen. Auf diese Weise erhält man zwar eine schnelle Übersicht, die communitybasierte Natur von OSM bringt jedoch typische Probleme mit sich: inkonsistente Benennungen, fehlende Attribute, veraltete Einträge und Duplikate. Für eine solide Analyse erwies sich die Datenqualität deshalb als unzureichend.
Da Krankenhäuser in Deutschland gesetzlich streng reguliert und registriert sein müssen, haben wir uns stattdessen auf offizielle Quellen gestützt. Besonders relevant sind hier die öffentlichen Verzeichnisse der Deutschen Krankenhausgesellschaft (deutsches-krankenhaus-verzeichnis.de) sowie des Bundesministeriums für Gesundheit (bundes-klinik-atlas.de). Da der Klinik-Atlas jedoch politisch unter Druck stand und von einer möglichen Abschaltung bedroht war, entschieden wir uns für das stabilere Krankenhausverzeichnis. Ergebnis: eine hochwertige und strukturierte Liste mit 2.417 Krankenhäusern, ergänzt um Detailinformationen wie Standort, Bettenzahlen und Trägernamen.
Ermittlung von IP-Adressen
Um später die Sicherheit eines Krankenhauses mithilfe eines Netzwerkscans untersuchen zu können, müssen jedoch noch die zugehörigen IP-Adressen identifiziert werden. Während private Internetanschlüsse in der Regel dynamische IPs aus einem großen Pool erhalten, werden größeren Institutionen wie Krankenhäusern statische Netzblöcke zugewiesen. Verantwortlich dafür sind die sogenannten Regional Internet Registries (RIRs). Für Europa, den Mittleren Osten und Teile Zentralasiens übernimmt diese Rolle das RIPE NCC (Réseaux IP Européens Network Coordination Centre).
Die RIPE-Datenbank stellt öffentlich zugängliche Informationen über IP-Blöcke und deren Halter bereit. In der Praxis erfolgt der Zugriff oft über die REST-API, wir haben uns jedoch für einen Download der Datenbank entschieden um Rate-Limits zu vermeiden. Ein typischer Eintrag enthält Felder wie:
inetnum: Adressbereich (z.B. 192.168.0.0 – 192.168.255.255)netname: Name des Netzblocksdescr: Beschreibung, oft inkl. Organisation
Das Hauptproblem: Die offiziellen Krankenhausnamen aus dem Verzeichnis stimmen selten exakt mit den in RIPE eingetragenen Organisationsnamen überein. Eine automatisierte Zuordnung erfordert deshalb eine Reihe von zusätzlichen Bearbeitungsschritten:
- Umfassende Normalisierung: Unter anderem die Kleinschreibung aller Namen, Ersetzung von Umlauten, und die Entfernung von Sonderzeichen
- Reihenfolgeunabhängigkeit: Tokenisierung der Namen (z.B. „Klinikum München Süd“ → [klinikum, muenchen, sued]) und Matching unabhängig von der Wortreihenfolge
- „Fuzzy Matching“: Einsatz von Ähnlichkeitsmetriken, wie der Levenshtein-Distanz, um Tippfehler, Abkürzungen oder orthografische Unterschiede auszugleichen
- Mehrfaktorabgleich: Heranziehen von zusätzlichen Merkmalen wie Adresse, Webseitendomäne und Trägername
Durch diese mehrstufige Matching-Pipeline konnten wir rund 80 % der Krankenhäuser eindeutig mindestens einem IP-Adressblock zuordnen. Für die restlichen 20 % war die Datenlage zu unscharf oder es existierten keine expliziten Netzblockeinträge im RIPE-Register.
Man sieht: Eine solide Datenbasis ist wichtig, aber oft anspruchsvoller als gedacht. Im nächsten Beitrag werden wir darauf aufbauend erläutern, wie wir die eigentlichen Scans durchgeführt und die gefundenen Schwachstellen ausgewertet haben.