Diesem Artikel ist der Artikel “Homeserver: Planung der Komponenten” vorausgegangen.

Mein Eindruck von der Hardware war von vornherein positiv. Alles was solide verpackt, nichts wackelte. Keine Kratzer oder ähnliches. Der Zusammenbau ist für jeden der schon mal einen Rechner zusammen gebaut hat sicherlich logisch - wenn auch manchmal etwas kniffelig. Das ganze System ist eben wirklich sehr eng gestrickt.

Das Mainboard wird auf eine Platte montiert die T-Förmig auf dem Rückteil montiert ist. Diese kann im ganzen in einer Art Führungsschiene herausgezogen werden , was die Montage erheblich erleichtert. Unter dem Mainboard bleibt so platz für die vier Festplatten und die Spannungswandler. Das ganze ist schwer zu beschreiben - wenn man das Gehäuse gesehen hat aber eigentlich ganz logisch. Das Belüftungskonzept ist sehr durchdach - an der Rückseite des unteren Teils (mit den Festplatten) befinden sich zwei Lüfter die Luft an den festplatten vorbei über die Spannungswandler. Im oberen Teil werkelt in meinem Fall nur der CPU-Lüfter. Wenns hier zu heiß wird könnte aber auch noch ein Lüfter montiert werden.

In meinem Fall waren die Kabel allesamt bereits vormontiert. SD-Kartenleser und FrontUSB auch. Ich musste lediglich das Mainboard bestücken (Speicher und CF-Karte) und verschrauben. Unschön ist dass sich am Gehäuse zwei LEDs für die LAN Aktivität finden, auf dem Mainboard aber keine Pins dafür vorgesehen sind. Auch die Warning-LED ist ohne Funktion. Mich stört das nicht das ich das Gehäuse eh nie sehe - wer sich sowas aber als Prestigegerät in die Vitrine stellt könnte isch daran stören. Desweiteren passen die USB-Anschlüsse vom Cardreader und vom FrontUSB nicht auf das Mainboard da sich auf diesem lediglich Mini-USB Pinheader befinden (2mm) - das Gehäuse hat die normalen USB - Stecker. Ohne Adapter (bei mir hieß der “Adapter Mini USB 2mm“) geht da nichts. Da ich mir den aber nun nicht gekauft habe (und das vorerst auch nicht plane) kann ich da von keinen Erfahrungen berichten - vermute aber dass das wohl problemlos funktionieren wird.

Für die folgenden Fotos habe ich das Mainboard montiert und angeschlossen. Später habe ich noch einige Kabel in den Unteren Teil des Gehäuses verbannt um die Durchlüftung im oberen Teil zu optimieren. Die Bilder entstanden aber vorher. Außerdem einige Bilder vom Mainboard selbst - vor allem auf der Rückseite sicher sehr interessant da man hier mal sieht wo CF-Karte und MiniPCI Karte Monitiert werden können.

Was mir negativ auffiel

• Neben dem genannten Problem mit den USB Anschlüssen und den LEDs, die ich aber nicht so kritisch sehe da es für das eine eine Lösung gibt und mir das andere Egal ist ist mir Negativ aufgefallen dass weder zum Gehäuse noch zum Mainboad eine gedruckte Bedienungsanleitung geliefert wurden. Beim Mainboard wars auf der Treiber CD - von außen ist das aber nicht zu erkennen - beim Gehäuse lediglich aus dem Internet zu beziehen. Für Europäische Verhältnisse echt schwach.
• Wenn man auf dem Board eine PCI-Express-Karte montieren möchte ist keine Aussparung auf der Rückseite vorgesehen um da vielleicht mal eine Kabel anschließen zu können.
• Das Schloss ist einfach für den Allerwertesten und hätte getrost eingespart werden können.

Was mir positiv auffiel

• Die Kabel zur Festplattenbackplane waren vorbildlich beschriftet, so dass eine Zuordnung zu den Ports auf dem Mainboard problemlos möglich war.
• Die Verarbeitung wirkt durchweg solide.
• Das System ist selbst in der Standardkonfiguration angenehm Leise.
• Das Raumaufteilungskonzept ist gelungen das dazugehörige Lüftungskonzept auch

Betriebssystem

Das System dann zu installieren stellte sich als schwieriger heraus als zunächst angenommen. Nach langem hinundher entschied ich mich für einen Ubuntu Server. Einfach weil der aktuelle Pakete liefert und ich so nicht in die Verlegenheit komme dass das neues Filesharing programm XYZ nicht laufen mag. Außerdem hab ich so immer was zum basteln - weil eben wahrscheinlich auch immer gerade irgendwas nicht funktioniert :o) (aber Spaß beiseite.).

Da sich der On Board CF-Slot und die IDE-Buchse einen IDE-”Kanal” teilen funktioniert nur das eine oder das andere, wobei die CF-Karte Vorrang hat. Bleibt also nur die Installation über USB-CDRom. Hier stand ich aber gleich vor dem nächsten Mysterium. Bei ubuntuusers im Wiki liest man dass für VIA Eden Prozessoren auf die Alternate CD zurückgegriffen werden soll. Diese Installation kommt aber offenbar nicht mit USB-CDRom Laufwerken klar. Die normale Serverinstallation hingegen lief. Wichtig ist also - wenn man eine CF-Karte nutzt braucht man wahrscheinlich ein USB-CDRom.

Der Rest der lief Problemlos. Das System schein an sich flot zu agieren. Die CF-Karte ist aber nicht die schnellste so dass man den Einruck hat das Schreiboperationen immer etwas träge sind. Des weiteren habe ich lm-sensors mit dem Distributionskernel nicht davon überzeigen können mir einige Temperaturwerte auszuliefern. Damit werde ich mich nochmal beschäftigen - vielleicht gibt’s also später nochmal was über den “c7temp” Kernelpatch zu lesen.

