Ist meine Firewall sicher?
Werde ich angegriffen?
Konnte jemand in meinen Rechner oder in mein Netzwerk einbrechen?
Welche Absicht verfolgte der Einbrecher?

Häufig merkt der Anwender nicht oder viel zu spät, dass er Opfer eines Angriffs wurde. Dabei ist es sehr wichtig schnell reagieren zu können, um den Schaden möglichst gering zu halten. Dies ist Aufgabe der Intrusion Detection.

Die Intrusion Detection wird grundsätzlich in die rechnerbasierte (host-based) und netzwerkbasierte (network-based) Intrusion Detection unterschieden.

Dieses Tutorial bespricht in zwei Teilen die Intrusion Detection und die anschließende forensische Analyse der kompromittierten Systeme.

Teil 1 (Vormittags):

Dieser Teil stellt die verschiedenen Verfahren der Intrusion Detection vor.

Zunächst werden die rechnerbasierten Verfahren besprochen:
Zu Beginn wird das einfache Auditing besprochen. Dabei handelt es sich um ein Verfahren, bei dem regelmäßig gewisse Systemeinstellungen, wie Rechtestrukturen, offene Ports etc. kontrolliert werden.

Anschließend werden kurz Verfahren besprochen, die es einem Einbrecher erschweren, einzubrechen und anschließend seine Spuren zu verwischen. Hierzu gehören der Einsatz des xinetd als Ersatz für inetd, das Protokollieren per Syslog über das Netzwerk und der Einsatz von alternativen Syslog Diensten zur gesicherten Übertragung der Protokolldateien.

Schließlich wird mit Tripwire ein sogenannter System Integrity Verifier (SIV) besprochen und die Konfiguration an Hand einfacher Beispiele nachvollzogen.

Anschließend wird mit Snort eine Network Intrusion Detection System (NIDS) besprochen, welches versucht verdächtige Netzwerktätigkeiten aufzuspüren, und so Angriffe über das Netzwerk erkennen.

Hierzu zählt die Erkennung von Portscans, Buffer-Overflows, DoS-Angriffen und den Zugriff auf Trojaner. Die Konfiguration von Snort wird an einigen einfachen Beispielen vorgestellt. Hierbei werden insbesondere die fortgeschrittenen Funktionen von Snort an Beispielen vorgestellt: Unicode-Dekodierung, Streamreassemblierung, etc.

Den Anschluss stellen einige Ausführungen über die Geschwindigkeit von Snort und deren Optimierung dar.

Zusammenfassend bietet Intrusion Detection kein Schutz vor Angriffen, sondern erlaubt die schnelle Erkennung eines Angriffs und die Reaktion auf den Angriff: Entfernen des Angreifers, Entfernen der Sicherheitslücke.

Teil 2 (nachmittags):

Wurde der Einbruch erkannt, so ist es wichtig, das Ausmaß des Einbruchs zu bestimmen, die Vorgehensweise des Einbrechers zu erkennen und zukünftige Einbrüche zu verhindern.

Hierzu sind forensische Analysen der von den Intrusion Detection Systemen gesammelten Daten und der auf den betreffenden Rechner existierenden Daten erforderlich. Diese erlauben häufig Rückschlüsse auf den Einbrecher, gelöschte und veränderte Dateien und installierte Hintertüren.

Diese Erkenntnisse erlauben dann die Wiederherstellung der Systemintegrität und den Schutz vor weiteren gleichartigen Angriffen.

Im einzelnen werden Werkzeuge besprochen, die es erlauben

• Netzwerkdumps (snort, tcpdump),
• kompromittierte Rechner (z.B. Dateisysteme) und
• binäre Programme

zu analysieren. Diese Werkzeuge werden in ihrer Funktion vorgestellt und an Beispielen nachvollzogen.

Bei diesen Verfahren werden häufig wertvolle Hinweise auf die ausgenutzte Sicherheitslücke, den Einbrecher und seine Aktionen gewonnen.

Diese Informationen sind notwendig um anschließend die Sicherheit des kompromittierten Systems und Netzwerks wiederherzustellen.

