Vor drei Tagen hat Apple seine neueste Kreation vorgestellt, und unsere Befürchtungen in Hinblick auf dieses Gerät scheinen sich zu bestätigen. Doch beginnen wir mit dem Positiven.

Was wir an Apple schätzen

Ende 2008 sind wir auf Apple umgestiegen, nachdem wir seit Mitte der 1990er beginnend mit Windows 3.11 die gesamte Microsoft-Historie auf firmengegebenen portablen Siemens- und Fujitsu-Siemens-Computern hinter uns gebracht haben. Zuvor in der Unix-Welt zuhause, haben wir Windows über lange Zeit als Zumutung empfunden und waren schließlich mit Windows 2000 recht zufrieden. Wir haben uns angewöhnt, eine Windows-Linie erst dann selbst einzusetzen, wenn Microsoft bereits die nächste in den Markt entläßt, stagnieren also noch bei Windows XP und Server 2003.

Microsoft Windows ist nicht der einzige und vielleicht nicht einmal der Hauptgrund, sich für Apple-Produkte zu interessieren. Wer eine Abneigung gegen die Berührung von Plastikgegenständen hegt, sollte ernsthaft über den Kauf des wunderbaren Stücks Hardware eines Macbook nachdenken. Nach einem Jahr Verwendung knarrt oder klappert noch nichts, der aufgeklappte Monitor bleibt in seiner Position und wackelt nicht und die Lüfter sind im Normalbetrieb unhörbar wie am ersten Tag. Es ist bezeichnend, daß für den Benutzer dieser Hardware die reflektierende Oberfläche des Bildschirms zu den größten Ärgernissen zu zählen scheint. Dagegen ist das Trackpad wiederum der beste bislang bekannte Mausersatz.

Was am Betriebssystem Vertrauen erweckt, zumindest unseres, ist der grundsolide Unix-Kern (das von BSD Unix abstammende Darwin). Der Vorteil des Unix-Kerns ist nicht nur das Vorhandensein einer Kommandozeile mit einer echten Shell, die im Bedarfsfall Zugriff auf Systemfunktionen und echte Skripte erlaubt. Mac OS ist der erste massenmarkttaugliche Versuch, ein Unix-Betriebssystem mit einer graphischen Oberfläche zu versehen. Um diese Leichtigkeit kämpft Linux noch immer, Ubuntu mittlerweile an der vordersten Front, aber nach wie vor unbefriedigend.

Die Mac-Legende, nämlich daß sich das Gerät dadurch auszeichnet, daß alles eben einfach funktioniert, ist eine Realität. Wer seine Zeit nicht mit Basteleien vertun will, sondern mit dem Computer einfach arbeiten oder kommunizieren oder sich die Zeit vertreiben will, ist bei diesem Betriebssystem richtig aufgehoben. Da stimmen die Software-Entwicklungsprozesse offenbar schon etwas länger als im Hause Microsoft, das anscheinend erst nach der Vista-Katastrophe geschafft hat, das Steuer herumzureißen. Da das Postulat des Funktionierens aber nicht nur für die Apple-Software gilt, sondern nach unserer Erfahrung auch für die meisten Fremdanwendungen, kann dies nicht nur auf einem kulturellen Faktor beruhen, sondern muß seine Ursachen in der Software-Systemarchitektur haben.

Es geht natürlich nicht ohne Windows, und das soll es ja auch nicht. Aus Kompatibilitätsgründen sollte man unbedingt weiter die Office-Anwendungen von Microsoft auf Windows-Basis benutzen, also in einer virtuellen Maschine.

... und was nicht

Sprechen wir nach so viel lobenden Worten, die man uns hoffentlich nicht als Schwärmerei ankreidet, von der Kehrseite der Apple-Philosophie. Wir wollen sie nicht die häßliche Kehrseite nennen, weil gerade (Januar 2010) auf dem neuesten Produkt die Hoffnungen einer ganzen Branche oder gar mehrerer Branchen ruhen und wir dies sehr ernst nehmen. Es sind die Hoffnungen derer, die von der Vermarktung von Inhalten (Nachrichten, Literatur, Wissen) leben und mittlerweile heftig unter der Kostenlos-Kultur des Internet unserer Jahre leiden, die in einen bedrohlichen Qualitätsverlust umzuschlagen droht. Verlage dürfen hoffen, daß mit der gerade neugestifteten Mode des iPad auch eine neue Akzeptanz bezahlter (wertvoller) Inhalte aufkommt.

So sehr wir also einen kulturellen Umschwung erhoffen, der dringend fällig ist, so unzufrieden sind wir mit der Bevormundung durch das populärste Produkt des vergangenen Jahres: das iPhone. Wir haben es ausprobiert und nach ein paar Tagen wieder verkauft.

Natürlich könnten wir uns an ein zigarettenschachtelgroßes Display gewöhnen, auf dem man mit den Fingern herumtippen und -wischen muß und das darum immer etwas verschmiert ist. Das man immer sperren muß, bevor man das Gerät in eine Hemd- oder Anzugtasche gleiten läßt. Dieser Art der Bedienung gehört die Zukunft und die nächste Generation von Bildschirmen zum Anfassen ist, wie wir sehen, wenigstens schon schreibheftgroß.

Was uns am iPhone nachhaltig verärgert hat, ist, daß es kastriert wurde, um uns zum Teil fremder Geschäftsmodelle zu machen. Ein Telephon, das für die Verwendung als Modem am Laptop gezielt unbrauchbar gemacht wurde, lehnen wir ab. Und man stelle sich vor, Microsoft brächte ein Gerät heraus, das nur von Microsoft zensierte und signierte Applikationen erlaubt! Apple darf das (noch) - aber nicht mit uns. Und Digital Rights Management (DRM)? Doch bitte keine weitere Gängelung bei Inhalten, für die wir bezahlt haben.

Während wir bei Verwendung eines Universalbetriebssystems (wie Windows oder Mac OS) auf einer hinreichend zugänglichen Hardware die Wahl haben, welchen Netzbetreibern, Anwendungsherstellern und Inhaltelieferanten wir uns sonst zuwenden, wir also in den uns zustehenden Genuß eines freien Marktes kommen, müßten wir uns bei Verwendung eines iPhones dem Diktat des Herstellers beugen. Das wollen wir aber nicht tun. Uns ist freilich bekannt, daß man ein iPhone hacken kann, wie man es "jail-breakt" und so weiter. Da wir an solchen Basteleien aber mittlerweile keine besondere Freude mehr haben und aus dem Besitz eines geknackten iPhones keine Genugtuung schöpfen können, bleiben wir bis auf bessere Zeiten beim Nokia mit voller Tastatur und Symbian-Betriebssystem.

Es ist abzusehen, daß das iPad ebenfalls ein geschlossenes System sein wird. Damit erhält es von uns erst einmal seinen gebührenden Mißtrauensvorschuß. Wir trösten uns damit, daß sich in diesem Marktsegment bald sehr viele Anbieter tummeln werden und Microsoft bei der Kreation neuer Geschäftsmodelle einiges verpaßt hat, also Betriebssystemhersteller geblieben ist. Vielleicht wird unter den vielen kleinen, praktischen Geräten auch mal so ein schönes Stück Hardware sein, das aber unter Windows 7 läuft, normale PDFs anzeigt, normale MP3s, MP4s und Adobe Flash abspielt und seine Inhalte überall beziehen kann.

Wir sind gespannt, wie sich die Medienbranche jetzt umstellt. Wir beziehen unsere FAZ schon seit Jahren täglich online im PDF-Format, bezahlen dafür, wie es sich gehört, und hoffen, daß es bei diesem Arrangement bleiben kann.

Von Thomas Bez, TEDESCA Unternehmensberatung www.tedesca.com, Januar 2010.

Einleitung

Auch wenn man in der Praxis eines Service Management Projektes (zum Beispiel die Restrukturierung eines Servicebereiches, die Entwicklung von SLA und dem Aufbau eines Service Level Management, einem Service Outsourcing etc.) selten nach ausschließlich einer "reinen Lehre" vorgeht, ist die Orientierung an einer Methodik bzw. einem Referenzmodell (Framework) unbedingt erforderlich. Solche Referenzmodelle beginnen ihre Entwicklung in einem bestimmten Industriesektor bzw. einer Branche, entwickeln sich im Laufe der Jahre über mehrere Releases weiter, sofern sie erfolgreich sind und nicht wieder aussterben. Ein aussterbendes oder ausgestorbenes Referenzmodell in der Telekommunikation ist den älteren Semestern noch unter dem Namen "FCAPS" erinnerlich, einem inoffiziellen Akronym, das das ziemlich simple Prozeßmodell aus dem ITU-T Standard M.3400 mit seinen fünf Funktionsbereichen meint.

Viele dieser Referenzmodelle zeigen die Tendenz, im Laufe ihrer Entwicklung universeller zu werden und zumindest den Anschein zu erwecken, daß ihre Konzepte über den Industriesektor hinausreichen, für den sie ursprünglich geschaffen wurden. Wir selbst sind mit zwei dieser Frameworks ganz besonders vertraut:

• ITIL (IT Infrastructure Library), einer Sammlung von "Best Practices" oder neuerdings etwas bescheidener "Good Practices" aus dem IT Service Management, ohne die im IT-Servicebereich nichts mehr geht,
• eTOM (Enhanced Telecommunications Operations Map) des TeleManagement Forum, das sich immer stärker als de-facto Standard für die Gestaltung der Geschäftsprozesse in der Telekommunikationsindustrie durchsetzt.

Wir wollen aufzeigen, (A) daß ITIL tatsächlich den Ansatz zeigt, universell für das Service Management auch jenseits der IT zu werden, und (B) inwieweit dies speziell für die Telekommunikation gilt durch eine Anwendung parallel zu den Standards des TeleManagement Forum.

Anwendbarkeit des ITIL Lebenszyklus

Wenn wir für die einzelnen Prozesse der fünf Lebenszyklusphasen ermitteln (oder abschätzen), wie stark sie in Spezifiken der IT verhaftet sind, differenzieren wir einerseits nach der Methodik, die ITIL entwickelt (z.B. Prozeßsteuerung, Rollen, RACI-Matrizen), und andererseits den konkreten Objekten (z.B. KPI, Assettypen, Ressourcen, Fähigkeiten) mit denen ITIL operiert. Die konkreten Objekte sind naturgemäß stärker IT- oder branchenspezifisch. Da ITIL selbst auch keinen Versuch unternimmt, diese Objekte zu standardisieren, sondern ausdrücklich ein Good Practice Framework ist, bleibt die Bandbreite der Anwendbarkeit von ITIL-Methodik hoch. Wo der Prozeß andererseits stark von den behandelten Objekten abhängt, ordnen wir den Prozeß insgesamt dem "eher IT-spezifischen" Bereich zu. Einleuchtende Beispiele dafür sind Capacity Management oder Access Management.

Sieht man sich das Prozeßtemplate der ITIL an, das sich in die Bereiche Process Control, den eigentlichen Prozeß sowie Process Enablers aufspaltet, so kann man feststellen, daß Branchenspezifika vor allem den Bereich der Enabler (insbesondere Ressourcen und Fähigkeiten = Capabilities) betreffen.

KPI sind nicht notwendigerweise IT- bzw. branchenspezifisch. Je nach ihrer Position im Kennzahlsystem und insbesondere, wenn es sich um aggregierte Verhältniszahlen handelt, was häufig der Fall ist, können KPI-Schemata auch aus anderen Industriesektoren "kopiert" werden - ganz im Sinne der Nutzung einer "Good Practice". Eine prozentuale Verringerung der Wiederherstellzeit (MTRS) im Berichtszeitraum (ein Beispiel aus dem Availability Management) läßt sich für beliebige Services ermitteln.