Leistung

Um die Leistung objektiv beurteilen zu können werde ich mich mal an ein paar Benchmarks wagen.  Dazu komme ich aber in einem späteren Artikel. Subjektiv ist es verhält es sich beim allgemeinen Arbeiten flott - Festplattenoperationen auf der CF-Karte scheinen aber sehr träge.

(Fast) Jeder kennt das: man hat gemütlich am Laptop im Internet Musik gekauft und dann sitzt man im Arbeitszimmer und kann sie nicht anhören weil sie auf dem Laptop ist. Andersherum hat man ewig an einer Ausarbeitung gesessen und dann ist man bei einem Kumpel dem man das ganze vorführen möchte und kein Weg führt an die Dateien. Doch noch viel schlimmer: Das Notebook steckt zum laden an der Dose während man gerade noch am arbeiten ist, .. der Blitz schlägt ein und das Notebook samt Festplatte ist hinüber.

Gegen all solche Sachen ist ein Kraut gewachsen - die zentrale Datenhaltung. Musik, Videos, Dokumente, all das wird einfach Zentral auf einem dedizierten System abgelegt. Moderne Netzwerke ermöglichen es von quasi jedem Punkt auf dieser Erde auf die Daten zuzugreifen. Um das Backup kümmern sich entsprechende Automatismen. Zur Sicherheit liegen alle Daten nicht nur Verschlüsselt auf dem Server sondern werden per RAID auch auf eine zweite Platte gespiegelt.

Doch solche Dienste bieten auch noch mehr Wert. Filesharingprogramme können sich damit beschäftigen, Dateien herunter und herauf zu laden, während man des Nachts schläft. Drucker können über einen Printserver geteilt werden. Webcams können softwaregesteurt ausgewertet werden und schicken E-Mails wenn was vorfällt. Aber was erzähl ich hier - wer in diesem Blog liest, ist sich der Möglichkeiten eines solchen Homeservers wahrscheinlich längst bewusst oder hat gar schon einen.

Die Anwendungsmöglichkeiten sind jedenfalls schier unendlich. Ohne auf jede einzelnen Möglichkeit weiter einzugehen, möchte ich hier vorstellen wie ein solches System aufgebaut sein könnte.

Anforderungen

Was für Anforderungen gibt es an die Hardware?

• Der Prozessor muss in der Lage sein eine vernünftige Festplattenverschlüsselung zu stemmen ohne die Schreibgeschwindigkeiten auf Schneckentempo einzuschrumpfen
• Es muss genügend Arbeitsspeicher am Start sein um auch “Moderne” Filesharingprogramme zum laufen zu bekommen
• Dem Speicherplatz sollten zumindest auf Logischer ebene keine Grenzen gesetzt werden; Das bedeutet dass es Möglich sein sollte, nachträglich noch zusätzliche Platten einzubauen oder zumindest die vorhandenen Platten gegen größere zu tauschen ohne die ganzen Daten erst auslagern zu müssen
• Die Stromkostenabrechnung sollte nicht zum erblinden oder zu nervlichen Störungen führen

Und wie lösen wir das Problemchen?

Nein nicht mit einem Wölkchen (Schleichwerbung) sondern eben mit passender Hardware. Um genau zu sein mit Hardware die in der Lage ist aus möglichst wenig Strom möglichst viel Leistung heraus zu holen. Dabei haben sich bekannte (Prozessor-)Hersteller schon Gedanken gemacht und in Form von Mobile- und Embeddedprozessoren ihre bestehenden Prozessortechnologien auf besonders niedrigen Stromverbrauch getrimmt. Im Mobilprozessormarkt werden hierbei meist die normalen Desktop CPUs genutzt deren Leistung dann gesenkt wird. Für den Embedded Bereich werden meist eigene Prozessoren entwickelt die dann aber für Desktop Anwendungen meist untauglich sind.  In diesem Fall sind die Embeddedprozessoren also deutlich näher am Anwendungsfeld. Bekanntester Vertreter ist hier  Intels “Atom” Prozessor. Aber Auch AMDs Geode Reihe ist den meisten ein Begriff - weniger bekant ist dagegen vermutlich VIAs Prossoren Serie. Hierbei handelt es sich quasi immer um Prozessoren die fest auf einem Mainboard verlötet sind. Bei den ersten beiden stamen diese Mainboards nicht zwangsweise vom Hersteller selbst - bei VIA dagegen schon.

Prozessor und Mainboard

Doch von vorn. AMDs Prozessoren sind schlecht entwickelt. Der Hersteller scheint sich nicht weiter um diese Reihe zu kümmern und konzentriert sich lieber darauf seine Desktop- und Mobilprozessoren auf einen vernünftigen stand zu bringen. Bei der Entscheidung zwischen Intel und VIA habe ich einen spannenden Vergleich gefunden bei dem die beiden Leistungsstärksten Embeddedprozessoren der beiden Hersteller miteinender Verglichen werden. Es handelt sich um Intels Atom 330 Prozessor mit 1,6 GHz auf einem D945GCLF und um einen VIA C7 Prozessor mit 1.8GHz auf einem EPIA-SN18000G. Der Test lohnt auf jedenfall gelesen zu werden. Er hat mich dazu bewogen mich für die VIA CPU zu entscheiden und zwar auf genau dem dort genutzten Board.

Dieses hat aber auch noch weitere Features die mit dem (zumindest mit dem originalen) Intel Board gar nicht so ohne weiteres möglich wären. Es bietet zum beispiel einen Compact Flash Slot den ich später nutzen werde um das Betriebssystem auf stromsparende Weise auf einer Simplen CF-Karte abzulegen. Zudem bietet es 4 SATA Schnittstellen - das könnte später wenn es um die Erweiterbarkeit geht noch sehr praktisch sein. Es kann 4 GB Arbeitsspeicher aufnehmen und das absolute Killerfeature - es hat einen PCI Express Slot und einen Mini PCI Slot!!

