Abstracts

Ziel des Tutoriums ist es, aus Unix-Rechnern ein IPv6-Netzwerk aufzubauen, das einerseits in sich funktionsfähig ist, sich aber andererseits auch nahtlos in eine IPv4-Welt einbinden läßt.

Das nötige IPv6-Wissen, von der Terminologie über den Aufbau und die Notation von IPv6-Adressen bis zu den grundsätzlichen Unterschieden zwischen IPv4 und IPv6, eignen wir uns rund um diese Experimente an. IPv6-Vorkenntnisse sind also nicht nötig, nur etwas Erfahrung im Umgang mit Unix und IPv4-Netzen ist hilfreich.

Wir sind darauf angewiesen, daß möglichst viele Teilnehmer einen eigenen Unix-Rechner mitbringen, auf dem die Man Pages, die gängigen Entwicklungswerkzeuge (make, cc/gcc, ld, binutils) und wenn möglich ein Packet Sniffer (tcpdump, snoop, ethereal, ...) installiert sind. Das gewählte Unix-Derivat sollte dem jeweiligen Teilnehmer einigermaßen vertraut (und IPv6-fähig) sein, andere Einschränkungen gibt es nicht. Wer das Unix in einer VMware oder ähnlichem laufen lassen will, kann das gerne tun.

Die Teilnehmerzahl ist bedingt durch den experimentell-praktischen Charakter des Tutoriums auf maximal fünfzehn Teilnehmer beschränkt.

Das Tutorium im Detail:

IPv6-Unterstützung im Betriebssystem: Wir richten im Betriebssystem, soweit nötig, die IPv6-Unterstützung ein und überprüfen ihre Funktionsfähigkeit.

Adresskonfiguration: Wir konfigurieren zunächst statische IPv6-Adressen. Dann richten wir Router so her, daß Hosts damit per Stateless Autoconfiguration ihre IPv6-Adressen dynamisch selbst konfigurieren können.

DNS: Wir richten DNS-Server ein, die auch über IPv6 angesprochen werden können, tragen statische Daten ein, erlauben kryptographisch abgesicherte dynamische Updates von den eingetragenen Rechnern und synchronisieren kontinuierlich die Forward und Reverse Zones miteinander.

IPv6-fähige Services: Mit SSH, NTP, Syslog, SMTP, IMAP, (x)inetd, HTTP und NFS vervollständigen wir unsere Systeme.

Routing: Wir richten auf mehreren Routern statisches und dynamisches Routing ein und untersuchen dabei einige Eigenheiten von IPv6 und Unterschiede zwischen den IPv6-Implementierungen.

Dual-Stack-Konfiguration: Wir richten Rechner mit IPv4- und IPv6-Stack ein, so daß sie sowohl auf IPv4- als auch auf IPv6-Ressourcen zugreifen können.

Application Gateways: Für DNS und HTTP bauen wir Application Gateways, die zwischen beiden Welten auf Applikationsebene vermitteln.

Protocol Translation: Ähnlich wie mit einem NAT-Gateway, das IPv4-Adressen dynamisch umschreibt, bauen wir ein TRT-Gateway, das zwischen IPv6- und IPv4-Adressen konvertiert.

Neue Funktionalitäten: Nachdem im Tutorium fast ausschließlich Funktionalitäten berücksichtigt wurden, die schon IPv4 zur Verfügung stellt, gehen wir auf interessante Features ein, die IPv4 nicht oder nur eingeschränkt zu bieten hat.

Offene Probleme: Die IPv6-Spezifikationen werden noch immer weiterentwickelt, die Implementierungen hinken mehr oder weniger stark hinterher. Wir sprechen einige Bereiche an, in denen in naher Zukunft wichtige Fortschritte zu erwarten sind.

Strategie: Abschließend diskutieren wir, wie und wann der Aufbau einer IPv6-Infrastruktur strategisch sinnvoll ist.

Über den Autor:

Der Autor ist Dipl.-Inform. und freischaffender Systemarchitekt im Unix- und TCP/IP-Umfeld.

Er unterstützt IT-Projekte dabei, Software auf real existierender Hardware in real existierenden Rechenzentren in einen effizienten und zuverlässigen Betrieb zu nehmen, bringt die Infrastruktur von Rechenzentren auf den Stand der Technik und führt die IT-Bausünden der New Economy in die betriebwirtschaftliche Realität.

Neben den dabei relevanten technischen Themen, insbesondere Performance, Hochverfügbarkeit und Skalierbarkeit, interessiert ihn auch die dazugehörige Betriebsorganisation und die Schulung und das Coaching der Mitarbeiter im IT-Betrieb.

Wenn er sich nicht gerade mit IPv6 beschäftigt, tauchen geht oder mit dem Fahrrad Kontinente sammelt, ist er unter stockebrand@guug.de und http://www.benedikt-stockebrand.de/ zu erreichen.

Sowohl Probleme als auch Funktionalitäten treten in den unterschiedlichsten Projekten immer wieder auf:

• Wieviel Zeit kostet Sie die Konfiguration der Entwicklungsumgebung?
• Ist Ihre Projekt-Basisstruktur für mehrere gleichzeitige Projekte vorbereitet?
• Kennen Sie die Versionskonflikte mit XML-Parsern, JDBC-Treibern, Logging-Klassen?

Inhalt:

Der zweitägige Workshop zeigt den sinnvollen Einsatz von:

• JUnit für Modultests (ein MUSS für jeden Java-Entwickler)
• Log4J zum Logging (wer die Möglichkeiten kennt, baut ganz andere Systeme)
• ANT zu Erstellung der BUILD-Skripte (noch ein MUSS, trotz Eclipse & Co)
• Konfigurationsdateien mit XML
• Anbindung an CVS

Es wird Eclipse als IDE vorgestellt und benutzt. Aber auch Benutzer von vi, emacs, jEdit, NetBeans, o.ä. kommen voll auf Ihre Kosten.

Ziel: Das Projekt muss ohne Änderungen auf Linux UND auf Windows funktionieren.

Vorraussetzungen: Grundkenntnisse in Java und XML

Zielgruppe: Windows-Programmierer, deren Programme im Unix-Umfeld laufen sollen. Unix-Programmierer, deren Programme auch im Windows-Umfeld laufen sollen. Programmierer, die bei ihrer Entwicklung eine größtmögliche Unabhängigkeit von Betriebssystem und proprietären Produkten haben möchten.

Über den Autor:

Freiberuflicher Informatiker, der den IT-Alltag sowohl aus Projekten als auch aus Schulungen kennt. Schulungsthemen: JAVA, XML, UML, COBOL (sic!)

Ansonsten betreibe ich intensiv Musik und betätige mich im Gymnasium meiner Kinder in verschiedenen Bereichen.

Große Netzwerkstrukturen bedürfen zentraler Überwachung und zentraler Dokumentation. Zu den Produkten Tivoli (IBM), OpenView (HP) hat sich bereits vor einiger Zeit ein OpenSource Produkt namens Nagios (früher Netsaint) gesellt. Es verfügt über eine Vielzahl an Möglichkeiten zur Überwachung von Hosts wie Routern, Switches, Server, UPS und anderen Netzwerkgeräten und ist durch seine einfache und modulare Struktur sehr einfach von Hand zu erweitern. Nichtsdestotrotz fehlt dem System ein wichtiger Punkt: es können Kommentare verwaltet werden, allerdings besitzt das System keine eigene Daten- und Informationsablage für Begleit-Dokumentation zu den überwachten Systemen.

Dieses Tutorial soll dem Interessierten die Möglichkeit geben einen Einblick darin zu erhalten, wie ein solches System mittlerer Größe aufgebaut, strukturierte Vernetzung abgebildet, mit SMS-Diensten integriert und um den fehlenden Punkt der Dokumentverwaltung erweitert wird.

Soweit die Entwicklung abgeschlossen ist, wird die für das erste Quartal 2004 zu erwartende Version 2.0 von Nagios präsentiert und in einer Beispiel-Umgebung aufgesetzt. Dies beinhaltet Erklärungen zu allen zentralen Konfigurationsparametern um Nagios, dessen Plugin's und deren Verwendung. Wichtig ist dabei das richtige "Tuning" des Monitoring-Systems, um eine dem Administrator eine sinnvolle Verwaltung seines Netzwerks mit bis zu 100 Rechnern und über 200 darauf laufenden Serverdiensten und/oder Leistungsparametern mit diesem Tool zu ermöglichen. Das modular aufgebaute System verfügt über ein ausgeklügeltes, objektorientiertes Template-System, welches die einfache Eingliederung in verteilte Text-Konfigurationsdateien (einem zentralen Merkmal von Unix-Systemen folgend) ermöglicht ohne, auch in komplexeren Umgebungen, auf grafische Schnittstellen und Administrations-Frontends angewiesen zu sein.

Die Konfigurationsobjekte erstrecken sich dabei von "Hosts" und "Services", über "Contacts" und "Timeperiods", bis hin zu "Dependencies" und "Serviceescalations", deren Interaktion und durch verschiedenste Bedingungen und Beziehungen verschachtelbare und erzeugbare Systemreaktionen im Detail besprochen werden. Auch auf die Möglichkeit der Fernsteuerung mittels SMS - nicht zu verwechseln mit der relativ einfachen und gebräuchlichen Benachrichtigung der verantwortlichen Administratoren - wird behandelt.

Über den Autor:

Günther Mair, geboren am 24.09.78 in Meran, Südtirol, spricht deutsch (Muttersprache) und fließend italienisch und englisch. Die ersten Gehversuchen mit Commodore 64er und 128er endeten sehr bald in der Programmierung von Basic, anschließend Pascal und ein paar Tropfen Assembler. Einige Jahre später und um Erfahrung auf MS-DOS, Turbo-Pascal und den verschiedenen Windows-Versionen reicher, mündeten die IT-Interessen schließlich auf Linux mit Perl, Shell-Scripts, C und PHP/PostgreSQL. Mit Hilfe dieser letzten Umgebung entstand, im Laufe von 2 Jahren als Systemadministrator und Programmierer, u.a. die mit einem Web-Award ausgezeichnete Internetseite der südtiroler Weinwerbung/Weinkost. Um die eigenen Interessen zu vertiefen und den Horizont auf anderen Gebieten, allem voran aber im Netzwerkbereich, zu erweitern, war ein Umstieg zu einem der großen südtiroler System-Integratoren der nächste logische Schritt. Seit 3 Jahren verwaltet dieses Unternehmen nun mit Hilfe von Nagios die eigenen Backbone-Systeme und alle managed Services seiner Kunden.

