Das HostLock Quarantänesystem

Größe: px
Ab Seite anzeigen:

Download "Das HostLock Quarantänesystem"

Transkript

1 Rechenzentrum Technical Report Das HostLock Quarantänesystem Adrian Wiedemann RZ-TR

2

3 Inhaltsverzeichnis Inhaltsverzeichnis 1 Automatismen zur Rechnerisolation bei Sicherheitsvorfällen Ausgangssituation und Problemstellung Zielsetzung der Arbeit Entwurf eines generischen Architektur zur Abschottung Analyse von Arbeitsprozessen Implementierung einer SOA Generische Mechanismen für Rechnerisolation Abschottung auf physikalischer Schicht, OSI Layer Abschottung auf logischer Zugangsschicht, OSI Layer Abschottung auf Vermittlungsschicht, OSI Layer Geschäftsprozesse 11 4 Architektur Anforderungen Einbettung in die vier Management-Modellbereiche Klassifizierung von Modulen Sensormodule Dispatchermodule Datenbankmodule Exportmodule Implementierung Verwendete Module Auswahl des Software-Frameworks Bewertung Ausblick Support für IDMEF Sensordiversifikation Sicherheitsmechanismen

4 Abbildungsverzeichnis Abbildungsverzeichnis 1 Zyklischer Bearbeitungsprozess eines Sicherheitsvorfalls. Dunkle Flächen markieren die Aufgaben des Quarantänesystems Darstellung des Geschäftsprozesses. Zu erkennen sind die einzelnen Arbeitsschritte die im Prozess serialisiert sind Darstellung der Funktionsweise des Sensormoduls als Datenquelle für das Quarantänesystem. Links ist ein (physikalischer) Sensor dargestellt der die Daten liefert, rechts die Softwaremodule des Quarantänesystems Generische Architektur des Quarantänesystems Einbettung des Quarantänesystems HosLock in die Managementumgebung am Rechenzentrum Implementierung des Quarantänesystems an der Universität Karlsruhe

5 Tabellenverzeichnis Tabellenverzeichnis 1 Übersichtstabelle der Isolationsmechanismen Häufung von Vorfällen pro IP-Adresse

6 Abstract Abstract HostLock ist ein Quarantänesystem für automatisierte Isolation von Rechnern in großen Netzwerken. Automatisierte Isolation von Rechnern ist bei der Anfälligkeit der heutigen Betriebssysteme und der hohen Ausbreitungsgeschwindigkeit von Schadsoftware ein integraler Bestandteil eines reaktiven Sicherheitskonzepts. In einer generischen Architektur wird diese Isolation durch die Abarbeitung vieler kleine Arbeitsschritte definiert. Diese Arbeitsschritte werden in Geschäftsprozessen modelliert, was hier auch die Basis der Softwareimplementierung ist. Diese prozessorientierte Modellierung ist in der Softwarearchitektur durch den Begriff der SOA (Service Oriented Architecture) bekannt geworden. Der Mechanismus orientiert sich, da die Rechner im Netzbereich isoliert werden sollen, am ISO/OSI Schichtenmodell, wobei dieses nur auf den unteren drei Schichten untersucht wird. Es wäre nicht sinnvoll eine Isolation auf höherer Schicht zu implementieren, da diese lediglich die Ende-zu-Ende Kommunikation regeln und daher bei Masseninfektionen nicht relevant sind. Es wird eine generische Architektur vorgestellt, die die größtmögliche Flexibilität bietet, da die Prozesse durch ein Regelsystem definiert werden. Auch die Implementierung des Systems an der Universität Karlsruhe wird beschrieben, und dies auch hinsichtlich der Effizienz betrachtet. Abschließend wird ein Ausblick über die weitere technische Entwicklung des Systems gegeben. Diese Ausarbeitung korrespondiert zu dem veröffentlichten Abstract des Autors beim SPRING Workshop 2006 in Berlin [Wie06]. 6

7 Automatismen zur Rechnerisolation bei Sicherheitsvorfällen 1 Automatismen zur Rechnerisolation bei Sicherheitsvorfällen Die Bearbeitung von Sicherheitsvorfällen in der Informationstechnologie gehört heute zu den Standardaufgaben eines Systembetreuers bzw. Administrators. Die Anzahl der Sicherheitsvorfälle innerhalb von IT Systemen vom Klein- und Mittelständischen Unternehmen liegt meistens in einem Bereich, der von einer Person manuell bewältigt werden kann. Falls die IT-Systeme jedoch eine gewisse Größe überschreiten, können diese Sicherheitsvorfälle nicht mehr manuell abgearbeitet werden, so dass die Erledigung dieser Arbeit nur mit Automatismen möglich wird. 1.1 Ausgangssituation und Problemstellung Sicherheitsvorfälle in größeren IT Systemen sind nicht mehr ohne Automatismen handhabbar. Sicherheitsvorfälle sind selbst dabei nicht nur Systemeinbrüche, sondern betreffen auch ein nicht konformes Verhalten eines IT Systems gemäß einer festgelegten Richtlinie (Policy). Ein Beispiel für ein nicht-konformes Verhalten wäre ein Rechner, der als Plattform für einenen ssh-bruteforce Angriff missbraucht wird. Um zu verhindern, dass weiterer Schaden entsteht, muss ein System, das diese Auffälligkeiten zeigt, von anderen Systemen abgeschottet werden. Die Abschottung muss dabei so realisiert werden, dass nur noch auf dedizierte Dienste (z.b. Selfservice Portale) zugegriffen werden kann. Dieser Fall lässt sich aber bei größeren IT Systemen nicht realisieren - insbesondere dann nicht, wenn das Gesamtsystem eine weite geographische Verteilung besitzt. Dedizierte Dienste wären beispielsweise spezielle Hilfeseiten, auf welchen die notwendige Vorgehensweise im Quarantänefall dokumentiert ist. Ein Quarantänesystem kann infizierte Rechner isolieren und den Rest des Netzwerks vor diesen schützen - es ist nicht Aufgabe des Quarantänesystems Sicherheitsvorfälle zu erkennen oder zu bewerten. Abbildung 1 skizziert die Behandlung eines Sicherheitsvorfalles. Die Aufgaben, die dabei vom Quarantänesystem übernommen werden, sind dunkler dargestellt. Augrund von verschiedenen Kriterien sind innerhalb einer IT Netzinfrastruktur Komponenten von verschiedenen Herstellern zu finden. Dies macht zunächst ein generischen Mechanis- Abbildung 1: Zyklischer Bearbeitungsprozess eines Sicherheitsvorfalls. Dunkle Flächen markieren die Aufgaben des Quarantänesystems. 7

8 Automatismen zur Rechnerisolation bei Sicherheitsvorfällen mus des Quarantänemechanismus notwendig, der sich an der OSI Schichtenarchitektur (Referenz) orientiert. In der Arbeit von Stephan Riebach et al. [Rie05] wird ein Quarantänesystem implementiert, das spezifische Herstellermechanismen (Quarantäne VLANs) zurückgreift - also nicht ohne weiteres auf andere Infrastrukturen übertragbar ist. Es ist jedoch nicht ausreichend, eine generische Architektur eines Isolationsmechanismus entworfen zu haben. Für eine effiziente Bearbeitung von Sicherheitsvorfällen müssen die Automatismen die bestehenden Arbeitsschritte und die daraus resultierenden Arbeitsprozesse möglichst detailgetreu abbilden. Das hat zur Folge, dass die verschiedenen Automatismen in sich abgeschlossen sein müssen. Diese Abgeschlossenheit impliziert einen modulartigen Aufbau der Softwarekomponenten. Die Gliederung der Arbeitsschritte und die damit bestimmte Verwendungsreihenfolge der unterschiedlichen Softwarekomponenten wird durch die Analyse der manuellen Arbeitsprozesse bestimmt. 1.2 Zielsetzung der Arbeit Zielsetzung der vorliegenden Arbeit ist der Entwurf einer generischen Architektur für die Isolation der infizierten Rechnersysteme, sowie - aufbauend auf dieser Architektur - die Schaffung von Softwaremodulen, die die entsprechenden Arbeitsschritte ausführen. Die Modellierung der Arbeitsprozesse muss dabei durch ein Regelsystem geschehen, so dass die Abbildung möglichst realitätsnah durchgeführt werden kann Entwurf eines generischen Architektur zur Abschottung Es soll eine genrische Architektur für die Abschottung von Systemen entworfen werden. Diese Architektur verwendet das OSI Modell als Gerüst, um die unterschiedlichen Abstraktionsstufen abzubilden. Dabei werden die in der jeweiligen Schicht des OSI Modells möglichen Abschottungsmechanismen untersucht Analyse von Arbeitsprozessen Entsprechende Arbeitsprozesse sollen untersucht und in einzelne Teilarbeitsschritte zerlegt werden. Diese Teilarbeitsschritte sind so zu wählen, dass diese möglichst unabhängig voneinander und in sich abgeschlossen sind. Diese Teilarbeitsschritte werden im Anschluss an diese Analyse als eigentständige Softwaremodule implementiert Implementierung einer SOA Ziel der Arbeit ist die Schaffung eines Quarantänesystems, das bei der automatisierten Isolation von infizierten Rechner unterstützend wirken soll. Es soll bei der täglichen Arbeit die wiederkehrenden Arbeitsschritte weitestgehend automatisieren, jedoch die Flexibilität und Erweiterbarkeit eines modernen Softwaresystems behalten. Die Implementierung richtet sich dabei nach den Grundsätzen einer serviceorientierten Architektur (SOA). 8