VIA selbst stellt hier den absolut interessanten VIA EPIA SN180000G Operating Guide (PDF) zur Verfügung den ich von meinen Händler per E-Mail bekam.

Gehäuse

Eigentlich war ich auf der Suche nach einem IPC-Tauglichen Wallmount Gehäuse für MiniITX Systeme. Da ich aber offenbar der einzige bin der sowas sucht musste ich leider feststellen dass es sowas wohl nicht gibt. Während meiner Recherchen bin ich aber über ein anderes interessantes Gehäuse gestoßen. Das Chenbro ES34069 bietet 4 Festplattenslots die sogar bequem Hotswapable von außen erreichbar sind (leider unterstützt das Mainboard das vermutlich nicht, aber es erleichtert die Wartung sicher trotzdem ungemein). Wenn man den Beiträgen in diversen Foren trauen darf handelt es sich hierbei wohl um eine Art Revolution im Homeservermarkt. Jedenfalls wurde es bereits mehrfach getestet und für Gut befunden (1, 2 und 3, und 4 dienten mir als Informationsquelle). Das schönste ist eigentlich dass eine Netzteil schon mit dabei ist (120 Watt oder 180 Watt), wodurch der recht hohe Preis wenigstens ansatzweise gerechtfertigt wird. Leider ist das Gehäuse in keinster Weise gegen Staub, wie er bei meinem nicht näher beschriebenen Installationsort zu erwarten ist, geschützt. Hier muss ich also noch etwas Handarbeit anlegen.

Hier wieder sehr schön anzusehen - das Chenbro ES34069 User Manual. Viele Informationen für alle Informations- und Rezensionversklavten wie mich.

Kalkulation

Billig wirds vermutlich nicht, … hier eine Preisübersicht. Zusammengestellt bei Amazon (die CF Karte) und einem örtlichen Händler (der Rest). Die Installationsmaterialien beziehe ich aus meinen Vorräten und in Bezug auf die IPC-Tauglichkeiten aus dem Baumarkt.

251.68 Euro (VIA EPIA SN18000G) Mainboard

045,18 Euro (2 mal Kingston 2048MB KVR533D2N4) Arbeitsspeicher

198,90 Euro (Chenbro ES34069 120 Watt) Gehäuse

028,34 Euro (Kingston CFCard 16GB) Compact Flash Karte

010,00 Euro Installationsmaterial
----------------------------------------------------------------
534,10 Euro
===========

Für etwas mehr als 530 Euro bekommt man heutzutage also das Grundsystem für ein NAS welches leistungstechnisch absolut auf dem Stand ist und wohl noch die nächsten 5 Jahre treu seinen Dienst leisten kann. Ich finde den Preis OK. Nochmal etwa 400 Euro kann man aber rechnen wenn man das Gerät auch ordentlich ausstatten will. Ich übernehme 2 terrabyte große Festplatten aus meinem alten Homeserver, so dass ich die hier mal außen vor lasse.

Wies weiter geht, …

Die Komponenten sind nun bestellt und ich warte gespannt auf Lieferung. Wies weiter geht lest ihr im Artikel “Homeserver: Installation” wo ich zunächst den zusammenbau und die Installation der Systeme beschreibe.

Ich muss dazu sagen, dass dieses Script eigentlich dafür gedacht war, die Ausgabe via SNMP abzufassen und dann in Cacti darzustellen. Leider ist es dazu nicht gekommen.

Das Script macht sich aber auch zur “Just-in-Time” Kontrolle der Query-Quantität ganz gut oder um die Ausgabe mit einen kleinen Shell-Script-Wrapper in ein RRD zu schreiben und dann als Graph darzustellen.

In etwa würde das auf einer Linux-Shell dann so aussehen:

[root@server bin]# watch -n10 “./mysql_query_stat.pl -u root -p password -h mysqlserver -n 10 -SQUID;”

Every 10,0s: ./mysql_query_stat.pl -u root -p password -h mysqlserver -n 10 -SQUID;

QPSnow:      471
QPSall:        731
Selects/s:    381
Inserts/s:    16
Updates/s:   9
Deletes/s:   7

Dieser Befehl erzeugt die Ausgabe der jetzigen Query-Quantität aller 10 Sekunden. Für ander Optionen (wie z.B. die gut zu parsende One-Liner Ausgabe) könnt Ihr euch das Script ja mal anschauen.

Für Fragen, Anregungen, Bug-Reports oder Feature-Wünsche wäre ich dankbar.

Das Script gibts natürlich hier.

MfG Maddin

• Rechner einschalten
• im Bootmenü das OS auswählen
• das OS, in meinem Fall Linux (Ubtuntu 8.04 LTS), starten
• Kaffee holen / auf Toilette gehen / Glotze anschalten und auf den Login warten

Da es mich aber mittlerweile etwas genervt hat, das die Boot-Zeit meines Systems mittlerweile bei knapp 1 Minute und 10 Sekunden liegt, was bei Bereitschaftsdiensten Nachts um 4 ganz schön lange sein kann, habe ich mich mal nach einem Visualisierungstool für den Linux-Boot-Prozess umgesehen.

Nach ein paar googlern bin ich dann auf bootchart gestoßen. Dieses Tool ermöglicht es Grafiken des Boot-Prozesses anzufertigen, in dem ausgewiesen wird, wann und zu welcher Zeit, welcher Prozess mit wieviel IO- und CPU-Last zu Gange ist.

