Schwanebeck ist nicht gerade reich an Attraktionen. Zu nennen wäre vielleicht die Mülldeponie, die einst der Stadt Berlin zu Diensten war, dank einer Entgasungsanlage als eine der modernsten überhaupt gilt und inzwischen zu unserer Freude stillgelegt ist. Die Entgasungsanlage entgast weiter, fängt sozusagen die Rülpser des Berges auf, heizt damit das nahegelegene Klinikum Buch und hält die Umgebung des Berges von üblen Gerüchen frei.

Zu nennen wäre auch das Autobahndreieck Schwanebeck, wo die Autobahn nach Stettin abzweigt. Manchmal wird es in den Nachrichten erwähnt und versorgt leider auch das nahegelegene Klinikum Buch öfter mit Kunden. (So hängt in Schwanebeck alles irgendwie miteinander zusammen.) An der Popularität der einschlägig bekannten Knotenpunkte in Nordrhein-Westfalen kann Schwanebeck sich aber nicht messen.

Eine kleine Sehenswürdigkeit hat Schwanebeck aber doch zu bieten. Unser Nachbar Dr. Alfons Weise hat in den vergangenen Jahren eine Kunstgattung entwickelt und zur Blüte gebracht, die wir Säulenpittoreske nennen möchten. Tatsächlich gab es wohl bislang kein Wort, das diese Installationen in ihrer surrealen Gewalt, die zuweilen an Magritte erinnert und besonders vor strahlend blauem Himmel höchst wirkungsvoll zur Geltung kommt, treffend beschreibt.

Spekuliert wird noch über die regelmäßig gewählte Konstruktionsform, bei der die Objekte eine meist weiße Säule krönen. Sei es aus praktischen Gründen der besseren Sichtbarkeit und des leichteren Rasenmähens, sei die Säule als konstituierendes Element und Aussageträger dieser Kunstform zu verstehen - jedenfalls erlaubt dieser Aufbau das zwanglose Arrangement der Disponate in ihrer eklektischen Vielfalt als frei assoziiertes Spannungsfeld.

Zu finden ist die Ausstellung in der Lübecker Straße in Schwanebeck-Bergwalde, Gemeinde Panketal bei Berlin.

... 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.BIZ.

"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 Tedesca® ist beim Deutschen Patent- und Markenamt geschützt.

Es war einmal ein guter Freund, der weilte zur Zeit der Herrschaft des Kaisers Hu Jintao in China. Er war von seinen Hauptleuten wegen wichtiger Geschäfte in eine kleine Stadt in der chinesischen Provinz beordert worden. Höchstens 4 Millionen Seelen umschloß der Ort, und das Leben an den langen Winterabenden war unendlich öd und trist. Der Freund vermochte nicht in der Zunge des gemeinen Volkes zu reden, auch ging jeder des Abends seiner Wege und den Freund dürstete es nach Neuigkeiten, die seine Seele zu erquicken vermöchten. Wie froh war er, als er in seiner bescheidenen Herberge einen Internetanschluß fand! Aber groß war sein Erschrecken, als er die Neuigkeiten des Tages von CNN hören wollte und von der Wikipedia nähere Informationen über die Stadt begehrte, in der er gerade weilte. Denn Kaiser Hu hatte nicht wollen leiden, daß seine Untertanen ihre Zeit mit Tand und Glitzer vertäten anstatt die Wohlfahrt des Hofes und der kaiserlichen Manufakturen zu mehren, und seine Präfekten und Minister angewiesen, streng gegenüber jeder Anmaßung und Hoffahrt in seinem Volke zu sein. Da wurde der Freund sehr traurig und haderte mit seinem Schicksal.

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.

Anfang Oktober mußte ich meinen 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 habe ich 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 nochmals 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 ich vermutet hatte, daß in 2008 die Zahl der eingehenden Emails die Marke von 1 Million überschreiten würde, mußte ich 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 derzeit jährlich mindestens.

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 ich diesen Test nach wenigen Wochen wieder deaktiviert habe. 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 erprobe ich 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

Ich lese oft, daß die Spamversender, die nach meinen 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 kann ich aber nicht erkennen. Solange Greylisting so wirkungsvoll ist, hat die Gemeinde der Spamversender ihre Möglichkeiten noch lange nicht ausgeschöpft. Außer einem kürzlich beschriebenen Weg, Google Mail zu verwenden, ist mir in den vergangenen Monaten kein Aufblitzen von Innovationsfreude aufgefallen. Es ist wie oft in der Netz- und sonstigen Wirtschaft: Es wird versucht, Mangel an Innovation durch Steigerung des Volumens auszugleichen.