9 Generische Mechanismen für Rechnerisolation 2 Generische Mechanismen für Rechnerisolation Bei infizierten Rechnern ist die Trennung vom Produktionsnetz als erste Maßnahme geeignet. Für die Isolaton des Rechners können unterschiedliche Trennungen vorgenommen werden - als Grundlage wird hier das ISO/OSI Modell verwendet. Durch die hierarchische Trennung sind die unerschiedlichene Techniken sauber voneinander abgegrenzt. Bei nachfolgenden Betrachtungen der unterschiedlichen Abschottungsmechanismen (wenn möglich) orientiert sich die Betrachtung streng an der Gliederung des ISO/OSI Modells. 2.1 Abschottung auf physikalischer Schicht, OSI Layer 1 Isolationen auf physikalischer Schicht sind mit Sicherheit die effektivsten Mechanismen, um einen Rechner von Netz zu trennen. Nach einer Trennung auf Schicht 1 hat ein Rechner keinen Kontakt mehr zum entsprechenden Netzwerksegment. Trotz der hohen Effektivität bezüglich der Isolation zieht eine physikalische Trennung weitere Probleme nach sich. Zum Teil sind in vorhandenen Netzwerkinstallationen noch alte Verkabelungsstandards vorhanden, die topologisch als Busstruktur ausgelegt sind. Diese Busstruktur (10 Base 2) lässt die Trennung eines einzelnen Rechners nicht ohne weiters zu, da eine gemeinsame Nutzung des Mediums erfolgt - es also bei allen an diesem Segment angeschlossenen Geräten zu einer Unterbrechung der Datenanindung kommen würde. Bei einer strukturierten Verkabelung nach EN hat jeder Rechner das Medium exklusiv zur Verfügung, in Falle einer Trennung wären daher keine Seiteneffekte zu erwarten. Moderne Netzwerkkomponenten erlauben die softwaregestützte Abschaltung einzelner Ports, so dass auch in größeren Umgebungen ein Einsatz dieses Abschottungsmechanismus denkbar wäre. 2.2 Abschottung auf logischer Zugangsschicht, OSI Layer 2 Auf Schicht zwei des OSI Modells wird die Übertragung der Daten zwischen den Rechnern innerhalb eines Segments durchgeführt. Ein Segment bezeichnet dabei die Menge aller Rechner, die direkt physikalisch miteinander konnektiert sind. Auf Schicht zwei wird als Übertragungsprotokoll in den meisten Fällen Ethernet eingesetzt, je nach Bandbreite in verschiedenen Standards. Um innerhalb eines Segments direkt miteinander kommunizieren können, müssen die Rechner adressierbar sein. Die Adresse wird als MAC (Medium Access Control) Adresse bezeichnet. Bei Ethernet besitzen die MAC Adressen eine Breite von 48 bit, und sind - lt. Standard IEEE weltweit eindeutig. Um eine Isolation eines Rechners auf Schicht zwei zu erreichen, gibt es verschiedene Möglichkeiten. Zunächst ist es möglich, auf den Anschluss einen Filter zu setzen, so dass keine Ethernet-Pakete mehr gesendet werden können. Damit ist der Rechner logisch von Netz getrennt. Leider ist dieser Mechanismus nicht effektiv, denn es gibt heute eine Vielzahl von Möglichkeiten, diese Isolation zu umgehen: eine sehr simple Methode ist die Verwendung eines zweiten Ethernet Anschlusses am Rechner. Des Weiteren ist bei der Verkabelung mittels einer Bustopologie dieses Verfahren nicht zweckmäßig: Die Filterung könnte nur am Übergang des Segments in andere Netzbereiche geschehen - der Schutz anderer Rechner innerhalb des Segments wäre mit dieser Methode nicht zu implementieren. Dies gilt ebenso für alle nachfolgend genannten Maßnahmen. Seit 1998 gibt es mit der Veröffentlichung des IEEE 802.1q Standards die Möglichkeit, so 9

10 Generische Mechanismen für Rechnerisolation Isolation Layer 1(e) Layer 1(g) Layer 2 Layer 3 Mediennutzung gemeinsam exklusiv beide beide Wirkungsbereich Segment Host Host Host Umgehung N/A N/A möglich einfach möglich Remediation N/A N/A Quarantäne VLANs spezielles Routing Tabelle 1: Übersichtstabelle der Isolationsmechanismen genannte VLANS einzusetzen. Das Ethernet Paket enthält dabei noch ein weiteres Datenfeld der Länge 32 bit. Das Datenfeld wird in diesem Standard als Tag bezeichnet. Durch den Einsatz von VLANs bieten sich flexiblere Möglichkeiten, Rechner zu isolieren, ohne dass diese dabei die Möglichkeit zur Kommunikation verliegen. Denkbar wäre der Einsatz von Quarantäne VLANs. Quarantäne VLANs funktionieren wie folgt: Nach der Erkennung eines infizierten Host wird den Anschluss ein anderes VLAN zugewiesen. Dies bedeutet, dass er mit den Rechnern innerhalb seines originalen Segments nicht mehr kommunizieren kann - nur noch mit Rechnern, die sich auch in diesem Quarantäne VLAN befinden. Bei kritischen Systemen macht es Sinn, diese also nicht in ein gemeinsames VLAN zu transferieren. In diesen Falls ist es notwendig mehrere Quaratäne VLANs zu haben, so dass sich jeder kritische Rechner, der infiziert worden ist, alleine in seinem Netz befindet. Augenscheinlich mag das paranoid klingen, hat aber doch einen triftigen Grund: Quarantäne VLANs unterliegen in der Regel nicht derselben (restriktiven) Kontrolle wie Produtionsnetze. Wenn nun ein kritischer Rechner infiziert worden ist, würde dieser ins Quarantäne VLAN transferiert. Ein möglicher Angreifer kann sich durch eine gezielte Attacke mit Absicht ins Quarantäne VLAN transferieren lassen - um ungestört den kritischen Rechner angreifen zu können. 2.3 Abschottung auf Vermittlungsschicht, OSI Layer 3 Es gibt aber neben der Abschottung auf Schicht eins und zwei noch die Möglichkeit, Rechner auf Schicht drei zu isolieren. Auf OSI Schicht drei gibt es eine Vielzahl von Protokollen - es wird hier aber nur das Internet Protocol betrachtet, da andere Protokolle für die Kommunikation in lokalen Netzen kaum noch von Bedeutung sind. Analog zu der Filterung auf Schicht zwei, gibt es die Möglichkeit, auch auf Schicht drei zu filtern. Dabei ist aufgrund der Aufgabenspezifikation der Schicht drei des OSI Modells die Filterung erst dann möglich, wenn die Daten das IP Subnetz verlassen. Wenn die Datenkommunikation innerhalb des Subnetzes geschieht, ist keine Filterung möglich. Ähnlich wie bei dem Transfer von infizierten Rechnern in Quarantäne VLANs ist die Umleitung der Rechner auf einen speziellen Host. Wenn ein infizierter Rechner einen Datenkanal über die Subnetzgrenzen hinweg aufbauen will, wird er von dem nächsten Vermittlungsknoten auf einen speziellen Rechner umgeleitet. Der Datentransfer innerhalb des Subnetzes ist durch diese Maßnahme nicht eingeschränkt. Durch die Einschränkung der Kommunikation auf einen Rechner außerhalb des Subnetzes eröffnet sich die Möglichkeit, dem Betreuer des betroffenen Rechners direkt Unterstützung zukommen zu lassen. Des Weiteren ist die Filterung bzw. Umleitung auf Schicht drei eine Möglichkeit eine Isolation herstellerunabhängig zu implementieren: Das Protokoll IP ist von der IETF als Standard (RFC 791) definiert worden. 10