Nach dem installieren und dem neuerstellen des initramfs (geschieht bei rpm’s und deb’s automatisch) kann man das System zum ersten Test rebooten. Nach erfolgreicher Tat solltet Ihr unter /var/bootchart/bootchart-$date-x.png eine Grafik haben in der Ihr die Reihendfolge und Zeiten ablesen könnt. Das ganze sieht dann ungefähr so aus.

Nach dem abschalten (bei mir via update-rc.d -f $initscript remove) der für mich nicht benötigten Dienste (cupsys - hab kein Drucker, bluetooth - kann manuel gestartet werden wenn benötigt, vmware - manueller start, openvpn - manueller start etc. pp.) veringerte sich die Bootzeit auf etwa 44 Sekunden.

Immerin knapp 25 Sekunden schneller als vorher. Abder da geht noch mehr. Nachdem ich dann wieder den Bootchart analysierte, fiel mir ein Init-Script Names readahead auf. Wieder kurz gegoogelt und siehe da, readahead wird als eines der ersten Scripte im runlevel S (also bei jedem Start) aufgerufen und liest Dateien (binaries, configs, libs etc. pp.) aus einer Datei (/etc/readahead/boot) ein, sodass diese sich im Filesystem-Cache aka RAM befinden. Der Vorteil dieser Methode ist, dass Linux auf diese schon einmal eingelesenen Daten, ein paar 1000 mal schneller zugreifen kann (etwa 100 ns) als von der Festplatte (etwa 5 ms).

Um readahead an die eigenen Boot-Bedürfnisse optimal anzupassen, kann man nach dem einbinden des Init-Scripts (bei Ubuntu Standard) beim reboot auf der Kernel-Kommandozeile (booten, Grub Auswahlmenü e drücken, kernel Zeile auswählen, wieder e drücken) das Schlüsselwort profile hinzufügen. Hat man dies getan drückt man b und der Boot-Vorgang beginnt. Hat alles geklappt kommt nach etwa 5 Sekunden eine Auschrift ähnlich “Readahead starts profiling boot process…“. Nach dem booten sollte es dann unter /etc/readahead/boot eine aktuelle Version der Konfiguration für readahead geben. Dies sollte man nach jedem Kernel-Update wiederholen, da dann ja wieder andere Treiber usw. geladen werden.

Nach diesem Prozedere habe ich es geschaft meine Boot-Zeit von etwa 1 Minute und 10 Sekunden auf etwa 33 Sekunden hearab zu setzen. Meiner Meinung nach ein ganz schöner Unterschied.

Jetzt seid Ihr dran. Vorher-Nacher vergleiche erwünscht.

MfG
Maddin

Nein - wer Adaptec/ICP RAID-Controller im produktiven Einsatz hat, wird das Problem kennen. Entweder man überlässt die Überwachung des RAID-Verbundes und des Controllers dem Zufall oder man installiert sich eine 50 MB große Java-Umgebung, um dann via X-Fowarding eine Speicherfressende Java-Console zu beäugen.

Und da Adaptec auch das aaccli (IMHO Adaptec Command Line Interface) nicht mehr für 64-bit System weiterentwickelt (für dieses CLI gab es ebenfalls einen Perl-Wrapper) es aber dafür arcconf (keine Ahnung was das bedeuten soll) gibt, habe ich dafür mal einen kleinen Perl-Wrapper gebaut der die Ausgaben parsed und je nach Stati die gewünschten Nagios Exit-Codes zurück gibt.

Interessierte finden das Script hier.

Über Kritiken, Anregungen oder Verbesserungsvorschläge würde ich mich wie immer freuen.

MfG

Maddin

Worauf ich zu sprechen kommen möchte, ist ein Script Namens sa-stats.pl. Dieses Perl Script, implementiert von David Ramsden, wertet SpamAssassin-Einträge aus Maillogfiles aus und gibt diese, aufgesplittet nach Spam und Ham, in tabellarischer Form aus. Dies ist z.B. sinnvoll um zu sehen welcher der User oder welche Domain prozentuall den meisten Spam erhält.

Da es unsere Mail-Admin’s aber auch interessiert, welche Filter dazu führen dass eine Mail als Spam deklariert wird, wurde ich beauftragt eine kleine Erweiterung des Scripts zu schreiben, welche die Quantität und den prozentualen Anteil der Filter augibt. Kurz gesagt eine Auswertung der von SpamAssassin vernwendeten Filter.

Interessierte finden das Script hier. Über Kritik, Lob, Anregungen oder sonstige Kommentare würde ich mich freuen.

Obwohl SSH an sich schon sehr Sicher ist, kommt es doch gelegentlich zu erfolgreichen Angriffen die es dem Angreifer dann natürlich unter Umständen ermöglichen Root-Rechte zu erlangen. Häufigste Ursache für den erfolgreichen Angriff sind in der Praxis meist schwache Passwörter und falsch konfigurierte SSH Daemons. Aus diesem Grund möchte ich hier darauf eingehen wie man den SSH Zugriff gegen diese beiden Faktoren härten kann.

Welcher Daemon ist der richtige?

Hier könnte man sich nun sicher schön streiten, jedoch ist OpenSSH nach angaben von openssh.org mit über 80% der meist Vertretene SSH-Daemon überhaupt, weshalb ich hier nur auf diesen eingehen Möchte. Zudem wird er von allen wichtigen Linux Distributionen schon in Paketform mitgeliefert und selbst unter Mac OS X läuft dieser Seit version 10.1. OpenSSH unterstützt beide Protokollversionen und liegt derzeit in Version 5.0 (vom 03. April 2008) vor. Die Sammlung von kleinen Tools umfasst neben dem eigentlichen Serverprogramm sshd auch die Clientprogramme ssh, scp und sftp zur verfügung. Dazu gesellen sich dann noch die Werkzeuge ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen und sftp-server. Die anderen Daemons sind aber sicher auch nicht schlecht.

1. Stufe: Protokollversion