Auch die verwendeten Adreßlisten und Wörterbücher ändern sich kaum noch. Innerhalb einer durchschnittlichen Woche mit 55.000 eingehenden Emails wurden 2200 verschiedene Phantasieadressen verwendet. Die Top 25 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 nw-b5request@barnim.net lcmaynard@barnim.net prettyboy3@barnim.net rainbowkevin@barnim.net outslay@barnim.net labore@barnim.net sbraggj@barnim.net mkrofchi@barnim.net sueavonnn@barnim.net ordersusa@barnim.net ollieweb@barnim.net sports4life8@barnim.net richard.bomber.lancaster@barnim.net richard.akre@barnim.net lkmejias@barnim.net

Erstaunlich dabei ist, daß die seit 2004 aktive Domain tedesca.net noch immer keine Rolle spielt. Ausnahmen sind

• richard.bomber.lancaster@tedesca.net auf Platz 85
• 46dca57e.3010608@tedesca.net weit abgeschlagen
• hard.bomber.lancaster@tedesca.net - sic!

Wir führen hier noch eine neue Adresse ein und sind gespannt, wie oft wir sie in einem Jahr wiederfinden werden: new_december07@tedesca.net

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.

In einer Vorgängerversion dieses Artikels aus dem Jahr 2003 waren noch ziemlich viele graue Kästen erforderlich, um ein zufriedenstellendes Hausnetz aufzubauen. Inzwischen sind die mit dem Budget des Soho-Nutzers erreichbaren Ergebnisse wesentlich attraktiver als vor 5 Jahren. Diese Beschreibung (mit Stand 2008) und die Aussagen zu Produkten beruhen auf eigenen Erfahrungen. Ansonsten stehe ich mit den Herstellern in keinerlei Beziehung.

Small Office - Home Office

"Soho" ist unser ganz privates Vergnügungsviertel im DSL-versorgten Berliner Umland. Meine Frau hat ihr Büro in einem Nebengebäude eingerichtet und ich selbst arbeite ebenfalls oft daheim.

Über eine VPN-Verbindung (Virtuelle Private Netze) ist meine Frau an ihr Firmennetz angeschlossen. Ich habe auf meinen Reisen entweder über das Kundennetz oder eine UMTS-Verbindung jederzeit VPN-Zugang zu allen Daten und Diensten des Heimatnetzes. 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. Nachbarn stellen wir unser Funknetz als Internetzugang zur Verfügung, so weit dieses halt 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 Gigabyte bei, wenn man nicht diszipliniert und rigoros löscht. 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 2 Terabyte installiert.

Zukünftige Erweiterungen werden zu gegebener Zeit WLAN-Telephone und Überwachungskameras sein. Die WLAN-Telephone werden die DECT-Telephone ablösen, sobald die Technik dafür reif genug ist. Und seit auch in unserer Gegend gelegentlich eine Hauswand besprüht wird, verdichten sich wieder die Pläne, eine Videoüberwachung einzurichten.

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, daß dies vorgesehen ist, braucht heutzutage 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: einer pro Gebäudeebene, 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 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ß.

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. Dazu gehört zum Beispiel eine Kamera, mit der wir zeitweise Videos von unseren Briardwürfen ins Internet übertragen, die "Welpenkamera".

Arbeitsstationen

Die Zeit der selbstgebauten und mit viel Mühe auf leise getrimmten PC-Türme ist vorbei. Bis auf wenige Ausnahmen kommen fast 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 äußerst flexibel in verschiedenen Arbeitsmodi konfiguriert werden kann. Dem Intranet-Server stellt der Router eine fixe private IP-Adresse (10.x.x.x) für das Internet zur Verfügung.

Server

Zwei Server kommen im Netz zum Einsatz: Ein Intranet-Server 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.

Intranet-Server

Der Intranet-Server fungiert im wesentlichen als Router und Firewall zwischen den verschiedenen Segmenten des Heimnetzes und dem Internet. Er ist über eine einzelne Gigabit Ethernet-Verbindung, über die alle VLAN transportiert werden, an den zentralen Switch angeschlossen. 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.

Als Router und Firewall vermittelt der Intranet-Server zwischen den verschiedenen VLAN-Segmenten im Haus, dem Internet und der Modem-Einwahlverbindung. Die Modemeinwahl ist für Wartungsfälle vorgesehen, wenn der DSL-Internetzugang nicht funktioniert. Die Firewall besteht aus einem umfangreichen Iptables-Regelsatz, insgesamt etwa 150 Einzelregeln. 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, den der Modem-Gateway-Router hindurchläßt.