Wir haben selbst in einem einige Jahre zurückliegenden Projekt "Mobile Virtual Network Enabler" (MVNE) die IT-fremde Anwendung der ITIL-Methodik (seinerzeit auf Basis v2) selbst versucht und waren mit dem Ergebnis zufrieden. Das Projekt verlangte die Koordination mit mehreren externen und internen Dienstleistern (Typen 2 und 3 nach ITIL Terminologie). Betroffen waren die Prozesse

• Event/Incident/Problem Management,
• Change Management/Request Fulfillment,
• Service Level Management.

Insbesondere die gemeinsame, abgestimmte Definition der Betriebsprozesse und -prozeduren, das Aufsetzen des SLA-/OLA-Management sowie die Definition des Service Desk wurden durch die gewählte Vorgehensweise erleichtert.

Verbesserungen mit ITIL v3

Version 3 von ITIL hat sich zum Ziel gesetzt, die IT an den jeweiligen Geschäftsprozessen auszurichten, denen sie dienen soll, und die IT stärker an die Unternehmensziele zu binden. Daher liegen die auffälligsten Neuzugänge in ITIL Version 3 in den Bereichen Service Strategy, Continual Service Improvement (diese beiden Lebenszykluselemente sind komplett neu) und Service Operation. Service Strategy und Continual Service Improvement sind allerdings in den ITIL-Büchern noch in einer Weise beschrieben, die die Verallgemeinerung auf andere Kategorien von Services nicht behindern kann. Die Bedeutung von ITIL v3 sehen wir darin, daß die Beziehung der IT zum Kerngeschäft des Unternehmens und die Rolle der IT als dienender Technologie herausgearbeitet wurde. Das ist eine Sichtweise, die es auch für andere Services aufzugreifen lohnt.

Es sollte eigentlich überraschen, daß gerade Service Operation, das man als den ursprünglichen Kern von ITIL betrachten kann (da dort die vom Kunden wahrgenommene Wertschöpfung stattfindet), mit ITIL Version 3 eine starke Erweiterung erfahren hat. Immerhin kamen dazu:

• Event Management
• Request Fulfillment
• Access Management

Allerdings sind gerade das die Prozesse, die wir selbst in ITIL Version 2 am stärksten vermißt haben. Im schon erwähnten Beispielprojekt MVNE haben wir das Event Management als Teil des Incident Management eingeordnet und das Request Fulfillment auf das Change Management abgebildet - wo beide Prozesse jeweils nicht besonders gut hinpassen. Besonders für jemanden, der aus der Telekommunikationswelt kommt, ist das ITIL-Framework ohne diese Erweiterungen schlichtweg unvollständig.

Wir haben hier Event Management als generisch eingeordnet. Zwar sind die Events und die Tools (z.B. Monitoringsysteme) branchenspezifisch, der Prozeß selbst ist aber relativ simpel und allgemeingültig. Ähnlich steht es um das Request Fulfillment. Es fällt auf, daß ITIL mit Version 3 gerade in den stärker generischen Prozessen seine Erweiterungen erfahren hat. Das belegt unsere eingangs geäußerte These vom zunehmenden Allgemeinheitsgrad von Referenzmodellen im Lauf ihrer Evolution.

Das Request Fulfillment nimmt im ITIL Buch über Service Operation nur einen schmalen Raum ein. Da das Request Fulfillment die Standard Changes beinhaltet, kann in anderen Branchen die bedeutung des Prozesses deutlich größer sein. Augenfällig wird das für die Telekommunikation, wenn man die Level 2 und 3 der eTOM-Definition der Fulfillment-Prozeßkette betrachtet. Fast alle diese Teilprozesse, die sich bis in Logistik und Field Provisioning erstrecken (man denke an die Bereitstellung eines DSL-Anschlusses), fallen nach ITIL-Termini unter Request Fulfillment. Daß ITIL in diesem Bereich aber noch immer von anderen Voraussetzungen ausgeht, kann man daran erkennen, daß der Service Desk als zentrale Stelle der Abarbeitung von Service Requests gesehen wird.

Der Service Desk, obwohl kein Prozeß, sondern eine Funktion, ist im Bild mit gezeigt. Als Single Point of Contact für den Kunden wird ein Service Desk zwar im Prinzip immer gebraucht, seine Ausgestaltung in ITIL scheint uns aber nicht ohne weiteres verallgemeinerungsfähig. Ebenfalls eine Sonderrolle spielen die Common Service Operation Activities, manchmal auch "Daily Operations" genannt. Als unstrukturierte Sammlung von Aufgaben werden sie selbst von ITIL stiefmütterlich behandelt. Man kann das vielleicht so erklären, daß diese Tätigkeiten (wie z.B. regelmäßig Backups ziehen) nicht auf explizite Service Requests zurückgehen und in der IT meist aus einer Hand, also ohne zusätzliche Prozeß- oder Providerschnittstellen, erbracht werden. Jedenfalls entziehen sich die Common Service Operation Activities, so wie sie in ITIL beschrieben sind, jeder sinnvollen Verallgemeinerung. Man führe sich vor Augen, daß solch aufwendige Prozesse wie Preventive Maintenance darunter fallen.

Bezüglich Continual Service Improvement, insbesondere der Governance, ist zu beachten, daß für die Bewertung der real existierenden Prozesse hinsichtlich Compliance und Reifegrad eine Reihe von Standards existiert, die in Teilbereichen auch konkurrieren. Zu nennen wären neben dem ITIL-eigenen Process Maturity Model (PMM), das auf CMM basiert, noch COBIT und das sehr neue "CMMI for Services". Weitere separate Standards existieren zum IT Security Management (ISO 27001) und zum Business Continuity Management (BS 25999).

In den hier aufgezeigten Grenzen halten wir die Methodik von ITIL auch für Services anwendbar, die ihrer Natur nach keine IT-Services sind. Das folgende Bild soll Beispiele solcher Services verdeutlichen.

Die Frameworks des TMF

Das TeleManagement Forum (TMF) ist keine klassische Standardisierungsorganisation wie zum Beispiel die ITU-T, sondern ein unabhängiges Industriekonsortium von Telco-Netzbetreibern, -Herstellern und Dienstleistern. Das ist vermutlich sein größter Vorzug, da dies die Schwerfälligkeiten der klassischen Telco-Standardisierung überwunden hat.

Dieser Kurzüberblick ist keine Einführung in eTOM; TMF selbst bietet für diesen Zweck ein Primer-Dokument an. Wir haben die Ehre, selbst Mitglied des TMF zu sein, und beraten gern zu Inhalten und Anwendung der Standards.

Das TMF hat eine Reihe von aufeinander aufbauenden Frameworks und Entwicklungs- bzw. Marketingaktivitäten auf den Weg gebracht, die zusammen dem einen Ziel dienen, das schon im Namen der Organisation festgeschrieben ist: dem Management von Telekommunikationsnetzen. Diese Frameworks sind:

• NGOSS (Next Generation Operations Support and Software) setzt sich zur Aufgabe, TK-Serviceprovidern interoperable Lösungen zum Management ihrer Services und Netze an die Hand zu geben
• eTOM (Enhanced Telecommunications Operations Map) ist das Prozeßmodell hinter allen Aktivitäten des TMF, das eine sehr TK-spezifische Sicht auf die Geschäftsprozesse eines Betreibers zeichnet
• TAM (Telecom Applications Map), eine nicht bindende Übersicht über Applikationen bzw. Applikationsfunktionen von OSS, die für die Erfüllung der eTOM-Prozesse erforderlich sind
• SID (Shared Information/Data Model), ein Fundus objektorientierter Informationsmodelle, die die Schnittstellen zwischen OSS oder Applikationen (im Sinne der TAM) beschreiben
• eine Reihe weiterer Aktivitäten, zum Beispiel Technologie- und Showcase-Programme, die die Interoperabilität von OSS-Lösungen praxisnah demonstrieren sollen, sowie Zertifizierung von OSS-Lösungen auf Konformität zu den TMF-Standards

Der Funktionsbereich "Strategy, Infrastructure & Product" wurde mit eTOM Release 3 in den frühen 2000er Jahren eingeführt. Somit verfügte die Telekommunikationsindustrie schon relativ früh über ein Referenzmodell, das alle wesentlichen Geschäftsprozesse abdeckt. Die Enterprise Services liegen eindeutig nicht im Fokus des TMF. Sie sind dem Referenzmodell offenbar der Vollständigkeit halber hinzugefügt, ermangeln aber einer detaillierteren Beschreibung.

Die Zuordnung der einzelnen Prozesse bzw. Lebenszykluselemente, die unser Bild zeigt, ist nur eine grobe Annäherung.

Das NGOSS-Programm läßt sich am besten anhand der historischen Entwicklung der Hersteller-Netzbetreiber-Beziehungen verstehen. Die Telekommunikationswelt ist geprägt von proprietären Lösungen, sozusagen Firmen-"Standards" der Hersteller, die zwar auf der Netzebene weitgehend interoperabel sind, nicht jedoch in ihrem Management. Netzbetreiber haben ihre eigenen Operations und Business Support Umgebungen entwickelt und über viele Jahre weiterentwickelt.

Aus Wettbewerbs- und wirtschaftlichen Gründen drängen TK-Netzbetreiber seit langem auf standardisierte Schnittstellen im Netzmanagement und auf mehr Flexibilität bei der Beschaffung von Operations Support Systemen auf der Basis von Standards und existierenden Systemlösungen (Commercial off-the-shelf Software, COTS).

Die mittlerweile zahlreich gewordenen unabhängigen Hersteller von (IT-basierten) Operations Support Systemen benutzen das TMF, um ihre Lösungen zu positionieren und zu propagieren. So hört man über das TMF manchmal die aus der Sicht dieser Hersteller formulierte Aussage "It is a big marketing engine." Andererseits ist uns die Einschätzung eines Managers der British Telecom in Erinnerung, der meinte "TMF is the only serious player in town."

Harmonisierung von TK- und IT-Standards

Die Telekommunikationswelt hat Gründe, sich um eine Harmonisierung ihrer Standards mit denen der IT-Welt zu bemühen, da die IT aus ihrer reinen Supportrolle (z.B. die Informationsinfrastruktur für den Netz- und Servicebetrieb oder die benötigten OSS-Applikationen bereitzustellen) herausgewachsen ist. IT wird zunehmend Teil des Telekommunikationsprodukts. Andererseits nimmt der Grad des Outsourcing von Betriebsfunktionen zu, die häufig von nicht TK-spezialisierten Providern übernommen werden.

Versuche, die Prozeßmodelle von TMF und ITIL über die gesamte Service-Wertschöpfungskette oder auch nur für die operativen Prozesse zur Deckung zu bringen, müssen aber scheitern. Es ist vielleicht möglich, aber nicht angemessen, die "Services", von denen eTOM spricht (Services, die als TK- oder Content-Produkte durch einen TK-Provider vermarktet werden), mit den Services von ITIL zu identifizieren. Beide Referenzmodelle haben eine unterschiedliche Granularität und Skala im Sinn, wenn sie von Services sprechen.

Weitere augenfällige Unterschiede zwischen beiden Welten sind:

• Das Accounting und Billing spielt in der Wertschöpfung des TK-Serviceproviders eine herausragende Rolle. Dieses Thema ist in ITIL praktisch nicht repräsentiert, da die Abrechnung von IT-Services anderen Prämissen folgt und eine um Größenordnungen geringere Komplexität aufweist.
• Die in eTOM vorgenommene Dreiteilung in Customer Relationship, Service und Resource (Network) Management spiegelt genau wider, wie TK-Serviceprozesse ablaufen und Provider organisiert sind - bis hinein in die statische Organisation. Die Unterscheidung dieser Ebenen ist der IT und damit auch ITIL fremd.
• Die Aufgaben eines Service Desk gemäß ITIL verteilen sich im eTOM-Modell über etwa 30% aller operativen Level-2-Prozesse.
• Eine CMDB ist dem Management von Telekommunikationsnetzen (noch) fremd. SID hat inhaltlich keine Ähnlichkeit mit der CMDB; am nächsten kommen ihr noch die Service und Network Inventories, wobei letzteres gelegentlich nur rudimentär erfaßt ist.

Wenn ein Telekommunikationsservice durch mehrere Provider gemeinsam erbracht wird, kann ITIL hingegen sehr hilfreich sein, um die für das Zusammenwirken erforderlichen Serviceprozesse zu definieren. Ein Mobile Virtual Network Operator (MVNO) oder -Enabler (MVNE) ist, wie bereits erwähnt, dafür ein instruktives Beispiel. Ansatzpunkte für die Anwendung der ITIL-Methodik ergeben sich in der TK-Wertschöpfungskette unter anderem:

• im Bereich Assurance: Event/Incident/Problem Management können partiell oder bestimmte Technologien vollständig outgesourct sein, insbesondere die Leistungen des Field Service;
• im Fulfillment: Change Management/Request Fulfillment, einschließlich der Fulfillment Logistik und wiederum einschließlich Field Service;
• IT- oder IT-nahe Services allgemein, bis hin zu Teilbereichen des Billing oder das Invoicing.

Fazit

Service Manager in Industriesektoren, die für die Definition ihrer Services auf kein ausgereiftes eigenes Referenzmodell zurückgreifen können, sollten ITIL in Betracht ziehen und von IT-Spezifika abstrahieren. ITIL v3 ist ein wichtiger Schritt, um das Referenzmodell einer breiteren Anwendung zugänglich zu machen.

Die Telekommunikationsindustrie hat hingegen ein vergleichsweise altes und gereiftes Service-Referenzmodell. Eine Anwendung von ITIL "in großem Maßstab" ist in diesem Kontext nicht sinnvoll. Für bestimmte operative Prozesse kann ITIL jedoch auch vorteihaft in der Telekommunikation eingesetzt werden, besonders dort, wo Provider-Subprovider-Beziehungen existieren.

Nachdem wir 2007 das letzte Mal eine statistische Auswertung zum Spamaufkommen und der Wirksamkeit von Filtermaßnahmen vorgenommen haben, folgt hier die Auswertung für das Jahr 2009.

Es geht um unseren kleinen, unauffälligen Familien-Mailserver mit gerade einmal zehn beruflich und privat genutzten Postfächern. Der älteste Domainname, der darauf gehostet wird, ist seit 11 Jahren registriert.

Übersicht

Gesamtes Email-Aufkommen in 2009	4,6 Millionen
... pro Tag	12.500
Spamanteil	99,7%

Wirksamkeit

Filterstufe	Effekt
Stufe 1: Postfix-Regeln zur Prüfung des HELO Kommandos	40,1%
Stufe 2: Postfix-Regeln zur Prüfung des MAIL FROM Kommandos	3,1%
Stufe 3: Postfix-Regeln zur Prüfung des RCPT TO Kommandos	2,2%
Stufe 4: Überprüfung eingehender Mail mit policyd-weight	49,5%
Stufe 5: Greylisting	4,7%
Stufe 6/7: Klassischer Spamfilter	0,1%
Zugestellte Mails (erfahrungsgemäß zu 90% spamfrei)	0,3%

Maßnahmen zur Filterung im Detail

Stufe 1: Postfix-Regeln zur Prüfung des HELO Kommandos

• Ungültiger Hostname
• Unvollständiger Hostname (kein FQDN)
• Eigener Domainname des Mailservers im HELO Kommando

Der Effekt dieser Filterungen ist frappierend. Es sind gerade die PC aus Bot-Netzen, die irgendwelche eingliedrigen Namen wie "localhost" oder einfach nur "???" als ihren Namen angeben. Der SMTP-Standard verlangt zwar nicht ausdrücklich, daß der HELO-Name ein FQDN sein muß, diese Praxis hat sich aber inzwischen durchgesetzt. Man kann zwar den HELO-Hostnamen darauf prüfen, ob er ein korrekt geformter FQDN ist, aber nicht darauf, ob er im DNS wirklich bekannt ist. Viele Betreiber weisen ihren Mailservern Phantasie-Subdomains zu.

Ganz gerissene Sendeprogramme geben den eigenen Domainnamen des Empfängers (also z.B. "tedesca.net") im HELO-Kommando an - weg damit.

Stufe 2: Postfix-Regeln zur Prüfung des MAIL FROM Kommandos

• Unvollständige Email-Adresse (ohne Domain-Teil)
• Unbekannter (nicht auflösbarer) Domainname

Diese Tests, ebenso wie die der Stufe 3, dienen eher der Vollständigkeit und sind beim Postfix einfach mit dabei.

Stufe 3: Postfix-Regeln zur Prüfung des RCPT TO Kommandos

• Angabe des Namens einer Verteilerliste
• Relaying (zu fremdem Zielserver)

Wer Verteilerlisten benutzt, muß darauf achten, daß kein Unbefugter an diese Listen senden kann. Sonst kommt es schon ohne böse Absichten zu peinlichen Überraschungen, wenn ein Empfänger an alle antwortet...

Relaying wird nur noch sehr selten versucht. Offenbar sind diese Schlupflöcher auf Mailservern schon lange genug populär und mittlerweise alle gestopft.

Stufe 4: Überprüfung eingehender Mail mit policyd-weight

• Überprüfen nach DNSBLs
• Heuristiken über HELO, MAIL FROM und Client IP Adressen

Diese Tests sind relativ "teuer", da pro eingegangene Mail etliche Anfragen ins Internet gesendet werden müssen. Wir mögen die DNSBL-Tests daher eigentlich nicht sehr, sie sind aber außerordentlich wirksam. Da dynamische IP-Adreßbereiche der Absender mit einem Mißtrauensvorschuß beaufschlagt werden, richtet sich die Maßnahme nicht nur gegen wohlbekannte Spamversender, sondern auch besonders gegen Bot-Netze.

Der Policy-Daemon ist eine sehr komfortable Implementierung der DNSBL-Tests und einiger anderer Heuristiken. Anlaß für manuelles Feintuning seiner Arbeit konnten wir bisher nicht finden.

Man kann auch als "guter" Mailserverbetreiber unvermutet auf eine DNSBL gelangen, ohne daß nachvollziehbar wäre, auf welche Weise. Streiten nützt in diesem Fall gar nichts, die Listenbetreiber haben da eine stoische Ruhe. Auch wenn man solches noch nie getan hat, muß man beteuern, künftig kein Spam mehr versenden zu wollen und wird dann nach einigen Tagen (hoffentlich) von der Liste wieder entfernt. Es lohnt sich, gelegentlich nachzuprüfen, ob sich der eigene Mailserver noch eines gutes Rufes erfreut. Wer sich einen neuen Server mietet und diesen als Mailserver verwenden möchte, sollte gleich prüfen, ob die IP-Adresse "sauber" ist und schlimmstenfalls den Provider um eine andere IP-Adresse bitten.

Stufe 5: Greylisting und Namensprüfung

• Abweisen aller eingehendem Mails mit einem transienten Fehler; Annahme der Mail, wenn sie nach einer Karenzzeit von einigen Sekunden wiederholt gesendet wird
• Unbekannte Empfängernamen

Greylisting ist nach wie vor wirksam. Die Zahl von 4,7% in der Gesamtstatistik sieht auf den ersten Blick nicht sehr eindrucksvoll aus, das liegt aber daran, daß durch die vorgelagerten Tests bereits so viel ausgefiltert wird. Andersherum betrachtet, filtert Greylisting 90% des noch für diese Methode in der Kette verbleibenden Verkehrs aus. Das dürfte den Anteil des Verkehrs aus Bot-Netzen widerspiegeln, da jeder richtige Mailserver nach gewisser Zeit den Sendeversuch wiederholt, wenn er einen 400er Fehler beim ersten Versuch gemeldet bekommt. Bei einem fest installierten Spamserver ist das SMTP-Protokoll immer vollständig implementiert. Wenn ein Mailserver nach einem 400er Fehler keinen neuen Sendeversuch unternimmt, ist das ein Versäumnis des Administrators.

Natürlich ist der Anteil unbekannter Empfängernamen deutlich höher, wie hatten uns schon früher mit diesem Phänomen auseinandergesetzt. Diese Sendeversuche werden aber in der Mehrheit schon durch die Stufen 1 und 4 abgefangen.

Stufe 6: Klassischer Spamfilter

• serverweite Schwarze Listen
• Spamassassin mit Razor und Pyzor

Stufe 7: Spamfilter mit nutzerspezifischen Einstellungen

• individuelle Schwarze Listen
• Bayes-Analyse

Immerhin noch ein Viertel des Restverkehrs läßt sich mit Spamassassin abfangen. Dazu gehören auch die eigenen Schwarzen Listen, auf denen zum Beispiel alle nicht abbestellbaren Newsletter geführt werden.

Rechtzeitige Zurückweisung

Die oben genannten Tests 1 bis 6 sollten durchgeführt werden, bevor der Mailserver die eingehende Nachricht überhaupt angenommen hat. Mit anderen Worten: Die Policyserver- und Filteraufrufe müssen an den richtigen Stellen in die smtpd_helo_restrictions, smtpd_sender_restrictions und smtpd_recipient_restrictions des Postfix-Servers eingebaut werden. Das hat einen formalen und zwei praktische Gründe.

1. Der formale Grund ist äußerst wichtig, wenn ein größerer Benutzerkreis mit Maildiensten bedient wird. Für eine einmal angenommene Mail hat der Server die Verantwortung; er muß sie auf jeden Fall zustellen. Die Ablage in ein nutzerspezifisches Spam-Postfach darf nur noch aufgrund einer vom Nutzer vorgegebenen eigenen Regel erfolgen.

2. Der erste praktische Grund ist die Minimierung des Datenverkehrs im Netz. Die inzwischen wie Spam geliebten Backscatter-Mails (d.h. eine Mitteilung über Nichtzustellbarkeit an die gefälschte aber meist existierende Absenderadresse) werden dadurch vermieden.

3. Der zweite praktische Grund liegt in der sicheren Behandlung der gefürchteten "false Positives". Durch die Rückweisung einer Mail noch während des Zustellvorgangs erhält der "gute" Absender auch sofort das Feedback über die gescheiterte Zustellung und kann darauf reagieren.

Top 10 der Spamversender (nach IP-Adresse)

Platz 1: 6589 Ereignisse, IP 83.66.167.71
inetnum: 83.66.167.0 - 83.66.171.255
descr: DOL ANKARA-VAE ADSL STATIC
country: TR

Platz 2: 5342 Ereignisse, IP 88.147.128.28
inetnum: 88.147.128.0 - 88.147.175.255
descr: Network of Saratov branch of OJSC "Volgatelecom"
country: RU

Platz 3: 4913 Ereignisse, IP 58.211.198.18
inetnum: 58.211.198.16 - 58.211.198.23
descr: Suzhou Kaiyuan Circuit Co.,Ltd
country: CN

Platz 4: 4648 Ereignisse, IP 213.243.5.100
inetnum: 213.243.0.0 - 213.243.15.255
descr: Dogan Iletisim Elektronik Servis Hizmetleri A.S.
country: TR