Sicherheitshalber sollte heutzutage nur noch die SSH-Protokoll Version 2 genutzt werden. Die Version 1 ist durch die Verwendung des recht schwachen CRC-32 (Cyclic Redundancy Check mit 32 Bit) anfällig für einen Man in the Middle Angriff in dem gefälschte Pakete in die Verbindung eingeschleußt werden können. Der Patch der dies erkennen sollte (SSH CRC32 attack detection) lässt sich aber zu einem Speicherüberlauf überreden der es erlaub die Authentifizierung zu umgehen. Die Protokollversion 2 festzulegen ist ganz einfach in dem man zunächst in der SSH-Konfiguration (/etc/ssh/sshd_config) darauf achtet das hinter Protocol außschließlich eine 2 steht und anschließend den SSH-Daemon neu startet.

/etc/init.d/ssh restart

Dies kann Problemlos auch aus einer SSH-Session heraus geschehen - bestehende Verbindungen werden bei dem Neustart nicht abgebrochen.

2. Stufe: Publickey Authentifizierung

Unter bestimmten Umständern kann es unheimlich praktisch sein beim Administrieren verteilter Rechner Zeit zu sparen in dem man sich beim SSH oder SCP Login nicht mit einem Passwort authentifizieren bzw. sich nur ein Passwort für alle Systeme merken muss. Als Beispiel seien hier Verbindungen verschiedener Clusternodes untereinander, Virtueller Maschinen vom Virtualisierungsserver aus oder innerhalb des Heimnetzwerkes genannt.

Hierzu wird ganz einfach ein Schlüsselpaar erstellt welches welches aus einem Privaten und einem Öffentlichen Schlüssel besteht. Der Private Schlüssel wird dabei im Benutzerprofil gespeichert, der Öffentliche Schlüssel wird auf dem Zielsystem hinterlegt. Beim Verbindungsaufbau wird nun vom Server ein Zufälliger Text erstellt und mit dem Öffentlichen Schlüssel verschlüsselt. Dieser verschlüsselte Text wird dann an den Client gesendet welcher den Text mit seinem Privaten Schlüssel entschlüsseln kann. Diesen entschlüsselten Text sendet er an den Server zurück wodurch er bestätigt dass er im Besitz des Privaten Schlüssels ist. Wenn der empfangene Text mit dem Ursprungstext übereinstimmt ist sicher gestellt das der Client auch wirklich Vertrauenswürdig ist.

In der Praxis funktioniert das natürlich alles von selbst. Hierbei wird zunächst mit ssh-keygen ein Schlüsselpärchen erstellt. Dabei wird mit -t der Schlüsseltyp übergeben.

ssh-keygen  -t rsa

Dabei wird man zunächst nach dem identity file gefragt (standard mäßig ist das <homedir>/.ssh/id_dsa) in dem später der private schlüssel gespeichert wird. Dann bekommt man die Gelegenheit ein Passwort für den schüssel einzugeben. Je nach Anwendungsgebiet ist das schwer zu empfehlen. Man tauscht ja nur das Passwort gegen eine “Datei” - dabei würde die Sicherheit natürlich nur geringfügig erhöht. Deswegen wird hier ein passwort fetsgelegt welches dann zur benutzung des Schlüssels gebraucht wird. Nach der wiederhohlten Passworteingabe wird der Fingerprint des öffentlichen Schlüssels ausgegeben - dieser braucht hier aber nicht weiter zu interessieren.

Neben dem Identiy file legt ssh-keygen auch noch eine gleichnamige .pub Datei an in der sich der zugehörige Öffentliche Schlüssel befindet. Der inhalt dieser Datei muss nun auf dem Zielrechner als Autorisierter Schlüssel eingetragen werden. Dazu wird einfach der Inhalt der Datei auf dem Zielsystem in die <homedir>/.ssh/authorized_keys Datei eingefügt.  Der letzte Schritt ist nun in der SSH-Konfiguration (/etc/ssh/sshd_config) die entsprechenden Optionen zu aktiveren. Im wesentlichen sind das:


PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys


Selbsterklärend eigentlich wird zunächst diese Authentifizierungsmethode freigegeben und anschließend festgelegt in welcher Datei der Öffentliche Schlüssel zu suchen ist. Nach einem neustart des SSH-Daemons sollte das ganze funktionieren.

3. Stufe: Logfileauswertung

Ein wenig Paranoid mag dieser Weg erscheinen, doch auch wenn man bereits die Publicey Authentifizierung nutzt kann ein Bruteforceangriff natürlich nicht ausgeschlossen werden. Die Chancen hier tatsächlich noch einen Treffer zu landen tendieren stark gegen Null, doch ist dies eine sehr effektive Angriffsmethode um den Angreifer auch von anderen gefährdeten Diensten fern zu halten. Jeder Anmeldeversuch wird in eine Logdatei geschrieben und protokoliert. Hier ist es also eigentlich sehr leicht einen Bruteforceangriff zu erkennen. Natürlich schaut aber niemenad ständig in diese Logfiles und wenn man mal einen blick dafür findet ist es eventuell schon zu spät. Selbst wenn der Angreifer nach einer weile entnervt aufgeben sollte könnte er eventuell versuchen den FTP oder Webserver zu kompromitieren - hier kann man also geschickt vorgreifen.