11 Geschäftsprozesse 3 Geschäftsprozesse Rechnerisolationen in einem Netzwerk sind aus verschiedenen Gründen in der Regel sehr aufwändig für größere Netzwerke. Zunächst ist die hohe Anzahl an Netzkomponenten und eine vermaschte Verbindung dieser ein großes Hindernis, da die Komplexität des Netzes nicht linear mit der Anzahl der Knoten wächst. Um diese hohe Komplexität zu meistern, ist der Prozess der Rechnerisolation in viele kleine Teilarbeitschritte unterteilt: 1. Entscheidung auf welcher Ebene ein System isoliert werden soll 2. Filterung der entsprechenden Netzkomponenten nach Kriterium aus 1 3. Lokalisierung des Rechner innerhalb dieser Netzkomponenten (z.b. Bestimmung des Anschlus-Ports) 4. Durchsetzung der Isolationsmaßnahme 5. Protokollieren des Vorgangs Diese Teilarbeitsschritte bauen aufeinander auf, können jedoch in ihrer Ausprägung unterschiedlich sein (Beispiel: Durchsetzung des Isolationsmechanismus: Hier kann auf Schicht 1-3 isoliert werden, die Abfolge der Arbeitsschritte bleibt jedoch gleich). Eine bestimmte Abarbeitungsfolge von Arbeitsschritten wird als Geschäftsprozess bezeichnet; Abbildung 2 verdeutlicht diesen. Abbildung 2: Darstellung des Geschäftsprozesses. Zu erkennen sind die einzelnen Arbeitsschritte die im Prozess serialisiert sind. Diese Arbeitsschritte sollten unabhängig voneinander implementiert werden. Dies kann durch die Modellierung der Arbeitsschritte als Services erreicht werden. Eine Architektur die diese Services als Bausteine verwendet und darauf aufbaut, wird als serviceorientieren Architektur (SOA) bezeichnet. Die vorgeschlagene Architektur (Kapitel 4) des Quarantänesystems orientiert sich stark an einer SOA. Das Konzept der SOA bietet die Möglichkeit, eine auf die Geschäftsprozesse ausgerichtete IT-Architektur möglichst flexibel zu gestalten. Dadurch kann auf Änderungen oder Erweiterungen durch zusätzliche Anforderungen schnell reagiert werden. Die Geschäftsprozesse werden in einer SOA durch die Aneinanderreihung von Services definiert. Ein Service in einer SOA ist eine gekapselte Funktionalität, die über eine standardisierte Schnittstelle zur Verfügung gestellt wird. 11

12 Architektur 4 Architektur Durch die Verwendung des Architekturprinzips einer SOA werden die einzelnen Funktionalitäten der Arbeitsprozesse als Service implementiert. Diese allgemein als Service bezeichneten Komponenten sind in der Regel Webservices. Ein Webservice [W3C02] stellt auf Basis des HTTP Protokolls einen Dienst zur Verfügung, der durch die extrem starke Verbreitung von Webservern und Browsern sehr einfach genutzt werden kann. Die Daten, die von und zu einem Webservice übertragen werden, unterscheiden sich aber signifikant vom bekannten HTML-Datenstrom. Sie basieren auf einem XML-Protokoll, dem Simple Object Access Protocol (SOAP) [W3C03]. Nicht nur der SOAP-Transportcontainer wird durch XML definiert, auch die Schnittstellenbeschreibung des Webservices selbst verwendet als Basis XML. Die Beschreibungssprache des Schnittstelle wird einfach als Webservice Description Language (WSDL) bezeichnet. 4.1 Anforderungen Durch diesen Architekturansatz ist zunächst keine Hierarchie zwischen den Services vorgegeben. Die Services sollen hier als Module bezeichnet werden. Da die Module nur einzelne Funktionalitäten bereitstellen und ein Geschäftsprozess nur durch die Kombination der verschiedenen Module entsteht, ist in diesen Modulen auch keine übergreifende Logik enthalten. Diese Logik wird durch ein externes Regelsystem vorgegeben (z.b. Microsoft Biztalk Server). Diese Verwendung einer SOA bringt für dieses System Vorteile mit sich, unter anderen sind die Anforderungen, die im Vorfeld für das System skizziert worden sind, durch die serviceorientierte Architektur vollständig abgedeckt: 1. Modulare Bauweise: Es ist eine loose Kopplung erforderlich, da die Komponenten in einem verteilen System arbeiten 2. Plattformunabhängigkeit: Die Komponenten werden auf verschiedenen Plattformen implementiert. Es kann nicht gesichert werden, dass diese Plattformen homogen sind, dies muss jedoch für das System vollständig transparent sein. 3. Sprachunabhängigkeit: Aufgrund der nicht gesicherten Plattformhomogenität kann auch keine Festlegung auf eine einheitliche Sprache durchgesetzt werden. 4. Datenstruktur XML: Die Notwendigkeit zur Kommunikation in einem verteilten System mit standardisierten Schnittstellen führten dazu, dass das generische Datenmodell XML als Basis verwendet wird. 4.2 Einbettung in die vier Management-Modellbereiche Das Funktionsmodell versucht die unterschiedlichen Arbeitsbereiche eines Managementsystems zu gliedern, dies sind in der Regel die Bereiche: Fault-, Configuration,- Accounting-, Performance-, und Securitymanagement. Das Quarantänesystem fällt dabei eindeutig in den Bereich des Securitymanagement, die anderen Bereiche sind der bisherigen Architektur noch nicht vorgesehen. Das Kommunikationsmodell für den Datentransfer zwischen den Modulen wird durch das SOAP Protokoll realisiert. Grafik 4 skizziert das Informationsmodell des Quarantänesystems, in den es die verwendeten Ressourcen zueinander in Beziehung setzt. Das 12

13 Architektur gesamte System ist durch die Konzentration der Services auf ein Host zunächst zentral organisiert, diese Services können aber auch auf unterschiedlichen Rechnern verteilt sein. Aus diesem Grund kann dies als dezentrales Organisationsmodell verstanden werden. Diese Anforderungen gelten für alle diese Module. Es kann jedoch nicht sichergestellt werden, dass alle Module in der gleichen Weise implementiert werden können (beispielsweise die Verwendung einer anderen Programmiersprache für die Implementierung). Aus diesem Grund gibt es zwei getrenne Entwicklungshierarchien des Quarantänesystems: Das Kernsystem (HostLock Core) und das Nicht-Kernsystem (HostLock Satellite). Ein Überblick über die generische Architektur wird durch Grafik 4 gegeben. 4.3 Klassifizierung von Modulen Da in einem Quarantänesystem die Module viele verschiedene, aber ähnliche Aufgaben haben, ist eine Modulklassifizierung eingeführt worden. Die Klassifizierung basiert auf den unterschiedlichen Funktionalitäten die durch die Module bereitgestellt werden. Bisher sind vier Modulklassen definiert worden: Sensormodule Dispatchermoule Datenbankmodule Exportmodule Sensormodule Sensoren sind die Systeme, die als Datenquelle für das Quarantänesystem fungieren. Die Sensoren können unterschiedlicher Ausprägung sein (netz- oder hostbasiert), und können ebenfalls verschiedene Plattformen verwenden. Die für die Ankopplung der Sensoren an das Quarantänesystem verantwortlichen Module befinden sich im Regelfall auf der Sensorplattform - dies impliziert, dass für die Implementierung der jeweiligen Sensormodule unterschiedliche Programmiermethoden und Sprachen eingesetzt werden. Die Sensormodule sind nicht an der Datenverarbeitung der Vorfälle innerhalb des Quarantänesystems beteiligt; aus diesem Grund sind diese nicht Teil des HostLock Kernsystems. Es ist nicht die Aufgabe der Sensormodule eine Einbruchserkennung durchzuführen, hierfür sind die Sensoren zuständig. Sensormodule leiten Daten also an das Quarantänesystem weiter, welche sie von den entsprechenden Sensoren erhalten haben. Die Funktionsweise dieser Module wird durch Abbildung 3 verdeutlicht Dispatchermodule Die interne Verarbeitung der Daten geschieht in den Dispatchermodulen. Typische Aufgaben der Dispatchermodule sind die Umwandlung von Datenformaten oder andere Hilfsaufgaben innerhalb des Quarantänesystems. Dispatchermodule sind Teil des HostLock Kernsystems Datenbankmodule Die Speicherung der Vorfälle geschieht in einem Datenbanksystem. Um den Datenzugriff der Dispatcherkomponenten transparent zu halten, sind Datenbankmodule entworfen worden. 13