Platz 5: 3796 Ereignisse, IP 84.21.74.1
inetnum: 84.21.74.0 - 84.21.75.255
netname: XXLINE-CORE-NET
descr: block for core of network
country: RU

Platz 6: 3201 Ereignisse, IP 77.91.190.21
inetnum: 77.91.128.0 - 77.91.191.255
netname: UA-TELESYSTEMS-20070426
descr: Telesystems of Ukraine LLC
country: UA

Platz 7: 2670 Ereignisse, IP 63.150.92.98
NetRange: 63.144.0.0 - 63.151.255.255
OrgName: Qwest Communications Company, LLC
Country: US

Platz 8: 2531 Ereignisse, IP 203.45.38.197
inetnum: 203.40.0.0 - 203.47.255.255
netname: TELSTRAINTERNET2-AU
descr: Telstra Internet
country: AU

Platz 9: 2434 Ereignisse, IP 66.109.226.202
inetnum: 66.109.224.0 - 66.109.255.255
descr: Sanitary Process Systems
country: US

Platz 10: 1807 Ereignisse, IP 68.151.224.239
NetRange: 68.144.0.0 - 68.151.255.255
OrgName: Shaw Communications Inc.
Country: CA

Fazit

Es sind nach wie vor die selben einfachen Maßnahmen wie vor drei Jahren, mit denen sich Spam abwehren läßt. Im Gegensatz zu einigen noch etwas optimistischeren Statistiken muß ich aber feststellen, daß der Anteil erwünschten Emailverkehrs sich inzwischen im niedrigen Promillebereich bewegt: Während 2007 noch 1 Prozent der Nachrichten erwünscht waren, waren es 2009 nur noch 3 Promille.

Mehr als 90% des Spam geht offenbar von Bot-Netzen aus. Das erklärt die Wirksamkeit von Greylisting. Das Interesse der Bot-Netz-Betreiber fokussiert sich momentan offenbar eher auf die Etablierung ihres Geschäfts. Die operative Seite wird für gut genug gehalten und zeichnet sich nicht durch Innovationen aus. Die Kunden der Bot-Netz-Betreiber, die erwarten, daß ihr Spam beim Empfänger ankommt, verschwenden ihr Geld.

Für die fest installierten Spamschleudern sind aufstrebende und etablierte Wirtschaftsmächte gleichermaßen Standorte.

Trouble with shared drives

I provide a file space accessible by SFTP and WebDAV to users working with Windows or Mac OS. The big pro for Expandrive is its Finder/Explorer integration. I was excited when I saw this the first time and I was really happy with the stability and the resilience. After losing the connection and reconnecting the drive is in place again as if nothing happened.

The downside of Expandrive is in the settings of group "w" bits after upload (creation of the file or directory). I tried different clients - with good results for Forkloft and WinSCP and bad results for Expandrive and Cyberduck.

Jesaja bez 18:32 /Users/bez/work/scratch $ ls -lisa
3317038 8 -rw-r--r--@ 1 bez staff 11 Dec 5 18:27 Cyberduck Transfer.txt
3317026 8 -rw-r--r--@ 1 bez staff 11 Dec 5 18:27 Expandrive Transfer.txt
3317042 8 -rw-r--r--@ 1 bez staff 11 Dec 5 18:27 Filezilla Transfer.txt
3317030 8 -rw-r--r--@ 1 bez staff 11 Dec 5 18:27 Forklift Transfer.txt
3317034 8 -rw-r--r--@ 1 bez staff 11 Dec 5 18:27 WinSCP Transfer.txt

Do file transfers with WinSCP, Forklift, Cyperduck, Filezilla and Expandrive, respectively, from Jesaja (Mac OS Snow Leopard) to Hiob (Debian Etch) ...

hiob bez 17:32 /home/bez/sftptest $ ls -lisa
38830081 8 drwxrws---+  2 bez tedesca 4096 Dec  5 17:47 .
27197444 8 -rw-r--r--+  1 bez tedesca   12 Dec  5 17:27 Cyberduck Transfer.txt
27197443 8 -rw-r--r--+  1 bez tedesca   11 Dec  5 17:27 Expandrive Transfer.txt
27197445 8 -rw-rw----+  1 bez tedesca   11 Dec  5 17:27 Filezilla Transfer.txt
27197442 8 -rw-rw----+  1 bez tedesca   11 Dec  5 17:27 Forklift Transfer.txt
27197441 8 -rw-rw----+  1 bez tedesca   11 Dec  5 17:27 WinSCP Transfer.txt

Expandrive and Cyberduck propagate the access mode from the client (which is 644 as on every Unix machine) to the server and do not respect the ACL set to the server directory. This is pointless behaviour of a file transfer program if the directory on the server shall be shared by a number of users. The ACL on the server would help if it was not overridden by the SFTP client.

hiob root 17:33 /home/bez/sftptest # getfacl /home/bez/sftptest /home/bez/sftptest/*
default:user::rwx
default:group::rwx
default:group:www-data:rwx
default:mask::rwx
default:other::---

file: Cyberduck Transfer.txt
user::rw-
group::rwx          #effective:r--
group:www-data:rwx  #effective:r--
mask::r--
other::r--

file: Expandrive Transfer.txt
user::rw-
group::rwx          #effective:r--
group:www-data:rwx  #effective:r--
mask::r--
other::r--

...

As you can see, files transferred with Cyberduck (the most popular SFTP client for the Mac, by the way) or Expandrive will not be writable by other users, not even with WebDAV because the server default ACL is being overridden. But no team using a shared filespace wants to fiddle around with access permissions.

Evaluation

I checked various SFTP clients for the Mac. See the results below:

Forklift:
o price USD 20
+ sets access rights in a user-friendly way, respects server ACL
- no Finder integration
+ supports Amazon S3 and WebDAV (the latter can also be mounted to the Finder directly)

Filezilla:
+ is free
+ sets access rights in a user-friendly way, respects server ACL
- poor handling
- can handle PPK (PuTTY) keys on local disk only without passphrase set
- no Finder integration

Cyberduck:
+ is free
- handles access rights similar to Expandrive
- no Finder integration

Flow:
- commercial, more expensive than Expandrive or Forklift
- handles access rights similar to Expandrive
- no Finder integration

Webdrive:
+ Finder integration
- commercial, more expensive than Expandrive or Forklift
-- only password authentication, no pubkey
-- only 1y or 2y of updates included

Fugu:
-- not maintained since 2005 (not tested therefore)

Macfusion:
-- only password authentication, no pubkey

Flow, CrossFTP, Transmit, Fetch, Netfinder, Interarchy:
- commercial, more expensive than Expandrive or Forklift (not tested therefore)

WinSCP (Windows):
+ is free
+ sets access rights in a user-friendly way, respects server ACL
- no Explorer integration
- supports only SFTP/FTP

Recommendation

Sadly, Expandrive's comment is: "At some point in the future, we will probably make this behavior configurable, but right now, it is hard-wired to use the client umask."

Therefore, my recommendations for now:

• Forklift under Mac OS,
• Filezilla if it has to be free (available for all major operating systems),
• WinSCP under Windows,
• or, if your filespace supports also WebDAV and your transfer volume is not too high, use WebDAV instead. It is now supported natively by all important OS (including Symbian S60).

... werden wir manchmal gefragt.

Wir hatten einmal einen kleinen Briard namens Tedesca, den wir sehr jung verloren haben. Der Domainname war dann halt da und harrte einer Bestimmung.

Vieles von dem, was wir (meine Frau und ich) tun, spiegelt sich im Internet, sei es meine berufliche Tätigkeit, sei es unsere Hundezucht, seien es andere Haupt- und Nebenbeschäftigungen. Irgendwann begannen bei uns verschiedene Dinge im Internet sich unter dem freien Namen zu sammeln, erst TEDESCA.NET, dann TEDESCA.ORG, und schließlich TEDESCA.COM.

"Tedesca" bedeutet also nichts Bestimmtes, ist jedenfalls kein geheimnisvolles Akronym. Es ist einfach ein Name, kurz, hoffentlich einprägsam, und er wird im Deutschen nicht allzu häufig verwendet.

Die Wortmarke HTML[TEDESCA®] haben wir uns beim Deutschen Patent- und Markenamt schützen lassen.

Sie werden das Problem vielleicht auch aus Ihrer Firma kennen: hinter Proxy und restriktiver Firewall ist Schluß. Der im folgenden vorgestellte Weg ist oft auch in solchen Fällen gangbar, um das Firmennetz zu verlassen, aber ich will Sie nicht dazu verleiten, Ärger mit Ihrem Arbeitgeber heraufzubeschwören. Gegen den freien Zugang zu wichtigen Informationen aus einem chinesischen Hotel heraus wird aber auch Ihr Arbeitgeber nichts haben.

Im konkreten Fall ergaben Tests:
1. Grundsätzlich funktionierte der Zugriff auf HTTP- und HTTPS-Seiten außerhalb Chinas. Nur bei einigen Domains (wie z.B. wikipedia.org oder cnn.com) kamen immer leere Seiten zurück.
2. DNS lieferte auch zu den inkriminierten Domains die richtigen IP-Adressen (erste Überraschung).
3. Der Zugriff mit SSH-Protokoll (Secure Shell) auf Port 22 eines Servers außerhalb von China funktionierte ebenfalls (zweite, große Überraschung).

Übertrieben hohen Wert scheint die chinesische Führung also auch nicht darauf zu legen, Kommunikationsversuche zu unterbinden. Wer also irgendwo einen Linux-Server sein eigen nennt, ob gemietet draußen im Internet oder daheim hinter einer Firewall, ist fein raus, denn er kann sich auf seine Reise vorbereiten. Im folgenden wird die Einrichtung einer abhörsicher verschlüsselten Verbindung beschrieben, die Zugriff auf einen in Freiheit lebenden Webproxy und gegebenenfalls noch weitere Dienste und Protokolle erlaubt.

Einrichtung des Servers

Auf dem Linux-Server muß nur der Proxy Squid zusätzlich installiert werden, denn der SSH-Server gehört zum Standardumfang jeder Linux-Installation. Für den genannten Zweck muß Squid nur Verbindungsaufnahmen von localhost unterstützen, man kann den Proxy also restriktiv konfigurieren und den Zugriff auf Port 3128 (den Standardport von Squid) von außerhalb im Paketfilter (zum Beispiel iptables) unterbinden. Wer den Proxy von außen zugänglich machen will, tut gut daran, den Zugriff auf Squid mit einem Paßwort zu schützen. Das geschieht durch entsprechend gesetzte Optionen in der Konfigurationsdatei squid.conf, die in Kommentaren innerhalb der Konfigurationsdatei bereits vorgeschlagen werden. Außerdem ist eine spezielle Paßwortdatei für Squid anzulegen.

SSH wird durch Änderungen an der Datei sshd_config eingerichtet. Ich rate grundsätzlich dazu, die Option AllowUsers zu verwenden und ChallengeResponseAuthentication sowie PasswordAuthentication auszuschalten. Der Nutzer meldet sich dann nicht mit einem Paßwort an, sondern ausschließlich durch Vorweisen seines Schlüssels. Ich empfehle außerdem, die autorisierten Schlüssel der Nutzer nicht unterhalb des Heimtverzeichnisses des jeweiligen Nutzers abzulegen, sondern zentral. Dazu erstellt man ein Verzeichnis /etc/ssh/authorized_keys (Zugriffsrechte 0755) und ändert eine weitere Option in der sshd-Konfigurationsdatei: AuthorizedKeysFile /etc/ssh/authorized_keys/%u.