Wichtig zu nennen sind hier zwei Programme: swatch, welches alle Möglichen Logfiles überwachen und mit Hilfe regulärer Ausdrücke auswerten kann und denyhosts (http://denyhosts.sourceforge.net/), welches speziell auf das auswerten fehlgeschlagener SSH Verbindungen ausgerichtet ist. Beide Dienste schreiben die IP-Adresse des Angreifers in die /etc/hosts.deny. Zweit genannter mag zwar “weniger können”, erfüllt seinen job dafür aber zuverlässiger, da die Verarbeitung der Logfiles hier ständig durch die Authoren gepflegt wird - aus diesem Grund entscheide ich mich für denyhosts.

Distributionsabhängig ist denyhosts bereits ab Werk als Paket verfügbar. In meinem Besipiel nutze ich Debian, es ist allerings auch nicht wirklich schwer es aus den Quellen zu installieren. Es ist lediglich von Python v2.3 oder höher abhängig.

aptitude install denyhosts

Unter Debian ist die Installation wie immer sehr leicht. Das Distributionseigene Paket ist im Prinzip bereits in einem Funktionsfähigen Zustand. Trotzdem sollte man sich bestimmte Parameter der /etc/denyhosts.conf anschauen. In den meisten Distributionspaketen ist die Standarkonfigurationsdatei sehr gut Dokumentiert. Unter /usr/share/denyhosts/denyhosts.cfg-dist sollte sich andernfalls aber ein gut Dokumentiertes Beispiel finden.

• SECURE_LOG: Aus dieser Datei liest denyhosts die Fehlgeschlagenen Loginversuche ab
• HOSTS_DENY: In diese Datei werden die Erkannten IP-Adressen geschrieben
• BLOCK_SERVICE: Dieser Dienst wird als zu blockierender Dienst angegeben. Standardmäßig steht hier sshd, dies sollte auf jedenfall durch “ALL” erstezt werden, damit auch andere Dienste wie der Webserver keine Verbindungen mehr von diesem Host annehmen
• DENY_THRESHOLD_INVALID: Die Anzahl an Fehlversuchen die ein Host starten darf bis er gesperrt wird
• SMTP_* und ADMIN_EMAIL: Diese Optionen erlauben es sich über gesperrte Host per E-Mail informieren zu lassen.

Zum Abschluss muss der Dienst nach den Anpassungen noch neu gestartet werden.



sh /etc/init.d/denyhosts restart

Um sicher zu stellen das auch wirklich alles Funktioniert sollte man sich von einem anderen Host einfach versuchen einige Male hintereinander “falsch” anzumelden. Nach einigen Versuchen sollte die IP-Adresse in der hosts.deny auftauchen (und es sollte keine Verbindung mehr möglich sein), wo man sie beim selbsttest natürlich einfach wieder entfernen kann. Falls man das nicht manuel tuen möchte kann denyhosts auch so konfiguriert werden dass die Adressen selbstständig freigegeben werden.

Das eigentliche Problem der Basic-Authentication ist, dass diese Passwörter und Nutzernamen im Klartext übertragen werden. Leider ist das ja nicht immer gewollt und unter umständen sehr unsicher.

So hier nun zur Konfiguration. Am einfachsten klappt es in dem Ihr, im zu schützenden Verzeichnis, eine .htaccess Datei anlegt und folgenden Inhalt hinzufügt:

AuthUserFile /var/www/domain.tld/secret/.htpasswd

AuthType Basic

AuthName "Secret Site"

require valid-user

SSLrequireSSL

ErrorDocument 403 /redirect.php

Die ersten 4 Einträge sollten klar sein. Mit SSLrequireSSL erzwingt man denn Zugriff via HTTPS. Wird die Domain nur mit HTTP aufgerufen, antwortet der Apache mit einem 403 Fehler. Dies fangen wir mit dem Eintrag ErrorDocument 403 /redirect.php ab. In diesem steht nur:

<?php

header('Location: https://www.domain.tld/secret/');

?>

So leiten wir alle normalen HTTP anfragen direkt auf HTTPS um. Danach erfolgt die Basic Authentication. Und schon wird die Authentifizierung nur noch über HTTPS abgewickelt.

Tolle Sache

XSLT (Extensible Stylesheet Language Transformation) ist eine noch recht junge Sprache die aus DSSSL 120hervorgegangen ist. Sie übersetzt einfache XML-Inhalte nach den in der XSLT-Datei festgelegten Regeln in eine Andere Sprache - zumeist HTML. Dazu wird ein sogenannter XSLT Prozessor genutzt der das XML entweder Serverseitig Transformiert und so schon HTML an den Client ausliefert oder der Browser übernimmt diesen Part und übersetzt lokal. Nähere Information bietet hier wie immer die Wikipedia121. Ich zeige hier in erster Linie den Weg über den Browser auf da die Kompatibilität inzwischen in meinen Augen ausreichend ist (IE ab Version 6, Mozilla ab Version 1.0.2).

PHP-SimpleXML ist eine Reihe von Funktionen die PHP anbietet um im XML Dateien aus Objekten zu erzeugen oder Objekte aus XML-Dateien zu erstellen. Dazu bedient sie sich einer DOM Struktur. SimpleXML ist ein Bestandteil von PHP der Version 5 und wird Standardmäßig mitinstalliert. Die meisten Provider bieten diese Funtionen auch an. Weitere Infos bietet hier PHP.net122 selbst.

Was wir hier nun probieren wollen ist mit PHP-SimpleXML XML Dateien zu erzeugen die dann mit XSLT Dargestellt werden. Erfahrungen mit PHP, HTML, CSS und XML an sich sind dabei vorausgesetzt. Ziel ist es eine Nutzerliste wie sie zum Beispiel in einem Forum zu sehen wäre anzuzeigen. Die Möglichkeiten sind natürlich unendlich ;o) .

XML erzeugen mit PHP-SimpleXML

Zunächst wird ein neues SimpleXML Objekt erzeugt.

$xmlstr =  "<?xml version=\"1.0\" encoding=\"UTF-8\"?>";
$xmlstr .= "<?xml-stylesheet type=\"text/xsl\" href=\"nutzerliste.xsl\"?>";
$xmlstr .= "<NUTZERLISTE>";
$xmlstr .= "</NUTZERLISTE>";
$xml = new SimpleXMLElement($xmlstr);