Dieses Tutorial beschäftigt sich mit dem Einsatz des neuen Linux Kernel 2.6 zum Aufbau von virtuellen privaten Netzen mit IPsec. Der Linux Kernel 2.6 enthält einen komplett neuen IPsec Stack. Dieser wurde in Anlehnung an das KAME und das USAGI Projekt von David Miller und Alexey Kuznetsov programmiert. Es stehen inzwischen drei verschiedene IKE Daemonen zur Verfügung, mit denen dieser Stack konfiguriert werden kann: Racoon (KAME), Isakmpd (OpenBSD) und Pluto (FreeS/WAN). Dieses Tutorial beschreibt die neue IPsec Implementierung und den Einsatz der verschiedenen Werkzeuge. Dabei werden verschiedene Fallbeispiele durchgespielt und diese live mit den Werkzeugen nachgestellt. Der Teilnehmer erhält eine fundierte Einführung in die Anwendung der Werkzeuge und die Fehlersuche bei ihrem Einsatz.

Ü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 (unter anderem für Red Hat) entwickelt. Als Referent wurde er bereits vom Linuxtag, dem LinuxKongress, der SANS und dem Frühjahrsfachgespräch eingeladen. In dem letzten Jahr war er Mitglied des Programmkommitees des Linuxkongresses und des FFG. Im Dezember 2002 veröffentlichte er sein erstes Buch "Intrusion Detection Systeme für Linux-Server". Im November 2003 erschien sein zweites Buch "VPN mit Linux".

Welche Folgen kann ein Hacker-Angriff für mein Unternehmen haben?

Welches Vorgehen empfiehlt sich zur Bewältigung solcher Sicherheitskrise?

Was ist zu bedenken?

Was kommt auf mich zu?

Das Tutorium spielt diese Fragen durch und bietet Raum, die Krisenbewältigung zu trainieren. In realistischen Szenarien übernehmen die Teilnehmer Rollen und Aufgaben eines IT-Krisenstabes und führen die bedrohte Organisation durch die Sicherheitskrise. Auf diese Weise können Sie die unmittelbare, persönliche Erfahrungen sammeln, von denen wir alle hoffen, dass Sie sie niemals erleben müssen, und die dennoch unerläßlich sind.

Das Tutorium bietet einen, wenn auch spielerischen, so dennoch ernsthaften Einstieg in Fragen der IT-Sicherheit: Die potentiellen Folgen eines Hacker-Einbruchs werden unmittelbar erlebbar und die Diskussionen um die IT-Sicherheit wesentlich konkreter und realitätsnäher. Der Fokus des Tutoriums liegt auf der Organisation und der Lenkung der technischen Kräfte, sowie den Entscheidungsprozessen, nicht jedoch auf technischen Details.

Inhalte:

Es werden - je nach Verlauf - ein oder mehrere Angriffsszenarien durchgespielt:

Vorbereitung: Die Teilnehmer wählen das Angriffsszenario und das angegriffene Unternehmen aus, und erhalten die notwendigen Informationen zu den Rahmenbedingungen. Sie können sich als IT-Krisenstab organisieren und ihre Strategien absprechen.

Durchführung: Das Angriffsszenario wird realitätsnah und in Echtzeit simuliert. Die Szenarienleitung gibt den Zeitablauf und die Ereignisse vor, die die Teilnehmer bewältigen müssen. Dazu können sie Untersuchungsaufträge und Handlungsanweisungen an (simulierte) Technikabteilungen geben, deren Ergebnisse die weitere Entwicklung des Szenarios bestimmen.

Manöverkritik: Die Auswirkungen der Entscheidungen auf das angegriffene Unternehmen, die Entscheidungsprozesse und die Wahrnehmung der jeweils vorhandenen Handlungsoptionen werden nach Abschluß des Szenarios retrospektiv analysiert.

Über den Autor:

Thomas Maus ist Diplom-Informatiker und seit über 10 Jahren selbstständiger IT-Sicherheitsberater.

Dieses Tutorial gibt in dem ersten Teil einen Überblick über die Theorie, den wissenschaftlichen und fachlichen Ansatz von Honeypots sowie die einzelnen Honeypot-Philosophien und Auswertungsmethoden.

Im zweiten Teil wird dann an einem praktischen Beispiel erst ein Honeypot, dann ein Honeypot-Netzsystem mit dem Ansatz zu einem wireless Honeynet aufgebaut. Die Teilnehmer können praktische Erfahrungen beim Simulieren von Schwachstellen sammeln. Darüber hinaus haben sie Gelegenheit zur praktischen Anwendung dieser Erfahrungen. Am Ende des Tutorials wird den Teilnehmern die Möglichkeit gegeben, eigene Auswertungsskripte auf die neu entstandenen Logfiles zu fahren. Sie können hierbei auch selber analysieren, welche Attacken auf ihr Honeynet durchgeführt worden sind, und auch versuchen, die Systeme der anderen Teilnehmer zu hacken.

Über den Autor:

arbeitet als Consultant bei der DN Systems GmbH in Hildesheim und ist in diverse freie Softwareprojekte involviert. Zeil: Unix-Admins mit Shell Erfahrung und know how in einer Skript / Auswetungssprache.

Das Tutorium besteht aus einem einleitenden Vortragsteil, gefolgt von der praktischen Anwendung des vorgestellten Verfahrens auf Problemstellungen der Teilnehmer.

1. Vorstellen der Methodik

Eigentlich interessiert es - außer einer kleinen Gemeinde - niemanden, ob Computersysteme sicher sind, oder überhaupt sicher gemacht werden können. Andererseits stützen wir vielfältige Arbeitsabläufe in Industrie und Verwaltung zunehmend auf IT-Systeme ab, und ob diese Arbeitsabläufe, und damit der Bestand von Unternehmen und die Wahrnehmung öffentlicher Aufgaben, ausreichend sicher sind - dies interessiert sehr wohl.

Und so stellen sich den Verantwortlichen folgende Fragen, auf die das Tutorium Antworten vorschlägt:

• Wieviel Sicherheit braucht Ihr Unternehmen?
• Was muß geschützt werden?
• Vor welchen Bedrohungen?
• Wieviel Sicherheit ist wirtschaftlich?
  • Welche Maßnahmen bringen den größten Nutzen?
  • Welche Maßnahmen sind die dringlichsten?
  • Welche IT-Systeme sind kritisch?
  • Wie "gesund" ist meine IT-Landschaft?
• Wie berücksichtige ich die IT im Risikomanagement, welches nach den Forderungen des KonTraG oder Basel II erforderlich wird?

Vorgestellt wird ein praxisorientiertes und vielfach praxiserprobtes Verfahren, um die Abhängigkeiten Ihrer Organisation von ihrer IT und die daraus resultierenden Risiken systematisch zu erfassen. Diese Einzelrisiken werden quantifiziert und in verschiedenen Dimensionen zu Risikokennzahlen verdichtet.

Unter Risikoinventar ("assets") werden dabei all diejenigen Daten- und Funktionsbestände der IT-Systeme verstanden, die im Rahmen der Geschäftsprozesse für die Organisation selbst oder einen Dritten wertvoll sind, oder deren Missbrauch für die Organisation oder Dritte einen materiellen oder immateriellen Schaden zur Folge haben könnten.

Die Inventarisierung betrachtet hierzu die verschiedene Aspekte der Organisation, um das Risikoinventar möglichst vollständig zu identifizieren: Werte, sicherheitsrelevante Prozeßwirkungen sowie rechtliche und vertragliche Schadenspotentiale. Zur Klassifikation materieller und immaterieller Schadenspotentiale wird ein Verfahren vorgestellt.

2. Praktische Anwendung des Verfahrens

Hier erlernen Sie die Anwendung des vorgestellten Verfahrens. Konkrete Problemstellung aus der Praxis der Teilnehmer sind willkommen und werden beispielhaft nach der Mehtodik gemeinsam erarbeitet.

Ziel ist, dieses Verfahren in der eigenen Berufspraxis anwenden zu können.

Sie lernen

• die Funktionsweise und Hintergünde, die Möglichkeiten und Grenzen des eingesetzten Modells kennen
• wie Sie die Risikokultur und Schutzbedürfnisse Ihrer Organisation in diesem Modell darstellen
• wie Sie die Auswirkung von verschiedenen IT-Versagensmodi auf Ihre Betriebsaubläufe modellieren
• die Nutzung zur Untersuchung konkreter Fragestellungen und zur Optimierung einiger Aspekte des IT-Betriebs

So können etwa aus diesem Risikoinventar an Hand der Schadensklassen Schutzbedürfnisse und Schutzziele abgeleitet, und das Risikoinventar auf IT-Komponenten lokalisiert werden. Auf Basis des Expositionsgrads und des Sicherheitsniveaus der Komponenten gegenüber mutwilligen Angriffen oder zufälligen Betriebsstörungen wird eine Risikoklassifikation gewonnen.

Sie erhalten damit eine Datenbasis, welche kontinuierlich weiter gepflegt werden kann, und Ihnen automatisiert jederzeit Überblick gibt über

• die aktuelle IT-Risikolage des Unternehmens aus Sicht der Geschäftsprozesse und der Technik
• die Dringlichkeit des Handlungsbedarfs in einzelnen Bereichen
• die Angemessenheit Ihres IT-Sicherheitsbudgets und der Sicherheitsmaßnahmen
• die Angemessenheit und Nachhaltigkeit Ihrer System-Architektur und des System-Managements
• die Auswirkungen konkreter Sicherheitskrisen, Systemausfälle, ...

Gleichzeitig dient sie als Werkzeug, um verschiedene Sicherheitsarchitekturen und -maßnahmen vor der Realisierung hinsichtlich ihrer Wirkung und Kosteneffizienz zu untersuchen und zu vergleichen. Weiterhin läßt sich die potentielle Wirkung neuer Bedrohungsszenarien genauso untersuchen, wie die Risikolage neuer Geschäftsprozesse oder die Auswirkungen von IT-Umstrukturierungen. Unterschiedliche Risikobewertungen unterschiedlicher Abteilungen, insbesondere Sicherheits- und Fachabteilung, werden durch das Verfahren transparent. Neben dem Nutzen der Versachlichung der Diskussion bieten sich sogar organisatorische Möglichkeiten, Dissens elegant zu regeln.

Inhalt im Einzelnen:

• Was ist Risiko-Inventar?
• Wie identifizieren Sie umfassend das Risiko-Inventar Ihres Unternehmens?
• Bewertung von materiellen und immateriellen Schadenspotentialen
• Bewertung von Eintrittswahrscheinlichkeiten
• Was ist Risiko?
• Lineare und nicht-lineare Risikobewertung
• Warum gerade dieses Modell?
• Modellierung der Abhängigkeiten der Geschäftsprozesse von der IT-Infrastruktur
• Modellierung von Sicherheitsmaßnahmen und Sicherheitsrisiken
• Praktisches Erstellen eines automatisierten Risiko-Inventars
• Praktisches Nutzen des automatisierten Risiko-Inventars