Damit Sie die gezeigten Beispiele nachzuvollziehen können, werden Ihnen einige Materialien auf einer CD zur Verfügung gestellt.

Über den Autor:

Der Autor setzt Linux seit etwa 8-9 Jahren privat ein. Seit etwa 4 Jahren ist er professionell im Linux/UNIX Umfeld als freiberuflicher Trainer für unterschiedliche Firmen tätig. Dabei setzt er seinen Schwerpunkt bei Netzwerkanwendungen und Sicherheit (Firewalls, Intrusion Detection, Penetration Testing) und hat hier auch bereits einige Kurse entwickelt. Im Dezember 2002 veröffentlichte er sein Buch "Intrusion Detection Systeme für Linux-Server".

Durchschnittlich verdoppelt sich in einem Unternehmen jedes Jahr die installierte Speicherkapazität. Das heißt: Wer heute 250GB Festplattenspeicher installiert hat, der wird in fünf Jahren ungefähr 8TB verwalten und sichern. Solche Datenmengen können nur noch mit Speichernetzen effizient verwaltet werden.

Bisher waren Speichergeräte über SCSI-Kabel an einen Server angeschlossen. Speichernetze ersetzen diese Verbindung durch ein neues Netzwerk, das zusätzlich zu dem bereits existierenden LANs installiert wird. Der Speicher wird dadurch unabhängig vom Server.

Im Tutorial erklären wir grundlegende Techniken und Funktionen von Speichernetzen sowie deren Einsatz. Im einzelnen behandeln wir folgende Themen:

• Grundlegende Konzepte und Definitionen
• Speicherkonsolidierung mit Speichernetzen
• Hochverfügbarkeit mit Speichernetzen
• Kompenenten für Speichernetze
• Intelligente Disksubsysteme
• Der Fibre Channel
• Network Attached Storage (NAS)
• Einsatz von Speichernetzen am Beispiel "Netzwerkdatensicherung"
• IP Storage (iSCSI, FCIP, iFCP)
• Speichervirtualisierung
• Verwaltung von Speichernetzen (SNMP, CIM/WBEM, Bluefin und mehr)

Über die Autoren:

Ulf Troppens und Rainer Erkens sind Mitarbeiter im IBM TotalStorage Interoperability Center in Mainz, einem Test-, Entwicklungs- und Demolabor für Speicherprodukte und Speichernetze. Beide Autoren arbeiten an der Schnittstelle zwischen Technik und Kunde. Zu Ihren Aufgaben gehört der Test neuer Produkte und die Validierung von Konzepten anhand von im Labor nachgestellten Kundenumgebungen. Sie stellen Kunden die neuesten Hard- und Softwareprodukte im Umfeld Speichernetze vor, und sie besprechen mit ihnen die nachgestellten Testumgebungen. Sie haben gemeinsam das Buch "Speichernetze: Grundlagen und Einsatz von Fibre Channel SAN, NAS, iSCSI und InfiniBand" geschrieben und sind die Autoren mehrerer Fachartikel über Speichernetze in der iX.

Ulf Troppens studierte bis 1995 Informatik an der Universität Karlsruhe. Seit 1989 beschäftigt er sich schwerpunktmäßig mit der Administration von Unix-Systemen, Speichersystemen, Daten- und Speichernetzen sowie verteilten Anwendungen.

Rainer Erkens studierte bis 2000 Mathematik an der Universität Mainz. Seine Erfahrungen mit der Verwaltung von Rechnern und der Verwaltung von verteilten Anwendungen gehen bis in das Jahr 1992 zurück. Seit 2000 beschäftigt er sich vor allem mit Speichersystemen und Speichernetzen.

General

Exim is a program with very many features. The general courses that I have previously run have lasted two days. For a one-day tutorial, therefore, I have to concentrate on certain aspects and miss out others.

To be included: Discussion of the configuration file and how Exim is configured, in detail, both for delivery of messages and for control of incoming messages.

To be excluded: Discussion of implementation philosophy, how Exim works internally in terms of processes, etc, management facilities, monitoring, log analysis, security.

Detail

First Session