Dies geschieht mit new SimpleXMLElement dem ein fertiger XML-String übergeben wird. In diesem Fall ist das die Standard XML-Definition, gefolgt von der Angabe des XSLT-Skripts und der Definition eines Elements. Nun werden einige Nutzer angelegt. Dazu würde man sich im Normalfall wahrscheinlich eine Datenbankanfrage bedienen - da dies aber nur ein Beispiel ist zeihe ich hier folgendes Array heran:

$nutzerarray = array();

$nutzerarray[0] = array('name' => 'Ralf', 'wohnort' => 'Dortmund', 'geburtstag' => '25.09.1962');
$nutzerarray[1] = array('name' => 'Stefan', 'wohnort' => 'Berlin', 'geburtstag' => '06.06.1981');
$nutzerarray[2] = array('name' => 'Georg', 'wohnort' => 'Pirna', 'geburtstag' => '13.06.1951');
$nutzerarray[3] = array('name' => 'Maik', 'wohnort' => 'Dresden', 'geburtstag' => '15.04.1969');

Jetzt wir das Array mit einer passenden Schleife durchlaufen um mit Hilfe der von SimpleXML gegebenen Funktionen um dazu jeweils ein Element im in der Nutzerliste zu erzeugen. Dazu nutze ich in erster Linie die PHP-Funktion addChild mit der zunächst an meine Haupt-XML-Klasseninstanz einen neuen Zweig angehängt wird. Als Ergebnis daraus erhalte ich eine neue Klasseninstanz im Objekt $nutzerobject welche mir nun erlaubt diesen neuen Zweig zu verändern. Dabei werden wiederum addChild Funktionen genutzt um den eigentlichen Inhalt einzufügen. Natürlich könnte man hier auch mit Attributen des Zweigs arbeiten - dies würde diese Anleitung aber unnötig kompliziert machen.

foreach($nutzerarray as $nutzer)

    {

$nutzerobject = $xml->addChild("NUTZER");
$nutzerobject->addChild("NAME", $nutzer[name]);
$nutzerobject->addChild("WOHNORT", $nutzer[wohnort]);
$nutzerobject->addChild("GEBURTSTAG", $nutzer[geburtstag]);

}

Wenn das XML-File nun ausgegeben wird finden wir eine Wohlgeformte XML Struktur, die aber mangels XSLT noch nicht sehr Anschaulich aussieht (Grün). Wichtig ist - da wir den XML-Baum ja dynamisch mit einer PHP Datei erzeugen eine passende Headerinformation mitzusenden die dem Browser verrät das es sich hierbei nicht um eine einfaches Textfile sondern um XML Inhalte handelt.

header('Content-Type: text/xml');
echo $xml->asXML();

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="nutzerliste.xsl"?>

<NUTZERLISTE>

    <NUTZER>

        <NAME>Ralf</NAME>

        <WOHNORT>Dortmund</WOHNORT>

        <GEBURTSTAG>25.09.1962</GEBURTSTAG>

    </NUTZER>

    <NUTZER>

        <NAME>Stefan</NAME>

        <WOHNORT>Berlin</WOHNORT>

        <GEBURTSTAG>06.06.1981</GEBURTSTAG>

    </NUTZER>

    <NUTZER>

        <NAME>Georg</NAME>

        <WOHNORT>Pirna</WOHNORT>

        <GEBURTSTAG>13.06.1951</GEBURTSTAG>

    </NUTZER>

    <NUTZER>

        <NAME>Maik</NAME>

        <WOHNORT>Dresden</WOHNORT>

        <GEBURTSTAG>15.04.1969</GEBURTSTAG>

    </NUTZER>

</NUTZERLISTE>

Dies ist der erzeugte XML-Code der in der Browserausgabe natürlich noch nicht so umwerfend aussieht. Im unterschied zu normalen Inhalten haben wir bis zu diesem Zeitpunkt aber noch kein Stückchen HTML gebraucht. und mussten uns darüber auch keine sorgen machen wie das ganze später mal aussieht. Für andere Programme ist es dank XML ein leichtes darauf zuzugreifen.

Aus XML werde HTML

Um dies nun Optisch anschaulicher zu machen wird sich des XSLT bedient um eine Sinnvolle Ausgabe zu erzeugen. Wie bereits in der XML-Stylesheet Definition festgelegt wurde benötigen wir dazu die Datei nutzerliste.xsl. Zunächst der nötige Kopfteil:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" />

Wie gewohnt wird also zunächst die XML-Version und das Encoding bestimmt. Für XSL muss der Namespace und die “Ausgabesprache” HTML festgelegt werden.

<xsl:template match="/NUTZERLISTE">

Jetzt geht es schon mit den XSL-Befehlen los. NUTZERLISTE wird als Hauptzweig festgelegt. Dies verhält sich wie ein Filter. Die in diesem Zweig festgelegten Regeln werden nur angewandt wenn der Hauptzweig NUTZERLISTE heißt. Um nun aber zum HTML zu kommen kann in diesem Bereich Ganz normal mir allen HTML Elementen gearbeitet werden.

<html>
<body>

<table>

Natürlich muss dabei auch eine normale HTML Deklaration erfolgen. In diesem Fall lege ich im Header nichts fest - es wäre hier aber gut möglich auch ein CSS-Stylesheet anzugeben um das Design noch ein wenig dynamischer zu gestalten.

<xsl:for-each select="NUTZER">

<tr>
 <td><strong>Name:</strong></td>         <td><xsl:value-of select="NAME" /></td>
 <td><strong>Wohnort:</strong></td>      <td><xsl:value-of select="WOHNORT" /></td>
 <td><strong>Geburtstag:</strong></td>   <td><xsl:value-of select="GEBURTSTAG" /></td>