Wer einen Server daheim verwendet, muß den Zugriff auf Port 22 des Servers in der Firewall freischalten und sollte außerdem dafür sorgen, daß der heimatliche Internetanschluß unter einem Namen im Internet sichtbar ist. Das kann über die Nutzung eines Dynamischen DNS-Dienstes geschehen. Für die Anmeldung der IP-Adresse bei solchen Diensten nach Adreßwechsel (z.B. nach der täglichen Zwangstrennung und Wiedereinwahl) sorgt das Linux-Paket ddclient.

Wer auf seinem Linux-Server den Port 443 frei hat, weil er keine HTTPS-Seiten ausliefert, kann den SSH-Dienst auch auf Port 443 betreiben. Das hat Vorteile, falls das hier beschriebene Verfahren einmal eingesetzt wird, um durch einen widerborstigen Proxy hindurch eine Verbindung herzustellen. Port 443 (HTTPS) wird von den meisten Proxies durchverbunden, ohne daß geprüft wird, ob das Protokoll wirklich HTTPS ist, während der Ausgang durch Port 22 in fast allen Firmen-Firewalls aus gutem Grund gesperrt ist. Wenn der Server auch noch ein gut ausgebauter Internetserver mit Apache SSL ist, und der Port 443 daher nicht frei ist, kann man von seinem Provider eventuell eine zweite IP-Adresse bekommen, unter der dann auch der Port 443 verfügbar ist.

Einrichtung des Clients

Auf dem Windows-Client wird das Programmpaket PuTTY installiert. Mit puttygen erzeugt man zuerst einen Schlüssel. Der öffentliche Schlüssel wird aus dem Fenster von puttygen in die Datei /etc/ssh/authorized_keys/ichselbst (für den Nutzer mit dem Login-Namen ichselbst, Zugriffsrechte auf die Datei 0600, Eigentümer ist ichselbst) kopiert. Wenn man innerhalb der SSH-Verbindung nur bestimmte TCP-Tunnel zulassen möchte, kann man dies durch Voranstellen der permitopen-Option erreichen.

Mit dem Programm putty wird eine neue Sitzung eingerichtet. Wir gehen im Beispiel davon aus, daß wir uns entschieden haben, für SSH den Port 443 zu mißbrauchen. Als Nutzername für die Anmeldung wird der Login-Name auf dem Linux-Server eingetragen.

Der Ablagepfad des zuvor generierten Schlüssels wird eingetragen und die Endpunkte des Tunnels festgelegt. Im Beispiel sieht man, daß der lokale Port 3128 (L3128) mit dem Port 3128 auf dem Linux-Server (127.0.0.1:3128) verknüpft ist. Die lokale IP-Adresse 127.0.0.1 bezieht sich dabei auf das jenseitige Ende des Tunnels.

Wer mit dem beschriebenen Verfahren noch einen Firmen-Proxy zu durchqueren hat, muß diesen unter dem Punkt "Proxy" auch noch eintragen. Bitte nicht verwirren lassen durch so viele Proxies und nicht vergessen, diese PuTTY-Einstellungen zu speichern!

Bevor wir zu den Einstellungen im Browser kommen, zeigen wir noch, wie man PuTTY so konfiguriert, daß es als SOCKS 5-Server fungiert. Wozu das gut ist, wird auch gleich erklärt. Vorerst belassen wir es aber noch bei den bisherigen Einstellungen (L3128 127.0.0.1:3128).

Zuerst wird die SSH-Verbindung aufgebaut. Der Browser (auf Reisen hoffentlich Firefox) wird auf den lokalen Proxy 127.0.0.1:3128 konfiguriert (linkes Bild). Damit sollte die Verbindung durch die Große Chinesische Mauer also funktionieren. Den Test sollte man aber schon einmal zuhause durchführen.

Wer Schwierigkeiten mit der Namensauflösung hat (z.B. weil die chinesische Führung beschließt, in dieser Hinsicht die Zügel etwas straffer anzuziehen), kann PuTTY auch als SOCKS-Server verwenden. Firefox hat den Vorteil, die DNS-Namensauflösung auch über den SOCKS-Server vornehmen zu können. Die dafür erforderlichen Einstellungen im Browser sind in den Bildern gezeigt.

Wir hoffen, daß Ihnen diese Hinweise auf Ihren Reisen in merkwürdige Länder etwas helfen. Wir freuen uns natürlich über Ihre Anmerkungen und Hinweise. Wenn Sie Fälle kennen, wo eine Verbindungsaufnahme mit dem SSH-Protokoll unterbunden wurde und wo stattdessen httptunnel oder stunnel funktionierte (bzw. SSH getunnelt durch einen httptunnel, der Phantasie sind ja keine Grenzen gesetzt), dann würden wir gern auch Ihre Konfigurationsanleitung veröffentlichen.

Document Management System (kurz: DMS) ist ein sperriger Begriff. Gemeint ist hier ein Ablage- und Wiederfinde-System für Dateien (PDF, Word, Excel, Powerpoint, Graphiken etc.), das die Zusammenarbeit mehrerer Personen in einer Gruppe unterstützt. Wenn das Team über das Land oder die Welt verteilt ist, befindet sich das DMS vorzugsweise im Internet.

Der Berater kennt das Problem zur Genüge: Wie mit einem Kunden zusammenarbeiten, der seine Unterlagen sicher im Intranet kursieren läßt und ablegt? Auf das Intranet erhält man keinen Zugriff. Andererseits ist das Hin- und Herkopieren dicker Dokumente über Emails und mit USB-Sticks auch keine Lösung. Bei vielen Email-Systemen liegt die maximale Nachrichtengröße noch zwischen 10 und 20 Megabyte und viele externe Firewalls lassen nur PDF durch. Heutzutage sind Dokumente aber größer, und nur mit PDFs läßt es sich nicht gut zusammenarbeiten. Es ist auch erstaunlich, wie leichthin viele Menschen Dokumente mit Emails verschicken. "Das ZIP-Paßwort ist meine Mobilnummer." Schön. Aber wer es schafft, eine Email mit einem vertraulichen Anhang abzufangen, sollte auch in der Lage sein, die Mobilnummer des Absenders herauszubekommen. PGP wiederum ist auf Firmenrechnern fast nie installiert. Wie also sicher und zuverlässig Dokumente austauschen?

Wer einen eigenen Server betreibt, auf dem ein DMS installiert ist, welches über HTTPS (also verschlüsseltes Web-Protokoll) erreichbar ist, verfügt schon über die wichtigsten Voraussetzungen, um diese Probleme zu lösen. Dokumente beliebiger Größen können dort gelagert werden, der Zugriff funktioniert weltweit, jede Übertragung über das öffentliche Internet erfolgt verschlüsselt. Mindestanforderungen an ein kundenfähiges DMS sind (A): es muß

• clientseitig mindestens mit Firefox, Internet Explorer, Safari und Opera funktionieren,
• die eigene, schnelle Administration der Nutzer und Zugangsrechte erlauben,
• ein ausgefeiltes Rechtemanagement bieten, das Kundenbereiche vollständig voneinander separieren kann (Mandantenfähigkeit),
• das Check-out/Check-in und möglichst auch eine Versionierung von Dokumenten erlauben

Das Rechtemanagement muß immerhin so leistungsfähig sein, daß ein Kunde, der Zugang zu dem DMS hat, nicht einmal die Namen der Ordner sehen kann, auf die er keinen Zugriff hat. Sie wollen Ihre Kunden ja vielleicht nicht unbedingt wissen lassen, für wen Sie sonst noch so arbeiten.

Die Suche nach dem richtigen System

Wer BSCW und Livelink kennt, weiß, wie ein DMS funktionieren muß und was es leisten muß. Leider sind BSCW und Livelink nicht (mehr) frei verfügbar. Damit sind wir beim nächsten Punkt. Wer einen eigenen Server betreibt, hat keinen Grund, für ein DMS einen kostenpflichtigen Service zu nutzen, der zudem den Nachteil haben könnte, daß man das Backup der Daten nicht mehr selbst effizient bewerkstelligen kann. Das DMS sollte also (B)

• als Open Source verfügbar sein,
• sich in einen LAMP-Server (Linux, Apache, MySQL, PHP) integrieren,
• Dokumente als Dateien abspeicheren (also keinesfalls als Binärobjekte in einer Datenbank), sodaß sie auch ohne den Weg über das DMS archivierbar und direkt auf dem Server lesbar sind,
• möglichst ohne Java SDK, Tomcat und andere Erweiterungen funktionieren, sondern nur mit reinem PHP und (wenn es unbedingt sein muß) Javascript.

Die Anforderung, ohne Java, JSP und andere Erweiterungen zu funktionieren, ist nicht zwingend. Dies war meine persönlicher Wunsch, da für die üblichen Anwendungen PHP serverseitig und Javascript plus Flash clientseitig alle wichtigen Funktionen bereitstellen. Was darüber hinausgeht, ist meist nur hübsche Spielerei, bläht die Installationspakete auf 15 Megabyte und mehr auf und macht die Installation und Pflege zu einem zeitraubenden Unterfangen.

Die Suche nach dem richtigen System ist nicht leicht. Die üblichen tabellarischen Gegenüberstellungen nach Art von Heise c't und Computerwoche helfen nicht weiter. Die Redakteure haben den Mainstream im Auge und verwechseln leider auch manchmal Content Management Systeme mit DMS, wozu Hersteller dieser Systeme aber auch ihren Teil beitragen. Beliebt sind heutzutage auch die Systeme, wo alles drin ist und ohne die X-te Kalenderfunktion kommt offenbar kaum noch ein Produkt aus.

Ein DMS ist aber keine Groupware und eine Groupware braucht nicht unbedingt ein DMS. Groupware hat Nachrichten-, Kalender-, Projektplanungs- und weitere Funktionen, die Abläufe innerhalb eines Projektes (den Workflow) unterstützen. Dokumentenmanagement hat damit wenig zu tun. Eine richtige Integration von Workflow und Dokumentenmanagement schaffen nur große, oftmals teure Produkte, die innerhalb einer Organisation eingesetzt werden können. Das ist gerade das Gegenteil der Situation, wie ich sie eingangs geschildert habe. Groupware-Funktionen nutzt eine freier Berater gerade nicht gemeinsam mit seinen Kunden.

Dementsprechend lohnt es kaum, bei der Suche nach dem richtigen DMS die üblichen Verdächtigen unter den Open Source Groupware-Produkten abzuklappern, wie PHProjekt, OpenGroupware etc. Es gibt in diesen Produkten zwar meist die Zuordnung von Dokumenten zum Projekt, aber sie sind nicht mandantenfähig, da jedes Gruppenmitglied die Gesamtstruktur sehen kann.

And the winner is...

Ich bin bei meiner Recherche (Anfang 2008) schließlich auf zwei geeignete DMS gestoßen: Epiware und Owl - die Eule. Beide Systeme leisten das Geforderte nach den Listen (A) und (B). Beide Produkte ließen sich jeweils innerhalb einer Stunde vollständig installieren, die Anleitungen in den Readme-Dateien reichten aus, waren bei Epiware aber präziser.