• Exim's runtime configuration file
• Layout and syntax
• Some of the more common global options
• Short introductory Access Control List
• Exim routers - how an address is routed
• Things a router can do
• Simple routing (description, no details)
• Exim transports (again, no detail yet)
• Retry rules (overview)
• How temporary delivery errors are handled
• Address rewriting - simple examples

Second session

• Configuring routers and transports
• Item lists, including lookups and negated items
• Named item lists
• Default routers - a walk through the default configuration
• Default transports
• Local delivery in maildir format
• Routing to smarthosts
• Mail hubbing
• Virtual domains
• Simple mailing lists
• External local delivery agent
• Mailboxes without login accounts

Third session

• Control of incoming mail
• Authenticated SMTP connections
• Encrypted SMTP connections
• Address verification (in general)
• Access Control Lists (ACLs)
• ACL statements
• The default ACL
• DNS black lists
• Verifying addresses and headers
• Authentication and encryption tests in ACLs
• Testing policy controls

Fourth session

• Message filtering
• Filter commands
• Alternate mailboxes
• The system filter
• local_scan() function - very brief mention

Über den Autor:

Philip Hazel grew up in South Africa. He has a PhD in applied mathematics, and has spent the last 30 years writing general-purpose software for the Computing Service at the University of Cambridge in England. Some major projects were text editors and text formatters for use on an IBM mainframe system. Since moving from the mainframe to Unix around 1990, he has become more and more involved with email. This lead to his starting to develop Exim in 1995, and the PCRE regular expression library two years later. These open source projects have both turned out to be larger and more successful that expected. Outside interests include classical music (as a choral singer and late convert to viola playing), music typsetting, working backstage in amateur theatre, and finding nice places to go walking, preferably not as flat as Cambridgeshire. Philip is married, and has three grown-up sons.

Das Tutorium wendet sich an Java-Programmierer, die die wichtigsten Schnittstellen zu XML sowie einige typische Anwendungen kennen und nutzen lernen wollen.

Jeder der 4 Blöcke des Tutoriums besteht ungefähr zur Hälfte aus praktischen Übungen.

1. Grundlagen

Die grundlegende Struktur einer XML-Datei wird erläutert, für die, die HTML kennen, klären wir, worauf man bei XML aufpassen muß.

Da es für den später folgenden Abschnitt über JAXB wichtig und zudem noch relativ neu ist, werden wir dann auf XML-Schema eingehen.

Tiefergehende Themen wie Entitäten, Namensräume oder Processing Instructions können aus Zeitgründen bestenfalls angerissen werden.

Im praktischen Teil widmen wir uns der - immer wieder Verwirrung hervorrufenden - Konfiguration und Installation der XML-Parser in J2SE 1.4 und verifizieren XML-Dateien anhand selbst ersteller Schemas.

2. JAXP

Mit dem Java API for XML Parsing (JAXP) hat Sun den Zugriff auf beiden Parser-Modelle "Simple API for XML" (SAX) und "Document Object Model" (DOM) vereinheitlicht.

So steht im Mittelpunkt dieses Abschnitt das Parsen von XML-Input mit Hilfe dieser beiden Parser-Modelle, auf das von JAXP ebenfalls abgedeckte "eXtensible Stylesheet Language Transformation"(XSLT)-Interface werden wir hier nicht eingehen, da das Thema XSL insgesamt zu umfangreich ist.

Während ein SAX-kompatibler Parser für jedes angetroffene XML-Element eine Callback-Methode in einer vom Entwickler zu schreibenden Klasse aufruft, man also quasi jedes Element selbst liest, liest ein DOM-Parser den XML-Eingabestrom komplett und hält dann eine Objekt-Struktur im Speicher vor.

DOM ist für kleine Eingabeströme einfacher handhabbar, bei größeren, die nicht komplett in den Speicher gezogen werden können, oder bei denen die Verarbeitung schon beginnen soll, bevor das Ende des Eingabestroms erreicht ist, ist SAX unabdingbar.

In den Übungen werden wir eine XML-Datei mit wenigstens einem dieser Parser-Modelle bearbeiten.

3. JDOM und JAXB