Fast ebenso wichtig ist heutzutage aber die Filterung des ausgehenden Verkehrs. Im Zusammenspiel mit den Personal Firewalls auf den einzelnen Arbeitsstationen sollte die Firewall (neben anderen Maßnahmen) HTTP- und HTTPS-Verkehr grundsätzlich blockieren, sofern dieser nicht über einen bestimmten Proxy geleitet wird. Damit werden unerwünschte Verbindungsaufnahmen vieler Applikationen nach draußen unterbunden.

Vom Internet her ist das Intranet nur über Secure Shell (SSH) erreichbar. Wenn man die Möglichkeiten von SSH richtig ausschöpft, lassen sich auch Windows-Laufwerke über das Internet verschlüsselt verbinden. Auch die Modemeinwahl führt erst einmal in eine Sackgasse, die erst nach SSH-Anmeldung Zugriff auf den Intranet-Server erlaubt. Nach einigen Versuchen, Linux und Windows mit IPsec zu verbinden, habe ich entnervt aufgegeben. Sicherlich kann es funktionieren, und die Versuche liegen auch schon einige Jahre zurück. Da SSH aber alles leistet, was wir benötigen, habe ich das Thema nie wieder aufgegriffen.

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.

Drei Platten mit je 1 Terabyte ergeben eine Nutzkapazität von 2 TB im Verbund als RAID-5. Eine zweimalige Erweiterung um jeweils ein Terabyte auf maximal 4 TB Nutzkapazität ist möglich, bevor in die nächste Technologiestufe investiert werden muß - was auch immer das in einigen Jahren sein mag.

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

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

Vielleicht können Sie mit einigen Anregungen etwas anfangen. Weitere Informationen finden Sie gelegentlich in unserem Wiki. Wenn Sie Fragen oder Hinweise haben, schreiben Sie bitte an bez@tedesca.net oder benutzen Sie das Nachrichtenformular.

Nutzer von Thunderbird und anderen Emailprogrammen kennen das Problem: Dateianlagen von Emails, die mit Outlook oder Outlook Express gesendet wurden, sind nicht lesbar. Stattdessen hat die Email nur einen Anhang namens "winmail.dat", mit dem das Emailprogramm nichts anfangen kann.

Das Problem ist, wie üblich, Microsoft. Microsoft hat ein sogenanntes "Transport Neutral Encapsulation Format" (TNEF) erfunden. Dazu gehört der MIME-Typ "application/ms-tnef". Warum das Format "transportneutral" genannt wird, weiß man nicht. Nur innerhalb der Microsoft-Welt ist es neutral.

Insbesondere entstehen TNEF-Anhänge, wenn die Email im sogenannten Rich Text Format gesendet wird. Grundsätzlich ist es sowieso besser, eine Nachricht als einfachen Text zu senden. Wer in Emails unbedingt farbigen Text oder Fettdruck will, sendet gern Rich Text Format - er weiß wahrscheinlich nicht, daß bei vielen Empfängern nur einfacher Text ankommt, die dann den farbigen Text oder den Fettdruck überhaupt nicht würdigen können.

Ist aber eine Email mit einem Anhang winmail.dat angekommen, gibt es folgende Möglichkeiten:

1. Benutzer von Thunderbird können im Thunderbird ein Plug-in namens "LookOut" installieren. Dieses ist unter https://addons.mozilla.org/en-US/thunderbird/addon/4433 erhältlich. Die genannte Webseite ist Englisch und das Plug-in funktioniert leider nicht im deutschsprachigen Thunderbird. Folgende Schritte sind erforderlich:

• Plug-in auf die eigene Festplatte herunterladen
• im Thunderbird den Untermenüpunkt Add-ons auswählen
• Installieren... auswählen
• die soeben heruntergeladene Datei suchen
• den weiteren Anweisungen folgen und schließlich Thunderbird neu starten

Künftig werden alle in den winmail.dat verborgenen Anlagen angezeigt und können geöffnet oder gespeichert werden.

2. Als Alternative für andere Emailprogramme oder für das deutschsprachige Thunderbird gibt es den "Winmail Opener" unter http://www.eolsoft.com/de/freeware/winmail_opener. Er wird nach dem Herunterladen wie ein normales Programm installiert. Zur Benutzung speichert man die winmail.dat-Anlage auf seiner Festplatte, ruft das Programm Winmail Opener auf und öffnet dann die winmal.dat damit.

Beide (das Plug-in und das normale Programm) sind kostenlos.

Nachdem wir bereits in Jahr 2005 einige Auswertungen zum Spamverkehr gemacht haben, folgt hier eine Auswertung von August 2006 bis Juni2007, also über 11 Monate. Es wird erläutert, welche Maßnahmen in dieser Periode wesentlich zur Reduzierung des Spamaufkommens beigetragen haben.

	Emails	Anteil	SPF	Erläuterung