Epiware kommt professionell daher, es steht eine richtige (kleine) Firma dahinter und es gibt das Produkt mit Premium Support für Firmen. Das Rechtemanagement leistet genau die geforderte Mandantenfähigkeit, aber nicht mit viel zusätzlichem Komfort. Neue Releases gibt es (zu) häufig: 4.8.5 im Januar 2008, 4.8.4 im November 2007, 4.8.2 im Oktober 2007. Wichtig ist: Die Firma dahinter läßt auf Zukunftssicherheit hoffen, und vielleicht bekommen sie auch noch heraus, was sie mit ihrem Produkt erreichen wollen. Das Produkt kann man sich auch als gehostete Lösung vorstellen. Der übliche Kalender und zusätzliche Schmankerln wie Gantt Charts, Aufgabenliste und Wiki sind dabei. Für eine Groupware aber noch weitaus zu wenig, das Dokumentenmanagement (bezeichnenderweise unter dem Menüpunkt "Library" und dort unter "Shared Drive" versteckt) dagegen wie gesagt ausreichend, aber doch spartanisch.

Deshalb habe ich mich schließlich für Owl entschieden. Owl strotzt vor Bescheidenheit und sieht überhaupt wie ein "typisches" Sourceforge-Projekt aus, man weiß nicht recht: Lebt es noch oder ist es schon entschlafen? Noch lebt es: Release 0.95 im Oktober 2007, 0.93 im September 2006 - sparsamer geht es wohl nicht. Dokumentation ist leider fast keine vorhanden, das Vorhandene verdient den namen Dokumentation nicht. Die vielen Optionen und Einstellmöglichkeiten lassen sich mit drei Stunden Probieren und etwas Phantasie erkunden. Also alles in allen wirklich ein typisches Sourceforge-Projekt.

Bei Owl mußte ich insgesamt 8 der installierten Dateien leicht modifizieren:

• bei zweien war dies im Rahmen der Installation vorgesehen,
• zwei PHP- und zwei CSS-Dateien mußte ich nur leicht anpassen, um Owl meinem eigenen Seitenlayout anzugleichen,
• zwei PHP-Dateien mußte ich korrigieren, damit Owl auch mit dem Internet Explorer funktioniert.

Es geht also leider nicht ganz ohne LAMP-Kenntnisse. Daß der Internet Explorer nicht funktionierte, war einigermaßen ernüchternd; die Entwicklermannschaft steht mit ihm offensichtlich auf Kriegsfuß. Auch ärgerlich ist, daß PHP viele Warnungen wegen nicht ganz sauberen Codes in die Logfiles schreibt. In der FAQ von Owl wird empfohlen, das Warnungsniveau von PHP heraufzusetzen - warum beseitigen die Burschen nicht einfach die Unsauberkeiten?

Zu den Stärken von Owl zählen:

• die weitreichende und ziemlich vollständige Funktionalität, wenn man es mit den Benchmarks BSCW und Livelink vergleicht,
• die Vielsprachigkeit,
• die zahlreichen Optionen und Einstellmöglichkeiten,
• die äußerst fein einstellbaren Rechte auf Ordner- und Dateiebene über Gruppen und individuell über detaillierte Access Control Lists (ACL),
• die Integration in eine vorhandene Nutzerverwaltung,
• die Fähigkeit, untergeschobene Dateien zu adoptieren.

Eine unerwartete freudige Überraschung war, daß Owl bereit ist, extern authentifizierte Nutzer zu bedienen. Da ich auf meinen Seiten bereits eine Nutzerverwaltung habe, kann ich die Authentifizierung selbst vornehmen und Owl im Sinne eines Single Sign-on (SSO) den Namen des autorisierten Benutzers übergeben. Die Verwaltung der Owl-spezifischen Zugriffsrechte erfolgt selbstverständlich innerhalb von Owl.

Erfreulich ist auch, daß man existierende Dateibäume in das Dokumentenverzeichnis von Owl direkt auf Linux-Ebene kopieren kann. Findet Owl solche neuen Dateien, werden diese automatisch mit voreingestellten Eigentümernamen und Zugriffsrechten katalogisiert.

Es mag noch weitere Systeme geben, die ebenso gut wie Owl die genannten Anforderungen erfüllen. Für Hinweise bin ich dankbar. Vielleicht hilft dieser Artikel aber einigen, ein ähnliches Problem, wie ich es hatte, schnell und ohne viel Sucherei zu lösen.

Anfang Oktober mußten wir unseren Internetserver nach einem Totalzusammenbruch aufgrund eines Hardwarefehlers neu aufsetzen. Der Server war dadurch 18 Stunden außer Betrieb, die Daten konnten aber alle aus der Sicherung wieder hergestellt werden. Bei der Neuinstallation haben wir auch das Email-System modernisiert, insbesondere

• komplett auf virtuelle Mailboxen umgestellt
• Amavis mit ClamAV und Spamassassin als Filtermaschine eingesetzt
• Postfix-GLD als Greylister verwendet
• auf eigene Scripts völlig verzichtet

Da jetzt wieder eine Änderung am Mailsystem erfolgt, nämlich die Einführung von policyd-weight vor Postfix-GLD, folgt hier nochmals eine Statistik über 12 Wochen.

Statistik

Die erstaunlichste Veränderung gegenüber der letzten Statistik ist die Zahl der eingegangenen Emails. Während wir vermutet hatten, daß in 2008 die Zahl der eingehenden Emails die Marke von 1 Million überschreiten würde, mußten wir jetzt feststellen, daß allein in den vergangenen 12 Wochen 630.000 Emails eingingen; das sind 320 pro Stunde, alle 11 Sekunden eine. Damit vervierfacht sich das Spam-Volumen offenbar derzeit jährlich.

Durch die veränderte Filterkette ergibt sich eine völlig neue Verteilung der Ausschlußgründe gegenüber der letzten Analyse, aber der Effekt ist der gleiche:

• 1,3% Helo command rejected: Invalid name (501 5.5.2)
• 25,0% Helo command rejected: need fully-qualified hostname (504 5.5.2)
• 0,5% Helo command rejected: Don't use my own IP address (550 5.7.1)
• 4,0% Helo command rejected: Host not found (450 4.7.1)
• 2,2% Sender address rejected: Domain not found (450 4.1.8)
• 63,2% Recipient address rejected: You have been greylisted, please try later (451 4.7.1) - not retried
• 2,1% Recipient address rejected: User unknown in virtual mailbox table (550 5.1.1)
• 0,1% Amavis/ClamAV Virustest
• 0,4% Amavis/Spamassassin Spamtest

Insgesamt 1,2% der Nachrichten haben alle Tests erfolgreich durchlaufen.

Schlußfolgerungen

Etwa ein Viertel der Nachrichten wurde schon nach der ersten Kontaktaufnahme mit dem HELO-Kommando abgewiesen. Dabei ist die Prozentzahl für "Host not found" (Fehlercode 450) deshalb so niedrig, weil wir diesen Test nach wenigen Wochen wieder deaktiviert haben. Es gibt zu viele "gute" Mailserver, die unter einem Namen senden, der nicht ordentlich im DNS registriert ist.

Zwei Drittel der Nachrichten werden durch das Greylisting abgehalten. Die hier gezeigte Zahl ist schon abzüglich der erneuten Sendeversuche, die das Greylisting dann erfolgreich passiert haben. Hier setzen Optimierungsmöglichkeiten an:
1. Das Greylisting erfolgt, bevor überhaupt geprüft wurde, ob die Zieladresse existiert. Das ist bei einem Postfix-Server mit virtuellen Mailboxen systembedingt und läßt sich vermutlich nicht ändern.
2. Es werden unnötig viele Emails auf die Greylist gesetzt, die bei genauerer Analyse der HELO- und MAIL FROM-Zeilen ausgeschlossen werden könnten. Dafür erproben wir jetzt policyd-weight.

Nach einem Tag Testlauf mit policyd-weight zeichnet sich folgende Verteilung (vor Übergabe an Amavis) ab:

• 1,5% Helo command rejected: Invalid name (501 5.5.2)
• 24,3% Helo command rejected: need fully-qualified hostname (504 5.5.2)
• 1,1% Helo command rejected: Don't use my own IP address (550 5.7.1)
• 0,1% Sender address rejected: need fully-qualified address (504 5.5.2)
• 0,3% Sender address rejected: Domain not found (450 4.1.8)
• 0,9% Relay access denied (554 5.7.1)
• 28,6% Recipient address rejected: Mail appeared to be SPAM or forged (550 5.7.1)
• 34,7% Recipient address rejected: Your MTA is listed in too many DNSBLs (550 5.7.1)
• 3,0% Recipient address rejected: temporarily blocked because of previous errors (550 5.7.1)
• 5,3% Recipient address rejected: You have been greylisted, please try later (451 4.7.1)
• 0,4% Recipient address rejected: User unknown in virtual mailbox table (550 5.1.1)

Masse statt Innovation

Wir lesen oft, daß die Spamversender, die nach unseren Erfahrungen für mehr als 90% des Volumens Bot-Netze verwenden, ihre Techniken immer weiter ausfeilen, um alle möglichen Filtermechanismen zu umgehen. Viel Kreativität können wir aber nicht erkennen. Solange Greylisting so wirkungsvoll ist, hat die Gemeinde der Spamversender ihre Möglichkeiten noch lange nicht ausgeschöpft. Es ist wie oft in der Netz- und sonstigen Wirtschaft: Es wird versucht, Mangel an Innovation durch Steigerung des Volumens auszugleichen.

Dabei scheint es für die Absender überhaupt keine Rolle zu spielen, ob die Empfängeradressen existieren. Wir verstehe nicht, nach welchen Kriterien sie bezahlt werden. Innerhalb einer durchschnittlichen Woche mit 55.000 eingehenden Emails wurden 2200 verschiedene Phantasieadressen verwendet. Die Top 10 sind alte Bekannte: simonwilkinson@barnim.net orsi_vale@barnim.net sdougal@barnim.net rajagopalan_v@barnim.net oerbeck@barnim.net raines@barnim.net popeyes@barnim.net smmaclean@barnim.net ntziorkas@barnim.net rrood@barnim.net und so weiter und so fort. All diese Namen haben nie existiert. Andere, reale Empfängeradressen, die noch dazu im Internet leicht abzufischen wären, werden weitgehend ignoriert.

Stattdessen wird eine bekannte Domain wie "barnim.net" mit zahllosen potentiellen Postfachnamen nach einer Standardliste kombiniert. Anscheinend wird diese Namensliste gelegentlich auch noch manuell abgeschrieben, denn anders währen gewisse Evolutionen in der Schreibung kaum erklärlich. der oben gesehene "oerbeck" war vor einigen Jahren mal ein "overbeck".

Im Jahre 1990 habe ich bei Siemens angeheuert, in einem Bereich, der einen deutschen Umlaut in seinem Namen führte. Ich war zuerst länger bei der Siemens AG, dann erhöhte sich die Frequenz: STS, wieder Siemens AG, schließlich Nokia-Siemens. Ich habe in zehn verschiedenen Aufgaben erst in Berlin gearbeitet, dann in München, dann wieder in Berlin, dann in Leipzig, dann wieder in München. War von den 17 Jahren nicht viele in Berlin, habe mein Basislager dort aber nie aufgegeben.

Mein nächster Neuanfang soll weder in Nokia Siemens Networks noch in Siemens stattfinden. Der Moment ist günstig und ich habe mich entschlossen, im Rahmen der allgemeinen Restrukturierung von NSN ein lukratives Abfindungsangebot anzunehmen und als freier Berater für Informationstechnologie, Telekommunikation und Unternehmensorganisation von gesammelter Erfahrung zu profitieren. Ich freue mich sehr auf die zweite Hälfte meiner beruflichen Laufbahn. Auch möchte ich künftig gemeinsam mit meiner Frau etwas mehr Zeit für die Zucht dieser wunderbaren Hunderasse finden - dem Briard.

