byte-arts.NET

Morgen (8.06.2011) ist ja der World IPv6 day und daher möchte ich euch folgende Seite vorstellen, mit der ihr prüfen könnt, ob ihr schon IPv6-fähig seid: test-ipv6.com

Wer eine Disk Station von Synology besitzt, dem werden diese Befehle in bestimmten Fällen durchaus nützlich erscheinen. Beispielsweise startet die Disk Station nach einem Stromausfall, bzw. ungeplantem Herunterfahren zwar noch, jedoch ist das Webfrontend nicht mehr erreichbar.

0 => Aktiviert den An-/Ausschalter der NAS

1 => Schaltet die NAS aus (Shutdown)

C => Startet die NAS neu (Reboot)

Vorraussetzung ist natürlich, dass der Zugang per SSH auf die NAS zuvor aktiviert war und natürlich auch noch funktioniert.

Wie erstellt man ein SSH-Zertifikat um sich sicher mit einem Linux-Server zu verbinden? Das geht ganz einfach – mit Abstrichen. Folgendes als root über die Konsole/Putty auf dem Server ausführen:

ssh-keygen -t rsa -b 2048

Damit werden der private und öffentliche Schlüssel mit RSA und 2048 Bit erzeugt. Für weitere Einstellungsmöglichkeiten siehe Handbuch. Jetzt wird zuerst gefragt, wo man die Dateien speichen möchte. Wenn nichts angegeben wird, werden die Dateien unter /root/.ssh/ als id_rsa und id_rsa.pub gespeichert. Wenn für einen anderen Nutzer SSH-Schlüssel angelegt werden sollen, dann muss man mit diesem die Schritte ausführen. Dabei werden die Dateien in dem entsprechenden Home-Verzeichnis (/home/$username/.ssh/) angelegt. Danach wird nach einer Passphrase gefragt, welche die Sicherheit natürlich nochmals erhöht – kann aber auch einfach leer gelassen werden.

Als nächstes muss die Datei authorized_keys im selben Verzeichnis angelegt werden. Dieser muss über folgenden Befehl der öffentliche Schlüssel hinzugefügt werden:

cat id_rsa.pub >> /root/.ssh/authorized_keys

Damit sind die Arbeiten, soweit man nicht die Konfigurationsdatei unter /etc/ssh/sshd_config weiter anpassen möchte, auf dem Server abgeschlossen. Weiter gehts auf dem PC. Doch zuvor muss der private Schlüssel auf diesen, bspw. über WinSCP, runtergeladen werden. Der öffentliche bleibt auf dem Server.

Wer jetzt denkt, dass man den Schlüssel einfach in Putty angibt, wird mit der Meldung begrüßt, dass Putty damit nichts anfangen kann. Man muss zuerst den Schlüssel in ein Format konvertieren, was Putty versteht.

Dazu braucht man PuttyGen. Zuerst muss der Schlüssel in das Programm geladen werden, dazu wird, falls bei der Generierung eine angegeben wurde, nach der Passphrase gefragt. Danach speichert man den privaten Schlüssel ab und gibt diesen dann in Putty an. Und schon klappt die sichere Verbindung zum Server.

Optional kann in der Konfigurationsdatei die Anmeldung per Passwort verboten werden, oder dass ein anderer Port verwendet wird, was Angriffe verringert.

Heute mal wieder etwas technisches. Wer einen Server sein eigen nennt und diesen, sei es als physischen Server oder als virtuellen Client, mit Linux/Debian bestückt hat, kennt das eventuell auch den Maildienst Exim. Bei Debian 5 ist die Version 4 des Daemons dabei. Einzurichten ist er relativ einfach über die Konsole, jedoch kann es passieren, dass trotzdem keine Mails verschickt werden können. Ein Blick in das Log (/var/log/exim4/) zeigt dann auch warum, nämlich:

… jon.do@example.com: Unrouteable address