Über den Autor:

Thomas Maus ist Diplom-Informatiker und seit über 10 Jahren selbstständiger IT-Sicherheitsberater.

This tutorial presents an overview of generic firewall theory and techniques, as well as an overview of the available implementations of these concepts for the freely available Linux operating system.

The first part covers firewalls in general. It provides necessary background information, explains the most commonly used firewall terminology, and it describes most of the currently known firewall concepts. Furthermore, the various firewall techniques that are available (like packet filtering and proxy servers operating on different levels) are explained and their pro's and con's will be discussed. Some important aspects for designing firewalls are explained using some example firewall architectures.

The second part covers the firewall software available for the Linux operating system. A large number of different software packages for packet filtering and proxy services will be described, as well as auxiliary techniques and software, like network address translation, masquerading, virtual private networks, and various additional tools that can improve the host and network security using Linux systems. This part includes an extensive introduction to netfilter/iptables, the Linux 2.4 packet filtering and address translation software, but it also talks about less well-known software packages, that are often not standard available in most Linux distributions. The tutorial will emphasize on the techniques and tools available in Linux 2.4 and 2.6, but it also shortly addresses migration from Linux 2.2, as well as future directions.

Über den Autor:

Jos Vos is CEO and co-founder of X/OS Experts in Open Systems BV. He has an experience of 20 years in the area of research, development, and consulting related to UNIX systems software, Internet, and security. He is the author of ipfwadm and part of the firewall code in the Linux 2.0 kernel. His company X/OS provides a number of products and services related to Linux, UNIX and Open Source software, including firewall and VPN solutions, ranging from small embedded systems to high-availability server products.

Knapp zwei Jahre nach der für den Produktiveinsatz gedachten Kernel-Linie 2.4 wurde im Dezember 2003 der erste Vertreter der neuen 2.6 Version veröffentlich. Auch wenn sicherlich nach den Erfahrungen mit den ersten Releases der 2.4er Version nicht sofort an ein Umstellen von kritischen Systemen zu denken ist, so soll dieser Vortrag die Neuerungen und Verbesserungen eingehen die für den Einsatz von Linux in Produktivsystemen eine Rolle spielen werden. Dabei soll besonderes Gewicht auf die verbesserte Skalierbarkeit auf Mehrprozessorsystemen (u. a. weiche Echtzeitfähigkeit, neuer Scheduler, Thread-Modell) und die Sicherheitsfeatures im Kernel (u. a. volle IPv6-Unterstützung, IPSec) gelegt werden. Auch der Einsatz auf unterschiedlichen Hardwareplattformen und die erweiterte Unterstützung von mobilen Geräten wird betrachtet werden.

Über den Autor:

Wilhelm Dolle hat in Bochum studiert, wechselte 1995 zur Promotion nach Marburg und lebt inzwischen in Berlin. Mit diversen Computersystemen beschäftigt er sich seit 1985. Hauptsächliche Schwerpunkte seines Interesses lagen und liegen dabei auf Netzwerkfähigkeiten und Netzwerksicherheit. Seit 1999 arbeitet er für die Firma interActive Systems GmbH, leitete dort seit 2000 die Networking Unit und ist seit August 2003 in der Geschäftsleitung für den Bereich Information Technology zuständig. Wilhelm Dolle hält in regelmäßigen Abständen Vorträge über Sicherheit in vernetzten Systemen, hat einige Fachartikel zu diesen Themen veröffentlicht, arbeitet als Gutachter bei verschiedenen Verlagen und unterrichtet an einer Berufsakademie das Fach Netzwerksicherheit.

Die Flut unerwünschter E-Mails ist derzeit die größte gemeinsame Plage der Internet-Anwender und eine große Herausforderung für Entwickler. Im ständigen Wettstreit mit Filterentwicklern und Anbietern anderer Gegenmittel scheinen die Spammer die Nase derzeit vorn zu haben: Im Verbund mit Würmern und Trojanern bedrohen sie nicht nur die elektronische Post, sondern das Internet insgesamt. Nach DoS-Attacken mussten bereits Betreiber von Blacklist-Servern die Segel streichen.

Verteilte Spam-Angriffe, wie sie zurzeit überhand zu nehmen drohen, lassen sich am besten verteilt abwehren. Mit jeder Spam-Mail, die lokale Filterprogramme einzelner Anwender einfach nur löschen, gehen wertvolle Informationen für die Gesamtheit verloren. Wirkungsvolle Filter müssen über bidirektionale Schnittstellen zueinander verfügen, um zum Beispiel Spam-Prüfsummen und -Gateway-Adressen schnell zwischen allen Mail-Transportsystemen zu verteilen.

Darüber hinaus sind grundsätzliche Ergänzungen oder Änderungen von Internet-Protokollen und -Services wünschenswert, wie sie bereits angedacht sind oder sogar schon existieren (Stichworte: Reverse MX Records, AMTP). Doch schon das Beispiel IPv6 zeigt, wie schwerfällig das Internet auf wichtige Neuerungen reagieren kann.

Bei allen Bemühungen dürften technische Lösungen allein keine Abhilfe schaffen. Bewusstsein und Verhalten der E-Mail-Anwender müssen sich ändern - sowohl auf Seiten der Absender als auch der Empfänger. Ungefragte Werbung an frühere Kunden ist ebensowenig angesagt wie die Weiterleitung privater Witze an die ganze Firma.

Genau hier lauert nach dem Spam die nächste Gefahr: Im Zumüllen des Posteingangs mit E-Mails, die eigentlich nicht erwünscht sind, aber auch kein Spam im heutigen Sinne. An dieser Stelle liegt denn auch die eigentliche Chance für die individuelle statistische Klassifizierung und Vorsortierung von Mails, denn Spam sollte das Mail-Gateway erst gar nicht verlassen.

Es wird vielleicht noch Jahre dauern, bis die Spamwelle verebbt, aber letztlich erfahren das Internet im Allgemeinen und E-Mail im Besonderen einen Entwicklungsschub, von dem Anwender nur profitieren können.

Über den Autor:

Dipl.-Phys. Bert Ungerer (40) ist seit 1989 Redakteur beim Heise-Verlag (zunächst bei c't, seit 1996 bei iX). E-Mail ist für ihn die erste und bis heute mit Abstand wichtigste Internet-Anwendung.

Unter anderem zur Verteidigung gegen unerwünschte E-Mails startete er 2002 die Entwicklung eines eigenen Filters. Das Procmail-Script bewahrt mittlerweile diverse Verlagsmitarbeiter vor Spam, sortiert Pressemitteilungen und beantwortet E-Mails bei Bedarf automatisch. Ungerers Fazit: "Die Inhaltsanalyse ist viel zu schade, um nur Müll auszusortieren."

Eine veröffentlichte Version des Filters steht inzwischen iX-Lesern für den Einsatz auf dem eigenen Gateway zur Verfügung. Aber auch Entwickler und Anwender anderer Filter können vom iX-Projekt profitieren: Die Filterelemente lassen sich per Autoresponder testen, und eine automatisch generierte, laufend aktualisierte "temporäre schwarze Liste" demonstriert das Ausmaß der Bedrohung durch verseuchte "Zombie"-Gateways.

Zeitschriftenartikel des Autors zum Thema finden sich in iX 5/2003, S. 58, und iX 11/2003, S. 123.

Die neueste Generation des Linux-Kernels zeichnet sich gegenüber dem Vorgänger sowohl durch eine Reihe nützlicher und interessanter Features, als auch durch eine intensive Überarbeitung interner Strukturen und Subsysteme aus.

Diese Modifikationen innerhalb des Kernels sind aber nicht rückwirkungsfrei für den Administrator und den Anwender. An vielen Stellen begegnen ihm neue Komponenten und Abläufe. Der Vortrag stellt hiervon die Wichtigsten vor.

Die Überarbeitung beispielsweise des Kernel-Build-Systems führt dazu, dass Module nicht mehr die Dateierweiterung ".o", sondern die Erweiterung ".ko" tragen. Hinter der neuen Namensgebung steckt ein Verfahren, um die Versionen von Kernel, Compiler und Modul genauer aufeinander abzustimmen.

Auch das Laden von Modulen ist überarbeitet worden. Die Folge: Neue, vor allem aber schlankere "Modutils" werden benötigt. Zudem haben sich die Verfahren, Module automatisiert zu laden, geändert (Stichworte hier "modprobe" und "hotplug"). Kurz vor Veröffentlichung der ersten Kernel-Version 2.6.0 hat Torvalds noch die seit den Anfängen von Unix bekannten Majornummern durch Gerätenummern ersetzt. Damit wird die Limitierung auf 256 Geräte pro Treiber aufgehoben.

Und als wesentliche Neuerung haben die Entwickler ein Gerätemodell eingeführt. Mit dem Gerätemodell kommt der Administrator über das Sys-Filesystem in Kontakt. Dieses bietet ihm die vielfältigsten Möglichkeiten zur Konfiguration und Zustandserfassung. In Verbindung mit dem Hotplug-Mechanismus wird es in naher Zukunft auch genutzt werden, um das so genannte Device-Filesystem abzulösen.

Gerätenummern und Gerätemodell sind Elemente des Kernels mit besonderem Zukunftspotenzial. Dass diese in kommenden Kernelversionen eine zentrale Rolle spielen werden, steht außer Frage und soll beleuchtet werden.

Über den Autor:

Nach Studium, Promotion und Industrietätigkeit ist Jürgen Quade heute an der Hochschule Niederrhein im Bereich von Echtzeitsystemen, Embedded Linux und Netzwerksicherheit tätig.

Mit Kernel 2.6 (respektive 2.5) beschäftigt sich der Autor seit mehr als 1 1/2 Jahren. Über den Kernel veröffentlicht er als Co-Autor regelmässig Fachaufsätze und über die Entwicklung von Treibern erscheint demnächst ein Buch.

Dieser Vortrag beschreibt die Emulation von ganzen Netzwerken mit Hilfe von User-Mode-Linux (UML). UML ist ein spezieller Linux-Kernel, der auf einem laufenden Linux-System booten kann und ein neues virtuelles System zur Verfügung stellt. Ursprünglich für die Vereinfachung der Entwicklung von Kernelmodulen gedacht, erlaubt UML heute auch den Aufbau von von virtuellen Netzen eigenständigen virtuellen Rechner, auf denen das Linux Betriebssystem läuft. Dabei stellt UML sämtliche Netzwerkfunktionen zur Verfügung. Ähnlich dem kommerziellen Produkt VMware kann das Open Source Produkt UML daher genutzt werden um verschiedene Applikationen auf einzelnen getrennten virtuellen Systemen laufen zu lassen oder um Testnetzwerke zu simulieren. Einige Firmen bieten sogar inzwischen Hosting-Lösungen auf dieser Basis an. Der Vortrag wird UML und seine Netzwerkfunktionen vorstellen und praktisch demonstrieren.

Ü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 (unter anderem für Red Hat) entwickelt. Als Referent wurde er bereits vom Linuxtag, dem LinuxKongress, der SANS und dem Frühjahrsfachgespräch eingeladen. In dem letzten Jahr war er Mitglied des Programmkommitees des Linuxkongresses und des FFG. Im Dezember 2002 veröffentlichte er sein erstes Buch "Intrusion Detection Systeme für Linux-Server". Im November 2003 erschien sein zweites Buch "VPN mit Linux".

Das Jahr 2004 wird den endgültigen Durchbruch für die Bluetooth Technologie bringen. Die Preise für Bluetooth fähige Endgeräte fallen und es gibt immer mehr Anwendungen die Bluetooth unterstützen. Langsam aber stetig dringt diese Technologie in den Alltag ein. Und wie so oft spielt Linux bei der Umsetzung neuer Technologien eine sehr wichtige Rolle. Den offiziellen Bluetooth Support für Linux gibt es schon seit Mai 2001 und alle grossen Linux Distributionen bringen mittlerweile Bluetooth Unterstützung von Haus aus mit. Mit dem BlueZ Projekt steht eine freie Implementierung der Bluetooth Spezifikation zur Verfügung, die den kommerziellen Varianten in nichts nachsteht.

Der Vortrag gibt einen Einblick in den Aufbau von Bluetooth und dessen Protokollstack. Es wird gezeigt, wie diese Protokolle und auch die Anwendungsprofile in Linux umgesetzt und nahtlos in andere Teilbereiche von Linux integriert wurden. Des weiteren wird auf die Bluetooth Funktionen für den täglichen Gebrauch eingegangen. Hierzu zählt die Einwahl ins Internet über Handy und ISDN und das Aufbauen von kleinen Bluetooth Netzwerken. Aber auch das Drucken über Bluetooth und die Benutzung von drahtlosen Tastaturen und Mäusen ist ein zentraler Punkt.

Ein grosses Ziel von Bluetooth ist es vorhandene Standards zu benutzen und einfach zu integrieren. Genau dieses ist auch eines der obersten Ziele von BlueZ und so wird in vielen Bereichen auf die etablierten Programme und Module gesetzt um diese dann mit Bluetooth zu erweitern. Bekannte Beispiele hierfür sind OpenOBEX, Gnokii, CUPS, CAPI und auch HID.

Über den Autor:

Marcel Holtmann ist einer der beiden Hauptentwickler des offiziellen Linux Bluetooth Stacks BlueZ (www.bluez.org) und arbeitet dabei am Kernel Code so wie auch an der Bluetooth Library und den Tools. Des weiteren betreut er auch das OpenOBEX Projekt und hilft anderen Entwicklern die Bluetooth Technologie in ihre System zu integrieren.

Die Diskussion, ob IPv6 tatsächlich nötig oder doch nur eine Spielerei von weltfremden Tekkies ist, wird fast ausschließlich um den vergrößerten Adressraum herum geführt, oft genug mit Pseudoargumenten, die stark an "640 KByte sind genug für jeden" (Bill Gates, 1981) erinnern. Dabei werden andere wichtige Verbesserungen, die IPv6 bietet, genauso vernachlässigt wie die Frage, welchen Nutzen dieser große Adressraum als solcher bietet.

Zwei große Vorteile von IPv6 sind vereinfachte Konfiguration und höhere Zuverlässigkeit:

Anders als ARP in Ethernet-basierten IPv4-Netzen verhindert IPv6 während der Konfiguration Adresskollisionen, während ARP blind darauf vertraut, daß die Netzwerkkartenhersteller jede Ethernet-Adresse nur einmal vergeben.

Mit den langen Adressen wird es praktikabel, die Subnetzgröße /64 fest vorzugeben. Innerhalb eines Subnetzes generiert IPv6 aus jedem gegebenen Netzwerk-Prefix, das es von einem erreichbaren Router erfragt, und seiner 48 Bit langen Ethernet-Adresse eine IPv6-Adresse. Auf DHCP oder statisch konfigurierte Netzwerkparameter kann IPv6 also verzichten.

Wenn Router mehrere Netzwerk-Prefixe verkünden, wird zu jedem Prefix eine IPv6-Adresse konfiguriert. Unkontrollierte DHCP-Server können deshalb keinem Rechner seine "richtige" Adresse überschreiben.

Routing-Informationen liegen ausschließlich auf den Routern. Normale Hosts schicken (etwas vereinfacht) alle Pakete, die sie nicht direkt ausliefern können, an den nächsten erreichbaren Router und brauchen deshalb keine eigene Routing-Konfiguration mehr.

Mit dieser automatisierten Konfiguration werden einige administrative Aufgaben erheblich einfacher, was interessante Möglichkeiten eröffnet:

Müssen in IPv6-Netzen die Adressen zum Beispiel bei einem Providerwechsel geändert werden, lassen sich im laufenden Betrieb die neuen als zusätzliche Adressen einrichten, so daß die alten Adressen allmählich "aussterben" können.

Network Appliances können so auch ohne technisches Know-How in Plug-and-Play-Manier in Betrieb genommen werden. Das senkt die gerne zitierte "Total Cost of Ownership" pro Netzkomponente und macht damit IP-Telefone, netzwerkgesteuerte Lichtschalter und Thermostatventile und viele andere Kleinigkeiten bei ständig sinkenden Hardwarekosten zunehmend interessant.

Einige neue Features wurden bei IPv6 sauber integriert, während sich die IPv4-Welt hier mit eingeschränkten Lösungen behelfen muß:

Mobile IP erlaubt es, auch bei ständig wechselnden Netzwerkverbindungen existierende TCP-Verbindungen nahtlos aufrechtzuerhalten. Egal ob ich mich mit meinem Notebook oder PDA nur von meinem Büro in einen Besprechungsraum bewege oder quer durch Deutschland fahre, ich muß mich nirgends ab- und anderswo wieder anmelden, muß nur soweit über Ethernet, DSL, UMTS, GPRS oder WLAN nachdenken, wie ich das Gerät physikalisch einstöpseln muß oder Performance-Fragen relevant sind.

Mit Ressource Reservation (RSVP) kann ich für einzelne Verbindungen Bandbreite reservieren und Quality-of-Service-Merkmale festlegen, womit IPv6 Aufgaben von spezialisierten Bus-Systemen übernehmen kann.

Ein letztes Scheinargument, das in der Diskussion um IPv4 oder IPv6 oft angeführt wird, ist die Behauptung, daß eine Migration zu aufwendig ist und man den Betrieb dafür nicht stillegen kann, obwohl IPv4 und IPv6 problemlos im gleichen Netz parallel zu betreiben sind und die IETF konsequent auf zuverlässige Migrationspfade geachtet hat.

Über den Autor:

Der Autor ist Dipl.-Inform. und freischaffender Systemarchitekt im Unix- und TCP/IP-Umfeld.

Er unterstützt IT-Projekte dabei, Software auf real existierender Hardware in real existierenden Rechenzentren in einen effizienten und zuverlässigen Betrieb zu nehmen, bringt die Infrastruktur von Rechenzentren auf den Stand der Technik und führt die IT-Bausünden der New Economy in die betriebwirtschaftliche Realität.

Neben den dabei relevanten technischen Themen, insbesondere Performance, Hochverfügbarkeit und Skalierbarkeit, interessiert ihn auch die dazugehörige Betriebsorganisation und die Schulung und das Coaching der Mitarbeiter im IT-Betrieb.

Wenn er sich nicht gerade mit IPv6 beschäftigt, tauchen geht oder mit dem Fahrrad Kontinente sammelt, ist er unter stockebrand@guug.de und http://www.benedikt-stockebrand.de/ zu erreichen.

This talk will share experiences rebuilding the Red Hat Enterprise Linux 3 source rpm's to create X/OS Linux, a free enterprise-class Linux distribution.

The technical issues and caveats will be discussed, as well as the motivation behind this effort and some of the legal aspects involved.

Über den Autor:

Das originale Berkeley-Sendmail - bzw. sein aktueller Nachfolger - gilt als monolithisch, unübersichtlich und fehleranfällig. Der heutige Systemadministrator muss sich also nach Alternativen umsehen - aber auch bei diesen müssen wir jederzeit bereit sein, kurzfristig eine neue Version einzuspielen, um Sicherheitslücken zu schliessen.

Schön wäre es daher, eine kompakte Alternative für den Einsatz auf Workstations zu haben, welche auch bei Fehlkonfiguration keine Spams von außen annimmt und auch bei einem Buffer-Overflow das System oder Daten unbeteiligter Benutzer nicht angreift.

Vielfach wird das schon dadurch implementiert, dass die Benutzer die e-mail- Funktion eines Webbrowsers benutzen, der üblicherweise per SMTP direkt an einen getrennten MTA ausliefert. Dies hilft jedoch nicht, wenn ein Programm oder ein alteingesessener Unix-Benutzer ihre E-mail verschicken wollen - hier wird vielfach ein Programm erwartet, das sich wie das Berkeley-Sendmail verhält.

Weniger als Jef Poskanzers "mini_sendmail" kann man gar nicht machen: es liefert die Standardeingabe per SMTP bei einem Smartmailer ein und meldet per Exit Code Erfolg oder Misserfolg. Keinerlei Privilegien (außer Öffnen einer TCP-Verbindung und Lesen der Standardeingabe) sind notwendig.

(Weitere Pakete mit ähnlichen Eigenschaften - aber bedingt durch u. a. SSL- Support mit doppelt so grosser Binärprogrammgröße - sind "msmtp" und "ssmtp".)

"mini_sendmail" braucht daher kein Spoolverzeichnis und ist besonders gut geeignet für plattenlose Clients, oder Rechner, die von einer Flashplatte laufen. Es kann auch aus einem chroot-Käfig heraus Mail an den MTA auf dem uneingeschränkten Filesystem liefern - das ist oft nötig, wenn Dienstprogramme dort erwarten, über die traditionelle Sendmail-Schnittstelle Meldungen an die Administratoren zu schicken.

"mini_sendmail" hat jedoch auch Nachteile. Heutzutage sind die Benutzer nicht daran gewöhnt, von ihrem Mailsystem wegen eines tempörären Ressourcenengpasses eine Fehlermeldung zu bekommen; ein lokaler Spoolbereich auf dem Client ist also doch empfehlenswert. Dazu kommt die sehr minimalistische Implementierung der recht ausufernden Kommandozeilenoptionen des Berkeley-Sendmail, die immer wieder zu neuen Patches an "mini_sendmail" zwingt.

Will man also nicht zur "nullclient"-Konfiguration von Sendmail oder einer äquivalenten Konfiguration von postfix, Exim, etc. greifen, so muss ein spezialisiertes Programm gefunden werden. Stellvertretend hierfür soll der Einsatz von "nullmailer" beschrieben werden. "Nullmailer" benutzt einen lokalen Spool-Bereich, der nur von einer speziellen Userid beschrieben werden kann; seine Injektorkomponente läuft mit setuid-Bit (auf diese User-ID). Ein Daemon liest die Spooldateien und versucht sie wiederholt (je nach Konfiguration über ein SMTP- oder ein QMQP-Backend) auszuliefern.

Nullmailer ist also für Workstations mit echten Festplatten geeignet und kann für diese temporäre Überlastungen des Mailservers abfedern.

Der Vortrag stellt die genannten Programmpakete vor und vergleicht Konfiguration und Anforderungen.

Über den Autor:

Ignatios Souvatzis ist "Systemprogrammierer" (in Wirklichkeit eine Kombination eines Systemadministrators, eines Bandoperators, eines Kernelhackers und eines Benutzerberaters) in der Abteilung V des Instituts für Informatik der Universität Bonn. Er glaubt, den ersten WWW- Server an seiner Universität - jedenfalls aber in der Informatik - eingerichtet zu haben und weiß rückblickend nicht, ob er es nicht bedauern sollte.

Er ist außerdem ein NetBSD- Entwickler und war dort hauptsächlich für einige Gerätetreiber, das neue ARP-Subsystem und den Amiga-Port verantwortlich.

Er schrieb Beiträge über Unix-Anwendungen und -Administration für verschiedene Zeitschriften und ist Co-Autor je eines Buches über FreeBSD- und NetBSD- Systemadministration.

Unix lernte er in seinem zweiten Studienjahr (Physik und Astronomie0 in einer kleinen Softwarefirma auf einem Z8000- System kennen. Später kamen - neben diversen Nicht-Unizes - Ultrix auf DECstation 2100 bis 5000/260, ConvexOS auf Convex C1, AIX 2.2.1 (IBM RT), SunOS 4 und SunOS 5.x (Sparc) dazu.

In diesem Übersichtsvortrag zum Thema Linux-Cluster werden die drei grundsätzlichen Anwendungsbereiche Hochleistungsrechner "High-Performance-Computing" (HPC), Hochverfügbarkeit "High Availability" (HA) und Lastverteilung "Load-Balancing" vorgestellt. Es wird gezeigt, wie diese Anwendungsbereiche mit Linux und weiteren Software- und Hardware-Komponenten abgedeckt werden können. Dazu gibt es einige Fallbeispiele aus der Praxis von science + computing.

Über den Autor:

Christoph Herrmann, Jahrgang 1969, studierte Physik an der TU-Berlin. Danach arbeitete er 1.5 Jahre als Lehrer und Systemadministrator im Lette-Verein in Berlin.

Seit 1999 ist er bei der science + computing ag beschäftigt. Dort ist er hauptsächlich für Design und Betrieb großer heterogener Rechnernetze verantwortlich, wobei er hier in zunehmendem Maße mit Linux-Clustern arbeitet.

In seiner Freizeit beschäftigt er sich am liebsten mit FreeBSD, und hat auch schon in begrenztem Umfang selber für FreeBSD programmiert.

Das World Wide Web ist aus dem Internet praktisch nicht mehr wegzudenken. Häufig wird sogar schon das Internet mit dem WWW gleich gesetzt. Das Datenvolumen des WWW steigt stetig und exponentiell, die Angebote werden immer vielfältiger - in alle Richtungen. Zu einer geregelten und ressourcenschonenden Kommunikation im WWW können Proxy-Server einen erheblichen Beitrag leisten. Durch eine intelligente Cache-Funktion können sie das Datenvolumen beachtlich senken, durch Access-Regeln können Zugriffe gezielter gesteuert oder gar beschränkt werden und durch Ihre eigentliche Proxy-Funktion tragen sie auch zur Sicherheit von Clients oder Webservern bei.

Squid ist der wohl bekannsteste und am häufigsten eingesetzte Proxy-Server auf Unix-/Linux-Systemen. Durch seine gute Skalierbarkeit und den vielfältigen Konfigurationsoptionen eignet er sich sowohl für kleine lokale Installationen wie auch für große Proxy-Verbünde in Weitverkehrsnetzen.

Nach einem kurzen Abriss über die Funktion von Poxy-Servern im Allgemeinen und den Leistungsmerkmalen von Squid, wird am einem praktischen Beispiel der Einsatz von Squid in einem größeren Netzwerk beschrieben. Neben der konzeptionellen Planung wird schwerpunktmäßig die praktische Umsetzung und Konfiguration eines Verbundes von mehreren Proxyservern vorgestellt. Themen wie Lastverteilung, gemeinsamer Cache, Zugriffsregelung, Zugriff auf mehrere getrennten Netze und Ausfallsicherheit, werden genau so angesprochen, wie konkrete Konfigurationsbeispiele und mögliche Stolpersteine. Weitere Einsatzgebiete wie "reverse Proxy" oder "transparent Proxy" soviel Delay Pools werden kurz angeschnitten. Nach einem Ausflug in die Access-Listen und -Regeln von Squid wird mit den Möglichkeiten zur Überwachung des laufenden Betriebs und der Fehlersuche abgeschlossen.

Über den Autor:

Dirk Dithardt ist bei der Niedersächsischen Landesverwaltung beschäftigt. Schwerpunkte seiner Arbeit sind Intranet- und Internet-Dienste, wie DNS, Web und Proxy. Im Besonderen beschäftigt er sich mit dem zentralen Proxyserver und Webfilter für die rund 2.000 Dienststellen der Landesverwaltung und ihrer 40.000 Nutzer. Auf seiner Website www.squid-handbuch.de veröffentlicht er neben einem Online-Handbuch auch eine im Aufbau befindliche deutsche FAQ zu Squid.

Hochverfügbare Systeme stellen eine Herausforderung für jeden IT-Verantwortlichen dar. Während es mittlerweile Produkte und Lösungen für fast jedes System gibt, sind Konzepte und Herangehensweisen kaum vorhanden.

Im Rahmen dieses Vortrages werden verschiedene Blickwinkel zum Thema hochverfügbarer Systeme aufgezeigt. Hierbei liegt der Schwerpunkt auf der Darstellung der technischen Risiken und möglicher Lösungen. Besonderer Augenmerk wird der Suche nach single points of failure (SPoF) gewidmet, zu denen der Referent neben den technischen Einrichtungen auch das organisatorische Umfeld zählt.

Im Rahmen des Vortrages werden die folgenden Punkte behandelt:

• Systemanalyse und -darstellung
• Kommunikationswege
• Schwachstellenanalyse
• Risikobewertung
• Konzepte zur Vorbeugung bzw. Vermeidung von SPoFs
• Vorraussetzungen für funktionierende HA-Systeme
• Eigenarten der Projektabwicklung bei HA-Systemen

Über den Autor:

Kai Dupke ist seit Anfang 2000 bei der probusiness AG, Hannover, für den Geschäftsbereich Linux zuständig. Als Projektberater unterstützt er darüber hinaus Kunden bei der Erstellung von Backupkonzepten und Hochverfügbarkeitslösungen. Zuvor hat er als freier Systemberater kaufmännische Komplettlösungen in Industrie und Handel implementiert und betreut. Kai Dupke beschäftigt sich seit 1992 mit Linux, hat in den Bereichen ISDN und Portierung auf die Alpha-Plattform mitgewirkt. Er ist Inhaber einer RHCE-Zertifizierung und schreibt seit 1996 Artikel in diesem Bereich für die Zeitschrift iX und das Linux-Magazin. Kai Dupke tritt auch als Referent auf und hat als solcher an der CeBIT 2001, den Linux-Tagen 2001 und 2003 sowie der Linuxworldexpo 2003 teilgenommen. Kai Dupke ist 36 Jahre als, in Wuppertal geboren und lebt seit 1989 in Hannover.

In Zeiten wirklich großer Mengen an Plattenplatz, die es zu verwalten gibt, kommt man um eine Verteilung desselben im Netzwerk nicht herum. Sei es SAN oder NAS oder eine beliebige Zwischenform, Speicher wird heutzutage immer weiter virtualisiert.

Das Andrew File System ist ein Netzwerkdateisystem, das für große Umgebungen entworfen wurde. Diese Fokussierung auf Skalierbarkeit bringt einen höheren initialen Aufwand bei der Installation und eine teilweise etwas gewöhnungsbedürftige Semantik mit sich. Diese Hürden zahlen sich jedoch mehr als aus, da AFS bei großen und vielen Servern sehr viel besser zu handhaben ist als beispielsweise NFS.

In letzter Zeit sind im Rahmen des Samba-Projektes einige Erweiterungen entstanden, mit denen sich AFS besser und reibungsloser in aktuelle Umgebungen integrieren lässt. Dieser Vortrag wird die neuen Möglichkeiten theoretisch vorstellen und praktisch zeigen.

Einer der großen Vorteile von AFS gegenüber NFS ist die Authentifizierung der Benutzer gegenüber dem Server. Ein NFS-Server vertraut dem Client, dass dieser die Benutzer authentifiziert hat. Bei AFS muss sich jeder Benutzer zunächst ein Kerberos-Ticket verschaffen, das er dem Kernel übergibt, um auf Dateien zugreifen zu können. Dazu benötigt er das Klartextpasswort.

Wenn man mit Samba AFS-Dateisysteme an Windows-Clients exportieren möchte, muss sich Samba anstelle des Benutzers ein Ticket verschaffen. Jedoch hat Samba grundsätzlich keinen Zugriff auf das Klartextpasswort des Benutzers. Der Vortrag wird grundsätzliche Lösungen für dieses Problem aufzeigen, und den Weg, den Samba gewählt hat, beschreiben.

AFS pflegt eine eigene Benutzer- und Gruppendatenbank. Diese ist unabhängig von der Unix- oder NT-Benutzerdatenbank. Wenn man einen AFS-Server in einer Unix- oder Windows-Welt betreiben möchte, muss man alle Benutzer und Gruppen doppelt pflegen: Einmal in der Unix- oder Windows-Welt und einmal im AFS.

Die AFS-Benutzerdatenbank ist im ptserver oder Protection Server implementiert. Die wesentlichen Operationen, die AFS vom ptserver benötigt, sind die Umsetzung von Namen in IDs und umgekehrt, und die Abfrage einer Liste von Gruppen, in denen ein Benutzer Mitglied ist. Diese Operationen können mit dem Programm ptproxy an einen Winbind-Dämon weitergeleitet werden, so dass keine separate Pflege der Benutzerdatenbank notwendig ist. Der Vortrag wird die Benutzung des ptproxy zeigen.

AFS hat eine eigene Vorstellung davon, was eine Access Control List ist. Ein wesentliches Feature von Samba 2.2 war, die Posix-ACLs im exportierten Unix-Dateisystem mit dem entsprechenden Windows-GUI ansehen und ändern zu können. Mit dem Modul vfs_afsacl gibt es nun die Möglichkeit, auch die weiter gehenden AFS-Acls von Windows aus zu bearbeiten.

Über den Autor:

Tja, Selbstlob :-)

Also: Ich bin seit Linux-Kernel 2.0 (oder 1.2??) im Credits-File für das smbfs und ncpfs, die Anbindungen an Windows- und Novell-Server. Seit 1997 habe ich daran aber nichts mehr gemacht, sondern habe mich eher der Serverseite zugewandt.

Seit 1994 bin ich Mitglied im Samba-Team und in Deutschland ziemlich viel im Consulting, Training und so weiter unterwegs. Dabei finde ich eine Menge Bugs und notwendige Features, die ich nach Möglichkeit implementiere.

In letzter Zeit bastele ich für IBM im Rahmen des Stonehenge-Projektes an der Integration von Samba und AFS und letztlich auch an der Verbesserung von AFS.

1997 habe ich in Göttingen mein Mathe-Diplom gemacht und ein halbes Jahr vorher zusammen mit 3 anderen die Service Network GmbH gegründet. Wir sind jetzt 20 Leute und leben vornehmlich von Infrastruktur-Dienstleistungen. Firewalls, VPN und seit ein paar Jahren auch deutlich zunehmend Samba.

"Was wollen Sie denn, es funktioniert doch (noch)!?!"

Warum konnten noch vor einem Jahrzehnt 5 Leute 7x24h über 5000 Benutzer und mehrere UNIX-Großrechner sowie hunderte kleiner Server stressfrei betreiben, und zwar Betriebssystem, Middleware, User und Anwendungen? Und warum explodieren heute der Administrationsaufwand und die Kosten, und manchmal auch die Administratoren und Manager?

Wie konnte es soweit kommen?

Ist diese Entwicklung zwangsläufig?

Wie - vor allem - kehren wir diesen Prozeß wieder um?

Der Vortrag beschreibt an anschaulichen Beispielen, wie es soweit kommen konnte, und zählt typische Ursachen mit hohem Wiedererkennungswert für diese Entwicklung auf.

Problem erkannt - Problem gebannt?

Noch nicht ganz: Es wird erläutert, wie die Kosten in Relation zum mit der IT erzeugten Nutzen und zum in der IT aufgebauten Wert gesetzt werden können, sowie Ansätze vorgestellt, wie - um den Preis eines mehr oder minder großen Paradigmenwechsel - die Ursachen der Fehlentwicklung eingedämmt und wieder wirksame Kontrolle über die eigene IT und ihre Kosten, ihren Nutzen und ihren inneren Wert (oder auch Hypothek) gewonnen werden kann.

Über den Autor:

Thomas Maus ist Diplom-Informatiker und seit über 10 Jahren selbstständiger IT-Sicherheitsberater.

• SAP-Landschaften: das vergessene Risiko
• Warum werden die meisten SAP-Systeme unsicher installiert
• Standard Software - Standard Fehler!?
• Überblick über die zwingenden Sicherheitsmassnahmen
• Gefährdungen an der Internetschnittstelle (ITS, WAS, mySAP.com)
• Angriffsbeispiele

Über den Autor:

Alexander Geschonneck ist leitender Sicherheitsberater bei der HiSolutions AG in Berlin. Seit 1993 ist er branchenübergreifend im strategischen und operativen IT-Sicherheitsumfeld tätig. Er ist Autor des im Februar 2004 erscheinenden Buches "Computer-Forensik. Systemeinbrüche erkennen, ermitteln, aufklären" (dpunkt.verlag), Mitautor des IT-Grundschutzhandbuches des Bundesamtes für Sicherheit in der Informationstechnik und schreibt für die "iX" sowie andere Fachzeitschriften. Seine Arbeitsgebiete sind u.a. Beratung im Umfeld der Informationssicherheit, Aufbau und Coaching von IT-Sicherheitsmanagementteams, Risiko- und Sicherheitsanalysen, Notfallplanung, Penetrationstests sowie Sicherheitsvorfallsbehandlung.

Die Themen XML (extensible Markup Language) und XSL (...) sind seit einiiger Zeit in aller Munde. Häufig werden diese zum Austausch von (strukturierten) Daten verwendet. Diese können maschinell auf Wohlgeformtheit und/oder Validität geprüft werden.

Einige CMS setzen ebenfalls auf XML auf, einige Webseiten verwenden XHTML. Warum ist aber XML auch zum Publishing interessant?

Zunächst erhält man, zum Beispiel mit DocBook, eine Dokumentenstruktur, die unabhängig von jeglicher Darstellung ist. Die verfügbaren Tools können die Dokumente dann in verschiedene Ausgabe-Formate konvertieren. Dazu dienen XSL-Stylesheets.

Warum DokBook? Ausgefeilte, stabile und verbreitete DTD. Diese kann für Artikel, Bücher oder Manual-Pages verwendet werden. Erweiterungen und Anpassungen für Webseiten oder Präsentationen sind ebenfalls verfügbar.

Zum Editieren kann ein beliebiger Editor verwendet werden (Emacs und VIM enthalten spezielle Modes für XML), es sind aber auch spezialisierte Editoren verfügbar. DocBook kann auch mit Abiword und/oder OpenOffice verwendet werden.

Frei verfügbare Stylesheets konvertieren DocBook/XML in HTML, FO und RTF. Aus dem FO-Format kann mittels FOP oder passivetex PS/PDF erzeugt werden. Damit sind alle wesentlichen Formate in passabler Qualität generierbar. Der Vortrag wird die verschieden Formate und Tools vorstellen und die verschiedenen Konvertierungen mit Vor- und Nachteilen beschreiben.

Manche Verlage verwenden eine eigene DTD, so zum Beispiel Pearson. Diese ist teilweise der Struktur von DocBook sehr ähnlich. Zur Abgabe des Manuskriptes in der Pearson-DTD muss jedoch eine Konvertierung erfolgen - dazu kann ein eigenes XSL-Stylesheet erstellt werden. Für Probeausdrucke sollte dann allerdings nicht das DocBook- Dokument gedruckt werden, sondern das bereits konvertierte - einfach um Konvertierungsfehler erkennen zu können.

Vorteile? - Standardformat, stabil, freie Tools verfügbar, aktive Meintainer, Mailingliste, Versionsverwaltung

Nachteile? - langsame und aufwändige Konvertierung, freie Tools haben gelegentlich schwächen, Verlags-DTD inkompatibel

Über den Autor:

Jochen Hein ist Autor für Addison-Wesley, nach drei Auflagen in LaTeX ist die vierte Auflage in XML konvertiert und durch einen professionellen Setzer gesetzt. Der Vortrag wird von den Erfahrungen beim Publishing mit XML/XSL berichten.

1988 wurde der Referent als SAP R/2 Basisbetreuer in einem Zeitungsverlag. Im Rahmen des Studiums der Informatik an der TU Clausthal lernte er im Jahr 1992 Linux kennen und schätzen und ist seitdem in der Community aktiv. Neben verschiedenen Beiträgen zu Projekten gründete er den Linux-Stammtisch in Clausthal und die Linux-User-Group Kassel mit.

Heute arbeitet er als SAP R/3 Basis Berater bei der Firma SerCon GmbH und hält dort außerdem Schulungen zum Thema Linux, Oracle und SAP.

Die Benutzerverwaltung in einem großen Netzwerk nimmt eine zentrale Rolle ein. Im Vortrag möchte ich ein Beispiel für eine recht einfache Lösung aufzeigen. Es geht um den Network Information Service, auch unter dem Namen NIS bekannt, und um das Authentifizierungsprotokoll Kerberos. Mit Hilfe von NIS werden Benutzerinformationen wie beispielsweise die User-ID, Gruppen-ID, Homeverzeichnis und Login-Shell zentral auf einem Rechner bereitgestellt und verwaltet. Jede Workstation die Teil derselben NIS-Domäne ist wie der NIS-Server kann auf die Informationen, die der Server bereitstellt, zugreifen. Zur eigentlichen Authentifizierung wird Kerberos in der Version 5 verwendet, da es um einiges sicherer ist, als die Authentifizierung über NIS vorzunehmen. Kerberos ist ein Ticket basiertes Authentifizierungsprotokoll. Es hat den Vorteil, das ein Benutzerpasswort niemals über das Netzwerk übertragen werden muss. Es schützt somit vor ungewollten Netzwerksniffing. Außerdem bietet es den Vorteil, das ein Client sich in einer Netzwerkumgebung nur einmal authentifizieren muss, auch wenn er auch unterschiedliche Netzwerkdienste zugreifen möchte. Vorausgesetzt die Dienste unterstützen Kerberos (GSS-API). Zum Abschluß zeigt der Vortrag auf, wie es auch für Windows-Clients möglich ist, den neu eingerichteten Kerberos-Server zur Authentifizierung zu nutzen. Allerdings ist hierfür ein weiterer Directory-Service, wie beispielsweise LDAP notwendig, da NIS rein UNIX-spezifisch ist. LDAP ist nicht Thema dieses Vortrages. Der Vortrag basiert auf einer Red Hat Enterprise Linux 3 Installation. Natürlich funktionieren die gezeigten Beispiele auf unter anderen Distributionen bzw. anderen Versionen.

Über den Autor:

Thorsten Scherf ist 29 Jahre alt und arbeitet als Trainer bei der GfN AG. Hier führt er Red Hat-Schulungen durch und nimmt die RHCT- sowie die RHCE-Prüfung ab. Thorsten ist seit 1994 dem Betriebssystem Linux verbunden, und schreibt u.a. für das Linux-Magazin im Bereich Netzwerk-Sicherheit.

NetBSD ist ein frei verfügbares Unix-ähnliches "Open Source"- Betriebssystem auf Grundlage der Codebasis der University of Berkeley. POSIX- und SUS- Kompatibilität wird weitgehend angestrebt. Im Unterschied zu Linux kommen Kernel und grundlegende Libraries und Programme einschliesslich X11 aus einer Hand. Die kompletten Kernel- Sourcen sowie große Teile der Userland- Quellen unterliegen der sogenannten BSD- Lizenz, und sind daher auch kommerziell ohne Probleme in Drittprodukten verwendbar.

NetBSD läuft auf 13 CPU-Familien mit 53 Rechnerplatformen ("ports") - Tendenz steigend. Es ist crosscompilierbar; ein zentrales "build.sh" - Skript automatisiert alle dazu nötigen Vorgänge, so dass z.B. wöchentlich mehrere automatisierte Builds aus dem Release- und dem Entwicklungszweig zur Verfügung stehen.

Modernes Networking (IPv6, PPPoE, ISDN, WLAN) stehen in integrierter Form ebenso zur Verfügung wie wichtige Sicherheitsfeatures (SSH und SSL, Cryptographische Pseudodisk, Non-Exec Stack, "Verified Exec", systrace). Das NetBSD-Software-RAID (basierend auf "RaidFrame") ist autokonfigurierend und damit auch für die Rootpartition nutzbar.

Auch auf der i386-CPU (wie schon auf Alpha, Vax, Sparc) ist im Entwicklerzweig Multiprozessorunterstützung vorhanden. Eine Implementierung von "Scheduler Activations" dient als Grundlage für eine N:M - Threading- Implementierung.

Vielen Plattformen haben die Fähigkeit, Systemaufrufe anderer Betriebssysteme der gleichen CPU auszuführen, so dass z.B. und SunOS4- und Solaris- Anwendungen auf NetBSD/SPARC und NetBSD/SPARC64 einsetzbar sind, die nicht im Sourcecode zur Verfügung stehen; ebenso Linux/i386- Anwendungen unter NetBSD/i386.

Mehr als 4000 externe Anwendungen sind einfach (aus Sourcen, zum Teil auch kompiliert bereitgestellt) installierbar. Dieses Paket ("pkgsrc") ist inzwischen u.a. auch für Darwin/Mac OS X, Irix, Linux, Solaris, Open- und FreeBSD verfügbar; AIX und BSDi sind in Arbeit. Ein neues Feature, "Pkgviews", erlaubt, mehrere Versionen des gleichen Pakets zu installieren - interessant zum Upgrade von Paketen, von denen viele andere abhängen, ohne die Verfügbarkeit zu unterbrechen.

Der Vortrag beleuchtet besonders die Neuentwicklungen im letzten Jahr für die anstehende Release 2.0.

Über den Autor:

Hubert Feyrer ist Mitarbeiter am NetBSD Projekt (Packages Collection und Tools, Dokumentation & Artikel, PR, etc.), Musikant, Unix-SysAdmin, perl- und C/C++-Programmierer, Nachtmensch, IPv6-interessierter Anhänger und Autor Freier Software, Dozent, sowie Comic-Fan.

Ignatios Souvatzis ist "Systemprogrammierer" (in Wirklichkeit eine Kombination eines Systemadministrators, eines Bandoperators, eines Kernelhackers und eines Benutzerberaters) in der Abteilung V des Instituts für Informatik der Universität Bonn. Er glaubt, den ersten WWW- Server an seiner Universität - jedenfalls aber in der Informatik - eingerichtet zu haben und weiß rückblickend nicht, ob er es nicht bedauern sollte.

Er ist außerdem ein NetBSD- Entwickler und war dort hauptsächlich für einige Gerätetreiber, das neue ARP-Subsystem und den Amiga-Port verantwortlich.

Er schrieb Beiträge über Unix-Anwendungen und -Administration für verschiedene Zeitschriften und ist Co-Autor je eines Buches über FreeBSD- und NetBSD- Systemadministration.

Unix lernte er in seinem zweiten Studienjahr in einer kleinen Softwarefirma auf einem Z8000- System kennen. Später kamen - neben diversen Nicht-Unizes - Ultrix auf DECstation 2100 bis 5000/260, ConvexOS auf Convex C1, AIX 2.2.1 (IBM RT), SunOS 4 und SunOS 5.x (Sparc) dazu.

Die meisten elektronischen Geräte werden heute mit einem Mikrochip ausgestattet. So hat heute nahezu jede Waschmaschine schon einen eingebetteten Chip integriert. In Zukunft ist zu erwarten, dass sich dieser Trend fortsetzt. Werden diese Geräte mit einer drahtlosen Kommunikationsmöglichkeit ausgestattet (z.B. Bluetooth), so könnten sie zusammen mit schon vorhandenen Computern in Form von Desktop PC's, Mobiltelefonen und elektronischen Organizern ein weit verzweigtes drahtloses Netzwerk aufspannen. Ein solches Netzwerk, das dezentral und selbstorganisierend ist, wird Ad-hoc Netzwerk genannt. Ein Ad-hoc Netzwerk, das aus leistungsschwachen Sensoren besteht, die ihre Umgebung abtasten (z.B. Licht- oder Temperatursensoren), nennt man auch Sensor Netzwerk. Ad-hoc Netze sind insbesondere sinnvoll in Szenarien, wo keine feste Infrastruktur besteht, oder wo diese zu teuer ist. In solchen Netzwerken ist jeder Knoten auf seine Nachbarknoten angewiesen. Er bietet diesen seine Dienste an und nutzt genauso deren Dienste, z.B. bei dem Senden und der Weiterleitung von Datenpaketen. Ad-hoc Netze finden Anwendung in militärischen Szenarien, für die sie ursprünglich entwickelt wurden, aber auch in zivilen Szenarien. Beispiele für Ad-hoc Netzwerke sind:

1. Notfallsituationen, in denen die Kommunikation ausgefallen ist;
2. Erweiterung traditioneller Netzwerke, um Kosten zu sparen; und
3. Errichtung temporärer Netzwerke für ein Gruppentreffen.

Sicherheit in Ad-hoc Netzen muss genauso betrachtet werden wie in traditionellen Netzwerken. Die Herangehensweise ist jedoch unterschiedlich. So sind die Geräte, die in Ad-hoc Netzen genutzt werden, weniger leistungsstark, und in vielen Szenarien gibt es keine zentralen Server, also keine zuverlässige Infrastruktur. Sicherheit wird jedoch in den meisten Fällen benötigt, angefangen vom zuverlässigen Routing über den geschützten Austausch von Dateien bis hin zu finanziellen Transaktionen, die mit Hilfe der Geräte (z.B. Handy) abgewickelt werden. Der Ausgangspunkt von Sicherheit ist die Authentikation. Nur wenn man weiss, mit wem man spricht, kann man über Verschlüsselung und Integritätssicherung sprechen.

In dieser Arbeit zeigen wir diverse Ansätze zur Authentikation in Ad-hoc Netzen. Wir erläutern generelle Probleme, und gehen auf heute eingesetzte Verfahren ein, z.B. bei Bluetooth. Daraufhin geben wir einen Überblick über die Effizienz kryptographischer Primitive. Während auf einem Desktop PC die eingesetzte Kryptographie bezüglich Rechenintensität inzwischen nahezu irrelevant ist, ist die Lage bei eingebetteten Systemen, wie sie in Ad-hoc Netzen genutzt werden, anders. Hier ist es wünschenswert, größtenteils symmetrische Primitive einzusetzen, die um etwa um einen Faktor 1000 schneller sind als asymmetrische kryptographische Primitive. Schließlich geben wir einen Überblick über eigene Forschungsergebnisse. Wir stellen einen neuen Ansatz zur Authentikation vor, der extrem effizient ist und auch für leistungsschwache 4-Bit CPU's (z.B. Sensoren) geeignet ist. Dabei geht es darum, dass die Geräte in der Lage sind, andere Geräte (genauer gesagt Dienstanbieter) wiederzuerkennen. Wir erweitern diesen Ansatz so, dass er auch die Identifikation zweier Geräte bei moderater Rechenleistung sicherstellen kann, also immer noch weit effizienter als ein traditioneller Ansatz mit Public-Key Methoden ist. Diese Effizienz wird allerdings mit der Anforderung an eine grobe Zeitsynchronisierung erkauft.

Über den Autor:

André Weimerskirch erhielt seinen Master Abschluss in Informatik am Worcester Polytechnic Institute, USA. Er ist derzeit ein Doktorand bei Prof. Paar an der Ruhr-Universität Bochum und arbeitet seit 1999 im Bereich der Kryptographie. André Weimerskirch hat weit reichende Kenntnis in effizienter Arithmetik für kryptographische Verfahren, Sicherheit in Netzwerken mit leistungsschwachen Prozessoren, sowie kryptographischen Protokollen. Er hat mehrere Monate an verschiedenen renommierten Forschungsstätten wie Sun Labs (USA), Philips Research (USA), Accenture Technology Labs (Frankreich), und Aarhus University (Dänemark) verbracht. Er hält insgesamt drei Patente im Bereich Kopierschutz und Zufallszahlengenerator, und hat mehr als 10 internationale Artikel publiziert.

Die unter der Führung von Compaq, HP, IBM, Intel und Microsoft gegründete TCPA (Trusted Computing Platform Alliance) startete 1999 mit dem Ziel, die System- und Applikationssicherheit mittels geeigneter Kryptohardware, den so genannten TPMs (Trusted Platform Modules), zu verbessern. Seit April 2003 hat die TCG (Trusted Computing Group) die Rechtsnachfolge der TCPA übernommen. Auf die von der TCPA veröffentlichte Spezifikation erfolgte kaum eine Reaktion. Erst als Microsoft mit Palladium eine Erweiterung ihres Betriebssystems ankündigte und versprach, dass die größten Sorgen der Vergangenheit wie Viren, Würmer, Spam-Mails und ständige Sicherheits-Patches damit keine Chance mehr hätten, begann eine heftige öffentliche Diskussion. Besonders wurde Microsoft zum Vorwurf gemacht, mit ihrem Sicherheitskonzept, das seit kurzem NGSCB (Next Generation Secure Compution Base) heißt, und fest in das für 2005 geplante Windows mit Codenamen Longhorn integriert werden soll, als primäres Ziel die Verankerung der digitalen Rechteverwaltung voranzutreiben. Kritiker befürchten, dass die als Sicherheitsfeatures verkauften Lösungen eigentlich dazu dienen sollen den Benutzer an die virtuelle Kette zu legen und DRM (Digital Rights Management) flächendeckend durchzusetzen. Um die Lage realistisch bewerten zu können, ist es notwendig die Möglichkeiten der eingesetzten Hardware und Betriebssysteme genauer zu beleuchten und deren Zusammenspiel zu analysieren.

Die aktuellen Spezifikationen der TCPA erweitern einen Rechner um die folgenden Funktionen:

• Sealing (Versiegelung)
• Sicheres Abspeichern kryptographischer Schlüssel
• Sicherer Timer
• Sicherer Zufallszahlengenerator
• Authentifikation des Systems

IBM liefert schon seit geraumer Zeit Notebooks und Desktops mit TPM aus, HP hat inzwischen ebenfalls begonnen analoge Systeme anzubieten. Nach dem Willen der Industrie soll TCPA nicht nur in Computern, sondern auch zum Beispiel in Video- und Audiogeräten sowie Handys Einzug halten. Bisher wird immer noch betont, dass die Benutzung von TCPA optional sei. Wie "freiwillig" dies bei künftigen Betriebssystemen und Software abläuft, bleibt abzuwarten.

Der Vortrag beleuchtet neben der Historie und den Grundlagen die Hardware des TPM. Anhand des von IBM veroeffentlichten Linux-Experimentalpaketes wird gezeigt, welche Features heute schon unter Linux nutzbar sind.

Über den Autor:

Teil 1

War driving ist derzeit ein beliebter Zeitvertreib und führt auch meist schnell zum Erfolg. Bei einem WLAN-Audit für einen unserer Kunden in einem Industriegebiet wurden auf einer Wegstrecke von ca. 4km über 80 Accesspoints gefunden, ein grosser Teil davon sogar ohne WEP oder andere Sicherheitsmechanismen (soweit wir's gesehen haben, genauer hingeguckt haben wir nur bei unserem Kunden :-)

Derartige Angriffe lassen sich mit den normalen Systemtools oft nicht leicht entdecken. Inzwischen kann man aber mit einigen Tools und ein paar Patches (z.B. kismet) spezielle Sensoren aufbauen, mit denen eine Reihe von Layer-2 Angriffen auf eine WLAN-Infrastruktur erkannt werden kann. Werden derartige Sensoren mit klassischen IDS-Systemen gekoppelt, können auch in Funknetzen Angriffsversuche erkannt werden.

Teil 2

Nur in (mehr oder weniger) trivialen Fällen ist eine Überachung mit Einzelsensoren ausreichend, sobald z.B. verschiedene Netzsegmente oder (bei WLAN) größere Flächen überwacht werden sollen, die über eine Funkzelle hinausgehen, müssen mehrere Sensoren mit einem zentralen Analysesystem eingesetzt werden.

Logging in eine Datenbank ist aber bei Standard-SNORT eine sehr aufwändige Operation (über 10 INSERTs bzw. UPDATEs), während der keine weiteren Pakete analysiert werden können. Um das zu optimieren, wurde von Dirk Geschke ein Open-Source Tool FLoP (Fast Logging of Packets) freigegeben, das die Sensoren von den Datenbankoperationen entlastet und somit die Verluste minimiert.

Abschluss

Kurz soll noch das (igitt kommerzielle) Produkt GeNUDetect erwähnt werden, das die vorgestellten Mechanismen benutzt, um Angriffe sowohl auf LAN als auch WLAN erkennen und analysieren zu können

Über den Autor:

Bernhard Schneck (Dipl-Phys)

ist seit der Gründung vor 12 Jahren technischer Geschäftsführer und Mitgesellschafter der GeNUA Gesellschaft für Netzwerk- und UNIX-Adminstration mbH, Kirchheim (bei München). Die Hauptarbeitsgebiete sind Entwicklung von komplexen Internet Sicherheitslösungen sowie die Unterstützung bei der Migration zu und beim Betrieb von UNIX- und Linux-Systemen.

LDAP unter Unix, das heißt in den allermeisten Fällen: OpenLDAP. Mit OpenLDAP haben viele Admins allerdings negative Assoziationen: haarige Installation, unklare Schema, langsame ACLs, ein LDAP-Server verbraucht schon mal 100.000 offene Deskriptoren, u.v.m.

Aus der persönlichen Einschätzung des Autors, es bei OpenLDAP mit dem Sendmail bzw. BIND 4 unter den LDAP-Servern zu tun zu haben, entstand die Idee, vielleicht "mal schnell" selbst einen LDAP-Server zu programmieren. Dieser Talk soll in die Problematik einführen und über die Erfahrungen berichten.

Über den Autor:

Felix ist Geschäftsführer der Unix- und IP-Consulting-Firma Code Blau, würde sich selbst aber eher als Hacker bezeichnen und verbringt seine Zeit seit einigen Jahren damit, inspiriert von qmail typische Unix-Probleme möglichst klein und effizient zu lösen. Sein bekanntestes Projekt ist die diet libc, eine besonders kleine libc für Linux.

Wireless LANs haben mittlerweile in fast jedes Netzwerk Einzug gehalten. Nicht nur in Büros, in öffentlichen Einrichtungen und in Hotels, sondern durch eine Grossoffensive auch immer weiter im privaten Haushalt. Die Netze werden intesiv genutzt und neuwertige mobile Endgeraete wie Notebooks oder PDAs werden nun meist serienmaessig mit integriertem WLAN-Support ausgestattet. Die Verbreitung nimmt stetig zu und es hat sich mit neuen, schnelleren Standards und proprietaeren Erweiterungen von bis zu 108Mbps viel in der Entwicklung getan.

Doch wie sieht es mit der Sicherheit aus? Die Probleme sind bekannt, fast jedes bekannte Computermagazin, diverse Tageszeitungen bis hin zur TV-Boulevardsendung haben bereits darüber berichtet - das Funkmedium ist unsicher und die integrierte Verschlüsselung WEP ist leicht zu knacken. Der erste Teil des Vortrags gibt einen Überblick über die bekannten und weniger bekannten Probleme der WLANs nach IEEE 802.11 und die Bemühungen von Industrie und IEEE, diese zu beseitigen. Von WEPplus, WPA bis hin zur WPA und 802.11i gibt es diverse weitere Lösungen, die es zu durchleuchten gilt. Ein anderer Ansatz zur Absicherung von WLANs sind VPN-Technologien, bei denen höhere Protokollebenen verschlüsselt werden und die Unsicherheit des Link Layers in Kauf genommen wird.

Das Wireless LAN Security Framework ist ein Open Source Projekt, dass sich mit den Problemen der aktuellen WLAN Standards beschäftigt. Ziel des Projekts ist einerseits die Analyse und der demonstrative Angriff von Protokollschwächen und andererseits die Entwicklung von eigenen,alternativen Sicherheitsverfahren. So bietet das WLSec Projekt ein komplettes Authentifizierungs- und Verschlüsselungsverfahren, dass die Stärken von IPSec und Link Layer-Verschlüsselung vereint. Starke Kryptographie, sichere Authentifikation und Authentizität auf per-Paket Basis mit bewährten, anerkannten Verfahren geben dem WLSec-Ansatz einen entscheidenen Vorteil zu anderen, aktuellen WLAN-Sicherheitsmechanismen. Das Projekt soll im zweiten Teil des Vortrags anschaulich dargestellt und insgesamt mit anderen Sicherheitslösungen verglichen werden.

Über den Autor:

Reyk Flöter, geboren am 25.05.1980, ist Mitbegründer des IT-Security-Unternehmens .vantronix | secure systems und Verantwortlicher für den Bereich Research & Development. Er begann seine IT-Laufbahn in der Deutschen Post AG und wechselte später zur Deutschen Telekom AG. Er arbeitete in den Bereichen IT-Service, Administration und später in der T-Systems Nova im Entwicklungsbreich für UNIX-Systeme. Dort setzte er sich vor allem für den Einsatz von Open Source Software ein und richtete ein besonderes Augenmerk auf die Sicherheit der Netzwerke. Neben seiner beruflichen Tätigkeit engagierte er sich in fachbezogenen Projekten. Er ist unter anderem Vorsitzender des Chaos Computer Club Erfrakreises Hannover, trägt mit vielen Projekten und Patches zur Open Source Community bei und ist Mitbegründer des WaveHAN-Projekts zum Aufbau eines Bürgernetzes auf Basis von Wireless LAN. Derzeit engagiert er sich neben seiner Tätigkeit für .vantronix | secure systems weiterhin aktiv für das WaveHAN-Projekt, ausserdem ist er Maintainer des WLSec Projekts zur Entwicklung eines sicheren, alternativen WLAN-Securityframeworks.

Das Linux-Router Project ist tot, was kommt nun, mit Open-Router TNG wird ein plattformunabhäniges Build-System sowie eine modulare erweiterkeit von Funktionen und Features auf einem Free-Software-projekt welche einen kompletten ISP-/Mittelklasse-Router mit GNU/Linux und Boardmitteln nachbilden kann. Besonders zu Erwähnen sind die erweiterten Kontrolle- und Beobachtungsfunktionen.

Der Vortrag wird sehr Praxisnah mit vielen Beispielen und "proof-of concept code" vorgestellt, das projekt will aber noch KEIN FERTIGES PRODUKTIONSSYSTEM vorstellen sondern Konzepte von dem was kommen wird. Es wird gezeigt wie auf der ORP-Plattform andere Projekte aus dem Bereich PBX, Home-Automatisation oder Audit-Systeme sich als Turn-Key Lösungen aufbauen lassen.

Über den Autor:

arbeitet als Consultant bei der DN Systems GmbH in Hildesheim und ist in diverse freie Softwareprojekte involviert.

• Rollen und Abläufe bei der Ermittlung
• Ansatzpunkte für die Ermittlung
• Was müssen Administratoren bei der forensischen Untersuchung beachten?
• Umgang mit Beweismitteln
• Häufige Fehler

Über den Autor:

Alexander Geschonneck ist leitender Sicherheitsberater bei der HiSolutions AG in Berlin. Seit 1993 ist er branchenübergreifend im strategischen und operativen IT-Sicherheitsumfeld tätig. Er ist Autor des im Februar 2004 erscheinenden Buches "Computer-Forensik. Systemeinbrüche erkennen, ermitteln, aufklären" (dpunkt.verlag), Mitautor des IT-Grundschutzhandbuches des Bundesamtes für Sicherheit in der Informationstechnik und schreibt für die "iX" sowie andere Fachzeitschriften. Seine Arbeitsgebiete sind u.a. Beratung im Umfeld der Informationssicherheit, Aufbau und Coaching von IT-Sicherheitsmanagementteams, Risiko- und Sicherheitsanalysen, Notfallplanung, Penetrationstests sowie Sicherheitsvorfallsbehandlung.