connection loss	10.072	2,0%		Verbindung durch die Gegenseite unerwartet beendet. Zum Beispiel nur ein Portscan.
hostname verify	63.442	12,4%		Der "Reverse DNS Lookup" ordnete der IP einen Namen zu. Beim normalen Lookup wurde zu diesem Namen aber keine IP geliefert. Das deutet auf eine dynamische IP-Adresse.
HELO without FQDN (504)	100.513	19,6%		Beim Aufnehmen der Verbindung mit dem HELO-Kommando gab die Gegenstelle keinen vollen eigenen Domainnamen an, sondern zum Beispiel nur etwas wie "localhost".
HELO host verify (550)	108.339	21,1%		Beim Helo-Kommando wurde ein nicht im DNS registrierter Domainname angegeben. Achtung: Es gibt einige wenige "gute" Mailserver, die so etwas tun. Diese muß man in die Weiße Liste aufnehmen.
failed with protocol errors	282.366	55,0%		Fehler gesamt bis zur Verbindungsaufnahme
no mailbox (554)	191.993	37,4%		Die Email wurde an eine nicht bekannte Adresse geschickt, zum Beispiel weil Adressen nach Wörterbuch durchprobiert wurden.
SPF softfail	2.399	0,5%	6%	Laut SPF-Eintrag ist die Absenderadresse nicht zulässig.
SPF hardfail	1.830	0,4%	4%	Laut SPF-Eintrag ist die Absenderadresse nicht zulässig.
failed before greylisting	478.588	93,2%		Fehler gesamt bis zur Adreßprüfung
SPF none	34.145	6,6%	78%	Kein SPF-Eintrag.
SPF neutral	1.862	0,4%	4%	Keine verwertbare Information aus SPF.
SPF pass	3.346	0,7%	8%	SPF hat ausdrücklich "gut" zurückgemeldet.
greylisted (450)	34.961	6,8%		Gesamtzahl von Nachrichten, die zuerst auf der Grauen Liste gelandet sind.
no repeat	22.510	4,4%		Der gegnerische Server hat nach dem ersten Abweisen durch die Greylist nicht erneut gesendet.
spamfilter	7.164	1,4%		Durch Spamassassin abgewiesen.
failed total	508.262	99,0%		Fehler gesamt
incoming	513.549	100,0%		eingegangene Nachrichten
pass	5.287	1,0%		gute Nachrichten

Mehr als die Hälfte allen Spams werden wir schon dadurch los, daß wir nach einigen strengen Prüfungen gar nicht erst mit dem Gegner sprechen.

smtpd_helo_restrictions = permit_tls_clientcerts
permit_sasl_authenticated
permit_mynetworks
check_helo_access hash:/etc/postfix/map_helo_access_white
reject_invalid_hostname
reject_non_fqdn_hostname
reject_unknown_hostname
check_helo_access hash:/etc/postfix/map_helo_access_black

Fast noch einmal die Hälfte wird abgewiesen, weil die Empfängeradresse gefälscht ist.

SPF (Sender Policy Framework) bewirkt fast nichts, weil gerade einmal ein Fünftel des Verkehrs (was nicht notwendig einem Füntel der Domains entspricht) davon erfaßt wird. Es ist zu vermuten, daß wir die meisten der durch SPF entdeckten Spamnachrichten auch mit Greylisting eliminiert hätten.

Die verbleibenden 7% der eingehenden Nachrichten werden noch einmal sehr wirkungsvoll mit Greylisting gefiltert. Der Spamfilter (Spamassassin) eliminiert zwar auch noch einmal jede zweite der verbleibenden Nachrichten - in der Absolutzahl etwa so viel, wie SPF schafft. Man sollte seinen Beitrag in der gesamten Filterkette aber nicht überbewerten.

smtpd_recipient_restrictions = permit_tls_clientcerts
permit_sasl_authenticated
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unauth_destination
check_recipient_access hash:/etc/postfix/map_recipient_access_grey
check_policy_service inet:127.0.0.1:60000
check_policy_service unix:private/spf
check_recipient_access hash:/etc/postfix/map_distribution_lists
check_recipient_access hash:/etc/postfix/map_recipient_access_white
reject

Ein Prozent der Nachrichten kommt schließlich durch, wobei unter diesen Nachrichten der Spamanteil nur noch zwischen 10% und 20% liegt.

Oder immerhin noch 10 bis 20 Prozent verbleibender Spam; wie man es sehen will. Der technische Aufwand, diesen auch noch herauszufiltern, wäre aber immens.