In fünf Schritten in die DFN-Cloud - DFN-Verein
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Deutsches Forschungsnetz | DFN Mitteilungen Ausgabe 88 | Mai 2015
www.dfn.de
Mitteilungen
In fünf Schritten in die
DFN-Cloud
X-WiN – GÉANT – SINET: DFN-NeMo:
Globales VPN für deutsch-japanische Erkennung und Bearbeitung von
Weltraum-Mission DDoS-Angriffen im X-WiN
2 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | DFN-VEREIN
DFN-VEREIN | DFN Mitteilungen Ausgabe 88 | 3
Nachruf
Der Verein zur Förderung eines Deutschen Forschungsnetzes e. V. zes maßgeblich mitgeprägt und sich dadurch größte Verdienste
trauert um seinen langjährigen Vorstandsvorsitzenden für die Wissenschaft erworben.
Prof. Dr.-Ing. Eike Jessen Durch eine Vielzahl von Ehrenämtern in der Wissenschaft, als
28. August 1933 bis 18. März 2015 Träger des Bundesverdienstkreuzes am Bande und als Fellow
der Gesellschaft für Informatik hat sich Eike Jessen bis ins letzte
Lebensjahr hinein für das Deutsche Forschungsnetz engagiert
Als eine treibende programmatische Kraft, Gründungsvorstand und die Vision des DFN in Wissenschaft, Wirtschaft und Politik
und langjähriger Vorstandsvorsitzender des DFN-Vereins hat sich vertreten und vorangetrieben.
Eike Jessen herausragend um den Aufbau des Deutschen For-
schungsnetzes und die Einführung und Verbreitung der rech- Unser tief empfundenes Mitgefühl gilt seiner Familie, seinen
nergestützten Datenkommunikation in Deutschland verdient Freunden und Wegbegleitern.
gemacht.
Lieber Herr Jessen, herzlichen Dank für alles – Sie werden uns
Eike Jessen wurde als hervorragender und international aner- fehlen.
kannter Wissenschaftler im Bereich der Informatik und insbe-
sondere der Datennetze weit über das Forschungs- und Wissen- Prof. Dr. Hans-Joachim Bungartz
schaftsumfeld hinaus geachtet und gehört. Mehr als drei Jahr- im Namen der Mitglieder und der Mitarbeiterinnen und Mitar-
zehnte lang hat er die Entwicklung des Deutsches Forschungsnet- beiter des DFN-Vereins
Impressum Herausgeber: Verein zur Förderung eines Deutschen Forschungsnetzes e. V. DFN-Verein Alexanderplatz 1, 10178 Berlin Tel.: 030 - 88 42 99 - 0 Fax: 030 - 88 42 99 - 70 Mail: dfn-verein@dfn.de Web: www.dfn.de ISSN 0177-6894 Redaktion: Kai Hoelzner (kh) Gestaltung: Labor3 | www.labor3.com Druck: Bloch&Co, Berlin © DFN-Verein 05/2015 Fotonachweis: Titelfoto © infinity / fotolia Seite 8/9 © chungking / fotolia Seite 10 © R9_RoNaLdO / iStock Seite 36/37 © Nine Ok / gettyimages
Bob Day
Executive Director, Janet;
interim CEO, GÉANT Association
The recent merger of DANTE and TERENA into the new GÉANT Association (described in the last
edition of DFN-Mitteilungen) was a major chapter in the continuing history of increased collabo-
ration amongst Europe’s NRENs. Apart from producing a more coherent organisation and remo-
ving duplication, it offers new opportunities to harness to much better effect our collective ex-
pertise and innovation in the service of European research and education.
So what will be the next challenges to take up? They will be many and varied, but it is clear that
the research community across very many disciplines is approaching a profound shift in the way
it conducts its business. The widespread availability of unprecedented amounts of data, along-
side the storage and computational facilities to exploit these, will mean that ever more data-in-
tensive research will be conducted, with mining of this data supplementing or even in some dis-
ciplines replacing more traditional experimental techniques.
The physical infrastructure to support this, including the high-performance networks needed to
connect researchers, data and processing, already exist in the form of national networks such
as X-WiN and my own NREN, Janet, alongside GÉANT to interconnect them across Europe and to
the wider world. There are many challenges to be surmounted in sustaining this infrastructure
in the present economic climate, but the technological aspects of these are well understood and
largely tractable.
Newer, and more challenging, are the issues around management of the datasets involved. Sto-
ring them and making them accessible in a form that can be relied upon by other researchers is
one aspect of this. Another, equally important, is managing access to the data. Increasingly, such
datasets are sensitive, either because they have a commercial value or because their use raises
societal issues of privacy and ethical use of the data, particularly where large previously uncon-
nected datasets are combined. Failure to address these issues poses a very real risk that the full
value to humankind is not realised. There have already been examples where poor handling of
the aspects of privacy and ethics has led to this unfortunate outcome.
Europe’s NRENs are uniquely positioned to contribute. We have unprecedented achievements
in services such as eduroam and edugain, where highly scalable, reliable and trusted authenti-
cation and authorisation are critical. Janet is currently engaged in a major project with the UK’s
health informatics research community applying these technologies to medically sensitive data,
alongside introducing services to allow for secure transfer of such data across the network. As
GÉANT now goes forward I confidently expect the next chapter to be one where Europe’s NRENs
provide the basis for the true exploitation of the “data tsunami” – or the “data bonanza” as one
scientist a few years ago described it to me!
6 | DFN Mitteilungen Ausgabe 88 | Mai 2015
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16 17
Unsere Autoren dieser Ausgabe im Überblick
1 Michael Röder, DFN-Verein (roeder@dfn.de); 2 Dr. Thomas Hildmann,
Technische Universität Berlin (thomas.hildmann@tu-berlin.de);
3 Prof. Dr.-Ing. Stefan Schwarz, Universität der Bundeswehr München
(Stefan.Schwarz@unibw.de); 4 Benedikt Wegmann, GWDG
(benedikt.wegmann@gwdg.de); 5 Gisela Maiß, DFN-Verein (maiss@dfn.de);
6 Jochen Schönfelder, DFN-CERT Services GmbH (schoenfelder@dfn-cert.de);
7 Henry Kluge, DFN-Verein (kluge@dfn.de); 8 Christian Meyer, DFN-Verein
(cmeyer@dfn.de); 9 Dr. Jakob Tendel, DFN-Verein (tendel@dfn.de);
10 Dr. Leonie Schäfer, DFN-Verein (schaefer@dfn.de); 11 Thorsten Hindermann,
GWDG (thorsten.hindermann@gwdg.de); 12 Dr. Ralf Gröper, DFN-Verein
(groeper@dfn.de); 13 Jürgen Brauckmann, DFN-CERT Services GmbH
(brauckmann@dfn-cert.de); 14 Kevin Kuta, Forschungsstelle Recht im DFN
(kuta@dfn.de); 15 Philipp Roos, Forschungsstelle Recht im DFN (recht@dfn.de)
DFN Mitteilungen Ausgabe 88 | 7
Inhalt
Wissenschaftsnetz International
In fünf Schritten in die DFN-Cloud Globales VPN für deutsch-japanische
von Michael Röder ........................................................................ 10 Weltraum-Mission
von Jakob Tendel ............................................................................ 32
Cloudspeicher auf Basis von ownCloud Enterprise
von Thomas Hildmann ................................................................. 15 GÉANT in HORIZON 2020
von Leonie Schäfer......................................................................... 34
TeamDrive: Sync&Share an der Universität der
Bundeswehr München Kurzmeldungen ............................................................................. 35
von Stefan Schwarz ...................................................................... 16
GWDG Cloud Share Sicherheit
von Thorsten Hindermann ......................................................... 16
Sicherer E-Mail-Verkehr im DFN – von der
DFN-NeMo: Erkennung von DDoS-Angriffen Beantragung bis zur Nutzung von Zertifikaten
von Gisela Maiß, Jochen Schönfelder .................................... 18 von Thorsten Hindermann ......................................................... 38
Kein X für ein U – mehr Sicherheit fürs Sicherheit aktuell
Domain Name System! von Ralf Gröper, Jürgen Brauckmann .................................... 42
von Henry Kluge ............................................................................. 22
DFNFernsprechen: Kurznachrichten über Recht
SMS-Gateway versenden
von Christian Meyer...................................................................... 29 Lifestyle contra Sicherheit
von Kevin Kuta ................................................................................ 43
Kurzmeldungen .............................................................................. 30
Freies Wissen für alle?
von Philipp Roos ............................................................................ 49
DFN-Verein
Übersicht über die Mitgliedseinrichtungen
und Organe des DFN-Vereins .................................................... 54
8 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ
WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 88 | 9 Wissenschaftsnetz In fünf Schritten in die DFN-Cloud von Michael Röder Cloudspeicher auf Basis von ownCloud Enterprise von Thomas Hildmann TeamDrive: Sync&Share an der Universität der Bundeswehr München von Stefan Schwarz GWDG Cloud Share von Thorsten Hindermann DFN-NeMo: Erkennung von DDoS-Angriffen von Gisela Maiß, Jochen Schönfelder Kein X für ein U – mehr Sicherheit fürs Domain Name System! von Henry Kluge DFNFernsprechen: Kurznachrichten über SMS-Gateway versenden von Christian Meyer Kurzmeldungen
10 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ
WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 88 | 11 In fünf Schritten in die DFN-Cloud Viele wissenschaftliche Einrichtungen haben große Erfahrung mit der Bereitstellung von Cloud-Diensten. Mit der DFN-Cloud schafft der DFN-Verein einen Rahmen, in dem diese Cloud-Dienste von allen Teilnehmern am DFN-Verbund genutzt werden können. In entsprechenden Forschungsvorhaben bringt der DFN-Verein Anbieter und Nutzer zusammen, um die DFN-Cloud zu nutzen, zu erproben und weiterzuentwickeln. Text: Michael Röder (DFN-Verein)
12 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ
Eine Cloud für die Wissenschaft als Erprobungspartner aktiv. Dabei schließen sich beide Rollen
gegenseitig nicht aus, denn die DFN-Cloud selbst ist kein explizi-
ter Dienst. Sie bildet vielmehr das Dach für eine Vielzahl darunter
Mit der Einführung föderierter Dienste eröffnet der DFN-Verein vereinter Dienste und ist dadurch vergleichbar mit bereits be-
seinen Anwendern die Möglichkeit, sich neben der Inanspruch- kannten Diensten im DFN: Um beispielsweise DFNInternet oder
nahme der zentralen Dienste im DFN künftig auch gegenseitig DFNFernsprechen nutzen zu können, muss der Rahmenvertrag
Dienste zur Verfügung zu stellen. Der DFN-Verein schafft dafür über die Teilnahme am Deutschen Forschungsnetz anerkannt
einen Rahmen, innerhalb dessen Cloud-Dienste von allen Teil- werden. Aus diesem Grund kann eine Einrichtung einen Dienst
nehmern am DFN-Verbund sowohl angeboten als auch genutzt nutzen, während sie gleichzeitig einen anderen selbst anbietet.
werden können. Ziel ist nicht allein die Nutzung der DFN-Cloud
– das Augenmerk liegt vor allem auf der Erprobung und Weiter- In der Rolle des administrativen Partners und Organisators
entwicklung von Diensten in der Community. steht der DFN-Verein allen Teilnehmern in der DFN-Cloud zur
Verfügung.
Die DFN-Cloud startet mit Dienstprofilen aus dem Sync&Share-
Umfeld. Dabei handelt es sich um Dienste, die zur Dateiablage Erprobungs- oder Forschungsrahmenvertrag?
und -synchronisierung über verschiedene Endgeräte entstan-
den sind. Damit kann der Endnutzer zentral gespeicherte Daten Wer an der DFN-Cloud teilnehmen möchte, muss dafür zunächst
per Freigabe einem definierten Empfängerkreis zugänglich ma- einen Vertrag mit dem DFN-Verein abschließen. Hierbei existie-
chen und gezielt Rechte zur Bearbeitung der Inhalte vergeben. ren unterschiedliche Verträge, je nachdem ob eine Einrichtung
In der Vergangenheit wurden gemeinsam bearbeitete Daten und Cloud-Dienste nutzen oder anbieten will. Einrichtungen, die ei-
Dokumente vielfach als Anhang von E-Mails oder über ungesi- nen Cloud-Dienst nutzen wollen, setzen sich über cloud@dfn.de
cherte FTP-Verbindungen ausgetauscht. Der Synchronisierungs- mit dem DFN-Verein in Verbindung und erfragen den Erprobungs-
prozess im Anschluss an die Bearbeitung passierte manuell. Ein rahmenvertrag. Möchte eine Einrichtung selbst einen Dienst in
Sync&Share-Dienst verfügt im Gegensatz dazu über einen loka- der DFN-Cloud anbieten, erhält sie auf demselben Weg den For-
len Client, der die Kollaboration vereinfacht, indem er den Da- schungsrahmenvertrag. Einrichtungen, die sowohl Dienste nut-
tenbestand bei bestehender Netzwerkverbindung automatisch zen als auch anbieten wollen, schließen beide Verträge ab.
aktualisiert, sobald eine Veränderung vorgenommen wurde. Au-
ßerdem besteht die Möglichkeit, die eigenen Dokumente über Am Ende dieses Schrittes sind neben den allgemeinen Rechten
den Browser zu nutzen und zu editieren – völlig unabhängig von und Pflichten auch grundsätzliche Fragen wie z. B. die Laufzeit
Bearbeitungsort und Betriebssystem. geregelt. Damit sind die Voraussetzungen abgeschlossen, um an
der DFN-Cloud teilzunehmen – ohne dass bereits Details einzel-
Mit einem breit im DFN-Verein abgestimmten Konzept über die ner Dienste betroffen wären.
Organisation und die administrative Abwicklung beim Anbieten
und Nutzen bisher nur lokal oder regional verfügbarer Cloud- Auswahl des passenden Cloud-Dienstes
Services ermöglicht die DFN-Cloud ab sofort eine wissenschafts-
konforme Bereitstellung und Nutzung dieser Form der Zusam- Im nächsten Schritt soll bei der Nutzung der DFN-Cloud der pas-
menarbeit im gesamten Wissenschaftsnetz. sende Dienst gefunden werden. Da jeder Anbieter eines Cloud-
Services ein eigenes Betriebsmodell für seinen Dienst entwickelt
Schon heute stehen in der DFN-Cloud mit GWDG Cloud Share, hat, können sich die verschiedenen Dienste in der DFN-Cloud so-
der TU Berlin ownCloud und UNIBW Sync&Share erste für die wohl im Entgeltmodell als auch in Fragen der Verschlüsselungs-
Zwecke von Forschung und Lehre maßgeschneiderte Cloud-Ser- technologie, der Lizenzpolitik oder der Einflussnahme auf die
vices bereit. Weitere Cloud-Dienste sollen in den kommenden Entwicklung der Software voneinander unterscheiden.
Jahren folgen.
Eine Übersicht sämtlicher Dienste in der DFN-Cloud ist auf der
DFN-Cloud verbindet Anbieter und Nutzer von Webseite des DFN-Vereins unter
Diensten https://www.dfn.de/dfn-cloud/
verfügbar.
Die Teilnahme an der DFN-Cloud ist auf zwei unterschiedliche Ar-
ten möglich: Entweder bietet ein Teilnehmer einen Dienst in der Um interessierte Einrichtungen bei der Entscheidung zu unter-
DFN-Cloud an und tritt in der Folge als Forschungspartner auf – stützen, sind hier die Basisfunktionen der jeweiligen Services in
oder der Teilnehmer nutzt einen Cloud-Dienst und wird dadurch Kurzporträits dargestellt und konkrete Informationen über dasWISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 88 | 13
jeweilige Entgeltmodell abgebildet. Technische Details können
zielgerichtet vom Ansprechpartner abgerufen werden, der durch 5
den Forschungspartner hier hinterlegt wurde.
Eine Kurzvorstellung der ersten Dienste in der DFN-Cloud
durch ihre Anbieter findet sich ebenfalls in dieser Ausgabe der
DFN- Mitteilungen.
Unentgeltliche Probenutzung
Cloud
Selbstverständlich können nicht alle Facetten eines umfangrei-
chen Dienstes in wenigen Worten abgebildet werden. Die DFN- Produktivbetrieb
Cloud ist daher so konzipiert, dass die Dienste zunächst für ei-
nen gewissen Zeitraum kostenneutral erprobt werden können,
bevor sich ein Teilnehmer für eine dauerhafte Nutzung eines
Dienstes entscheidet.
Diese Probenutzung kann ohne Zutun des DFN-Vereins durch-
4 4.1 Nutzungskontingent beziffern
geführt werden. Im Sinne der gemeinsamen Weiterentwicklung 4.2 Nutzungspauschale entrichten
der DFN-Cloud ist der DFN-Verein jedoch interessiert daran zu
erfahren, welche Beweggründe zur Auswahl eines Dienstes der
DFN-Cloud geführt haben. EP
Deutsches
Forschungsnetz
Hat sich ein potentieller Anwender auf der Grundlage dieser Er-
probung für die Nutzung eines bestimmten Dienstes entschie-
den, ist der dritte Schritt geschafft. 3 Erprobungsvereinbarung (EP)
mit Forschungspartner (FP)
Erprobungsvereinbarung mit dem Anbieter
Im dritten Schritt stimmen sich Anwender und Anbieter des Cloud-
Dienstes darüber ab, auf welcher Basis der Dienst schließlich
EP FP
an die tatsächlichen Endnutzer – nämlich die Mitarbeiter und
Studenten des Erprobungspartners – weitergereicht wird. Das
Ergebnis wird in der sogenannten „Erprobungsvereinbarung“
festgehalten. 2 Testphase starten
Die Erprobungsvereinbarung hilft dabei, das rechtlich-techni- EP
sche Verhältnis zwischen Anwender und Anbieter zu regulieren. FP FP
Konkret betrifft das beispielsweise Fragen der Haftung und des
Datenschutzes. Aber auch Details zur Laufzeit der Vereinbarung
und das Format der Daten bei Herausgabe können darin veran- FP FP
kert werden.
Bei der Gestaltung der Erprobungsvereinbarung haben beide 1 Erprobungsrahmenvertrag
Seiten weitgehend freie Hand. Der DFN-Verein bietet allerdings 1.1 anfordern
Formulierungsvorschläge an, die im bilateralen Verhältnis zwi- 1.2 unterschreiben
schen Anbieter und Anwender bearbeitet werden können – so-
lange das Ergebnis nicht im Widerspruch zu den Rechten und (EP)
Pflichten steht, die dem Anwender durch Anerkennung des Er- (FP) Erprobungs- EP
Forschungs- Deutsches
partner Forschungsnetz
probungsrahmenvertrages und dem Anbieter durch Unterzeich- partner
nung des Forschungsrahmenvertrages zugesichert werden.
Für den Weg in die DFN-Cloud sind fünf Schritte erforderlich.14 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ
Anmeldung beim DFN-Verein Der Ausgleich von Planungsabweichungen und Schwankungen
bei der Nutzungsintensität erfolgt durch Anwendung des Fair-
Der vierte Schritt besteht darin, beim DFN-Verein die Nutzung ei- Use-Modells jeweils in der nächsten Nutzungsperiode, in der die
nes konkreten Dienstes anzumelden. Dadurch werden im Wesent- Entgelte auf der Basis der Vorjahresverbrauche festgelegt wer-
lichen der Mitwirkungsbeginn und das Nutzungskontingent fest- den. Jeweils bis zum 1. November eines Jahres melden die Nut-
gelegt. Der Anwender muss bei der Anmeldung für einen Dienst zer dem DFN-Verein ein aktualisiertes Nutzungskontingent pro
nach bestem Wissen abschätzen, in welchem Umfang er nach Cloud-Dienst, auf dessen Grundlage das Jahresentgelt für das
seiner eigenen Einschätzung den Cloud-Dienst im Mittel über Folgejahr bestimmt wird.
das Kalenderjahr nutzen wird. Der Anwender verpflichtet sich,
die künftige Nutzung des Dienstes möglichst gewissenhaft und DFN-Cloud als Motor für künftige Dienste
nicht zum Nachteil eines Dienstanbieters einzuschätzen. Der
DFN-Verein berät die Einrichtungen hierbei und stellt den Part- Ziel der DFN-Cloud ist nicht nur, den Anwendern im Wissenschafts-
nern seine Erfahrung bei der Gestaltung solcher Entgeltmodel- netz dezentrale Dienste in der DFN-Cloud zur Verfügung zu stel-
le zur Verfügung. len, sondern die Funktionen, Prozesse und Bedingungen föde-
rierter Dienste unter aktiver Mitwirkung aller Beteiligten zu er-
Nach der Anmeldung steht es dem Anwender frei, den Cloud- forschen. Das rege Interesse der Anwender an der DFN-Cloud
Dienst nach seinen Bedarfen zu nutzen. Überschreitet er sein spiegelt den Bedarf an wissenschaftskonformen Cloud-Diens-
Nutzungskontingent, so muss er es jedoch im fünften und letz- ten wider. Zugleich zeigt es die Potentiale, die ein Aufsetzen von
ten Schritt für das Folgejahr entsprechend anpassen. Diensten für einen größeren Kreis von Anwendern hinsichtlich
einer Economy of Scale für die Anbieter hat.
Kostenumlage der DFN-Cloud
Dem DFN-Verein ist es gelungen, mit der DFN-Cloud einen Rah-
Die Kosten für die DFN-Cloud werden den Anbietern der Cloud- men zu schaffen, innerhalb dessen sich Einrichtungen rechtssi-
Dienste vom DFN-Verein erstattet. Zur Deckung dieser Kosten cher und zu vernünftigen Konditionen gegenseitig Dienste er-
zieht der DFN-Verein die Anwender anteilig entsprechend ihren bringen können. Damit hat die DFN-Cloud die Chance, ein Mo-
Anmeldungen und der veröffentlichten Kostenumlage für die tor für die Ausweitung bestehender und die Entwicklung neuer
DFN-Cloud heran. Dienstinhalte zu werden. M
Somit trägt der DFN-Verein die Verantwortung, auf mittlere Sicht
eine kostendeckende Finanzierung der DFN-Cloud sicherzustellen.
Foto © Gio_1978 / fotoliaWISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 88 | 15
Cloudspeicher auf Basis von
ownCloud Enterprise
Text: Dr. Thomas Hildmann (Technische Universität Berlin)
Plattformunabhängige Cloud-Lösung Premium-Verfügbarkeit
Der DFN-Verein organisiert unter dem Stichwort „DFN-Cloud“ Bei der Premium-Verfügbarkeit werden die Daten auf beiden Re-
eine Cloud für die Wissenschaft. Die in diesem Rahmen ange- chenzentren gespiegelt. Bei Ausfall eines kompletten RZ kann der
botenen Cloud-Dienste können von allen Mitgliedern des DFN- Dienst (evtl. mit reduzierter Performanz) weiter erbracht werden.
Verbunds genutzt, erprobt und weiterentwickelt werden. Die
TU Berlin bietet im Rahmen der DFN-Cloud den Dienst: „Cloud- Quelloffene Linux-Lösung
speicher auf Basis von ownCloud Enterprise“ mit Hilfe des Spei-
cherdienstes „ownCloud“ an und stellt einen ortsunabhängigen Die Entscheidung zugunsten der Linux-basierten quelloffenen
Speicherbereich für Daten zur Verfügung. ownCloud basiert auf einer Evaluation, die die tubIT im Jahr 2012
durchgeführt hat. Vor allem galt es, schon zuvor bekannt ge-
ownCloud synchronisiert persönliche Daten auf mehreren End- wordene Sicherheits- und Rechtsprobleme bei der Nutzung von
geräten. Clients stehen aktuell für Windows, Linux, OS X, iOS und Cloud-Diensten zu lösen. Dabei standen Wartbarkeit, Skalierbar-
Android zur Verfügung. Die Dateien sind ferner über ein Web- keit und vor allem die Bedienschnittstelle und damit der Support
interface oder über WebDAV zugreifbar. Über verschiedene Plug aufwand im Vordergrund der Evaluation. Die Marktanalyse er-
ins kann die Funktionalität (z. B. über eine Fotogalerie, einen Edi- brachte zum damaligen Zeitpunkt keine interessanten Outsour-
tor, einen Kalender usw.) erweitert werden. ownCloud ist eine cing-Möglichkeiten. Hingegen zeigten einige getestete Produkte
quelloffene Alternative zu den bekannten Cloud-Speicherdiens- hohes Potential auch für die Integration und Weiterentwicklung
ten wie z. B. Dropbox. des Dienstes, weshalb die TU Berlin sich entschlossen hat, den
Dienst selbst aufzusetzen.
Blick in den Maschinenraum
Der Dienst wird 24/7 zur Verfügung gestellt. Updates der own
Cloud-Server-Version erfordern eine Downtime von gewöhnlich
wenigen Minuten. Der Dienst wird über ein Cluster mit mehreren
Webfrontends, ein Datenbankcluster und ein mehrfach redun
dantes Speichersystem über zwei Rechenzentrumsstandorte ver-
teilt angeboten. Ferner findet eine zusätzliche Sicherung über
eine Tape-Library in unserer Lampertz-Zelle statt. Die tubIT-Ad-
ministratoren werden vom ownCloud-Support-Team unterstützt.
Standard-Verfügbarkeit
Bei der Standard-Verfügbarkeit werden die Daten in der ownCloud Da die TU Berlin in vielen Bereichen seit Langem mit anderen
jeweils nur auf einem der beiden Rechenzentren der TU Berlin Hochschulen zusammengearbeitet hat und aus eigener Erfah-
gespeichert. Steht eines der Rechenzentren temporär nicht zur rung bei der Suche nach geeigneten Dienstanbietern wusste,
Verfügung (z. B. wegen Wartungsarbeiten, die die Abschaltung dass es hier eine Marktlücke gibt, beteiligte sie sich von Beginn
eines RZ nötig machen, wegen Ausfall der Leitungen zum RZ o.ä.), an an der Mitgestaltung der DFN-Cloud mit dem Ziel, den Dienst
kann somit auch der Dienst für den Erprobungspartner ausfallen. für andere Hochschulen anzubieten.16 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ
Economy of Scale Flexibel für Nutzerwünsche
Die Bereitstellung des Dienstes für eine größere Anzahl von Nut- Neben der Tatsache, dass die Daten der tubCloud sowie der über
zern erhöht in der Regel den Administrationsaufwand nur unwe- die DFN-Cloud angeschlossenen Instanzen ausschließlich in den
sentlich. Hingegen ist es möglich, bestimmte Infrastruktur in grö- beiden Datacenter-Standorten der TU Berlin gespeichert werden,
ßerem Maßstab für den Einzelnen sehr viel günstiger anzuschaf- steht auch die Flexibilität des Dienstes in Richtung Anpassung
fen. Insofern ist es auch im Interesse der TU Berlin, etwaige Hard- an Nutzerwünsche und Integration in die vorhandene Infrastruk-
ware- und Supportkosten mit anderen Hochschulen zu teilen. tur im Vordergrund. Die Vereinbarung zur Auftragsdatenverar-
beitung und das Sicherheitskonzept wurden bereits intern wie
Sicherheit auch extern positiv bewertet. ownCloud bietet viele Schnittstel-
len, die für die Integration im Hochschulumfeld benötigt wer-
An Stelle der in ownCloud implementierten serverseitigen Ver- den. Ferner hat ownCloud eine große Community, die das Pro-
schlüsselung werden derzeit verschiedene Lösungen von Dritther- dukt weiterentwickelt, gekoppelt mit einem vertrauenswürdigen
stellern auf ihre Eignung im Zusammenspiel mit ownCloud ge- Team, das diese Entwicklungen in unserem Sinne kanalisiert. M
testet. Eine Client-seitige Verschlüsselung würde nicht nur den
Schutz gegen Ausspähen erhöhen, sie hätte ferner keinen Ein-
fluss auf die Auslastung der Infrastruktur.
TeamDrive: Sync&Share an
der Universität der Bundeswehr
München
Text: Prof. Dr.-Ing. Stefan Schwarz (Universität der Bundeswehr München)
Gehäufte Nachfragen sicherheitsbewusster Anwender und die Primäres Ziel war stets eine ausreichende Berücksichtigung des
Analyse des aktiven Nutzungsverhaltens filebasierter Cloud- Datenschutzes. Daten und Dokumente sollten zwingend so ge-
dienste haben an der Universität der Bundeswehr München schützt werden, dass eine unberechtigte Kenntnisnahme oder
(UniBw M) im Jahr 2013 dazu geführt, ein hochschulinternes An-
gebot zur Bereitstellung von Sync&Share-Diensten zu projektie-
ren. Nur dadurch kann einerseits den im Hinblick auf Sicherheit
und Datenschutz bereits sensibilisierten Anwendern als auch
der Gruppe der weniger arglosen Nutzer ein langfristig sicheres
Verfahren zur zentralen Ablage und gemeinsamen Nutzung von
nahezu allen Arten von Daten angeboten werden. Manipulation (Vertraulichkeit und Integrität) außerhalb des Nut-
zerarbeitsplatzes wirksam verhindert werden kann. Dazu zählt
Die Initiative des DFN-Vereins zu einem föderierten Dienst für auch der Schutz der zuständigen Administratoren vor dem bloßen
Sync&Share wurde von der Universität der Bundeswehr Mün- Verdacht. Aus den Erfahrungen im Nutzerverhalten der Anwender
chen von Beginn an unterstützt und eine Integration der Föde- zeigt sich, dass insbesondere datenschutzrelevante Dokumente
ration war eine Grundvoraussetzung in der Auswahl möglicher bevorzugt mit anderen Anwendern geteilt werden (Bewerbun-
Produkte. Nur dadurch ist auch gewährleistet, dass Koopera- gen/Berufungsverfahren, Prüfungen, Notenlisten, Sitzungspro-
tionen zwischen Einrichtungen im Bereich von Lehre und For- tokolle etc.). Ein wesentliches Kriterium dazu ist auch die Spei-
schung auch durch die gemeinsame Bereitstellung von Doku- cherung und Verarbeitung der Daten an einem klar definierten
menten sinnvoll unterstützt werden. Ort, was zusätzliches Vertrauen der Anwender schafft.WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 88 | 17
Nach einer Marktanalyse vorwiegend unter Nutzung bereits ein- sondere sicheres Schlüsselmanagement) geprüft, was direkte
schlägiger (Fraunhofer SIT, DFN) Studien fiel die Entscheidung Änderungen in der Grundkonfiguration veranlasste. Bereits zu
ganz eindeutig zu Gunsten des Produkts TeamDrive (TeamDrive diesem Zeitpunkt war durch die Authentifizierung und Autori-
GmbH, Hamburg) aus. Danach wurde das Produkt über eine sechs- sierung über Shibboleth die Integration in die DFN-AAI sicher-
monatige Testphase intensiv (auch durch externe Einrichtun- gestellt. Als Resultat wurde der Dienst TeamDrive nahezu zeit-
gen) getestet, vor allem wurde dabei auch die Handhabung des gleich mit der Registrierung als Erprobungspartner des DFN im
Datenschutzes über verschiedene Nutzungsszenarien (insbe- Juni 2014 gestartet. M
GWDG Cloud Share
Text: Benedikt Wegmann (GWDG – Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen)
Die Gesellschaft für wissenschaftliche Datenverarbeitung mbH Im Vergleich zu Clients anderer verbreiteter Dienste erlaubt der
Göttingen (GWDG) betreibt für ihre Nutzer seit 2012 den Dienst Client von GWDG Cloud Share ein flexibleres Verwalten unter-
„GWDG Cloud Share“. Am Anfang des Projektes stand die Anfra- schiedlicher Ordner des Benutzers in individuellen Pfaden. Da-
ge der Max-Planck-Gesellschaft MPG, eine Alternative zu dem durch müssen Nutzer die Organisation ihrer Daten nicht ändern
verbreiteten Dienst »Dropbox« anzubieten. Forschungsdaten und es können relevante Verzeichnisse einfach unter die Verwal-
sollten komfortabel verwaltet und verteilt werden können, oh- tung von GWDG Cloud Share gestellt werden.
ne die Hoheit über die eigenen Daten zu verlieren, welche in ei-
nem Rechenzentrum der Deutschen Forschungsgemeinschaft
verbleiben sollten, statt einem internationalen Cloud-Anbieter
anvertraut zu werden.
GWDG Cloud Share steht seit Beginn der DFN-Cloud als Angebot
zur Verfügung. Durch ein modernes Betriebskonzept und ein gu-
tes Angebot des Herstellers PowerFolder kann die GWDG den
Dienst für Interessenten mit minimalem Aufwand und geringen
Kosten anbieten. Das neue Angebot eignet sich mit einem flexi
blen Preismodell sowohl für kleinere bis mittlere Teams oder Um Nutzern einen flexiblen Zugriff auf ihre Daten zu ermögli-
Abteilungen als auch mit einem stark ermäßigten Preismodell chen, bietet der Dienst eine moderne Web-Oberfläche, Clients
für ganze Einrichtungen. Interessenten steht der Dienst für drei für die gängigsten Desktop-Betriebssysteme ebenso wie für An-
Monate zur kostenfreien Evaluierung zur Verfügung. droid- und iOS-Oberflächen sowie eine API für Benutzer und Un-
terstützung für WebDAV.
Der Dienst wird von der GWDG in ihrem modernen, ISO-zertifi-
zierten Rechenzentrum mit hoher zugesicherter Verfügbarkeit Die GWDG hat als einer der ersten Anbieter von Cloud-Services
in der eigenen Servervirtualisierung und mit eigenem Storage in der DFN-Community seit 2012 Erfahrung im Betrieb des Diens-
betrieben. Verwaltet wird GWDG Cloud Share durch ein zen tes, entwickelt das Betriebskonzept eigenständig weiter und un-
trales Konfigurationsmanagement. Durch dieses Konzept wird terstützt den Hersteller in der Weiterentwicklung des Produktes
ein leicht skalierbarer Betrieb mit geringem administrativem für den breiten Einsatz im Hochschulrechenzentrum. M
Mehraufwand erreicht, der schnell eine größere Zahl neuer Be-
nutzer aufnehmen kann.18 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ DFN-NeMo: Erkennung von DDoS-Angriffen Für den sicheren Betrieb des DFNInternet-Dienstes auf dem X-WiN zählt die Beobachtung und Analyse des Netzverhaltens – das Netzwerk-Monitoring – zu den wesentlichen Aufgaben. Zur Abwehr von Angriffen auf die Infrastruktur müssen geeignete Methoden entwickelt und eingesetzt werden, die die Erkennung von DDoS (Distributed Denial of Service) Angriffen ermöglichen. Aufgrund der Analyse eines Angriffs und der erkannten Netzwerk-Anomalien soll das Netz so angepasst werden, dass der Angriff weitestgehend eingedämmt werden kann. Text: Gisela Maiß (DFN-Verein), Jochen Schönfelder (DFN-CERT Services GmbH) Foto © johny schorle / photocase.de
WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 88 | 19
In den letzten Jahren wurde eine Entwick-
0.2
lung gestartet, die genau diese Anomalien-
Erkennung im Datenverkehr über das X-WiN
zum Ziel hat. Sie soll zur Alarmierung und 0.1
Unterstützung bei der Vorfallsbearbeitung
dienen und setzt mit ihren Methoden und
0.0
Lösungen gezielt die betrieblichen Anforde-
rungen der beteiligten Gruppen um.
-0.1
Um Anwendungen wie die Erkennung von 18:00 18:30 19:00 19:30 20:00 20:30
DDoS-Angriffen im Betrieb des X-WiN ver-
dunkelblau: Paketanzahl von Verbindungen im Aufbau im Verhältnis
ankern zu können, ist es neben der Entwick- zur Paketanzahl der aktuell bestehenden Verbindungen
lung nötig, die vorhandenen Geschäftspro- hellblau: das Verhältnis in der Vergangenheit
zesse zu analysieren und weiterzuentwi- Anmerkung: Das Verlassen des Korridors führt zu einem Alarm.
ckeln. Dabei kommt der Berücksichtigung
Abb. 1: Beispiel eines Alarms auf einer Leitung, ausgelöst durch die Abweichung von statistischen
der nachhaltigen Nutzung sowie der Ge- Schwellwerten
währleistung von Datenschutz und Daten-
sicherheit bei der Auswertung der Verkehrs- de 2011 mit der Entwicklung begonnen. Seit zesse entwickelt wurden, gliedern sich in
daten ein hoher Stellenwert zu. 2013 wird die Software „produktionsnah“ Messung, Erkennung, Alarmierung, Analyse
beim DFN-NOC eingesetzt. und Aktion. In der Erkennungskomponente
1. Hintergrund der Entwick- nimmt DFN-NeMo die notwendigen Daten
lung von DFN-NeMo 2. Struktur der entgegen, verarbeitet sie vor und gleicht sie
DDoS-Anwendung mit den Daten der Netzwerkmodellierung
Der Bedarf für das Netzwerkmonitoring-Tool ab. Sobald bekannte statistische oder zeit-
DFN-NeMo entstand aus der täglichen Ar- DFN-NeMo kann als ein System aus Arbeits- abhängig zu erwartende Schwellwerte über-
beit der Mitarbeiter vom DFN-NOC und dem prozessen und -schritten beschrieben wer- schritten werden, erfolgt eine Alarmierung
Incident Response Team (IRT) des DFN-CERT. den, die auf Betriebsdaten im X-WiN zugrei- (Abb. 1). Es werden keine IP-Adressen beob-
Diese wurden in ihrer täglichen Arbeit mit fen und diese im Sinne definierter interner achtet, sondern die Auswertung erfolgt le-
Netzwerkanomalien konfrontiert, für die Dienste verarbeiten. So sind als Grundlage diglich aus gewonnenen Kennzahlen aus
ein Analysewerkzeug benötigt wurde. zur Modellierung des X-WiN aktuelle Infor- den Rohdaten wie z. B. UDP-Paketraten, Vo-
mationen erforderlich, die die Netztopolo- lumendaten über TCP oder Paketraten von
Eine typische Ursache solcher Anomalien gie abbilden. Mit diesen Informationen wer- Verbindungen mit gesetztem TCP-SYN-Flag.
sind kurzfristige Überlastsituationen der den den Routern, Leitungen, Autonomen
betroffenen Infrastruktur durch Datenströ- Systemen (AS) und IP-Adressbereichen des Alarmierungen erfolgen aus unterschiedli-
me mit extrem hohem Verkehrsaufkommen. X-WiN Kenndaten zugeordnet. Die eigentli- chen Gründen und werden durch die Erken-
Hierbei kann es sich um Angriffe auf Kompo- che Messung von Daten ist nicht Bestandteil nung von Überlastsituationen entweder am
nenten des X-WiN, auf Anwender im X-WiN der DFN-NeMo-Entwicklung, sondern wird Punkt der Messung oder an entfernteren
oder auch um Angriffe handeln, die von an anderer Stelle bereitgestellt. Bei den ver- Orten der Netztopologie erkannt. Es kön-
Anwendern selbst ausgehen. Aber nicht al- arbeiteten Daten handelt es sich um Sta- nen statistische Schwellwerte überschrit-
le Angriffe verursachen anhand von Über- tusinformationen der Router in Form von ten werden, Abweichungen von trainierten
last erkennbare Anomalien und nicht alle SNMP-Daten sowie um gesampelte Netflow- Kennzahlen auftreten, das Verkehrsverhal-
erkannten Anomalien im Überlastbereich Daten, die als Verbindungsinformationen ten kann von gelernten Modellen abwei-
werden durch Angriffe verursacht. Daher auf den Routern gemessen werden. Diese chen und auch eine extreme Überlast oder
sind ein genaues Monitoring und die Ana- Rohdaten werden maximal sieben Tage ge- ein Ausfall des Messsystems selbst kann zu
lyse des Datenverkehrs im X-WiN in der je- speichert und danach gelöscht. Sie dienen einer Alarmierung führen. Eine Übersichts-
weiligen Situation für eine Bewertung des als Datenbasis für eine Analyse im Angriffs- karte zeigt grob die Situation im Netz für
Vorgangs dringend erforderlich. fall. Ein Monitoring von Inhalten der Kom- einen ausgewählten Zeitraum an (Abb. 2).
munikation erfolgt zu keinem Zeitpunkt.
DFN-NeMo wird im Auftrag des DFN-Vereins DFN-NeMo liefert mit der Alarmierung eine
von einem Team des DFN-CERT entwickelt. Die Arbeitsschritte, die als Unterstützung Reihe notwendiger Informationen zur Pla-
Nach ersten Vorarbeiten im Jahr 2010 wur- der darauf aufbauenden Geschäftspro- nung und Durchführung einer zeitnahen Re-20 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ
jekten gespeichert und visualisiert. Wegen
der unterschiedlichen Zielsetzung werden
hier jedoch ausschließlich Autonome Sys-
teme modelliert. Diese sind in der Lage,
sowohl die AS interner DFN-Anwender als
auch die AS externer Organisationen abzu-
bilden. Im Rahmen der Messung von NEA
kann das in einem Netflow enthaltene Quell-
oder Ziel-AS und auch jedes AS, das auf dem
BGP-Pfad dazwischenliegt, erreicht werden.
Somit sind auch alle Peering-Partner mo-
dellierbar.
Interne DFN-Anwender, die über ein priva-
tes oder öffentliches AS verfügen, sowie
die Peering-Partner des DFN-Vereins wer-
den hierbei automatisch anhand der aktu-
ellen Netzwerkdokumentation modelliert.
Alle weiteren Objekte müssen manuell an-
gelegt werden und können vom Zeitpunkt
des Modellierens an betrachtet werden. Eine
Nachberechnung von Verkehrsströmen vor
dem Zeitpunkt der Modellierung ist nicht
möglich.
Abb. 2: Netzwerk-Topologiekarte: Schematische Darstellung des X-WiN-Backbones. Die Strichbreite Bisher wurden knapp 700 Objekte automa-
kennzeichnet die Paketrate, die Farben geben die Anzahl der Alarme in den letzten Stunden an. tisch bzw. manuell angelegt. NEA befindet
sich zurzeit noch in der Entwicklung. Ähn-
aktion. Diese Informationen ermöglichen Anwendern untereinander dienen. Hierbei lich wie bei der DDoS-Anwendung werden
eine sachgerechte Bewertung der Alarme. stehen nicht einzelne Verbindungen im Fo- die berechneten Kenngrößen in Zeitschei-
Die Alarme können mit anderen Alarmen kus, sondern die Volumenmessungen der ben gespeichert. Für kurze Zeiträume bie-
korreliert werden und es kann eine erste Verkehrsströme zwischen den Standorten, tet NEA eine Auflösung von 5 Minuten an.
Einschätzung des Schadpotentials vorge- was auch dem Gedanken des Datenschut- Länger zurückliegende Daten werden kon-
nommen werden. Es gibt die Möglichkeit, zes Rechnung tragen soll. Ziel von NEA ist figurierbar ausgedünnt. Eine Echtzeitfähig-
Angriffe durch die Topologie des X-WiN zu- die Unterstützung der Verkehrsplanung in- keit ist für NEA nicht erforderlich, dement-
rückzuverfolgen. Die entwickelten Werkzeu- nerhalb des X-WiNs als auch zu den exter- sprechend stellt eine größere oder schwan-
ge, die auch Funktionen wie Reporting, Do- nen Kommunikationspartnern. kende Latenz kein Problem dar.
kumentationen und ggf. Archivierungen ent-
halten, bieten die Möglichkeit, auch den An- Eine Rückverfolgung einzelner Kommunika- 4. Datenschutzaspekte
fragen und Hinweisen von Anwendern im tionsbeziehungen oder gar ein Zugriff auf
X-WiN oder anderen CERTs nachzugehen. die Rohdaten ist innerhalb von NEA nicht Es ist selbstverständlich, dass die Einhal-
möglich. Abb. 3 gibt einen Überblick über tung des Datenschutzes bei der Arbeit mit
3. Netzwerkanalyse NEA die Struktur von DFN-NeMo und NEA. den benötigten Daten höchste Priorität hat.
Deshalb haben schon im Vorfeld Gespräche
Im Rahmen des DDoS-Projekts wurde eine Eingabedaten für NEA sind die bereits in- mit Juristen stattgefunden und es wurde
weitere Entwicklung unter dem Namen nerhalb von DFN-NeMo genutzten Netflow- bereits während der Konzeptionsphase auf
Netzwerkanalyse (NEA) angestoßen. Diese Daten sowie zusätzlich BGP-Daten der Rou- datenschutzrechtliche Randbedingungen
soll zur Darstellung und Recherche der Kom- ter und aktuelle Daten der Netztopologie. geachtet. Unstrittig ist, dass der DFN-Ver-
munikationsbeziehungen zwischen DFN-An- ein sein eigenes Netz zum Zwecke der Stö-
wendern und externen Netzen bzw. Auto- Wie auch in der DDoS-Anwendung werden rungserkennung nach TKG Telekommunika-
nomen Systemen (AS) sowie zwischen DFN- die darzustellenden Daten anhand von Ob- tionsgesetz § 100 Abs. 1 überwachen darf.WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 88 | 21
Bei den verwendeten Daten in DFN-Ne- im Zusammenhang mit den geplanten sung der Dienstvereinbarung DFNInternet
Mo handelt es sich um Verbindungsda- Arbeitsabläufen genaue Anweisungen erforderlich machen wird.
ten, die IP-Adressen und Ports von Quel- an die Analysten und eine sorgfältige
le und Ziel, nicht jedoch Paketinhalte Berichts- und Dokumentationsform der Derzeit besteht keine Möglichkeit, dass ein
enthalten. Diese werden nach 7 Tagen Systemnutzung. Anwender sein eigenes Netz über DFN-NeMo
gelöscht. Darüber hinaus kann bei der überwachen kann, da es in der Anwendung
Verarbeitung in DFN-NeMo nur in den 5. Ausblick keine Trennung der Daten entsprechend ei-
Arbeitsschritten zur Angriffsanalyse ner Mandantenfähigkeit gibt. Somit sind
und Angriffsabwehr darauf zugegrif- DFN-NeMo hat sich bereits in der Pilotphase auch keine auf bestimmte Netzbereiche
fen werden, sodass im Normalzustand als ein sehr hilfreiches Werkzeug erwiesen. eingeschränkte Sichten möglich. Langfris-
kein manueller Zugriff auf diese Daten Es wird zurzeit in die internen Betriebspro- tig könnte die Entwicklung jedoch in einen
erfolgt. Bei den gewonnenen Kenn- zesse der DFN-Geschäftsstelle integriert. Für neuen DFN-Dienst mit separater Dienstver-
zahlen aus den Netflows, die aktuell einen Einsatz unter aktiver Einbeziehung einbarung und einem Vertrag zur Auftrags-
90 Tage aufgehoben werden, erfolgt aller Anwender sind zuvor jedoch noch Rah- datenverarbeitung einfließen.
keine Speicherung der IP-Adressen. Die menbedingungen zu klären. Im produktiven
Volumendaten der Router in Form der Einsatz wird unter anderem die Weiterga- Darüber hinaus ist der Einsatz von DFN-
SNMP-Daten enthalten ebenfalls keine be von Informationen an die Anwender er- NeMo auch im GÉANT-Umfeld denkbar. Erste
IP-Adressen und auch die Modelldaten forderlich sein. Hier ist ein äußerst sorgfäl- Kontakte wurden hierzu bereits aufgenom-
des Netzes sind nicht datenschutzre- tiges Vorgehen, gerade auch bezogen auf men und stießen auf großes Interesse. M
levant. Noch in der Entwicklung sind Haftungsfragen, geboten, was eine Anpas-
DFN-NeMo
SNMP-
Erkennung Analyse
Kollektor
Datenannahme
Konfiguration
Datenvorverarbeitung
Aufbereitung
Erkennung
Netztopologie- Analysedaemon
Alarmierung
Daten
Netzwerk-
modellierung Lokale Lokale
Datenhaltung Datenhaltung
Netflow- Visualisierung
Kollektor
(Rohdaten) Analyst
Alarm
NEA (Network Analyse Tool)
Datenaufbereitung Visualisierung
und
Pfadmodelling
Analyst
BGP-Client
Anwender Datenhaltung
Abb. 3: Strukturbild von DFN-NeMo und NEA22 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ Kein X für ein U – mehr Sicherheit fürs Domain Name System! Eines der häufigsten Ziele für Angriffe auf das Internet ist heute das Domain Name System (DNS). Angriffe auf das DNS treffen Kommunikationsinfrastrukturen an ihrer empfindlichsten Stelle, nämlich im inneren Kern. Attraktiv wird das DNS für Angriffe vor allem dadurch, dass es dezentral organisiert ist. Text: Henry Kluge (DFN-Verein) Foto © Sandor Jackal / fotolia
WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 88 | 23
Einleitung dig. Zum Beispiel muss der im Web-Brow- DNS-Funktionen abstützen (z. B. DANE/
ser eingegebene Name „www.dfn.de“ vom TLSA, SSHFP). Hier kommt jedoch eine
Jede Einrichtung im Deutschen Forschungs- DNS-Server in eine IP-Adresse übersetzt Schwäche des „Ur“-DNS zum Vorschein:
netz verwaltet ihrem Namensraum eigen- werden, hier die „194.95.248.240“ als IPv4 Bei der Definition der ersten RFC wurden
verantwortlich und muss ihn gegen An- bzw. die „2001:638:d:c101:acdc:1979:3:1008“ keine Maßnahmen zur Sicherung der ge-
griffe schützen. Besonders sensibel ist als IPv6. Erst aufgelöst können Datenströ- speicherten und übertragenen Daten vor-
das DNS vor allem, weil eine Manipulati- me von Netzwerkkomponenten wie Rou- gesehen. Aus damaliger Sicht ist die Wahl
on des ‚Adressbuchs’ DNS nicht nur die an- tern verarbeitet werden. Hierzu wird ei- eines „Keep It Simple“-Ansatzes zwar nach-
gegriffene Einrichtung, sondern potentiell ne Infrastruktur genutzt, die im Prinzip ei- vollziehbar, allerdings stellt eine derartige
auch andere Anwender im Netz schädigen ne über das ganze Internet verteilte, hie- Offenheit bei der heutigen Bedrohungsla-
kann. Unterlassungen bei Schutz und Pfle- rarchische Datenbank darstellt und über ge im Internet ein Problem dar. Typische
ge des DNS sind also potentiell schädlich standardisierte Schnittstellen und Netz- Angriffsszenarien in diesem Zusammen-
für die Gemeinschaft. Wenngleich heute werkprotokolle abfragbar ist. hang sind „DNS-Spoofing“ oder „Cache-
eine Reihe von Werkzeugen für DNS-Secu- Poisoning“, bei denen gefälschte oder zu-
rity (DNSSEC) bereitsteht, stellt DNSSEC Seit seiner Einführung im Jahr 1983 wurde sätzliche Informationen den DNS-Clients
für die Einrichtungen nach wie vor eine das DNS-Protokoll ständig optimiert und oder -Servern untergeschoben werden.
betriebliche Herausforderung dar. um neue Funktionen erweitert [DNS RFC]. Dadurch ist es zum Beispiel möglich, den
Gerade in den letzten Jahren ist zu beob- Datenverkehr vom Nutzer unbemerkt auf
Ob beim Aufrufen von Webseiten oder dem achten, dass immer mehr sicherheitskri- manipulierte Webseiten umzulenken und
Versenden von E-Mails, immer ist eine Um- tische Informationen im DNS verfügbar Schadsoftware auf die Clients zu laden.
setzung von logischen, durch Menschen gemacht werden bzw. dass sich andere
lesbaren Namen in für den Transport der Protokolle und Verfahren mit einem Si- Schon in den 1990er-Jahren wurden ers-
Datenpakete genutzte Adressen notwen- cherheitsfokus zumindest teilweise auf te Anstrengungen unternommen, die so-
Abbildung 1: Signieren der DNS Resource Records
DNS Record
zu DNS-Zone
Authoritative
DNS-Server „.“ (Root)
Hashing des
DNS Record
Veröffentlichen
der signierten Authoritative
DNS-Zone & DNS-Server de.
der Public Keys
(ZSK & KSK)
Signieren des
Fingerprints
mit Private Key Authoritative
Signatur (RRSIG)
DNS-Server dfn.de.
Client Recursive DNS-Server24 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ
genannten „Securitiy Extensions“ für das Fragestellung eingegangen wird, ist ein zuerst von jedem Resource Record (RR) ein
DNS-Protokoll (DNSSEC) zu definieren, um kurzer Abriss der grundsätzlichen Funk- Hash erzeugt, der im Anschluss mit dem
den Angriffen auf das Protokoll zu begeg- tionalitäten von DNSSEC hilfreich. privaten Zone Signing Key (ZSK) signiert
nen. Jedoch stellte sich schnell heraus, dass wird. Die Resource Records werden zusam-
dieser erste Ansatz nicht implementierbar men mit den zugehörigen Signaturen (RR-
war. Somit bedurfte es einer kompletten Funktion des SIG-Record) und dem öffentlichen Teil des
Überarbeitung der Standards, bevor im DNSSEC-Protokolls ZSK auf dem autoritativen Server veröf-
Jahr 2005 eine in diversen RFCs beschrie- fentlicht. Die Gültigkeitsdauer der Signa-
bene grundsätzliche DNSSEC-Architektur Im DNS werden öffentliche Informationen turen (typischerweise 30 Tage) und die An-
verfügbar war. Die mit diesen Erweiterun- verarbeitet. Deshalb liegt beim DNSSEC- gaben zum verwendeten Algorithmus wer-
gen verbundene Erhöhung der Komplexi- Protokoll der Fokus nicht auf dem Schutz den hier ebenfalls gespeichert.
tät und der Einsatz von anderen Verfah- der Vertraulichkeit, sondern auf der Sicher-
ren, die einen Teil der Angriffe abwehren stellung der Authentizität und Integrität Mit diesen Informationen ist es prinzipi-
konnten, verzögerten jedoch eine Einfüh- der abgefragten Daten. Das heißt, auch ell möglich, die Gültigkeit eines übermit-
rung von DNSSEC auf breiter Front. Mittler- wenn der Begriff „Security“ etwas ande- telten DNS-Eintrages zu überprüfen. Hier-
weile sind allerdings sowohl handhabbare res suggeriert, dass die zu schützenden für benötigt man jedoch ein übergreifen-
DNSSEC-Softwareimplementierungen als Datensätze (Resource Records/RR) „nur“ des Vertrauensmodell, um nicht für jeden
auch umfassende Erfahrungen aus der täg- signiert und nicht verschlüsselt werden. einzelnen DNS-Server den Vertrauenssta-
lichen Praxis verfügbar, sodass einer Nut- Hierbei werden bewährte kryptographische tus separat prüfen und lokal speichern zu
zung von DNSSEC prinzipiell nichts entge- Verfahren wie RSA oder SHA-1/2 genutzt. müssen.
gensteht. Wo aber liegen nun die Heraus-
forderungen, die eine Einführung dieses In Abbildung 1 ist das Signieren einer DNS- Zur Umsetzung dieser Vertrauenskette
Verfahrens erschweren? Bevor auf diese Zone schematisch dargestellt. Hierbei wird (Chain of Trust) wird, wie in Abbildung 2
Abbildung 2: Chain of Trust
Veröffentlichen
des Public Keys (KSK)
der Root-Zone
Signieren des Authoritative
Public Keys (KSK) der DNS-Server „.“ (Root)
delegierten Zone
(DS-Record)
Authoritative
DNS-Server de.
Signieren des
Public Keys (KSK) der
delegierten Zone
(DS-Record)
Authoritative
DNS-Server dfn.de.
Nutzen
des Public Key
der Root-Zone als
Vertrauensanker
Recursive
Client (Trust Anchor)
DNS-ServerWISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 88 | 25
dargestellt, die bereits vorhandene Hier- trauensanker herstellbar ist. Ist dies der üblichen maximal 512 Byte. Aus diesem
archie des Domain Name Systems genutzt. Fall, wird die Antwort per AD-Flag (Authen- Grund wurde die Einführung eines Exten-
Die Vertrauensbeziehung setzt auf dem ticated Data) als geprüft gekennzeichnet. sion Mechanismus für DNS (EDNS0) not-
Prinzip der Delegation von Zonen auf und Schlägt diese Prüfung fehl, wird dem anfra- wendig, der u. a. die UDP-Paketlängenpro-
ergänzt dieses um die Verknüpfung mit den genden Client eine Fehlermeldung (SERV- blematik auf Protokollebene löste. Leider
sogenannten Key Signing Keys (KSK) der FAIL) zurückgesendet. gab und gibt es noch immer Hersteller oder
delegierten Zone. Somit benötigt ein va- Administratoren von Netzwerkkomponen-
lidierender rekursiver DNS-Server (Resol- ten, die eine Übertragung von größeren
ver) im Standardfall nur den öffentlichen Herausforderung Technik & DNS-UDP-Paketen oder DNS-TCP-Paketen
Schlüssel der obersten Ebene (Public KSK Funktion blockieren. Hierdurch kann es zu schwer
der Root-Zone). nachvollziehbaren Fehlersituationen kom-
Bei der Einführung von DNSSEC sind im ers- men, die abhängig von Typ und Größe der
Die Validierung der DNS-Antwortpakete ten Schritt diverse technische bzw. funkti- DNS-Abfrage sind. Deshalb ist es dringend
stellt nun sicher, dass die übermittelten onale Rahmenbedingungen zu klären. Die- geboten, Firewalls, Loadbalancer und an-
Resource Records vom zuständigen DNS- se haben oftmals auch Auswirkungen auf dere Middle-Boxes, die sich in eigener Ho-
Server stammen und auf dem Transport- sicherheitsspezifische Aspekte, insbeson- heit befinden, auf diese Funktionalität zu
weg nicht manipuliert wurden (siehe Ab- dere auf die Verfügbarkeit des DNS-Servi- prüfen und gegebenenfalls die Konfigura-
bildung 3). Hierzu wird vom Resolver die ces. In den folgenden Ausführungen wird tion anzupassen.
Übermittlung der Signaturen und Public der Fokus auf eine Auswahl von Heraus-
Keys per DO-Flag (DNSSEC OK) angefordert. forderungen aus diesem Bereich gelegt. Eine weitere Besonderheit, die DNSSEC mit
Auf Grundlage dieser Informationen wird Durch die Einbindung der Signaturen wer- sich bringt, ist die Notwendigkeit, auch
geprüft, ob eine Vertrauenskette aus Pub- den DNSSEC-Antwortpakete deutlich grö- das Nichtvorhandensein von Domainna-
lic Keys und deren Signaturen bis zum Ver- ßer als die ursprünglich als Normalwert men authentisch nachzuweisen. Hierfür
Abbildung 3: DNSSEC-Validierung
DNSSEC-Validation „Normal“ DNS-Resolving
Authoritative
DNS-Server „.“ (Root)
Authoritative
DNS-Server de.
Authoritative
DNS-Server dfn.de.
Validierung von
DNS Request „www.dfn.de“ DNS Responses durch Resolver:
Prüfen der vollständigen Vertrauens-
Authenticated DNS Response Validierung kette von Signaturen und Public Keys
Client „www.dfn.de“ ist „194.95.248.240“ vom DNS-Record bis zum Trust Anchor
Recursive DNS-Server26 | DFN Mitteilungen Ausgabe 88 | Mai 2015 | WISSENSCHAFTSNETZ
Externes Netz DMZ Internes Netz
Iterative Query Zonetransfer Zonetransfer
Externe Authoritative DNSSEC-Signer Hidden Master
DNS-Server DNS-Server DNS-Server
Secondary Zones Primary Zones
HSM Datenbank für RR
(optional) (optional)
Recursive Query
Client Validating Recursive Webinterface für RR
DNS-Server (optional)
Abbildung 4: Beispiel Deployment DNSSEC
wurde initial der Resource Record NSEC Records etc.) muss hier entschieden wer- weile Implementierungen wie „Unbound“
(Next SECure) eingeführt, der über einen den, ob das Risiko eines potentiellen Zo- von NLnet Labs verfügbar. Betriebssyste-
Verweis auf den nächsten gültigen Ein- ne-Walks tragbar ist. me wie Windows Server 2012 unterstüt-
trag im Zonenfile eine ringförmige Ver- zen die DNSSEC-Validierung direkt (siehe
kettung herstellt und somit die „Lücken“ Eine weitere Risikobewertung ist für den auch [DNSSEC Resolver]).
zwischen den Einträgen füllt. Somit kann Umgang mit der „letzten Meile“ der DNS-
an einen anfragenden Client eine signier- Kommunikation notwendig. Da die DNS-Cli- Zwar ist der Schutz vor Angriffen kein spe-
te NXDOMAIN- bzw. NODATA-Antwort ge- ents der meist genutzten Betriebssysteme zifisches DNSSEC-Thema, dennoch ist auch
sendet werden. Nachteil dieser Methode standardmäßig keine DNSSEC-Validierung hierauf besonderes Augenmerk zu richten,
ist, dass die NSEC-Einträge in Klartext ge- unterstützen, wird diese Funktion von ei- da es sich bei DNS-Servern um kritische
speichert vorliegen und somit ein sehr ein- nem separaten DNS-Server erbracht. Dieser Infrastrukturkomponenten handelt. Aus
faches Auslesen der kompletten Domain- kann sich in eigener administrativer Hoheit diesem Grund ist es empfehlenswert, ei-
inhalte möglich ist (sog. Zone-Walking). befinden oder z. B. vom Netzprovider an- ne eventuell bereits vorhandene Instal-
Als Abhilfe wurde der RR-Typ NSEC3 defi- geboten werden. Mit dieser Betriebsweise lation unter diesem Aspekt zu überprü-
niert, bei dem die Informationen mittels ist verbunden, dass auf der Netzwerkstre- fen. Schwerpunkt sollte auf einer klaren
eines Hashs geschützt werden. Dieses hat cke zwischen Client und Server potentiell Definition der einzelnen Funktionen und
allerdings den Nachteil, dass für die Er- eine Manipulation der DNS-Antwortpake- wenn möglich deren Trennung liegen. So-
stellung und Validierung dieser Einträge te möglich ist. Bei besonders sicherheits- mit kann man z. B. die eigentliche Pflege
ein wesentlich höherer Rechenaufwand kritischen Systemen und Anwendungs- der Zonen- bzw. Domaindaten auf einen
nötig ist. Je nach Nutzungszweck der Do- servern ist es deshalb dringend zu emp- Hidden Master Server konzentrieren und
main und Schutzbedarf der einzelnen Do- fehlen, die Validierung der DNSSEC-Daten diesen in einer Sicherheitszone platzieren,
maininformationen (Hostnamen, Service- lokal vorzunehmen. Hierfür sind mittler- die eine nur sehr eingeschränkte Kommu-Sie können auch lesen