14 Architektur Abbildung 3: Darstellung der Funktionsweise des Sensormoduls als Datenquelle für das Quarantänesystem. Links ist ein (physikalischer) Sensor dargestellt der die Daten liefert, rechts die Softwaremodule des Quarantänesystems. Durch diese Schnittstelle kann das System unabhängig von der Datenbank operieren. Des Weiteren ist durch diese Kapselung der Daten eine saubere Trennung zwischen Datenhaltung und Geschäftslogik geschaffen worden Exportmodule Der vierte Modultyp sind die sogenannten Exportmodule. Mit diesen Modulen werden die Daten erzeugt, die den nachrangigen Komponenten mitteilen, welche Rechner oder Benutzer zu isolieren sind. Als nachrangige Komponenten werden dabei die Systeme bezeichnet, die in der jeweiligen Netztopologie die entsprechenden Isolationsmaßnahmen umsetzen. In den meisten Umgebungen werden das die Netzkomponenten sein, die physikalisch am nächsten an den infizierten Rechnern lokalisiert sind, also Vermittlungskomponenten auf Schicht zwei (Switches, Bridges, etc.). 14

15 Architektur Abbildung 4: Generische Architektur des Quarantänesystems 15

16 Implementierung 5 Implementierung Nachdem in Kapitel 4 die generische Architektur des Quarantänesystems vorgestellt worden ist, soll in nachfolgenden Kapitel ein Überblick über die Implementierung des Systems an der Universität Karlsruhe (TH) gegeben werden. Die Isolationen werden in diesem Szenario auf Schicht drei durchgeführt. Andere Isolationsmechanismen können nicht verwendet werden, da die entsprechende Hardware, die Isolationen auf Stufe zwei durchführen kann, nicht einheitlich vorhanden ist. Die Einbettung in die entsprechenden Landschaft des Managements wird durch Abbildung 5 visualisiert. 5.1 Verwendete Module Zunächst ist für die Detektion der entsprechenden infizierten Rechner eine Hardware notwendig, die vor dem Eingangsrouter installiert ist. Diese Hardware ist das Intrusion Prevention System der Firma McAfee und filtert in Echtzeit den Datentrom in der Außenanbindung. Diese Hardware ist entsprechend den Anforderungen der Universität konfiguriert worden, so dass diese nicht ohne weiteres in anderen Szenarien eingesetzt werden kann. Für die Einbindung des Sensors ist ein Sensor-Modul vorhanden, das die entsprechenden Vorfälle entgegennimmt und an das HostLock Kernsystem weiterleitet. Die interne Verarbeitung der Daten geschieht zur Zeit noch nicht regelbasiert, hierfür existiert ein Dispatcher-Modul, welches die entsprechende Geschäftslogik implementiert. Da es in diesem Szenario nicht immer sinnvoll ist, eine IP-Adresse zu sperren, wird hier eine Unterscheidung auf Basis der IP- Adresse getroffen, die als Quelle innerhalb des Netzes bekannt ist. Falls diese IP-Adresse zu dem Adresspool des Virtual Private Networks (VPN) gehört, wird für diese VPN-Verbindung die entsprechende Benutzerkennung ermittelt und diese für eine eventuelle Sperre an die zuständigen Systeme übergeben. Diese zwei grundsätzlich untschiedlichen Isolationsmechanismen machen die Notwengigkeit zweier getrennter Exportmodule notwendig. Abbildung 6 stellt die gerade vorgestellten Module in einen Zusammenhang und verdeutlicht die spezifische Architektur des HostLock Systems an der Universität Karlsruhe (TH). 5.2 Auswahl des Software-Frameworks Für die Entwicklung des Kernsystems wurden zunächst Implementierung auf Basis von Java untersucht. Diese Evaluierung kam aber zu dem Ergebnis, das die Implementierung von Webservices mit der Java Plattform auf Basis des Axis2 Toolkit noch zu wenig dokumentiert ist, des Weiteren befindet sich das Toolkit noch in einem Entwicklungsstadium. Aus diesem Grund wurde beschlossen, dass die Implementierung der Webservices mittels des.net Frameworks 1.1 von Microsoft erfolgen soll. Diese Plattform hat sich in den letzten zwei Jahren in der Industrie etabliert und bewährt. Der gesamte Kernbereich von HostLock wird mit.net 1.1 entwickelt, nicht jedoch die Sensoren. Diese laufen auf den verschiedenen Plattformen, daher wird die Implementierung auf Basis der entsprechenden Plattform festgelegt. Wenn möglich, sollte die Implementierung jedoch auch mit.net 1.1 (C#) erfolgen. Im Falle der Universität Karlsruhe (TH) sind nachrangigen Netzkomponenten die zentralen Routerkomponenten: hier werden durch die Exportmodule die ACL-Einträge in den Routern erzeugt, welche dann zu einer Isolation des System führen. 16

17 Implementierung IP-Adresse Gezählte Vorfälle Tabelle 2: Häufung von Vorfällen pro IP-Adresse 5.3 Bewertung Das System war vier Wochen im Testbetrieb ( ), so dass das Verhalten genau beobachtet werden konnte, um eventuelle Fehler in der Implementierung zu beheben oder Seiteneffekte zu identifizieren. In dieser Testphase wurden Sperrungen in die Datenbank geschrieben, diese wurden aber nicht durch Exportmodule auf die entsprechenden Router weitergegeben. Statt dessen wurden zu Debugzwecken s über jede Transaktion an den Entwickler versandt, so dass eine genaue Untersuchung der Vorfälle durchgeführt werden konnte. Während der Testphase wurde ein Adressraum von IP-Adressen überwacht ( /16 und /17), für den insgesamt 268 Fälle gemeldet worden sind (0,29% des Adressraumes, Tabelle 2). Die Verteilung der Vorfälle in Abhängigkeit der IP-Adresse ist signifikant, aber bei genaueren Hinsehen keineswegs ungewöhnlich. Die Häufung der Vorfälle ist bei dem Rechner mit der IP-Adresse zu erkennen. Aufgrund der fast durchgängigen Verwendung von privaten IP Adressen nach RFC 1918 muss ein System vorhanden sein, um diese auf öffentliche IP-Adressen umzusetzen (Network Address Translation, NAT). Dieser Rechner ist ein zentraler NAT-Router der Universität, die Vorfälle werden demzufolge nicht von diesem Rechner selbst, sondern von Rechnern dahinter erzeugt. Es ist ohne Weiters - aufgrund der Platzierung des Intrushield Sensors - keine weitere Identifizierung der Ursprungsrechner möglich. Eine Isolation wäre in diesem Fall nicht sinnvoll, da durch die Sperrung viele Rechner hinter dem NAT-Router betroffen wären. Für dieses Problem gibt es zwei mögliche Lösungen. Eine davon wäre die Platzierung eines weiteren Intrushield Sensors hinter (auf der Seite der privaten IP-Adressen) dem NAT-Router, 17

18 Implementierung so dass die originale IP-Adresse des verursachenden Rechners bekannt ist. Die andere Lösung wäre die Etablierung eines Webservices, mit Hilfe dessen die entsprechende IP ermittelt werden kann. Momentan werden diese Daten von Hand aus der Verbindungstabelle ausgelesen. Wenn davon ausgegangen wird, dass nur jeder dritte Vorfall einem Rechner zuzuordnen ist, müssen pro Monat noch ca. 80 Vorfälle von Hand herausgesucht werden. Bei einer durchschnittlichen Suchdauer von 10 Minuten sind das 40 Minuten pro Tag, die ein Mitarbeiter aufwenden muss um den entsprechenden Rechner zu identifizieren. Es ist also ratsam, für diese Suche ein Modul zu implementieren. Ähnlich verhält es sich mit den anderen IP-Adressen, die eine signifikante Häufung der Vorfälle zeigen. In der Tabelle sind jedoch auch noch 12 Rechner aus dem Bereich /17 aufgeführt. Dabei handelt es sich um VPN-Verbindungen. Auch hier ist eine Sperrung der IP- Adresse nicht sinnvoll, denn aufgrund der dynamischen Adresszuweisung kann keine eindeutige Zuordnung des Rechners geschehen. Für diese Fall existieren Dispatcher-Module, die anhand der momentan aktiven IP-Adresse die Benutzerkennung zurückliefern, mit der diese VPN-Verbindung aufgebaut worden ist. Diese Kennung wird dann gesperrt, so dass nach einer Trennung der Verbindung keine weitere möglich ist. 18

19 Implementierung Abbildung 5: Einbettung des Quarantänesystems HosLock in die Managementumgebung am Rechenzentrum Abbildung 6: Implementierung des Quarantänesystems an der Universität Karlsruhe 19

20 Ausblick 6 Ausblick 6.1 Support für IDMEF In den letzten Jahren sind viele Intrusion Detection Systeme (IDS) entstanden. Fast jedes deckt einen Spezialbereich ab, in welchem es versucht, Einbrüche zu erkennen. Durch diese starke Spezialisierung sind die erkannten Einbrüche extrem kontextabhängig. Diese Kontextsensititivät erschwert die Klassifikation und die Korrelation mit Daten, die von anderen IDS erkannt worden sind. Hervé Debar hat 1998 eine Taxonomie für IDS veröffentlicht [Deb98]. Diese Taxonomie soll das Ziel verfolgen, die Daten, die aus IDS gewonnen werden, entsprechend zu kategorisieren. Durch diese Kategorisierung und die daraus resultierende Vereinheitlichung kann ein IDS einem anderen IDS Daten zur verfügung stellen, ohne dass die Daten in einem anderen Kontext interpretiert werden. Das Protokoll zum Austausch der Daten ist das Intrusion Detection Message Exchange Format (IDMEF). Dieses XML basierende Datenkonstrukt ist ein generischer Behälter, in dem jeder Vorfall abgebildet und von einem System zum anderen übertragen werden kann. Momentan existiert nur ein Draft zu IDMEF [IDMEF06]. In der monentanen Implementierungsphase ist HostLock noch nicht in der Lage, Daten im IDMEF Format entgegenzunehmen. Diese Möglichkeit soll in naher Zukunft aber verfügbar sein, denn die Anzahl Applikationen, die Daten als IDMEF exportieren können, vergrößert sich. 6.2 Sensordiversifikation Neben dem momentan schon verwendenten Intrushield Sensor sollen in absehbarer Zeit noch weitere Sensoren hinzukommen, geplant sind zahlreiche Systeme, die elektronische Köder verwenden (Honeypots, Honeynets). Es ist aber auch denkbar, dass mehr hostbasierende IDS zum Einsatz kommen, hier muss aber vor dem Einsatz genau evaluiert werden, in welchem Maß der Einsatz von solchen Sensoren die Benutzbarkeit von Mehrbenutzersystemen einschränkt. 6.3 Sicherheitsmechanismen Das HostLock System stellt eine sehr kritische Infrastruktur dar, da dieses System (bei erfolgreicher Kompromittierung) für einen DoS Angriff auf die Infrastruktur der Universität ohne größeren Aufwand missbraucht werden könnte. Aus diesem Grund müssen die Sicherheitsanforderungen für das Kernsystem selbst aber auch für die entsprechenden Sensoren sehr hoch sein. Neben den an der Universität implementierten netztechnischen Absicherungen muss das System die bekannten Sicherheitsmerkmale Vertraulichkeit, Authentizität und Datenintegrität sicherstellen. Die Erfüllung dieser drei Anforderungen kann am besten durch den Einsatz von digitalen Zertifikaten sichergestellt werden: Jedes Modul bekommt ein eigenes Zertifikat. Durch gegenseitige Überprüfung der Kommunikationspartner kann die Authentizität überprüft, durch Verschlüsselung der Kommunikationskanäle die Vertraulichkeit und durch kryptographische Hash- Verfahren die Integrität der Daten sichergestellt werden. Der Einsatz digitaler Zertifikate setzt jedoch das Vorhandensein einer Public Key Infrastrcuture (PKI) voraus. 20

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden:

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden: Abkürzung für "Virtual Private Network" ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (z.b. Internet), über die nicht öffentliche bzw. firmeninterne Daten sicher übertragen werden. Die

Mehr

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Wolfgang Ginolas Fachhochschule Wedel 21. September 2009 Wolfgang Ginolas (Fachhochschule Wedel) 21. September 2009 1 / 14 Einleitung

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Halle 2007-05-08 Oliver Göbel

Halle 2007-05-08 Oliver Göbel RUS CERT Sicherheit und Sprach-dienste (VoIP) 8. Tagung der DFN-Nutzergruppe Hochschulverwaltung Halle 2007-05-08 http://cert.uni-stuttgart.de/ Das RUS-CERT Folie: 2 Stabsstelle DV-Sicherheit der Universität

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

VIRTUAL PRIVATE NETWORKS

VIRTUAL PRIVATE NETWORKS VIRTUAL PRIVATE NETWORKS Seminar: Internet-Technologie Dozent: Prof. Dr. Lutz Wegner Virtual Private Networks - Agenda 1. VPN Was ist das? Definition Anforderungen Funktionsweise Anwendungsbereiche Pro

Mehr

Enterprise WLANs erfolgreich planen und betreiben

Enterprise WLANs erfolgreich planen und betreiben Enterprise WLANs erfolgreich planen und betreiben Auf dem Weg zum Controller-basierten WLAN-Design von Dr. Simon Hoff Technologie Report: Enterprise WLANs Seite 5-116 5.2 Aufbau eines virtuellen Distribution

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Trusted Network Connect. Networking Academy Day 19.04.2008

Trusted Network Connect. Networking Academy Day 19.04.2008 Trusted Network Connect Networking Academy Day 19.04.2008 Dipl.-Inf. Stephan Gitz Roadmap Ziele der Informationssicherheit Herausforderungen der Informationssicherheit Angriffsvektoren

Mehr

Kurzeinführung VPN. Veranstaltung. Rechnernetze II

Kurzeinführung VPN. Veranstaltung. Rechnernetze II Kurzeinführung VPN Veranstaltung Rechnernetze II Übersicht Was bedeutet VPN? VPN Typen VPN Anforderungen Was sind VPNs? Virtuelles Privates Netzwerk Mehrere entfernte lokale Netzwerke werden wie ein zusammenhängendes

Mehr

Netzwerkkonzepte in System Center 2012 R2 Virtual Machine Manager

Netzwerkkonzepte in System Center 2012 R2 Virtual Machine Manager Netzwerkkonzepte in System Center 2012 R2 Virtual Machine Manager Agenda Das grosse Ganze MAC Adresspools IP-Adresspool Logische Netzwerke Netzwerkstandorte VM-Netzwerke Logische Switches Portprofile Portklassifizierungen

Mehr

HÄRTUNG VON WEB-APPLIKATIONEN MIT OPEN-SOURCE-SOFTWARE. Münchener Open-Source-Treffen, Florian Maier, 23.05.2014

HÄRTUNG VON WEB-APPLIKATIONEN MIT OPEN-SOURCE-SOFTWARE. Münchener Open-Source-Treffen, Florian Maier, 23.05.2014 HÄRTUNG VON WEB-APPLIKATIONEN MIT OPEN-SOURCE-SOFTWARE Münchener Open-Source-Treffen, Florian Maier, 23.05.2014 ÜBER MICH 34 Jahre, verheiratet Open Source Enthusiast seit 1997 Beruflich seit 2001 Sicherheit,

Mehr

Daniel Schieber Technical Consultant

Daniel Schieber Technical Consultant Aktueller Status Unternehmensprofil Daniel Schieber Technical Consultant COMCO Fakten: Gründung 1998 als Systemhaus Firmensitz in Dortmund, NRW 42 Mitarbeiter Umsatzerwartung 10 Mio. in 2006 Entwicklung

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

Mehr

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten Prof. Dr. P. Tran-Gia Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten 4. Würzburger Workshop IP Netzmanagement, IP Netzplanung und Optimierung Robert Henjes, Dr. Kurt Tutschku

Mehr

IPsec. Vortrag im Rahmen des Seminars Neue Internet Technologien

IPsec. Vortrag im Rahmen des Seminars Neue Internet Technologien IPsec Vortrag im Rahmen des Seminars Neue Internet Technologien Friedrich Schiller Universität Jena Wintersemester 2003/2004 Thomas Heinze, Matrikel xxxxx Gliederung IPsec? - Motivation, Grundbegriffe,

Mehr

Agenda. Einleitung Produkte vom VMware VMware Player VMware Server VMware ESX VMware Infrastrukture. Virtuelle Netzwerke

Agenda. Einleitung Produkte vom VMware VMware Player VMware Server VMware ESX VMware Infrastrukture. Virtuelle Netzwerke VMware Server Agenda Einleitung Produkte vom VMware VMware Player VMware Server VMware ESX VMware Infrastrukture Virtuelle Netzwerke 2 Einleitung Virtualisierung: Abstrakte Ebene Physikalische Hardware

Mehr

InfiniBand Low Level Protocol

InfiniBand Low Level Protocol InfiniBand Low Level Protocol Seminar Ausgewählte Themen in Hardwareentwurf und Optik HWS 08 17.12.2008 Andreas Walter Universität Mannheim Inhalt Motivation InfiniBand Basics Physical Layer IB Verbs IB

Mehr

Technischer Anhang. Version 1.2

Technischer Anhang. Version 1.2 Technischer Anhang zum Vertrag über die Zulassung als IP-Netz-Provider im electronic cash-system der deutschen Kreditwirtschaft Version 1.2 30.05.2011 Inhaltsverzeichnis 1 Einleitung... 3 2 Anforderungen

Mehr

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216 WS-Security Sicherheitskonzepte in global verteilten Anwendungen Thies Rubarth 21. Sep 2007 ACM/GI Localgroup #216 Thies Rubarth, M.Sc. (Informatik) IT Berater Jahrgang 1979 Anwendungsentwicklung seit

Mehr

Securing SOAP e-services

Securing SOAP e-services Securing SOAP e-services Nilson Reyes Sommersemester 2004 aus: E. Damiani, S. De Capitani di Vermercati, S. Paraboschi, P. Samarati, Securing SOAP e-sservices, IJIS, Ausgabe 1 (2002), S.110-115. Gliederung

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Rainer Janssen Wolfgang Schott. SNMP- Konzepte, Verfahren, Plattformen

Rainer Janssen Wolfgang Schott. SNMP- Konzepte, Verfahren, Plattformen Rainer Janssen Wolfgang Schott SNMP- Konzepte, Verfahren, Plattformen Inhaltsverzeichnis 1. Einführung 1.1 Netzmananegement, ein Modethema? 1.2 Entwicklung der Netzstrukturen 1.3 Verfahren, Protokolle

Mehr

Ethernet Switching und VLAN s mit Cisco. Markus Keil IBH Prof. Dr. Horn GmbH Gostritzer Str. 61-63 01217 Dresden http://www.ibh.de/ info@ibh.

Ethernet Switching und VLAN s mit Cisco. Markus Keil IBH Prof. Dr. Horn GmbH Gostritzer Str. 61-63 01217 Dresden http://www.ibh.de/ info@ibh. Ethernet Switching und VLAN s mit Cisco Markus Keil IBH Prof. Dr. Horn GmbH Gostritzer Str. 61-63 01217 Dresden http://www.ibh.de/ info@ibh.de Der klassische Switch Aufgaben: Segmentierung belasteter Netzwerke

Mehr

Cisco Systems Intrusion Detection Erkennen von Angriffen im Netzwerk

Cisco Systems Intrusion Detection Erkennen von Angriffen im Netzwerk Cisco Systems Intrusion Detection Erkennen von Angriffen im Netzwerk Rene Straube Internetworking Consultant Cisco Systems Agenda Einführung Intrusion Detection IDS Bestandteil der Infrastruktur IDS Trends

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Version 2.1 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Stand: 28.10.2014 ads-tec GmbH 2014 Big-LinX 2 Inhaltsverzeichnis 1 Einführung... 3 1.1 NAT

Mehr

Daten-Kommunikation mit crossinx

Daten-Kommunikation mit crossinx Daten-Kommunikation mit Datenübertragung.doc Seite 1 von 8 Inhaltsverzeichnis 1 Einführung... 3 1.1 Datenübertragung an... 3 1.2 Datenversand durch... 3 2 X.400... 4 3 AS2... 4 4 SFTP (mit fester Sender

Mehr

Internetworking. Motivation für Internetworking. Übersicht. Situation: viele heterogene Netzwerke

Internetworking. Motivation für Internetworking. Übersicht. Situation: viele heterogene Netzwerke Internetworking Motivation für Internetworking Übersicht Repeater Bridge (Brücke) Verbindung zwischen zwei gleichen LANs Verbindung zwischen zwei LANs nach IEEE 802.x Verbindung zwischen mehreren LANs

Mehr

Chapter 9 TCP/IP-Protokoll Protokoll und IP-Adressierung. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von

Chapter 9 TCP/IP-Protokoll Protokoll und IP-Adressierung. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Chapter 9 TCP/IP-Protokoll Protokoll und IP-Adressierung CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Rick Graziani Cabrillo College Vorbemerkung Die englische Originalversion

Mehr

Schutz kleiner Netze mit einer virtuellen DMZ. Tillmann Werner, CERT-Bund

Schutz kleiner Netze mit einer virtuellen DMZ. Tillmann Werner, CERT-Bund Schutz kleiner Netze mit einer virtuellen DMZ Tillmann Werner, CERT-Bund Agenda Das BSI - Kurzvorstellung Demilitarisierte Zonen Virtuelle Maschinen Aufbau einer virtuellen DMZ Beispielkonfiguration Das

Mehr

Analyse von Sicherheitaspekten in Service-orientierten Architekturen

Analyse von Sicherheitaspekten in Service-orientierten Architekturen Analyse von Sicherheitaspekten in Service-orientierten Architekturen Vortragende: Jia Jia Betreuer: Dipl.-Inf. Matthias Lehmann Dresden,10.12.2009 10.12.2009 Analyse von Sicherheitaspekten in SOA 1 Gliederung

Mehr

Integriertes Management von Sicherheitsvorfällen

Integriertes Management von Sicherheitsvorfällen Integriertes Management von Sicherheitsvorfällen Stefan Metzger, Dr. Wolfgang Hommel, Dr. Helmut Reiser 18. DFN Workshop Sicherheit in vernetzten Systemen Hamburg, 15./16. Februar 2011 Leibniz-Rechenzentrum

Mehr

Service Oriented Architecture. IM-Briefing 2008 4. Dezember 2008

Service Oriented Architecture. IM-Briefing 2008 4. Dezember 2008 Service Oriented Architecture IM-Briefing 2008 4. Dezember 2008 Agenda Begrüssung Was ist SOA Herkunft Player Modell Komponenten Zusammenfassung Diskussion Seite 1 Was ist SOA? Herkunft Der Begriff serviceorientierte

Mehr

IP Adressen & Subnetzmasken

IP Adressen & Subnetzmasken IP Adressen & Subnetzmasken Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Network Access Control für Remote Access: Best Practice Technical Paper

Network Access Control für Remote Access: Best Practice Technical Paper Network Access Control für Remote Access: Best Practice Technical Paper Stand Mai 2010 Haftungsausschluss Die in diesem Dokument enthaltenen Informationen können ohne Vorankündigung geändert werden und

Mehr

How-to: Webserver NAT. Securepoint Security System Version 2007nx

How-to: Webserver NAT. Securepoint Security System Version 2007nx Securepoint Security System Inhaltsverzeichnis Webserver NAT... 3 1 Konfiguration einer Webserver NAT... 4 1.1 Einrichten von Netzwerkobjekten... 4 1.2 Erstellen von Firewall-Regeln... 6 Seite 2 Webserver

Mehr

Ingentive Fall Studie. LAN Netzwerkdesign eines mittelständischen Unternehmens mit HP ProCurve. Februar 2009. ingentive.networks

Ingentive Fall Studie. LAN Netzwerkdesign eines mittelständischen Unternehmens mit HP ProCurve. Februar 2009. ingentive.networks Ingentive Fall Studie LAN Netzwerkdesign eines mittelständischen Unternehmens mit HP ProCurve Februar 2009 Kundenprofil - Mittelständisches Beratungsunternehmen - Schwerpunkt in der betriebswirtschaftlichen

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

Business Rules und SOA. Parallelen und Synergien

Business Rules und SOA. Parallelen und Synergien Business Rules und SOA Parallelen und Synergien White Paper Januar 2008 Innovations Software Technology GmbH, 2008. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von

Mehr

Sicherheitsaspekte von Web Services. Hauptseminar Rechnernetze

Sicherheitsaspekte von Web Services. Hauptseminar Rechnernetze Sicherheitsaspekte von Web Services Hauptseminar Rechnernetze Stefan Hennig sh790883@inf.tu-dresden.de 21. Januar 2005 Gliederung Einführung Überblick Sicherheit auf Netzwerk- und Transportebene XML-Sicherheit

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Sicherheitsmechanismen für Voice over IP

Sicherheitsmechanismen für Voice over IP Sicherheitsmechanismen für Voice over IP von Dr. Behrooz Moayeri Technologie Report: Sicherheitsmechanismen für VoIP Seite 6-138 6.2 Schutz für Quality of Service (QoS) Dieser Abschnitt befasst sich mit

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

Sichere Web-Services in einem föderierten Umfeld

Sichere Web-Services in einem föderierten Umfeld Sichere Web-Services in einem föderierten Umfeld ZKI Arbeitskreis Verzeichnisdienste ZEDAT FU Berlin Axel Maurer Die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH) integrierte

Mehr

Seminar im Sommersemester 2009. Complex and Distributed IT-Systems TU Berlin

Seminar im Sommersemester 2009. Complex and Distributed IT-Systems TU Berlin Betrieb komplexer IT-Systeme Seminar im Sommersemester 2009 Complex and Distributed IT-Systems TU Berlin Status Quo Rechenzentren erfüllen Vielzahl an Diensten Klassische Server-Dienste Mailserver, Newsserver,

Mehr

Teil 2 Virtuelle Netzwerke im Überblick

Teil 2 Virtuelle Netzwerke im Überblick Teil 2 Virtuelle Netzwerke im Überblick Motto von Teil 2: Gäste flexibel im LAN oder in abgeschotteten Testumgebungen betreiben. Teil 2 dieser Workshopserie erklärt die Grundlagen virtueller Netzwerke

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

IT-Dienstleistungszentrum Berlin

IT-Dienstleistungszentrum Berlin IT-Dienstleistungszentrum Berlin»Private Cloud für das Land Berlin«25.11.2010, Kai Osterhage IT-Sicherheitsbeauftragter des ITDZ Berlin Moderne n für die Verwaltung. Private Cloud Computing Private Cloud

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

DynFire. An Architecture for Dynamic Firewalling. Alexander Vensmer Alexander.Vensmer@ikr.uni-stuttgart.de 28.11.2011

DynFire. An Architecture for Dynamic Firewalling. Alexander Vensmer Alexander.Vensmer@ikr.uni-stuttgart.de 28.11.2011 DynFire An Architecture for Dynamic Firewalling Alexander Vensmer Alexander.Vensmer@ikr.uni-stuttgart.de 28.11.2011 Universität Stuttgart Institut für Kommunikationsnetze und Rechnersysteme (IKR) Prof.

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen 9. Februar 2008 Vortrag für den PC-Treff Böblingen Agenda 1 Einleitung Netzwerkeinstellungen 2 Feste Zuordnung Lease 3 4 Einleitung Einleitung Netzwerkeinstellungen DHCP, das Dynamic Host Configuration

Mehr

ComputeriaUrdorf «Sondertreff»vom30. März2011. Workshop mit WLAN-Zugriff auf das Internet

ComputeriaUrdorf «Sondertreff»vom30. März2011. Workshop mit WLAN-Zugriff auf das Internet ComputeriaUrdorf «Sondertreff»vom30. März2011 Workshop mit WLAN-Zugriff auf das Internet 30. März 2011 Autor: Walter Leuenberger www.computeria-urdorf.ch Was ist ein (Computer-)Netzwerk? Netzwerk-Topologien

Mehr

FIDeS: Frühwarn und Intrusion Detection System auf der Basis von kombinierten Methoden der KI

FIDeS: Frühwarn und Intrusion Detection System auf der Basis von kombinierten Methoden der KI FIDeS: Frühwarn und Intrusion Detection System auf der Basis von kombinierten Methoden der KI Workshop Informationssicherheit Carsten Elfers 06.11.2009 System Qualität und Informationssicherheit Rahmenbedingungen

Mehr

Überlegungen zur Struktur eines Schulnetzes

Überlegungen zur Struktur eines Schulnetzes Überlegungen zur Struktur eines Schulnetzes Kurzbeschreibung Viele Schulen arbeiten heute mit einem Computernetzwerk, das unterschiedlichen Anforderungen genügen muss. Bereits durch eine entsprechende

Mehr

Gauß-IT-Zentrum. DHCP für Institute. Zielgruppe: DV Koordinatoren. Version 1.0

Gauß-IT-Zentrum. DHCP für Institute. Zielgruppe: DV Koordinatoren. Version 1.0 Gauß-IT-Zentrum DHCP für Institute Zielgruppe: DV Koordinatoren Version 1.0 1 DHCP für Institute Inhalt Dynamic Host Configuration Protocol (DHCP) für Institute 2 DHCP-Interface im KDD 2 DHCP beantragen

Mehr

TCP/IP-Protokollfamilie

TCP/IP-Protokollfamilie TCP/IP-Protokollfamilie Internet-Protokolle Mit den Internet-Protokollen kann man via LAN- oder WAN kommunizieren. Die bekanntesten Internet-Protokolle sind das Transmission Control Protokoll (TCP) und

Mehr

KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777

KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777 KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777 Fernzugriff mit der ETS Achatz 3 84508 Burgkirchen Tel.: 08677 / 91 636 0 Fax:

Mehr

Whitepaper. Friendly Net Detection. Stand November 2012 Version 1.2

Whitepaper. Friendly Net Detection. Stand November 2012 Version 1.2 Whitepaper Stand November 2012 Version 1.2 Haftungsausschluss Die in diesem Dokument enthaltenen Informationen können ohne Vorankündigung geändert werden und stellen keine Verpflichtung seitens der NCP

Mehr

Computeria Urdorf «Sondertreff» vom 7. November 2012. Workshop. auf das Internet

Computeria Urdorf «Sondertreff» vom 7. November 2012. Workshop. auf das Internet Computeria Urdorf «Sondertreff» vom 7. November 2012 Workshop mit WLAN-Zugriff auf das Internet 7. November 2012 Autor: Walter Leuenberger www.computeria-urdorf.ch Was ist ein (Computer-)Netzwerk? Netzwerk-Topologien

Mehr

1HXHLQVWLHJ± /LQX[ RGHU0LFURVRIW (LQH(QWZHGHU2GHU(QWVFKHLGXQJ"

1HXHLQVWLHJ± /LQX[ RGHU0LFURVRIW (LQH(QWZHGHU2GHU(QWVFKHLGXQJ /XW]%URFNPDQQ Interoperabilität von Linux und Windows 1HXHLQVWLHJ± /LQX[ RGHU0LFURVRIW (LQH(QWZHGHU2GHU(QWVFKHLGXQJ" \DVF 8QWHUQHKPHQVJUXSSH 6RIWZDUH(QJLQHHULQJ yasc Informatik GmbH Gründung 1996 Sitz

Mehr

VPN Virtual Private Network

VPN Virtual Private Network VPN Virtual Private Network LF10 - Betreuen von IT-Systemen Marc Schubert FI05a - BBS1 Mainz Lernfeld 10 Betreuen von IT-Systemen VPN Virtual Private Network Marc Schubert FI05a - BBS1 Mainz Lernfeld 10

Mehr

Was nicht erlaubt ist, ist verboten

Was nicht erlaubt ist, ist verboten Was nicht erlaubt ist, ist verboten E-Government-Initiativen und Investitionen in Netzwerktechnologie setzen das Thema IT-Sicherheit ganz oben auf die Agenda der öffentlichen Verwaltung. Moderne Informationstechnologie

Mehr

ITELLIUM Systems & Services GmbH der IT Dienstleister der KarstadtQuelle AG

ITELLIUM Systems & Services GmbH der IT Dienstleister der KarstadtQuelle AG Schutz vor ARP-Spoofing Gereon Rütten und Oliver Stutzke Hamburg, 04.02.2004 ITELLIUM Systems & Services GmbH der IT Dienstleister der KarstadtQuelle AG Agenda Einleitung ARP-Spoofing Erkennung von ARP-Spoofing

Mehr

JavaIDS Intrusion Detection für die Java Laufzeitumgebung

JavaIDS Intrusion Detection für die Java Laufzeitumgebung JavaIDS Intrusion Detection für die Java Laufzeitumgebung Bundesamt für Sicherheit in der Informationstechnik Security Forum 2008 23. April 2008 Agenda 1. Das BSI 2. Überblick über die Java-Plattform 3.

Mehr

Klassifikation und Einsatzmöglichkeiten von Intrusion Detection Systems (IDS)

Klassifikation und Einsatzmöglichkeiten von Intrusion Detection Systems (IDS) Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Prof. Dr. Dietrich Reschke Klassifikation und Einsatzmöglichkeiten

Mehr

Remote-Administration von eingebetteten Systemen mit einem Java-basierten Add-On-Modell

Remote-Administration von eingebetteten Systemen mit einem Java-basierten Add-On-Modell Remote-Administration von eingebetteten Systemen mit einem Java-basierten Add-On-Modell F. Burchert, C. Hochberger, U. Kleinau, D. Tavangarian Universität Rostock Fachbereich Informatik Institut für Technische

Mehr

Einführung. Übersicht

Einführung. Übersicht Einführung Erik Wilde TIK ETH Zürich Sommersemester 2001 Übersicht Durchführung der Veranstaltung Termine (Vorlesung und Übung) Bereitstellung von Informationen Einführung Internet Internet als Transportinfrastruktur

Mehr

Workshop Sicherheit im Netz KZO Wetzikon. Peter Skrotzky, 4. Dezember 2013

Workshop Sicherheit im Netz KZO Wetzikon. Peter Skrotzky, 4. Dezember 2013 Workshop Sicherheit im Netz KZO Wetzikon Peter Skrotzky, 4. Dezember 2013 Zentrale Fragen! Wie kann sich jemand zu meinem Computer Zugriff verschaffen?! Wie kann jemand meine Daten abhören oder manipulieren?!

Mehr

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen 2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen Dienste des Internets Das Internet bietet als riesiges Rechnernetz viele Nutzungsmöglichkeiten, wie etwa das World

Mehr

University of Applied Sciences. Hochschule Merseburg (FH) Anwendung Rechnernetze. Layer 3 Switching. Frank Richter. 7. Semester

University of Applied Sciences. Hochschule Merseburg (FH) Anwendung Rechnernetze. Layer 3 Switching. Frank Richter. 7. Semester University of Applied Sciences Hochschule Merseburg (FH) Anwendung netze Layer 3 Switching Frank Richter 7. Semester Fachbereich: Informatik Matrikel: 2INF03 Kennnummer: 10760 1. Inhaltsverzeichnis: 1.

Mehr

Prof. Dr. Martin Leischner Netzwerksysteme und TK. Hochschule Bonn-Rhein-Sieg. Modul 5: IPSEC

Prof. Dr. Martin Leischner Netzwerksysteme und TK. Hochschule Bonn-Rhein-Sieg. Modul 5: IPSEC Modul 5: IPSEC Teil 1: Transport- und Tunnelmode / Authentication Header / Encapsulating Security Payload Security Association (SAD, SPD), IPsec-Assoziationsmanagements Teil 2: Das IKE-Protokoll Folie

Mehr

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION Präambel Die COI GmbH entwickelt seit 1988 moderne, prozessorientierte Lösungen rund um die Themen Archivierung, Dokumentenmanagement und Workflow. Als kompetenter

Mehr

IT-Grundschutz-Novellierung 2015. Security Forum 2015. Hagenberger Kreis. Joern Maier, Director Information Security Management

IT-Grundschutz-Novellierung 2015. Security Forum 2015. Hagenberger Kreis. Joern Maier, Director Information Security Management IT-Grundschutz-Novellierung 2015 Security Forum 2015 Hagenberger Kreis Joern Maier, Director Information Security Management 1 AGENDA 1 Ausgangslage 2 unbekannte Neuerungen 3 mögliche geplante Überarbeitungen

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) Technische Grundlagen und Beispiele. Christian Hoffmann & Hanjo, Müller

Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) Technische Grundlagen und Beispiele. Christian Hoffmann & Hanjo, Müller Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) VPN (Virtual Private Network) Technische Grundlagen und Beispiele Christian Hoffmann & Hanjo, Müller Dresden, 3. April 2006 Übersicht Begriffsklärung

Mehr

Port-Weiterleitung einrichten

Port-Weiterleitung einrichten Port-Weiterleitung einrichten Dokument-ID Port-Weiterleitung einrichten Version 1.5 Status Endfassung Ausgabedatum 13.03.2015 Centro Business Inhalt 1.1 Bedürfnis 3 1.2 Beschreibung 3 1.3 Voraussetzungen/Einschränkungen

Mehr

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner Adressübersetzung und Tunnelbildung Bastian Görstner Gliederung 1. NAT 1. Was ist ein NAT 2. Kategorisierung 2. VPN 1. Was heißt VPN 2. Varianten 3. Tunneling 4. Security Bastian Görstner 2 NAT = Network

Mehr

MailStore Service Provider Edition (SPE)

MailStore Service Provider Edition (SPE) MailStore Solutions MailStore Service Provider Edition (SPE) E-Mail-Archivierung für Service Provider Mit Hilfe der MailStore Service Provider Edition können Sie Ihren Kunden moderne E-Mail-Archivierung

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

Infrusion Defection System Evasion durch Angriffsverschleierung in Exploiting Frameworks

Infrusion Defection System Evasion durch Angriffsverschleierung in Exploiting Frameworks Thomas Stein Infrusion Defection System Evasion durch Angriffsverschleierung in Exploiting Frameworks Diplomica Verlag GmbH Inhaltsverzeichnis Abbildungsverzeichnis 7 Tabellenverzeichnis 9 Listingverzeichnis

Mehr

Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003. Subnetting

Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003. Subnetting Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003 Subnetting Einleitung Thema dieser Ausarbeitung ist Subnetting Ganz zu Beginn werden die zum Verständnis der Ausführung notwendigen Fachbegriffe

Mehr

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF Dipl.-Inf. Lutz Suhrbier Prof. Dr.-Ing. Robert Tolksdorf Dipl.-Inf. Ekaterina Langer Freie Universität Berlin Institut

Mehr

Intrusion-Detection für Automatisierungstechnik

Intrusion-Detection für Automatisierungstechnik Intrusion-Detection für Automatisierungstechnik Franka Schuster Lehrstuhl Rechnernetze und Kommunikationssysteme Brandenburgische Technische Universität, Cottbus SPRING 7 GI SIDAR Graduierten-Workshop

Mehr

10. WCI-Konferenz in Berlin

10. WCI-Konferenz in Berlin 10 WCI-Konferenz in Berlin Ende-zu-Ende-Sicherheit bei Long Term Evolution (LTE) Foliennr: 1 Prof- Dr-Ing Kai-Oliver Detken DECOIT GmbH Fahrenheitstraße 9 D-28359 Bremen URL: http://wwwdecoitde E-Mail:

Mehr

HST Greenfield. Session Border Controler (SBC) im Unternehmenseinsatz. Henning Schaefer, Rolf Hunziker 25. August 2014

HST Greenfield. Session Border Controler (SBC) im Unternehmenseinsatz. Henning Schaefer, Rolf Hunziker 25. August 2014 HST Greenfield Session Border Controler (SBC) im Unternehmenseinsatz Henning Schaefer, Rolf Hunziker 25. August 2014 Vorsprung auf den Punkt gebracht. Praxiserfahrung. Über uns HST Greenfield auf den Punkt.

Mehr

Intrusion Detection / Intrusion Prevention. Technologie zwischen Anspruch und Wirklichkeit

Intrusion Detection / Intrusion Prevention. Technologie zwischen Anspruch und Wirklichkeit Intrusion Detection / Intrusion Prevention Technologie zwischen Anspruch und Wirklichkeit IDS Bisher Zwei Bereiche Netzwerk basiert Host basiert Erkennung von Angriffen aufgrund von Mustern / Signaturen

Mehr

Sichere Abwicklung von Geschäftsvorgängen im Internet

Sichere Abwicklung von Geschäftsvorgängen im Internet Sichere Abwicklung von Geschäftsvorgängen im Internet Diplomarbeit von Peter Hild Theoretische Grundlagen der Kryptologie Vorhandene Sicherheitskonzepte für das WWW Bewertung dieser Konzepte Simulation

Mehr

JE Web Services. Hinweise. Beschreibung. Doku.-Version: 1.0 Letzte Änderung: 02.02.2011

JE Web Services. Hinweise. Beschreibung. Doku.-Version: 1.0 Letzte Änderung: 02.02.2011 Beschreibung Hinweise Doku.-Version: 1.0 Letzte Änderung: 02.02.2011 http://www.jacob-computer.de/kontakt.html software@jacob-elektronik.de Inhaltsverzeichnis 1. Inhaltsverzeichnis Hinweise... 1 1. Inhaltsverzeichnis...

Mehr

Systemvoraussetzungen 14.0

Systemvoraussetzungen 14.0 Systemvoraussetzungen 14.0 CMIAXIOMA - CMISTAR 29. Oktober 2014 Systemvoraussetzungen 14.0 Seite 2 / 12 Inhaltsverzeichnis 1 Allgemeines... 3 1.1 Support Lifecycle Policy... 3 1.2 Test Policy... 3 1.3

Mehr

Modul 6 LAN-Komponenten (Repeater, Bridge, Switch)

Modul 6 LAN-Komponenten (Repeater, Bridge, Switch) Lernziele: Nach der Lehrveranstaltung zu Modul 6 sollen Sie in der Lage sein, Modul 6 LAN-Komponenten (, Bridge, Switch) (a) die Grundfunktion eines s darzustellen, (b) die Anforderung, Notwendigkeit,

Mehr

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Peter Hillmann Institut für Technische Informatik Fakultät für Informatik Peter.Hillmann@unibw.de Peter Hillmann 1 Gliederung 1. Motivation

Mehr

Information Security Policy für Geschäftspartner

Information Security Policy für Geschäftspartner safe data, great business. Information Security Policy für Geschäftspartner Raiffeisen Informatik Center Steiermark Raiffeisen Rechenzentrum Dokument Eigentümer Version 1.3 Versionsdatum 22.08.2013 Status

Mehr

Service. Was ist eine Enterprise Service Architecture und wie reagiert SAP. Warum Monitoring in ZENOS, was monitort die XI?

Service. Was ist eine Enterprise Service Architecture und wie reagiert SAP. Warum Monitoring in ZENOS, was monitort die XI? Service Was ist eine Enterprise Service Architecture und wie reagiert SAP Allgemeine Definition Was gehört in ZENOS (Service-Layer)? Business Logik ZENOS als Provider für SAP-based Services (ESA/SOA) Warum

Mehr

Military Air Systems

Military Air Systems Trennung von Applikationen unterschiedlicher Kritikalität in der Luftfahrt durch Software en am Beispiel des Real-time Operating Systems PikeOS Dr. Bert Feldmann DGLR Workshop Garching, 09.10.2007 Seite

Mehr