Ich habe in der Firma Siemens Menschen getroffen, deren Kompetenz, deren Mut und deren Energie mich beeindruckt haben und es sind einige darunter, vor denen ich größte Hochachtung empfinde. Eine meiner persönlichen Theorien besagt, daß man in einem bewegten Berufsleben im Schnitt zwei neue Bekanntschaften täglich schließt. Ich habe das nie exakt nachgerechnet, diese Zahl ist also ein "gefühlter Bekanntenkreis". Wenn ich unterstelle, daß meine Theorie stimmt, habe ich in dieser Zeit also etwa 5000 Siemensianer getroffen.

Nur von wenigen dieser 5000 konnte ich mich schließlich persönlich oder mit einer Email verabschieden. Mit nahezu allen habe ich aber gern zusammengearbeitet und hoffe, unsere Wege werden sich wieder einmal kreuzen. Vielleicht werde ich den einen oder anderen einmal in einem gemeinsamen Projekt wiedertreffen. Die Welt ist klein und als Freelancer ist man bekanntlich prinzipiell käuflich. Ich werde "lebenslänglich" hier im Internet zu finden sein. Allen Kollegen und Freunden wünsche ich gutes Gelingen, ob bei Siemens, Nokia-Siemens oder anderswo.

"SoHo" ist unser privates Vergnügungsviertel im DSL-versorgten Berliner Umland. Da wir regelmäßig daheim arbeiten (ich selbst als Freiberufler, und meine Frau hat ihr Büro in einem Nebengebäude eingerichtet) haben wir uns eine entsprechende Infrastruktur eingerichtet. Für ein Büro mit kleinem (aber auch wieder nicht zu sparsam bemessenem) Budget kann das ein Beispiel abgeben. Vielleicht können Sie mit einigen Anregungen etwas anfangen.

Übersicht

Ich habe auf meinen Reisen entweder über das Kundennetz oder eine UMTS-Verbindung jederzeit VPN-Zugang zu allen Daten und Diensten des Heimatnetzes. Über eine VPN-Verbindung (Virtuelles Privates Netz) ist meine Frau mit ihrem Heimarbeitsplatz an den Server in ihrer Firma angeschlossen. Auch privat, zum Beispiel in unserer Hundezucht, ist das Internet ein unverzichtbares Kommunikationsmittel geworden. Neben der Abwicklung von viel Emailaustausch pflegen wir einen umfangreichen Internetauftritt.

Unser Wirkungsbereich erstreckt sich nicht nur über drei Ebenen im Haus und ein Nebengebäude, sondern umfaßt auch den gesamten Garten mit einer Längsausdehnung von 100 Metern. Dieser ganze Bereich ist mit Wireless LAN in mindestens guter Funkqualität abgedeckt. Einigen Nachbarn stellen wir unser Funknetz als Internetzugang zur Verfügung, so weit dieses reicht. Dabei legen wir Wert darauf, daß unser privates Netz von dem halböffentlichen sicherheitstechnisch getrennt ist.

Datenarchive werden heutzutage vor allem durch Musik und Digitalphotos belastet. Jede vollphotographierte Speicherkarte aus der Kamera trägt neue 2 oder mehr Gigabyte bei, wenn man nicht diszipliniert und rigoros löscht. Pro Video mit Roh- und Mac-Schnittinformationen meist um 1 Gigabyte. Da wir nicht dauernd mit USB-Festplatten hantieren wollen und Daten zur Dauerablage auch nichts auf einem Arbeitsplatz-PC zu suchen haben, ist Datenspeicher in der Größenordnung von derzeit 3 Terabyte installiert.

LAN- und WLAN-Telephone lösen ISDN- und DECT-Telephone schrittweise ab, da die (W)LAN-Abdeckung besser ist. Zukünftige Erweiterungen werden Kameras für eine Videoüberwachung des Außenbereichs sein.

Verkabelung und WLAN

Das Haus ist schon seit Bau (1998) mit Cat 5e-Kabel ausgestattet, das Gigabit-fähig ist. Daß man darauf achten sollte, braucht heutzutage eigentlich nicht mehr erwähnt zu werden. Die Kabel laufen sternförmig in einem Anschlußraum zusammen, wo der LAN-Verteiler und der Server stehen.

Die meisten der LAN-Anschlußdosen im Haus sind mittlerweile unbenutzt, an den strategisch günstig gelegenen befinden sich die WLAN-Accesspoints. Um nicht überall noch ein Steckdosennetzteil neben dem Accesspoint zu plazieren, werden die Accesspoints über den LAN-Verteiler mit Strom versorgt (Power over Ethernet, PoE, nach IEEE 802.3af).

Insgesamt sind fünf Accesspoints Netgear WG102 im Einsatz: drei im Hauptgebäude für das Haus und die Nahumgebung (West, Ost, Obergeschoß), einer für das Nebengebäude, einer für den Garten. Umfangreiche Experimente mit der richtigen Positionierung nur weniger Accesspoints anzustellen lohnt sich nach meiner Erfahrung nicht, denn es sind dann doch immer etliche Ecken schlecht ausgeleuchtet. Die Accesspoints sind nur auf das G-Funknetz (IEEE 802.11g, 54 Mbps) eingestellt, nicht auf den älteren Standard mit 11 Mbps, da das bei wilden Einbuchungsversuchen fremder Geräte nur die Bandbreite verschlechtern würde.

Wo im Gebäude eine bessere als die Standardantenne erforderlich ist, setzte ich die omnidirektionale Netgear ANT24O9 mit 9 dBi ein. Der Garten wird mit einer Sektorantenne Netgear ANT24D18 (die alte Bauform mit 18 dBi und Abstrahlwinkel horizontal 60°/vertikal 30°) versorgt. Dabei ist zu beachten, daß man die Leistung des Accesspoints herunterregeln muß, wenn man im Rahmen der gesetzlichen Abstrahlungsbeschränkungen bleiben will.

Jeder Accesspoint arbeitet parallel in zwei unterschiedlichen Funknetzen (d.h. verschiedenen SSID), die unterschiedlich verschlüsselt werden: das private Netz mit WPA, das halböffentliche mit WEP. Der Accesspoint ordnet diesen Funknetzen unterschiedliche VLAN-Identifikationen zu und sorgt so dafür, daß der Verkehr zwischen diesen beiden Netzen streng getrennt bleibt. Der genannte Accesspoint unterstützt "virtuelle AP" bereits seit Anfang 2006 zu einem Preis im Consumer-Segment; der Hersteller bewirbt das nicht offensiv.

WPA2 ist unbedingt zu empfehlen. Es gibt mittlerweile Algorithmen, die unter ungünstigen Umständen in ein WEP-Netz innerhalb von Minuten einbrechen können. Auch WPA der ersten Generation wird bald nicht mehr ausreichend sicher sein. Leider verstehen ältere Geräte nur WEP, und beim Kauf von neuen Notebooks im unteren und mittleren Preissegment muß man noch immer darauf achten, daß ihre WLAN-Chipsätze das effizientere WPA mit AES-Verschlüsselung (WPA2 genannt) beherrschen.

Wer hingegen ein offenes Funknetz betreibt, erlegt seinen Nutzern auf, für ihre Sicherheit selbst zu sorgen: mit ihren eigenen Firewalls, Nutzung von HTTPS, wo dies möglich ist, oder VPN in Firmennetze. Nach aktueller Rechtsprechung haftet man als Dienstebetreiber mit, wenn der Dienst mißbraucht wird, zum Beispiel für Urheberrechtsverletzungen. Man sollte also den Kreis derer einschränken, denen man den Dienst zur Verfügung stellt. Seinen Sorgfaltspflichten hat man bereits durch den Einsatz des unsicheren WEP Genüge getan. Es empfiehlt sich aber außerdem, den gängigen Webverkehr (HTTP, FTP) nur über einen Proxy zu erlauben, der die angesteuerten Internetadressen (URL) protokolliert. Dadurch kann man gegebenenfalls nachweisen, daß nicht man selbst einen Rechtsverstoß begangen hat, zu dem die eigene IP-Adresse ermittelt wurde.

Der genannte Accesspoint hat noch eine andere sehr nützliche Eigenschaft: Er unterstützt ein Leistungsmerkmal "AutoCell". Damit sucht sich der Accesspoint automatisch einen geeigneten Kanal, auf dem gerade möglichst wenig Interferenzen vorliegen, und paßt auch seine Sendeleistung dem aktuellen Bedarf an. Damit wird auch eine etwas größere Funknetzkonfiguration nachbarfreundlich, ohne daß man über die Frequenzen mit den anderen Anwohnern der Straße in Verhandlung treten muß. Aber Achtung: Ab Firmware Version 5 ist das Leistungsmerkmal AutoCell aus Lizenzgründen nicht mehr vorhanden. Benutzen Sie die höchste 4er Version, sie funktioniert problemlos, und nehmen Sie danach kein Upgrade mehr vor.

Das Nebengebäude ist mit einer Powerline-Brücke (Linksys PLK200) an das Hausnetz angeschlossen. Es lohnt sich dabei, jeweils eine Steckdose eigens für den Powerline-Adapter unmittelbar im Schaltschrank oder Anschlußkasten des Gebäudes zu installieren und statt des Einbaus von Phasenkopplern reicht es, alle drei Phasen durchzuprobieren, wo sich der beste Datendurchsatz einstellt. Jede weitere Entfernung der Steckdose kann den Datendurchsatz erheblich reduzieren.

(Ich empfehle unbedingt das Linksys-Produkt in dieser Konfiguration. Devolo dLAN Highspeed, das vom Datendurchsatz durchaus ausgereicht hätte, arbeitet in einer Konfiguration mit VLAN nicht zufriedenstellend und war eine Fehlinvestition. Die Ursache sind MTU-Probleme. VLAN vergrößern den Ethernet-Frame um einige Bytes, die dann zu überlangen Datenpaketen auf der Powerline-Brücke führen. Den Intranet-Server und alle Clients in den betroffenen Segmenten auf eine niedrigere MTU einzustellen, kann eine Lösung sein, wenn es sich bei den Clients um PC handelt. Wenn der Client aber eine Wireless Webcam oder ein LAN-Printserver ist, läßt sich dort in aller Regel keine niedrigere als die Standard-MTU von 1500 Byte einstellen. Solches sind halt die Kriterien, in denen sich ein Consumer-Produkt von einem in diesem Fall sogar preisgleichen professionellen Produkt unterscheidet.)

Virtuelle LAN

Um den Verkehr in den verschiedenen LAN-Segmenten zu separieren und trotzdem über eine einfache Kabelinfrastruktur zu führen, werden die Segmente unterschiedlichen Virtuellen LAN (VLAN, nach IEEE 802.1q) zugeordnet. Ein zentraler VLAN-Switch im Anschlußraum vermittelt diesen Verkehr und übergibt ihn über eine Gigabit-Ethernet-Schnittstelle an den Intranet-Server, der zwischen den verschiedenen Segmenten und dem Internet routet. Als VLAN-Switches kommen Linksys SLM224G4SP (mit Gigabit-Ports und Power over Ethernet) als zentraler Verteiler sowie Linksys SRW208 im Nebengebäude zum Einsatz.

Das virtuelle LAN, in dem das halböffentliche Funknetz läuft, genießt nur geringeren Schutz durch die Firewall. Es fungiert auch gleichzeitig als demilitarisierte Zone (DMZ), aus der Dienste in das Internet exportiert werden. Es versteht sich von selbst, daß Besucher, die diesen Internetzugang verwenden, für sich selbst die üblichen Schutzmaßnahmen einsetzen, die auch bei einem UMTS-Zugang zum Mobilnetz erforderlich wären.

Arbeitsstationen