Die Einrichtung also erneut über folgenden Befehl starten:

dpkg-reconfigure exim4-config

Soweit so gut, doch was hat man falsch gemacht? Typischer Fall von RTFM, denn bei Schritt 4 heißt es, dass man eine kommaseparierte Liste von Domains eingeben soll, um die sich Exim selbst kümmern soll. Wer da nun eine Domain eingetragen hat, wie bspw. Google.com, hat was falsch gemacht, denn nur, wenn der Server die Verteilung und Annahme als richtiger Mailserver übernehmen soll, dann müssen hier die entsprechenden Domains eingetragen werden. Wer also einfach nur möchte, dass Mails nach außen verschickt werden können, bspw. über ein Kontaktformular, welches auf einem Webserver läuft, dann muss dieses Feld leer bleiben.

Wenn die Konfiguration abgeschlossen ist, muss der Dienst nur neu gestartet werden und sollte funktionieren.

/etc/init.d/exim4 restart

Quelle & mehr: exim4 unrouteable address error: A Lesson in RTFM

byte-arts.NET bietet schon seit über einem Jahr einen kostenlosen und frei zugänglichen TeamSpeak Server an. TeamSpeak Server sind speziell für die Kommunikation über das Internet beim Spielen ausgelegt, da die Bandbreite, sowie die Prozessorlast sehr gering sind und damit keinen unnötiger Traffic im Gegensatz zu bspw. Skype erzeugt wird. Mehr Informationen findet ihr auf der Webseite von TeamSpeak.

Zuerst in der Version 2, nun in der Version 3 (zur Zeit noch Beta) ist unser Server über die Adresse ts.byte-arts.net erreichbar. Einfach die Adresse (Port ist der Standardport) im TeamSpeak 3 Client angeben und los gehts. Unser Server bietet Platz für bis zu 32 Clients und besitzt im Moment 12 Channels, unter anderem für Left 4 Dead 2, Alien Swarm, Call of Duty: Modern Warfare 2 und Homeworld 2.

Wenn Ihr die Möglichkeit dazu habt, ist die Installation und Verwaltung eines TeamSpeak Servers nicht schwer. Für Hardcore-Gamer lohnt es sich auf jeden Fall.

Zuerst einmal der Hinweis darauf, dass es vollständige Anonymität im Internet nicht gibt. Wozu also den Aufwand betreiben, wenn es doch sowieso nicht 100%tig geht? Das kann man gut mit der Ausfallrate von einem Server vergleichen, welche meistens über 99%, jedoch nie bei 100% liegt. Garantieren kann keiner, dass der Server nicht ausfällt, aber die Wahrscheinlichkeit ist sehr gering. Genau so verhält es sich mit der Anonymität im Internet. Keiner kann garantieren, dass man 100%tig anonym ist, aber je besser man sich “verkleidet“, desto geringer ist die Wahrscheinlichkeit identifiziert zu werden.

An dieser Stelle sei gesagt, dass dieser Artikel nicht darauf abzielt unerkannt bei diversen Tauschbörsen oder Filehostern Dateien herunterzuladen, sondern lediglich einen Einblick in die Möglichkeiten zur Anonymisierung im Internet gibt.

Jetzt zum eigentlichen Thema. Wie findet man zuerst einmal heraus, welche Informationen überhaupt preisgeben werden, wenn man bspw. eine Webseite besucht? Auf MeineIPAdresse.de kann ein Privacy Check gemacht werden, damit man einen Einblick in die vom Browser übermittelten Informationen erhält. Allen vorran dient natürlich die IP-Adresse zusammen mit der Zugriffszeit als teilweise eindeutige Identifikation. Teilweise deshalb, da damit nur der Teil einer Verbindung vom Provider zum jeweilen DSL-Anschluss des Kunden eindeutig bestimmt werden kann.