</tr>

</xsl:for-each>

XSL Stellt ganz normale Schleifen zur Verfügung wie sie bei anderen Programmiersprachen auch bekannt sind. In diesem Fall wird mit xsl:for-each für jenen Nutzer Zweig der eingeschlossene Code ausgeführt. Dabei wird eine Tabellenzeile erstellt die mit Hilfe von xsl:value-of mit Werten gefüllt wird. Eine logische Angelegenheit eigentlich.

</table>
</body>

</html>

</xsl:template>

</xsl:stylesheet>

Die vielen geöffneten tags müssen natürlich noch geschlossen werden. Ein abschließender Aufruf der zuvor erzeugten PHP-Datei ist vom Browser gemäß den Festgelegten Regeln formatiert Der Zurück gelieferte Quelltext ist noch immer reinstes XML und vollkommen unabhängig vom Design. Die wichtigsten Werkzeuge um beispielsweise ein Templatingsystem für einen Blog zu implementieren hätten wir so im Prinzip schon in der Hand. Doch das ist noch nicht alles - XSL ist noch viel mächtiger.

Grenzenlos mit XSL

XSL kann die zurück gelieferten XML Inhalte nicht einfach nur wiedergeben sondern auch sinnvoll auswerten. Dies kann zum einen Sinnvoll sein im bestimmte Designelemente eben nur anzuzeigen wenn sie Tatsächlich einen Einhalt haben (Leerer Warenkorb?), um Abstufungen zu bieten (Fortschrittsbalken) oder gar um Fremdquellen auszuwerten.

Nachfolgend eine Angepasste Version der Zählschleife von oben:

Insgesamt <xsl:value-of select="count(NUTZER)"/> Einträge

<table>

<xsl:for-each select="NUTZER">

<xsl:if test="starts-with(WOHNORT, 'D')">

<tr>

<td><strong>Name:</strong></td>         <td><xsl:value-of select="NAME" /></td>
<td><strong>Wohnort:</strong></td>      <td><xsl:value-of select="WOHNORT" /></td>
<td><strong>Geburtstag:</strong></td>   <td><xsl:value-of select="GEBURTSTAG" /></td>

</tr>

</xsl:if>

</xsl:for-each>

</table>

Hier ist zunächst eine spezielles value-of dazu gekommen was mit count() Ausgibt wie viele Nutzer wir denn insgesamt haben. Zudem wurde in der for-each Schleife Ein xsl:if hinzugefügt. Diesem wird eine Bedingung mitgegeben und falls diese Wahr ist werden die darin liegenden Regeln ausgeführt. In diesem Fall muss der Wohnort mit ‘D’ beginnen.

Die Ausgabe ist jetzt zunächst eine Angabe wie viele Einträge sich im Array befinden und dann wie bereits vorher die Nutzer - nur das diesmal nur die beiden Einträge bei denen der Wohnort mit ‘D’ anfängt angezeigt werden.

<xsl:for-each select="NUTZER">
<xsl:sort select="WOHNORT"/>

<tr>

<td><strong>Name:</strong></td>         <td><xsl:value-of select="NAME" /></td>
<td><strong>Wohnort:</strong></td>      <td><xsl:value-of select="WOHNORT" /></td>
<td><strong>Geburtstag:</strong></td>   <td><xsl:value-of select="GEBURTSTAG" /></td>

</tr>

</xsl:for-each>

Eine weitere Praktische Funktion ist das Sortieren - xsl:sort ist ein Kindelement der for-each Schleife und Bestimmt dessen Sortierung - in diesem Fall wird nach dem Wohnort in Alphabetischer Reihenfolge Sortiert - möglich wäre hier aber auch mit order=”descending” zum Beispiel eine umgekehrte Sortierung und Ähnliches. Der Befehl kann auch mehrfach hintereinander eingesetzt werden falls sich zum Beispiel ein Ortsname doppelt und dann nach Name sortiert werden soll.

Mehr, mehr, mehr!

… gibt es zum Beispiel auf data2type.de123 und auf xml-xslt.de124. Hier gibt es ein XSLT-Tutorial125 sowie eine Befehlsreferenz (von data2type.de126 sowie etwas umfassender von xml-xslt.de127). Des weiteren gibt es ein schönes Buch von Doug Tidwell welches man zum “auf den Geschmack kommen” auch Online einsehen128 kann. Dies waren im großen und ganzen auch meine Hauptquellen für diesen Artikel. Ansonsten sind Informationen hierzu eher weitläufig gestreut - besonders im Bezug auf Test-Funktionen. Aber im Allgemeinen findet man dank Google schon was man sucht.

Weitere interessante Links:

• http://de.selfhtml.org/xml/darstellung/index.htm129
• http://www.usegroup.de/software/xmltutorial/index.html

Dateien aus diesem Beispiel:

• xslt_phpsimplexml.tgz

XSLT bietet eine der wenigen Möglichkeiten Design und Content in PHP wirklich vollkommen von einander zu trennen. Im PHP-Code muss sich kein Stück HTML-Code befinden. Wenn nun noch alle Eingabewerte vernünftig gefiltert werden steht der sicheren Programmierung nichts mehr im Wege. Auf jeden Fall ein Thema mit dem sich jeder ambitionierte Webdesigner mal näher beschäftigen sollte.

Hier kommt die Lösung, auf dieses Problem:

sed -n '/^CREATE TABLE foobar/,/^)\;/p' dump.sql

Wie einfach doch die Welt sein kann. Dieser Einzeiler eignet sich natürlich hervorragend um auch andere Daten aus Texten heraus zu schneiden.

[UPDATE]

Natürlich geht das auch wunderschön mit Perl:

cat test.txt | perl -ni -e 'print if m/^ANFANG/..m/^ENDE/;'