Die Zeit der selbstgebauten und mit viel Mühe auf leise getrimmten PC-Türme ist vorbei. Bis auf wenige Ausnahmen kommen nur noch Notebooks zum Einsatz. Als Client-Betriebssysteme sind Mac OS X, Windows XP Professional und Windows Server 2003 im Einsatz.

Nach mehreren Jahren des Hoffens auf eine stabile und bedienbare Variante des Linux für Arbeitsstationen (wobei Ubuntu schon ziemlich dicht dran war) bin ich nun ins Macintosh-Lager gewechselt und werde für die etwas höheren Ausgaben für die Hardware mit nachhaltig geschonten Nerven belohnt. Daß Software und Hardware funktionieren, ist in der Macintosh-Welt der Normalzustand, nicht die Ausnahme. Wo sich Macintosh-Nutzer über Unzulänglichkeiten ihrer Technik beschweren, jammern sie auf hohem Niveau. Mac OS X integriert sich in die beschriebene Netz- und Serverumgebung nahtlos, und zwar vom ersten Einschalten des MacBook an.

Jede Arbeitsstation verfügt (trotz Internet-Firewall auf dem Server) über eine sogenannte Personal Firewall. Diese dient in erster Linie der Aufdeckung unerlaubter ausgehender Verbindungen. Immer mehr Anwendungen überraschen durch Geschwätzigkeit, sie wollen ohne dringende Notwendigkeit mit einem Server im Internet sprechen. Darunter kann durchaus auch einmal ein Trojanisches Pferd sein, das mehr nach außen meldet als uns lieb sein kann. Wirklicher Schutz kann aber nur durch geeignetes Zusammenwirken zwischen Personal Firewall und Internet-Firewall entstehen. Als Personal Firewall setze ich unter Windows die Outpost Security Suite ein. Diese unterstützt auch Windows Server 2003 und erlaubt genügend feingranulare Steuerung des Verkehrs auf Protokoll-, Port- und Applikationsebene. Viele andere Personal Firewalls, insbesondere diejenigen, die zu den gängigen Antivirus-Suiten gehören, sind in ihrem Wirken zu intransparent bzw. erlauben nicht die volle Unterscheidung nach Protokollen, Ports und Applikationen.

Internetzugang

Der Internetzugang erfolgt über ein kombiniertes Modem-Router-Paketfilter-Gerät. Ich verwende Lancom 1723 VoIP, das gleichzeitig als ISDN-, Analog- und SIP-Telephonanlage arbeitet und VPN-Verbindungen von außen terminiert. Es kann äußerst flexibel auf verschiedene Arbeitsmodi konfiguriert werden.

Als Router und Firewall vermittelt das Lancom-Gerät zwischen den verschiedenen VLAN-Segmenten im Haus und dem Internet. Eine Modemeinwahl ist für Wartungsfälle möglich, wenn der DSL-Internetzugang nicht funktioniert. Die Firewall besteht aus einem umfangreichen Regelsatz. Dazu gehört die Filterung des Verkehrs zwischen den VLAN-Segmenten, insbesondere natürlich der fast vollständige Ausschluß von Verkehr aus dem halböffentlichen WLAN in Richtung Intranet. Dazu gehört weiterhin die Filterung des eingehenden Verkehrs.

Als Modem unterstützt das Gerät ADSL2+ (T-DSL bis 16Mbps). VDSL-Modems oder Router sind zur Zeit noch nicht auf dem freien Markt erhältlich, sondern nur über die Telekom. Für professionelle Verwendung sind die Geräte der Telekom erfahrungsgemäß ungeeignet, da sie für den Consumer-Markt entwickelt sind und wichtige Konfigurationsmöglichkeiten fehlen.

Dem Intranet-Server stellt der Router eine feste private IP-Adresse für das Internet zur Verfügung.

LAN-Telephonie (VoIP)

Als SIP Gateway ermöglicht das Lancom-Gerät hausinterne LAN-Telephonie sowie WLAN-Telephonie über die zahlreichen Accesspoints mit automatischem Handover. Das Gateway verbindet die hausintern über LAN angeschlossenen Telephone mit dem öffentlichen ISDN-Telephonnetz. Eingehende ISDN-Rufe werden sowohl auf den entsprechenden analogen (DECT-) Stationen als auch auf den zugeordneten LAN-/WLAN-Telephonen parallel signalisiert.

Das klingt nach "verkehter Welt", denn in vielen Fällen werden hausinterne Analogtelephone über ein SIP-Gateway an einen Internet-Telephoniebetreiber angeschlossen. In unserem Fall ist solch ein Szenario unsinnig. Einerseits ist der ISDN-Dienst der Telekom (auch wenn internationale Gespräche inzwischen über ein IP-Backbone vermittelt werden) noch immer viel zuverlässiger als die VoIP-Dienste gängiger Provider für den Endkunden. Wenn man die Gesamtkosten eines Anschlusses berücksichtigt, einschließlich der Call-by-Call-Möglichkeiten bei Anrufen in etwas exotischere Zielländer, ist die Telekom inzwischen ohnehin am günstigsten. Andererseits ist die Erreichbarkeit über Accesspoints im Haus- und Gartenbereich fast überall besser als über eine DECT-Basisstation. Und schließlich kann, wer nicht ohnehin schon eine separate Telephonverkabelung im Gebäude verlegt hat, darauf verzichten und das LAN verwenden - ganz besonders, wenn ein Nebengebäude anzubinden ist.

Als fest installierte VoIP-Endgeräte kommen Lancom VP-100 zum Einsatz. Moderne Mobiltelephone, z.B. Nokia E71 Smartphones (Symbian S60), sind vollwertige WLAN-Telephone. Von der Anschaffung eines (auf den ersten Blick handlicheren) dedizierten WLAN-Telephons ist abzuraten, da sie teuer sind, vielfach schwer zu konfigurieren und die entsprechenden Produktlinien der wenigen verbliebenen Hersteller schlecht gepflegt wirken.

Server

Zwei Server kommen im Netz zum Einsatz: Ein Kommunikationsserver zuhause und ein Internet-Server bei einem der einschlägigen Anbieter. Beide Server laufen unter Debian Linux 4.0 (Etch) als Basissystem ohne graphische Oberfläche.

Internet-Server

Der Internet-Server fungiert als Web-, Email- und Proxyserver. Der Webserver umfaßt Apache 2, PHP 5 und MySQL 5. Der Emailserver besteht aus Postfix und Courier IMAP. Dazu kommen umfangreiche Maßnahmen zum Herausfiltern von Spam. Eine Übersicht über diese Maßnahmen und ihre Wirksamkeit findet sich in einem anderen Artikel. Als Proxyserver kommt Squid zum Einsatz.

Zur Administration und Synchronisierung ist der Internet-Server über Secure Shell (SSH) erreichbar, wobei nur ein Zugang mit Public-Key-Authentifizierung möglich ist.

Der Server ist ein dedizierter Server (Rootserver) von Strato. Ein virtueller Server (vServer) ist nicht zu empfehlen, wenn man viele Internetzugriffe hat und auf vorhersagbares Antwortzeitverhalten Wert legt. Strato weist gute Verbindungsgeschwindigkeit und Zuverlässigkeit des Netzzugangs auf. Hauptvorteil von Strato-Rootservern ist, daß im Grundpreis ein Konsolenzugang enthalten ist. Bei Fehlkonfigurationen im SSH oder in der Firewall oder bei anderen Netzproblemen ist dieser erforderlich; auch eine Neuinstallation des Betriebssystems (Upgrade) ist damit möglich.

Den seit etwa einem Jahr angebotenen Strato Multiserver mit der Möglichkeit, mehrere virtuelle Server auf einem physischen Server einzurichten, hätte ich gern getestet. Bei der Umwandlung des dedizierten Servers in einen Multiserver zeigt sich Strato jedoch enttäuschend unflexibel; an der Schulung des Account Managements läßt sich noch einiges verbessern.

Kommunikationsserver

Das Gerät ist eine 1 HE hohe und (dank Mini ITX-Mainboard) besonders kurze Bauform, die im Netzwerkschrank Platz hat. Die Leistung reicht für einen Kommunikationsserver vollkommen aus.

Dieser Server führt mittlerweile nur noch ein Schattendasein, da ich seine früheren Funktionen fast vollständig auf das Internet-Gateway und das NAS übertragen habe. Diese Geräte basieren mittlerweile alle auf Linux-Kernen. Die besseren Produkte gewähren auch freiwillig Zugang zu den Funktionen des Systems und die Leistung reicht zum Beispiel aus, um Mailarchive lokal zu verwalten oder Synchronisationsskripte ablaufen zu lassen.

NAS

In einer früheren Version dieses Artikels war noch von einem selbstgebauten Software-RAID in einem normalen PC-Gehäuse die Rede. Inzwischen gibt es Network Attached Storage (NAS) als Geräte mit Gigabit Ethernet-Anschluß zu vertretbaren Preisen. Ich setze Synology DS508 ein, das fünf Festplatten aufnehmen kann, nach anfänglicher Teilbestückung dynamisch erweitert werden kann und Plattenaustausch ohne Betriebsunterbrechung ermöglicht.

Vier Platten mit je 1 Terabyte ergeben eine Nutzkapazität von 3 TB im Verbund als RAID-5. Eine Eine fünfte Platte ist als Hot Spare konfiguriert, sodaß bei einem Plattenausfall sofort eine automatische Reorganisation des RAID erfolgen kann und die schutzlose Periode minimiert wird. Das ist sehr zu empfehlen, ganz besonders, wenn mehrere Festplatten aus einer Charge beschafft wurden und daher auch dieselbe Beztriebsdauer aufweisen. Es kommt nicht selten vor, daß in solch einer Konstellation zwei Festplatten binnen weniger Tage ausfallen.

Eine unterbrechungsfreie Stromversorgung (USV) schützt das NAS-Gerät und erlaubt diesem bei Stromausfall ein geordnetes Herunterfahren.

Die Sicherung der Inhalte erfolgt auf USB-Festplatten mit Kapazitäten von 1,0 oder 1,5 Terabyte. Neben einer jährlichen Sicherung, die permanent archiviert wird, existieren immer noch zwei weitere Generationen von Backups. Eine nicht zu alte Komplettsicherung wird immer außerhalb des Hauses an sicherer Stelle verwahrt - jedoch natürlich nicht in der "Cloud" im Internet.

Im Netz stellt das NAS die Daten über das Microsoft CIFS (SMB) Protokoll bereit, das auch von Linux und Mac OS gesprochen wird.

Auf dem NAS ist auch der komplette statische Internetauftritt gespiegelt, der über den Internet-Server schließlich ins Netz gelangt. Alle Änderungen erfolgen zuerst lokal und werden nach Fertigstellung über eine SSH-Verbindung (unter Verwendung von "rsync") auf den Internet-Server kopiert. Der dynamische Teil des Internetauftritts, also alle Seiten, die mithilfe von PHP aus der MySQL-Datenbank generiert werden, wird dadurch gesichert, daß jede Nacht auf dem Internet-Server ein Shellscript (neben anderen Sicherungsaktionen) die Datenbankinhalte in eine Archivdatei schreibt, die sich der Intranet-Server mit "rsync" automatisch abholt. Zusätzlich werden bei diesem Schritt auch alle Daten auf den Intranet-Server kopiert, die durch Nutzer auf den Internet-Server hochgeladen wurden.

Vielen Dank für Ihr Interesse

Weitere Informationen finden Sie gelegentlich in unserem Wiki. Wenn Sie Fragen oder Hinweise haben, schreiben Sie bitte an bez@tedesca.com oder benutzen Sie das Nachrichtenformular.