Der Vorteil daran ist, dass zwar der Provider, dem die IP-Adresse angehört, bekannt ist, man jedoch nicht ohne dessen Zustimmung Einblick in die Liste bekommt, worin steht, welcher Kunde zu diesem Zeitpunkt über die IP verbunden war. Diese Zustimmung gibt der Provider natürlich keinem x-belibigen auf Nachfrage, sonder nur in bestimmten Fällen heraus. Wann so ein Fall eintritt hängt von der Gesetzeslage ab.

Wie kann man also seine IP-Adresse anonymisieren? Die Antwort: gar nicht! – Zumindest nicht 100%tig, wie schon im ersten Absatz erwähnt. Es gibt natürlich die Möglichkeit einen oder mehrere Proxy zu verwenden. Wer einfach nur mal auf die schnelle eine Seite besuchen möchte die anhand der IP-Adresse entscheidet, ob der Inhalt (bspw. ein Video) angezeit wird, kann Hide My Ass benutzen. Dieser kostenlose Dienst funktioniert über ein Suchfeld, in das man die entsprechende URL der Webseite eingibt und anschließend über einen Proxy auf die Webeite weitergeleitet wird. Damit kennt die Webseite nur die IP-Adresse des Proxy und nicht mehr die des Providers (sofern es natürlich kein transparenter Proxy ist).

Der Proxy widerum kennt natürlich die IP-Adresse des Providers noch und desshalb ist diese Art der Verbindung nicht anonym, sondern nur schwerer zu identifizieren. Eine Auswahl an Proxy findet man auf Proxy-listen.de. Einen Schritt weiter gehen ganze Proxy-Netzwerke, wie Tor und JAP, bei denen die Verbindung über mehrere Proxy bzw. Teilnehmer am Netzwerk hergestellt wird. Hierbei wird es immer schwerer die Verbindung zurück zu verfolgen – es ist aber nicht unmöglich! Das ganze Konzept beruht eher auf Security through obscurity.

Natürlich gibt es noch viele weitere “Erschwerungsmethoden” bzw. Dinge die man beachten sollte, wie das Deaktivieren von JavaScript und das Abhören der Verbindung, welches bspw. durch SSL verhindert werden kann.

Ein von Google entwickeltes Modul names Page Speed für den Apache HTTP Server 2.2 soll Webseiten schneller vom Browser laden lassen. Das Modul liegt derzeit in 32 und 64 Bit für die Betriebssyteme CentOS/Fedora und Debian/Ubuntu vor. Das ganze ist Open Source und für Entwickler gibt es auch ein SDK zum Download.

Zusätzlich bietet Google auch das gleichnamige Add-on für den Firefox, welches Stand Alone arbeitet oder sich, falls installiert, in den Firebug integriert. Das Add-on gibt anhand eines Rankings Aufschluss über die Geschwindigkeit einer Webseite und stellt zudem die aufgetretenen Probleme, nach Priorität geordnet, inklusive möglicher Lösungen dar.

Das Modul und das Add-on können hier runtergeladen werden. Ebenfalls findet man dort und bspw. bei golem.de weitere Informationen dazu.

In diesem Artikel wird beschrieben wie man ein SSL-Zertifikat erstellt und unter Apache 2.x auf Debian 5 installiert. Zuerst erzeugt man mit OpenSSL den Private-Key.

Falls OpenSSL noch nicht installiert ist, wird dies mit diesem Befehl nachgeholt:

apt-get install openssl

Erstellen eines SSL-Zertifikats

Einen 1024 Bit RSA Private-Key erzeugt man über:

openssl genrsa -out /pfad/zum/private-key/dateiname.key 1024

Natürlich kann auch ein anderer Verschlüsselungsalgorithmus, bspw. DSA, oder eine andere Verschlüsselungsstärke, bspw. 2048 Bit (zwingend erforderlich für Extended-Validation-Zertifikate), gewählt werden.