Da DOM ein sprachunabhängiger Standard ist, der auch durch Sprachen, die beispielsweise keine Vererbung "beherrschen", implementierbar sein soll, wirkt der Zugriff auf DOM in Java stellenweise unnötig kompliziert. Das Open-Source Projekt "Java Document Object Model" (JDOM) stellt ein entsprechend einfachere Schnittstelle zur Verfügung, ist aber zur Zeit nicht durch Sun abgesegnet.

"Java Architecture for XML Binding" (JAXB) ist eine weitere Stufe der Annäherung von Java und XML. Im wesentlichen stellt JAXB einen Code-Generator bereit, der aus einem XML-Schema (oder einer DTD) Java-Klassen generiert, die zu diesem Schema kompatible Objektstrukturen darstellen und natürlich Datenströme lesen und schreiben können.

4. ant

Wie das gute alte make definiert ant, das ein Teilprojekt des Apache-Projekts ist, in einer Datei Regeln, wie man über mehrere Zwischenschritte zu einem Ziel kommt. Im Gegensatz zu make werden diese Regeln jedoch in XML notiert. Daneben ist ant, natürlich selbst in Java geschrieben, stark mit Java verzahnt: ant hat mehr Wissen über java und kompiliert daher in der Regel schneller als ein unoptimiertes Makefile das machen würde. Dadurch hat sich ant schnell zu dem make-Ersatz in der Java-Welt gemacht.

Sollte dann noch Zeit sein, können wir einen Blick auf einen einfachen per XML-Input konfigurierbaren Code-Generator oder weitere in diesem Zusammenhang interessante Apache-Projekte werfen: xalan (xsl-Transformator), batik (svg-Viewer), FOP (Formatting Objects), ...

Über die Autoren:

Martin Schulte ist Vorsitzender der GUUG, verdient sein Geld aber in erster Linie als Java-Programmierer oder Trainer.

Seit der Version 2.2 ist Samba in der Lage, für Windows-Workstations Dienste als Domänencontroller anzubieten. Damit können Unternehmen Client Access Lizenzen zum Zugriff auf NT4-Domänencontroller einsparen. Der PDC-Support in Samba 2.2 ist jedoch bezüglich der Steuerung von Benutzereigenschaften deutlich eingeschränkt. Beispielsweise kann man nicht für jeden Benutzer wirklich individuell den Pfad des Login-Skriptes angeben, sondern muß dies mit einer globalen Option tun. Ein Grund für diese Einschränkung liegt im Format der Datei smbpasswd von Samba 2.2. Dort gibt es schlicht keinen Platz für zusätzliche Felder, die über das Benutzerpasswort hinaus gehen.

Seit der Version 2.2.3 ist Samba um die Unterstützung des LDAP-Protokolls erweitert worden. Anstatt inder smbpasswd-Datei speichert Samba nun alle wesentlichen Benutzerdaten in einem Verzeichnis ab und kann so für jeden Benutzer individuell alle Daten festlegen, die im NT4-Benutzermanager abgelegt sind. Darüber hinaus gibt einem LDAP eine sehr einfache Möglichkeit, die gesamte Benutzerdatenbank zu replizieren. So kann Samba eine verteilte und redundante Authentifizierung für Windows-Rechner ermöglichen.

Das Tutorial zeigt die Möglichkeiten von Samba als Primary Domain Controller, es wird eine Einführung in die Konfiguration eines Verzeichnisses unter LDAP bieten und die Konfiguration einer verteilten Authentifizierungsinfrastruktur zeigen.

Über den Autor:

Volker Lendecke ist Diplom-Mathematiker in Göttingen. Den ersten Kontakt mit Unix hatte er etwa 1990 mit einer NeXT-Workstation. 1991 ist er nach Göttingen gekommen, um dort in der Uni mit DEC Ultrix Workstation konfrontiert zu werden. Sein erster Beitrag zu Samba war die Portierung auf NeXT. In letzter Zeit versucht er, Samba als PDC ein bißchen zu polieren. Ende 1996 stellte sich die Frage, was man denn nach der Zeit der Uni machen könnte. Es fanden sich vier Leute zusammen, die Service Network GmbH zu gründen. Dort ist Volker Lendecke für Training und natürlich Samba verantwortlich.