Nun wird das CSR (Certificate Signing Request) erzeugt. Dazu bitte folgende Zeile in die Konsole eingeben:

openssl req -new -key /pfad/zum/private-key/dateiname.key -out /pfad/zur/csr-datei/dateiname.csr

Nun werden ein paar Informationen abgefragt die man wahrheitsgemäß angegeben sollte.

Country Name (2 letter code) [AU]: (Zweistelliger Ländercode, bspw. DE für Deutschland)
State or Province Name (full name) [Some-State]: (Vollständiger Name des Bundeslandes/Staates, bspw. Schleswig-Holstein)
Locality Name (eg, city) []: (Vollständiger Name der Stadt, bspw. Berlin)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: (Vollständiger Firmen-/Personenname)
Organizational Unit Name (eg, section) []: (Vollständiger Abteilungs-/Bereichsname)
Common Name (eg, YOUR name) []: (Vollständiger Domainname, bspw. www.example.com, subdomain.example.com)
Email Address []: (Gültige E-Mail-Adresse)
A challenge password []: (Optional: Passwort)
An optional company name []: (Optional: Zusätzlicher Firmen-/Personenname)

Auf die unter dem Common Name angegebene Domain wird das Zertifikat validiert und gilt ausschließlich nur für diese Adresse. Es kann jedoch auch ein sogenanntes Wildcard-Zertifikat ausgestellt werden, indem man anstatt der Subdomain (www ist auch nur eine Subdomain) einfach ein Sternchen (*) angibt. Bspw:

Common Name (eg, YOUR name) []: *.example.com

Dieses Zertifikat würde dann für alle Subdomains gelten. Wenn Sie bei A challenge password ein Passwort eintragen, kann der Apache nach der Einbindung des Zertifikats nur noch nach Eingabe des Passworts gestartet werden.

Das CSR überprüft man mit folgendem Befehl:

openssl req -noout -text -in /pfad/zur/csr-datei/dateiname.csr

Wenn das CSR die vollständig richtigen Angaben enthält, können Sie dieses nun an eine Zertifizierungsstelle weitergeben. Bei normalen Zertifikaten erfolgt dann eine E-Mail-Validierung. Das bedeutet, es wird eine E-Mail an die im CSR angegebene Adresse geschickt, welche einen Link zu Bestätigung enthält. Hat man das Zertifikat bestätigt, bekommt man selbiges von der Zertifizierungsstelle zugesand und kann es anschließend in den Apache integrieren. Kostenlose Zertifikate werden z. Bsp. von StartCom angeboten. Dafür ist eine Anmeldung und die Angabe der persönlichen Daten, wie Name und Anschrift notwendig.

Sollte man kein offizielle Zertifikat benötigen, bspw. für eine Entwicklungsumgebung, kann man es auch selbst signieren. Selbstsignierte Zertifikate erzeugen bei den meisten Browsern eine Warnung und der Besucher muss eine Ausnahme hinzufügen, um die Seite verschlüsselt ansehen zu können.

So signiert man ein 1 Jahr gültiges Zertifikat selbst:

openssl x509 -req -days 365 -in /pfad/zur/csr-datei/dateiname.csr -signkey /pfad/zum/private-key/dateiname.key -out /pfad/zum/zertifikat/dateiname.crt

Man kann natürlich den Zeitraum auch verkürzen oder verlängern.

Nun wird das CSR nicht mehr benötigt und kann gelöscht werden. Vom Private-Key sollte man nun ein Backup erstellen, damit bei Verlust oder Umzug ohne Probleme ein neues Zertifikat erstellt werden kann.

Einrichten eines SSL-Zertifikats

Es wird davon ausgegangen, dass eine Konfiguration für einen (virtuellen) Host bereits existiert und dieser nun zusätzlich noch über SSL erreichbar gemacht werden soll. Dazu muss lediglich die Konfigurationsdatei kopiert und folgende Änderungen umgesetzt werden:

NameVirtualHost *
<VirtualHost *:80> [wird zu] <VirtualHost *:443>
ServerName www.exampl.com [wird zu] ServerName www.exampl.com:443

Das Sternchen kann natürlich durch eine IP ersetzt werden. Optional können, für eine bessere Zugriffsübersicht, separate Log-Dateien angelegt werden.

Nun werden der Pfad zum Private-Key, zum Zertifikat, sowie die Aktivierung des SSL-Modus hinzugefügt.

SSLEngine on
SSLCertificateKeyFile /pfad/zum/private-key/dateiname.key
SSLCertificateFile /pfad/zum/zertifikat/dateiname.crt

Abschließend muss nur noch der Apache neu gestartet bzw. die Konfiguration neu geladen werden. Das geschieht über folgenden Befehl:

/etc/init.d/apache2 reload

Sollten die Einstellungen nicht übernommen worden sein wiederholen Sie den Befehl, ersetzen aber reload durch restart.

Als Hinweis ist noch zu sagen, dass pro Domain/Zertifikat eine IP erforderlich ist. Ein Wildcard-Zertifikat gilt nur für alle Subdomains einer Domain.

Eigene Fehlerseiten erhöhen die Benutzerfreundlichkeit einer Webseite enorm, da immer die Möglichkeit besteht, dass z. Bsp. eine Seite nicht angezeigt werden kann oder dem Besucher der Zugriff auf eine Seite nicht erlaubt ist. In diesem Artikel wird beschrieben, wie man die Standardfehlerseiten von Apache, ab Version 2.0 (für ältere Versionen siehe unten) unter Debian 5, durch eigene ersetzt.

Man benötigt dazu das Recht die Konfigurationsdatei des Apache, zu finden unter /etc/apache2/, bearbeiten zu können. Eine Konfiguration über eine .htacces-Datei ist leider nicht möglich, da diese nicht global, sondern nur ordnerspezifisch arbeitet. Fehlerseiten können für jeden (virtuellen) Host definiert werden. Dazu muss man folgende Zeilen in die Konfiguration des entsprechenden (virtuellen) Host eintragen:

ErrorDocument 401 ‘Zugriff verweigert!’
ErrorDocument 403 ‘<p style=”color: red;”>Aktion nicht erlaubt!</p>’
ErrorDocument 404 /pfad/zu/den/eigenen/fehlerseiten/fehler_500.html
ErrorDocument 500 http://interner_fehler.example.com/

Die Direktive ErrorDocument ### (Die Rauten stehen für einen HTTP-Statuscode) teilt dem Apache mit, dass wenn der Fehler mit diesem Statuscode eintritt, soll entweder eine einfache Textmeldung, ein mit CSS formatierter HTML-Text, eine eigene Fehlerseite oder eine beliebige URL angezeigt werden.

Abschließend muss nur noch der Apache neu gestartet bzw. die Konfiguration neu geladen werden. Das geschieht über folgenden Befehl auf der Konsole:

/etc/init.d/apache2 reload

Sollten die eigenen Fehlerseiten nicht angezeigt werden wiederholen Sie den Befehl, ersetzen aber reload durch restart.

Bei der Version 1.3 des Apache ist zu beachten, dass die beginnenden/beendenden Zeichen keine doppelten (“”) einfachen (”), sondern einfache (”) doppelte (“”) Anführungszeichen sein müssen. Ansonsten ist die Syntax identisch.

UPDATE (17.08.2010): Bei meinen Tests haben die absoluten Pfadangaben nicht funktioniert. Erst als ich einen Alias für den Ordner, in dem sich die Fehlerseiten befanden, angelegt hatte lies sich der Apache neu starten. Ebenfalls kam bei den Tests heraus, dass es anscheinend nicht möglich ist bei einem 401er-Fehler eine Weiterleitung zu einer vollständigen URL anzugeben. Bei den anderen ging dies jedoch problemlos.