planetknauer.net

mod_gnutls hab ich wieder durch mod_ssl ersetzen müssen. Grund:

[Tue Aug 17 09:21:32 2010] [notice] Apache/2.2.9 (Debian) mod_gnutls/0.5.1 configured -- resuming normal operations
page 7: illegal page type or format
PANIC: Invalid argument
PANIC: fatal region error detected; run recovery

Und die letzte Zeile wiederholt sich dann, bis das Logfile die Festplattenkapazität gesprengt hat. Dauert bei den paar freien GB auf dem vserver so ca 20 Minuten...

Komische Welt bei Microsoft. Einen kleinen russischen Softwaretester mit mutmasslichen Verbindungen zum Geheimdienst schafft man aus. Aber dann gibt man quasi im gleichen Atemzug mal den Sourcecode von Windows 7 an den FSB weiter? Das versteh mal einer.

Ob diese Code-Weitergabe wohl Einfluss auf das künftige nationale Betriebssystem von Russland haben wird? Bislang hatte ich ja eher das Gefühl, dass dies einfach eine weitere Linux-Distribution werden soll. Gut möglich, dass es nun ein "Lindows-Reloaded" wird.

...das Drecksvieh hat mir anscheinend automatisch ein rm /mnt -type f -exec rm -f '{};' ausgeführt... (für Leute ohne Shell-Kenntnis: Das löscht genau alle Dateien unterhalb des Verzeichnisses /mnt, lässt aber die Verzeichnisstruktur intakt). Dass Probleme mit ext4 und grossen Dateien bestehen, war bekannt. Nur: das waren je eine XFS und eine ext3 Partition. Woher das kommt? Keine Ahnung. Und nein, so doof, um solche Befehle auf meinem Rechner auszuführen, bin ich nun doch auch wieder nicht!

Ich hatte heut Morgen kurz ein System mit hoher Last und starker HD-Aktivität, wird wohl dann passiert sein. Ich hab gedacht, dass das wohl das Backup-Skript sei. Falsch gedacht, offensichtlich. Tatsächlich lief zu dem Zeitpunkt auch ein find-Prozess. Immerhin hab ich vor wenigen Wochen ein Backup auf externe HDs gezogen. Und was seither zur Musiksammlung dazugekommen ist, lässt sich wieder rippen.

Und was passiert mit dem Koala? So eine Scheisse krieg nicht mal Microsoft gebacken. Also einschläfern, würd ich meinen. Aber eiligst!

Da werden doch Erinnerungen an die Kindheit wach: Die Mauer ist gefallen, die DDR-Stasi-Archive wurden geöffnet... und in den ach so guten und freien westlichen Ländern wie der Schweiz hat man festgestellt: Hey, unsere Geheimdienste waren ja gar nicht besser! Auch hierzulande wurde geschnüffelt bis die Nasenscheidewände kollabiert sind.

Und nun kommen also unsere EJPD-Heinis wieder daher und wollen wieder schnüffeln. Na gut. Sachliche Kritik nutzt bei den merkbefreiten Politikern eh nichts. Nehmen wir's also humoristisch. Ich hab in der Folge in Anlehnung an die deutschen Schäublonen für SSchäuble und Zensursula nun eine Schlumpfone unserer EJPD-Führerin gebastelt. Bitte sehr, steht zur freien Verwendung zur Verfügung:

Wer das Thema bislang verschlafen hat, dem empfehle ich diese perfekt aufbereitete und kommentierte Linksammlung.

So, und was soll ich als nächstes tun? Nen vServer in Holland oder Schweden mieten und all meinen Traffic da drüber laufen lassen? Oder mich lieber gleich in die nächste Klappsmühle einsperren lassen, damit die mich die nächsten 50 Jahre unter Drogen setzen, so dass ich die abstrusen Vorgänge in dieser Welt nicht mehr mitbekomme?

Ich hab mir ein neues Spielzeug besorgt. Nachdem endlich der eeepc 901 in schwarz und ohne Microsoft-Steuer nicht nur "anderswo" sondern tatsächlich auch im IT-Drittweltland Schweiz verfügbar ist, habe ich natürlich sofort zugegriffen. Danach musste als erstes das Xandros-Verräterlinux runter. Stattdessen läuft nun ein Debian Sid mit nur freier Software.

Die 16GB SSD habe ich komplett verschlüsselt. Die Installation war drum etwas knifflig da der Debian EEE Installer das nicht von Haus aus beherrscht und ich drum eine normale Installation mit Ergänzungen gemäss Anleitung vornehmen musste.

Die Hardware ist ganz OK. Die SSD überzeugt mit ihrer Geschwindigkeit. Um sie zu schonen habe ich sämtliche Tricks von meiner Xubuntu-Stick-Installation vorgenommen, das Debian-Wiki hält auch noch ein paar Tricks parat. Zum Surfen ist die CPU passabel schnell. Der Akku hält auch lange genug. Einzig das kleine Display ist etwas gewöhnungsbedürftig. Die Tastatur ist aber definitiv zu klein für mich, da werd ich längere Gewöhnungszeit brauchen. Vor allem tipp ich gerne auf "Cursor hoch" statt der rechten Shift-Taste.

So langsam ergreifen die Parteien die Parole für die Abstimmung über die biometrischen Pässe vom 17. Mai. Unsere demagogischen jederzeit neutralen, objektiven und unparteiischen Medien berichten auch brav darüber. Jedoch immer mit zwei klitzekleinen Detailfehlern: Erstens titeln sie ihre Beiträge jeweils immer zum Thema "Einführung von biometrischen Pässen" bzw der "Nichteinführung von biometrischen Pässen". Das ist leider, leider, leider KREUZFALSCH!!! Die biometrischen Pässe sind nämlich bereits eingeführt worden. Es ist bereits jetzt problemlos möglich, seine Fingerabdruckdaten zentral registrieren zu lassen und diese brav per in alle Welt funkenden Pass zu verteilen. Zweitens kann das nicht so ein zwingendes Kriterium für die Schengenmitgliedschaft sein, wenn die Schengenländer Irland, Grossbritannien und Dänemark kein Obligatorium für biometrische Pässe kennen.

Richtigerweise geht es in der Abstimmung um die "Abschaffung traditioneller, nichtbiometrischer Pässe". Wird nämlich an der Abstimmung der Zwang zu biometrischen Pässen abgelehnt, ändert sich nichts. Dann behält man weiterhin die Wahl zwischen biometrischem und nichtbiometrischem Pass. Wer also "nichts zu verbergen™" hat, darf sich trotzdem den biometrischen Pass holen. Wird hingegen der Zwang zu biometrischen Pässen angenommen, so muss jeder Schweizer einen teuren, unsicheren, ortbaren Pass kaufen und sich wie ein Verbrecher fichieren lassen. Ob er nun in die USA reisen will oder nicht.

Übrigens, liebe Windfähnlipartei (CVP), die ihr ja den Biometriezwang so sehr unterstützt: Ich hab euch noch eine coole Idee für einen Vorstoss nach der Abstimmung. In Mexiko bekommt man jetzt neue Handies nur noch gegen Abgabe eines Fingerabdrucks. Das könnt ihr doch auch in der Schweiz versuchen einzuführen. Damit würdet ihr mir helfen, viel, viel Geld zu sparen. Weil ich dann das Handy wieder abschaffen und Kontakte künftig ganz traditionell mit der analogen Technik Stift und Papier aufnehmen werde. Meine Fingerabdrücke gibt's erst, wenn mir ein Verbrechen untergeschoben wird. Punkt.

Apache ist ein äusserst exponierter Dienst. Grad auf Servern mit vielen Seiten und zahlreichen PHP-Skripten ist das durchaus die grösste Bedrohung für die Serversicherheit. Daher empfiehlt es sich, der Absicherung von Apache besonders viel Aufmerksamkeit zukommen zu lassen. Eine wichtige Methode der Absicherung ist das chroot, in dem der Apache in ein Unterverzeichnis des Systems gesperrt wird. Gelingt ein Angriff auf ein Webskript, so sind für den Angreifer noch immer weitere Hürden in den Weg gelegt, bevor er sich im System einnisten kann.

Relativ einfach lässt sich ein chroot mittels mod_chroot einrichten. Es gibt auch unzählige Howtos im Internet. Aber leider kein einziges brauchbares. Apache ins chroot sperren ist an sich keine Sache. Die nötigen Pakete installieren, dann noch zwei Konfigurationseinträge vornehmen und gut. Gut? Nein! Denn damit geht eigentlich gar nichts mehr, ausser der Auslieferung statischer Webseiten und ein Bisschen Basis-PHP. Email? Tot! ImageMagick? Tot! Das muss nicht sein. Daher mein Howto für Apache mit mod_chroot, mod_php5, suhosin und PHP im safe_mode:

Zuerst müssen die nötigen Pakete installiert werden:

aptitude install apache2 libapache2-mod-chroot libapache2-mod-php5 php5-suhosin php5-imagick imagemagick dash msttcorefonts

Weitere PHP-Module können nach Bedarf installiert werden, wie z.B. php5-gd php5-imap php5-ldap php5-mcrypt php5-mysql. Vorsicht ist bei suhosin geboten, einige grössere PHP-Applikationen bekommen dadurch Probleme. Entsprechende Workarounds müssen dann per individueller Konfiguration eingebaut werden. Die meisten wichtigeren Applikationen haben in ihrer Hilfe oder im Supportbereich entsprechende Informationen.

Ein erster Härtungsschritt ist, dass Apache der Zugang zu einer Shell entzogen wird. Eine Shell ist nicht notwendig und nur ein weiterer potentieller Unsicherheitsfaktor. Also:

usermod -s /bin/false www-data

Nun müssen die Module aktiviert werden:

a2enmod mod_chroot && a2enmod php5

In der Datei /etc/apache2/apache2.conf muss folgende Zeile eingefügt werden:

ChrootDir /var/www

Als nächster Schritt wird das chroot gebaut. Das ist ein sehr langer und aufwändiger Prozess. Denn ins chroot müssen sämtliche ImageMagick-Binaries sowie ein SMTP-Server samt ihrer Abhängigkeiten kopiert werden. Ich hab das chroot wie schon bei Teamspeak mit den Thread Local Storage Bibliotheken gebaut. XEN-User sollten davon Abstand nehmen und die "normalen" Bibliotheken verwenden. Als Mini-Mailserver habe ich mich für esmtp entschieden, wer andere vorlieben hat, darf sich natürlich auch gerne ssmtp anschauen oder versuchen mini_sendmail zum Laufen zu überreden.

Mailer vorbereiten

Leider akzeptiert Debian nur die Installation eines MTA gleichzeitig. Da man als Systemmailer wohl lieber Postfix oder Exim einsetzt, muss hier etwas getrickst werden. Verwendet hier bitte für den Download der Pakete (auch wenn sie recht klein sind) den Debian Mirror EURER Wahl, damit sich die Last entsprechend verteilt. Ausserdem muss auf die Versionsnummer acht gegeben werden, die kann sich natürlich mit der Zeit ändern. .deb-Pakete sind mit dem Packer ar gepackt, dieser sollte standardmässig auf jedem Debian-System installiert sein.

mkdir ~/esmtp
cd ~/esmtp
wget http://mirror.switch.ch/ftp/mirror/debian/pool/main/e/esmtp/esmtp_0.5.1-4.1_i386.deb
wget http://mirror.switch.ch/ftp/mirror/debian/pool/main/libe/libesmtp/libesmtp5_1.0.4-2_i386.deb
ar xv esmtp_0.5.1-4.1_i386.deb
tar -zxf data.tar.gz
ar xv libesmtp5_1.0.4-2_i386.deb
tar -zxf data.tar.gz

Basis-Chroot bauen

Bei sämtlichen Befehlen, die nun folgen, wird davon ausgegangen, dass man sich im Verzeichnis /var/www befindet. Ist dem nicht so, so stimmen natürlich die relativen Pfade nicht mehr und das Howto schlägt fehl. Wie schon eingangs erwähnt, sollten XEN-User aus Performancegründen nicht die TLS-Bibliotheken verwenden.

cd /var/www
mkdir bin etc lib tmp usr
mkdir -p lib/tls/i686/cmov usr/lib/i686/cmov var/lib/php5 var/log/apache2 var/run
chown www-data:www-data tmp
chown www-data:www-data var/lib/php5
chown www-data:www-data var/log/apache2
chown www-data:www-data var/run
touch var/run/apache2.pid
ln -sf var/run/apache2.pid /var/run/apache2.pid
cp /bin/dash bin
cd bin
ln -sf dash sh
cd ..
cp /etc/mime.types etc
grep www-data /etc/passwd > etc/passwd
cp /lib/ld-linux.so.2 lib
cp /lib/libgcc_s.so.1 lib
cp /lib/libnss_dns.so.2 lib
cp /lib/tls/i686/cmov/libc.so.6 lib/tls/i686/cmov
cp /lib/tls/i686/cmov/libdl.so.2 lib/tls/i686/cmov
cp /lib/tls/i686/cmov/libpthread.so.0 lib/tls/i686/cmov
cp /lib/tls/i686/cmov/libresolv.so.2 lib/tls/i686/cmov
cp /usr/lib/libz.so.1 usr/lib
cp /usr/lib/i686/cmov/libcrypto.so.0.9.8 usr/lib/i686/cmov
cp /usr/lib/i686/cmov/libssl.so.0.9.8 usr/lib/i686/cmov

Dash wird als Shell mit minimalem Speicherbedarf installiert. Leider benötigt esmtp zwingend eine Shell, ansonsten verweigert er den Dienst. Dies ist natürlich ein klarer Sicherheitsmangel, der durch Workarounds wie safe_mode behoben werden muss.

Nun wird der Mailer ins chroot kopiert:

cp ~/esmtp/usr/bin/esmtp bin
cp -r ~/esmtp/usr/lib usr/lib

Und als nächstes wird der Mailer konfiguriert. Unter Annahme, dass auf dem Server z.B. ein Postfix oder Exim als Mailserver läuft, muss dazu die Datei /var/www/etc/esmtprc mit folgendem Inhalt erstellt werden:

hostname = 127.0.0.1:25
starttls = disabled

Ausserdem ist jetzt der Zeitpunkt gekommen, um PHP mitzuteilen, wie es mailen soll. Ausserdem kann man bei der Gelegenheit auch weitere Absicherungen vornehmen und z.B. den safe_mode einschalten. Dazu müssen ein paar Direktiven in der Datei /etc/php5/apache2/php.ini angepasst oder eingefügt werden. Beachte, dass die Shell in /bin liegt, während als safe_mode_exec_dir /usr/bin konfiguriert wird. PHP-Skripte können also nicht auf die Shell zugreifen.

safe_mode = On
safe_mode_exec_dir = /usr/bin
expose_php = Off
display_errors = Off
log_errors = On
sendmail_path = /bin/esmtp -t

ImageMagick und Schriften

Es müssen ein paar weitere Bibliotheken sowie die benötigten ImageMagick-Binaries ins chroot kopiert werden:

mkdir -p usr/lib/mime/packages/
mkdir usr/bin
cp /lib/tls/i686/cmov/libm.so.6 lib/tls/i686/cmov/
cp /usr/lib/libMagick.so.9 usr/lib/
cp /usr/lib/liblcms.so.1 usr/lib/
cp /usr/lib/libtiff.so.4 usr/lib/
cp /usr/lib/libjasper-1.701.so.1 usr/lib/
cp /usr/lib/libjpeg.so.62 usr/lib/
cp /usr/lib/libpng12.so.0 usr/lib/
cp /usr/lib/libXext.so.6 usr/lib/
cp /usr/lib/libXt.so.6 usr/lib/
cp /usr/lib/libSM.so.6 usr/lib/
cp /usr/lib/libICE.so.6 usr/lib/
cp /usr/lib/libX11.so.6 usr/lib/
cp /lib/libbz2.so.1.0 usr/lib/
cp /usr/lib/libxml2.so.2 usr/lib/
cp /usr/lib/libfreetype.so.6 usr/lib/
cp /lib/tls/i686/cmov/libdl.so.2 usr/lib/
cp /usr/lib/libXau.so.6 usr/lib/
cp /usr/lib/libXdmcp.so.6 usr/lib/
cp /usr/lib/mime/packages/imagemagick usr/lib/mime/packages
cp /usr/bin/animate usr/bin
cp /usr/bin/compare usr/bin
cp /usr/bin/composite usr/bin
cp /usr/bin/conjure usr/bin
cp /usr/bin/convert usr/bin
cp /usr/bin/display usr/bin
cp /usr/bin/identify usr/bin
cp /usr/bin/import usr/bin
cp /usr/bin/mogrify usr/bin
cp /usr/bin/montage usr/bin

Wer noch Schriften braucht, kann diese nach Bedarf installieren. Die Dateinamen der Schriftdateien müssen komplett in Kleinbuchstaben gehalten sein.

mkdir -p usr/share/fonts/truetype/msttcorefonts/
cp /usr/share/fonts/truetype/msttcorefonts/verdana.ttf usr/share/fonts/truetype/msttcorefonts/

DocumentRoot

Der Startvorgang des Apache verläuft in etwa folgendermassen:

1. Apache startet ausserhalb der chroot-Umgebung und wertet die Konfiguration in /etc/apache2 aus.
   
2. Apache schreibt sein PID in die vorgegebene pid-Datei
   
3. Apache prüft die Existenz der DocumentRoot-Verzeichnisse gemäss Konfiguration in den vhosts.
   
4. Apache öffnet die Logfiles gemäss Konfiguration in den vhosts.
   
5. Apache wechselt ins chroot.
   
6. Apache öffnet die Sockets.
   
7. Apache wechselt zu einem unpriviliegierten User.
   
8. Apache ist bereit. Sämtliche Anfragen werden nun im chroot bearbeitet. Die Ausführung von PHP-Skripten findet nun im chroot statt.

Folglich muss von den DocumentRoot-Verzeichnissen eine Schatteninstallation und eine Life-Installation vorgenommen werden. Wird in der Apache-Konfiguration z.B. die Direktive

DocumentRoot /var/www/htdocs/myhost

eingetragen, müssen folgende Verzeichnisse erstellt werden:

mkdir -p /var/www/htdocs/myhost
mkdir -p /var/www/var/www/htdocs/myhost

Effektiv arbeiten wird Apache dann mit dem Verzeichnis /var/www/var/www/htdocs/myhost, dorthin gehören folglich alle HTML-Dateien.

Apache starten, stoppen, neu laden

Jetzt kann man mal die ganze Sache testen und Apache starten. Ich habe festgestellt, dass mod_chroot leider die reload- und restart-Befehle zerschiesst. Folglich bleiben nur noch start und stop übrig. Um eine geänderte Konfiguration einzulesen, bleibt folglich leider keine andere Möglichkeit, als Apache erst zu stoppen und dann wieder zu starten. Bei stärker frequentierten Seiten freuen sich da vermutlich nicht alle User darüber. Sorry, aber dafür gibt's wohl keine Lösung.

/etc/init.d/apache2 start
/etc/init.d/apache2 stop

Ich habe mein WLAN jetzt umgestellt auf Authentifizierung per Radius und LDAP. Das ist eigentlich schon eine Konfiguration für grössere Firmen. Ich mach das für mich allein Damit habe ich mein privates Single-Sign-On nun auch auf WLAN ausgeweitet.

Das Setup:

• OpenLDAP als zentrale Authentifizierungs-Instanz. Die Passwörter sind mittels SSHA1 verschlüsselt.


• FreeRadius als Authentikator für WLAN.


• WRT54GL mit Tomato-Firmware (wobei DDWRT mit Chillispot jetzt erst recht interessant wäre)


• Client mit Ubuntu 8.10, die Konfiguration erfolgt Klickibunti über den Network Manager

An sich ist das gar nicht mal schwer, eine gute Vorkonfiguration und gutes Howto vorausgesetzt. Für die Vorkonfiguration habe ich mich auf Gentoo verlassen, nach der Installation von FreeRadius lag da schon ein recht brauchbares und sauber strukturiertes Setup vor. Die Anpassungen habe ich anhand dieses Howtos vorgenommen, welches fast alles erklärt. Lediglich eine Sache bleibt dieses Howto schuldig: Was mache ich, wenn ich keine Passwörter im Klartext in meinem LDAP möchte?

Die Antwort auf diese Frage hat eine kurze Recherche und etwas ausprobieren ergeben: Die PAP-Konfiguration muss so eingestellt werden, dass PAP die Header des Passwort-Strings auswertet. LDAP liefert nämlich ein Passwort in der Form {SSHA}XYZ/ABC zurück, der Teil in den Klammern ist der Header und gibt den verwendeten Hashing-Algorithmus an. Das geschieht durch folgende Konfiguration in /etc/raddb/modules/pap:

pap {
auto_header = yes
}

Uffa, so einfach. Jetzt sollte ich nur noch die Radius-Konfiguration etwas ausmisten und nicht benötigte Authentifizierungs-Module deaktivieren sowie Accounting (z.B. per MySQL) einbauen.

Update: In letzter Zeit habe ich mehrere Anfragen zu diesem Beitrag erhalten. Ich nutze und betreue seit Jahren keine Radius-Installationen mehr, so dass ich bei Problemen mit Radius keine Fragen beantworten kann.

Teamspeak ist böse. Es ist proprietär, die letzte Version des Servers ist ein uralter RC und es ist komisch in der Konfiguration. Nun, was macht man mit sowas kriminellem? Na klar, einsperren! z.B. in einem chroot. Wie das bei mir funktioniert hat, erkläre ich hier:

Ein kurzes Suchen mit der Suchmaschine meines geringsten Misstrauens hat mich zu einer bereits sehr guten Anleitung geführt, welche ich mit leichten Modifikationen übernehmen konnte. Ich musste zum einen das Startskript etwas anpassen, zum anderen verwendet mein System standardmässig die TLS (Thread Local Storage) Bibliotheken der glibc. Für XEN-User ist dieser Hinweis insofern wichtig, als dass man diese Bibliotheken unter XEN aus Performancegründen nicht nutzen sollte. Auf einem XEN-System sind diese daher standardmässig nicht installiert. Da ist folglich ein Vorgehen gemäss der Originalanleitung zu empfehlen.

Ich bin so vorgegangen:
Erst werden die Verzeichnisse erstellt, ein Benutzer angelegt und Teamspeak entpackt. Danach werden die Berechtigungen angepasst. Leider konnte ich es Teamspeak nicht austreiben, in seinem Installationsverzeichnis Schreibrechte zu fordern (ein weiterer guter Grund für ein chroot).

mkdir /opt/teamspeak
cd /opt/teamspeak
tar -jxf ts2_server*.tar.bz2
useradd teamspeak -d /opt/teamspeak -s /bin/false
chown -R teamspeak:teamspeak tss2_rc2
chown root:root tss2_rc2/server_linux
chown root:root tss2_rc2/*.so

Nun werden die benötigten Bibliotheken ins chroot kopiert. Mittels ldd /opt/teamspeak/tss2_rc2/server_linux und ldd /opt/teamspeak/tss2_rc2/*.so lassen sich diese leicht bestimmen. Teamspeak fordert ebenfalls Zugriff auf /dev/null, was insofern blöd ist, dass man nun Teamspeak nicht auf einer Partition installieren kann, welche mit der Option "nodev" gemountet wurde:

mkdir etc dev lib tmp
mkdir -p usr/lib/gconv usr/lib/locale /lib/tls/i686/cmov var/run
grep teamspeak /etc/passwd > etc/passwd
grep teamspeak /etc/group > etc/group
cp /etc/localtime etc
cp /lib/ld-linux.so.2 lib
cp /lib/tls/i686/cmov/libc.so.6 lib/tls/i686/cmov
cp /lib/tls/i686/cmov/libdl.so.2 lib/tls/i686/cmov
cp /lib/tls/i686/cmov/libpthread.so.0 lib/tls/i686/cmov
cp /lib/libncurses.so.5 lib
cp /lib/libgcc_s.so.1 lib
cp /usr/lib/gconv/ISO8859-15.so usr/lib/gconv
cp /usr/lib/gconv/gconv-modules usr/lib/gconv
cp /usr/lib/locale/locale-archive usr/lib/locale/
mknod -m666 dev/null c 1 3

nano /etc/init.d/teamspeak

Der letzte Befehl startet einen Editor, mit welchem das Startskript erstellt wird. Im von mir verwendeten Editor nano lassen sich Dateien durch Eingabe von ctrl+o speichern und der Editor sich durch ctrl+w beenden. Meine grundlegende Änderung im Startskript gegenüber der Vorlage ist ein Wechsel ins Teamspeak-Verzeichnis. Dieser erwies sich als notwendig, damit Teamspeak überhaupt startet. Ausserdem habe ich nur die start und stop Parameter implementiert, den Rest brauche ich eigentlich nicht.

#! /bin/sh
CHROOT_DIR=/opt/teamspeak
EXECDIR=/tss2_rc2
USER=teamspeak
GROUP=teamspeak

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:${CHROOT_DIR}
EXEC=${EXECDIR}/server_linux
DAEMON=${EXEC}
NAME=tss2
DESC="TeamSpeak 2 Server"
PIDFILE=${EXECDIR}/server.pid
test -x ${CHROOT_DIR}${DAEMON} || exit 0

set -e

case "$1" in
start)
echo "Starting $DESC: $NAME"
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--chuid $USER:$GROUP \
--chroot ${CHROOT_DIR} \
--startas $EXEC \
--chdir ${EXECDIR}
echo "."
;;
stop)
echo -n "Stopping $DESC: $NAME "
start-stop-daemon --stop --quiet --pidfile ${CHROOT_DIR}$PIDFILE \
--exec ${CHROOT_DIR}$DAEMON
echo "."
;;
esac

Das war's auch schon. Jetzt muss Teamspeak nur noch gestartet werden. Ausserdem kann man bei dieser Gelegenheit auch noch elegant die generierten Admin-Passwörter auslesen:

chmod a+x /etc/init.d/teamspeak
/etc/init.d/teamspeak start
update-rc.d teamspeak defaults 95
grep "admin account" tss2_rc2/server.log

Nachdem der Server wieder (fast) vollständig läuft und ich nun zwei Tage lang Doku (woraus ich das eine oder andere gelungene Howto veröffentlichen werde) geschrieben habe, fasse ich hier ein paar Gedanken zu Serversicherheit zusammen. Wir haben nun extrem viel Arbeit in die Sicherung des Systems gesteckt. Vermutlich haben wir einige Dinge richtig paranoid abgesichert. Aber irgendwie ging es zumindest mir mit der Zeit so, dass ich nur schon das theoretische Maximum an Möglichkeiten ausschöpfen wollte. Quasi eine akademische Suche nach Serversicherheit.

• Sicherheit ist ein Prozess, kein Zustand. Nur während Δt=0 ist es ein Zustand!


• Ein sicheres System verwenden. Dazu gehört, dass das System sicher designt wurde, dass Updates leicht einzuspielen sind und dass es vom Hersteller auf lange Frist unterstützt wird.


• Virtualisierung nutzen, dadurch können Dienste getrennt werden. Wird eine virtuelle Maschine befallen, kann sie einfach ersetzt werden. Virtuelle Maschinen lassen sich leicht backuppen. VMWare bietet ausserdem mit nonpersistenten virtuellen Festplatten eine Möglichkeit, sämtliche Änderungen an einem Dateisystem mit einem Neustart zurückzusetzen.


• chroot nutzen! Insbesondere besonders exponierte Dienste gehören in ein chroot. Natürlich nutzt ein chroot nur dann, wenn es sauber eingerichtet wird und der Dienst nicht mit root-Rechten läuft.


• Dienste nutzen, die sicher designt wurden. Dazu gehört insbesondere, dass das Programm standardmässig root-Privilegien abgibt, auch wenn es z.B. privilegierte Ports nutzen will (da kann es einfach mit root-Rechten den Port öffnen und danach die Rechte abtreten).


• Sicherheit aktiv prüfen. Dazu gehören automatisierte Tests wie rkhunter, logcheck oder auch Statusüberprüfung durch Nagios.


• Restriktive Firewall. Es darf weder schädliches hinein noch unnötiges heraus. Neue Verbindungen soll das System idealerweise nur zu seinen Update-Servern öffnen dürfen.


• Nur ein Minimum an Diensten betreiben. Und auch sonst möglichst wenig Software installieren.


• Ausführliche und vollständige Dokumentation schreiben! Dazu gehört auch, dass jede Änderung am System sofort in der Doku nachzutragen ist, damit auch die anderen Admins wissen, was Sache ist.


• Backups! Wenn denn doch etwas passiert, sind wenigstens die Anwenderdaten in Sicherheit.


• Kommunikation mit Co-Admins und Kunden. Wer Daten auf dem Server hat, ist automatisch in den Sicherheitsprozess involviert.


• Dass Passwörter lang und komplex sein müssen und nie im Klartext übertragen werden dürfen, brauch ich wohl kaum noch einmal zu wiederholen...

Derzeit geht's rund! Ärger mit Servern, Ärger mit dem Militär und Freude über meinen Internetprovider!

Nachdem seit letztem Samstag mein Server wieder frisch läuft, hab ich ja Zeit, mich um anderes zu kümmern. MÖÖÖP, nix da! Am Dienstag stelle ich fest, dass in diesen Server hier eingebrochen wurde und das Ding nun frisch-fröhlich Spam versendet! Na toll. Vermutlich hat da einer der Domain-Mieter ein faules Skript in seinem Webroot liegen gehabt. An sich war der Server ja gut gewartet, aber wenn die Sicherheitsvorkehrungen unterwandert werden, nützt das auch nicht viel. Wie auch immer: Seit Donnerstag wurde die Sache neu gemacht und maximal gehärtet: Virtualisierung, exzessives chroot, verstärkte Firewallregeln, Rechteeinschränkungen, verstärkte Überwachung etc pp. Und wir sind noch lange nicht fertig!

Ganz überraschend lag am Donnerstag ein Päckchen in meinem Briefkasten. Siehe da. Fast 3 Monate nach Vertragsabschluss erhalte ich mein ADSL-Modem. Das nenne ich doch eine prompte Erledigung. Zum Glück bin ich als Informatiker sowieso mehrfach mit sowas ausgestattet. Heute habe ich trotzdem das neue installiert. Gemäss Leistungsaufschrift auf dem Netzteil sollte es wohl so 25% weniger Strom verbrauchen.

Am Freitag bekam ich ein nettes Briefchen von Väterchen Staat, worin stand, dass man von mir noch keine Meldung wegen obligatorischem Schiessen erhalten hätte. Na Ihr seid ja so toll, meine lieben! Ich kann absolut nicht verstehen, wieso ein Prozess, der seit 100 Jahren jedes Jahr 400'000 Mal ausgeführt wird, nach wie vor nicht reibungslos verläuft! Es kann doch nicht sein, dass ich jeden Scheiss selbst machen muss? Na gut, geh ich halt mein Schiessbüchlein hervorsuchen und schicke es euch. Bleibt zu hoffen, dass die Post das Ding nicht verschlampt. grrrrmpf!!!

Am Sonntag Morgen hatte ich ein unschönes Erwachen. Über Nacht hatte auch noch eine der beiden brandneuen Platten im Homeserver verabschiedet. Dank RAID-1 ist da zum Glück nichts passiert. Da es sich um HotPlug-taugliche SATA-Platten handelt, wurde die defekte Platte einfach im Kernel abgemeldet und das System lief mit der funktionsfähigen Disk weiter. Mühsamer und Zeitaufwändiger als die Reparatur des RAID-Arrays war aber der Umtausch der Platte. Da die Angaben auf der Homepage meines Lieferanten wieder alles andere als korrekt waren, musste ich zweimal in dessen Laden, um Ersatz zu erhalten.

Langsam normalisiert sich die Lage wieder. Bleibt zu hoffen, dass sie auch normal bleibt.

Neulich führte ich über ICQ (ja, Jabber wär mir lieber gewesen - grad auch im Kontext dieses Artikels ) eine Diskussion über die Möglichkeiten der Anonymisierung seiner Datenspuren im Netz. Ich habe mir folglich ein paar Gedanken dazu gemacht, welche ich hier vorstellen möchte.

Natürlich ist im Zeitalter von staatlicher Terrorparanoia, Vorratsdatenspeicherung und verhaltensbasiertem Marketing kaum noch Anonymität möglich. Allerdings lassen sich die einige Massnahmen anwenden, um sich weniger bekannt zu machen. Dabei gelten quasi die gleichen Grundsätze wie beim Verstecken im Wald. Spuren vermeiden, Spuren verschleiern, falsche Fährten legen und Ruhe bewahren. Einige der dafür möglichen Massnahmen sind technischer Natur, andere psychologischer. Nicht alle meiner Ideen sind wirklich sinnvoll oder überhaupt realisierbar, ich versuche einfach eine möglichst umfassende Sammlung zu erstellen.

Technische Massnahmen

Spuren verschleiern

Passende Software auswählen:Hier gibt es zwei Strategien. Entweder man nutzt die häufigst benutzte Software (also Windows XP mit Internet Explorer, was praktisch alle anderen Massnahmen wohl grad zunichte macht) und versucht in der Masse unterzugehen, oder man nutzt Software, die standardmässig gute Privatsphären-Einstellungen bietet.

Software passend konfigurieren: Grad für den Firefox gibt es viele gute Addons, welche die Privatsphäre verbessern. Da wären u.a. Adblock Plus, Flashblock, Customize Google und Stealther zu zählen. Ausserdem sollten Cookies deaktiviert (oder besser: Nur für die aktuelle Session gespeichert) werden. Den Festplattencache sollte man bei einer DSL-Leitung auch abschalten oder in eine RAM-Disk verschieben.

TOR nutzen? TOR leitet IP-Pakete über zahlreiche Rechner um, wodurch die Herkunft verschleiert werden kann. Mit dem Firefox-Paket DeerPark bekommt man eine simpel zu nutzende TOR-Installation mitsamt Browser. Das Problem ist nur, dass praktisch alle TOR-Exit-Nodes von Geheimdiensten und Hackern betrieben werden. Ergo sollten keinesfalls Passwörter oder finanzielle Daten darüber gesendet werden. Meine Empfehlung ist also ganz klar besser die Finger von TOR zu lassen.

Anonymisierenden Proxy verwenden: Die etwas sicherere Variante zu TOR, jedoch muss man auch hier dem Betreiber des Proxys vertrauen, dass er weder protokolliert noch mitsnifft.

Fallstrick DNS: DNS-Anfragen geben natürlich Aufschluss darüber, welche Seiten man ansurft. Man sollte daher einen DNS-Server verwenden, der nichts protokolliert. Dieses Problem ist kaum auf triviale Weise zu lösen. Ideal ist's wohl, wenn man einen eigenen DNS-Cache nutzt, um wenigstens die Anfragen zu reduzieren, viel bringt das aber auch nicht.

IP-Adresse häufig ändern: Dies schlägt zwei Fliegen mit einer Klappe. Einerseits wird die Vorratsdatenspeicherung damit etwas strapaziert (obwohl... viel Platz braucht das im Logfile auch nicht...), andererseits wird man schwieriger verfolgbar. Allerdings ist das mit zwei Einschränkungen versehen. Erstens hat ein Provider nur eine bestimmten IP-Bereich zur Verfügung. Zweitens werden viele Sessions durch den Wechsel der IP gekappt. Hier gilt es also, einen guten Zwischenweg zu finden. Mein DSL-Router sollte trotzdem die IP so selten wie möglich wechseln, da ich zuhause einen Server betreibe, auf den ich gelegentlich auch aus dem Internet zugreifen möchte.

Spuren vermeiden

Werbeblocker nutzen: Durch die Nutzung von Werbeblockern wird es für die Werbetreiber ziemlich schwierig ein Profil aufzubauen. Man existiert für sie nämlich schlicht nicht. Des weiteren spart man ordentlich Bandbreite, da nicht mehr tausende Werbebanner geladen werden müssen. Und die Augen werden geschont, da die Webseiten nicht mehr blinken wie Las Vegas in der Nacht. Ganz wichtig ist es insbesondere, dass Flash-Filme blockiert werden, da diese Flash-Cookies ablegen können, die nicht durch bisherige Browser-Automatismen gelöscht werden.

Hosts-Datei anpassen: Zusätzlich zum Werbeblocker kann man die hosts-Datei modifiziert werden, einen guten hosts-Datei-Generator gibt's hier. Damit kann man auch ganz prima Google Analytics blocken lassen.

Google nicht nutzen! Auf jeden Fall Hände Weg von Chrome, Gmail, Picasa Webalbum, Google Docs etc pp. Neben der Google-Suche auch mal Yahoo oder Ask nutzen (nein, MSN empfehle ich aus Prinzip nicht!)

Kein Microsoft Office und keine .doc-Dateien verwenden: Microsoft Office hat die schlechte Angewohnheit, bei der Erstellung einer Datei sämtliche Daten in Word-Dateien mitzuspeichern. Nimmt man eine Änderung an einer Word-Datei vor, kann diese später nachvollzogen werden, indem man diese Datei einfach in einem Texteditor öffnet. Ich weiss nicht, ob das bei Office 2007 und .docx-Dateien noch der Fall ist, aber OpenOffice ist hier definitiv die bessere Variante. Office-Dateien sollten allerdings sowieso nie verschickt oder ins Internet gestellt werden, dafür gibt es PDF!

Verschlüsselung nutzen: Wenn möglich sollten Daten nur verschlüsselt genutzt werden.

Lügen wie gedruckt: Nicht nur Papier ist geduldig, nein, das Internet ist es auch. Mit der Wahrheit sollte man es folglich nicht so genau nehmen.

Do It Yourself! Statt einem Freemailer, der protokollieren muss, sollte man einen eigenen Mailserver aufsetzen, womit man der Vorratsdatenspeicherung entgeht. Ebenso sollte man anstelle von Skype, ICQ oder MSN auf Jabber umsteigen, natürlich ebenfalls mit eigenem Server. Idealerweise steht dieser Server dann im weit entfernten Ausland. Einziges Problem dabei: Man sollte ein Minimum an Ahnung von der Materie haben. Einen Server im Internet sollte man nur betreiben, wenn man wirklich weiss, was man tut.

Falsche Spuren generieren

Offenes WLAN anbieten: Die Idee ist simpel. Man lässt den Access Point unverschlüsselt, schon können Fremde etwas das eigene Internetprofil verfälschen. Grosses Problem dabei ist natürlich, wenn diese unbekannten Dritten illegale Dinge über den Anschluss laufen lassen. Dann riskiert man Ärger mit dem Gesetz.

TOR Exitnode anbieten: Dies ist genau dasselbe Prinzip wie das offene WLAN. Auch hier riskiert man, dass die Polizei den eigenen Rechner abholt.

TOR Durchgangsknoten anbieten: Das ist nett und nützt dem TOR-Netzwerk mehr als gar nichts zu tun, bringt aber leider keinen Gewinn für die eigene Anonymität. Wenigstens muss man auch keine Repressalien des Staates befürchten.

YaCy installieren: YaCy ist eine verteilte Internet-Suchmaschine. Das ist vermutlich die beste Lösung. YaCy verursacht permanent etwas Traffic, indem es Webseiten crawlt. Allerdings sind auch hier ein paar Einschränkungen zu beachten. Werden Remote-Crawls anderer YaCy-Betreiber akzeptiert, riskiert man ebenfalls wieder illegale Inhalte abzurufen und sich somit Ärger mit der Polizei einzuhandeln. Andererseits verfälscht man sein Profil nur mässig, wenn man nur eigene Crawls startet. Und drittens meldet sich YaCy bei anderen Webseiten immer als YaCy an, ergo kann diese leicht unterscheiden, ob nun die Anfrage von Mensch (Firefox/Opera/Safari/IE) oder Maschine kam.

Verhalten

Spuren verschleiern

Spuren vermeiden

Datensparsamkeit.

Sich nicht selbst googeln.

Nicht zu paranoid sein! Wer zu paranoid ist, schläft schlecht. Dadurch lässt die Aufmerksamkeit nach und man begeht datenschützerische Fehler. Also besser Ruhe bewahren und wachsam bleiben!

Namen ändern

Eine gute Methode und in der Masse unterzugehen ist ein Allerweltsname wie Hans Meier aus Zürich, den es dutzendmal gibt. Folglich sollte man in der Grossstadt wohnen und so einen Namen haben.

Falsche Spuren generieren

Dies ist wohl der zweitschwierigste Teil, da es einfacher als eine Änderung des Realnamens geht, aber mit viel Bedacht gemacht sein will. Durch gezieltes Streuen von Fehlinformationen könnte man eigene Identitäten erfinden und sich so schlechter Auffindbar machen. Beim Streuen der Daten sollte man jedoch seine Location (wie IP-Adresse) möglichst verschleiern.

Ultima Ratio für Hyperparanoiker

Meine ultimative Idee ist die Verwendung einer Prepaid-SIM-Karte für den Internetzugang über das Mobilfunknetz. Zwar müssen alle Prepaid-SIM-Karten registriert werden, allerdings gibt es Mittel und Wege, an bereits registrierte Karten heranzukommen. Allerdings warten noch viele weitere Stolperfallen. So muss man beim Nachladen des Guthabens immer mit Bargeld an anonymen Ladestationen bezahlen. SBB-Automaten könnten dafür eine Lösung sein, jedoch sind diese von Kameras überwacht. Des weiteren sind neben der SIM-Karte auch Handies mit einer Seriennummer versehen, welche bei Verwendung an die Basisstation gesendet wird. Man braucht folglich auch ein anonymisiertes Gerät. Des weiteren sind Handies prima Peilsender, welche die Position auf wenige Meter genau verraten, und dies wird natürlich vorratsgespeichert. Kommt noch dazu, dass dies eine extrem kostenintensive Methode ist. *plopp* Seifenblase geplatzt

Fazit

Anonymität ist nicht möglich. Übermässige Paranoia nutzt aber auch nichts. Und je mehr Ahnung von IT man hat, desto mehr Anonymität kann man sich verschaffen. Also eigentlich gibt es überhaupt keine neuen Erkenntnisse

Neben Ubuntu habe ich mich auch wieder mit Gentoo befasst, wenn auch eher zwangsweise. Mein Server hat kürzlich angefangen, beim Booten lustige Fehlermeldungen auszuspucken und sich geweigert, die verschlüsselten Partition zu entschlüsseln. Manuell liess es sich hingegen problemlos bewerkstelligen.

Die Gentoo-Installation war aber sowieso schon ein Bisschen in die Jahre gekommen und entsprechend mit vielen unnötigen Paketen zugekleistert. Gleichzeitig haben die Festplatten keinen freien Platz mehr geboten. Folglich war es also an der Zeit, wieder von vorne anzufangen. Und wenn man das schon macht, können ja grad noch ein paar Verbesserungen reingebracht werden.

Als erstes wurde die untertaktete Radeon9000 gegen eine uralte Mach64 ersetzt, was wohl den Stromverbrauch weiter senken dürfte.

Als zweites habe ich von drei auf zwei Platten reduziert und von leisen Platten mit 5400rpm auf 7200rpm-Scheiben umgestellt. Die sind wesentlich schneller und dennoch kaum lauter. Statt RAID-5 läuft jetzt alles als RAID-1, was auch die CPU freut. Der neue Array packt 80MB/s Übertragungsrate auch über längere Zeit. Sehr schön. Die Partitionierung wurde beibehalten, je eine LVM-Partition für /, /var und /home, auf RAID-1 sowie eigene Partitionen für den portage-Tree und /tmp bzw /var/tmp auf RAID-0.

Als drittes habe ich von "normalem" Gentoo auf Hardened Gentoo umgestellt. Da ich auch noch SELinux implementieren möchte, sind jetzt alle Partitionen bis auf die Portage-Partition mit ext3 statt reiserfs formatiert. Reiserfs unterstützt nicht alle Sicherheitslabel, die SELinux benötigt. Zuvor hatte ich übrigens noch Debian Lenny evaluiert, allerdings hatte ich da massive Probleme mit SELinux, so dass ich doch bei Gentoo geblieben bin.

Als viertes habe ich längst nicht mehr benötigte Dienste gar nicht mehr installiert. Samba braucht mein Microsoft-freies Netz ja nun mal gar nicht.

Gerne hätte ich als fünfte Verbesserung noch Virtualisierung genutzt, da jedoch die CPU noch keine Hardware-Virtualisierung bietet, wird das etwas knifflig: Für XEN-Dom0 gibt es nur alte Kernel. Selbiges gilt für UserModeLinux, welches wohl eh tot ist. In beiden Fällen müsste ich auf viele gute Verbesserungen der neueren Kernel verzichten. VMWare ist proprietär. Und Qemu lässt sich nicht mit einem gehärteten GCC kompilieren (ausser mit manuellem Gefrickel). Nun muss also vorerst alles nativ laufen und ich warte vorerst auf neuere Implementierungen von XEN, welches mir für meine Zwecke der beste Ansatz zu sein scheint.

Vieles ist an Firefox 3 besser als an Firefox 2. Einiges ist anders und gewöhnungsbedürftig, aber deshalb nicht zwingend schlechter. Einiges ist aber eindeutig zur Katastrophe geworden. Mein Liebling hierbei ist der Umgang mit selbstsignierten SSL-Zertifikaten. Was da nun an Verrenkungen nötig ist, damit entsprechende Seiten (wie z.B. diese hier) wieder Erreichbar sind, ist unglaublich. Den dadurch entstehenden Sicherheitsgewinn erachte ich als minimal, die nötigen Arbeitsschritte für gelegentliche Internetuser hingegen für unüberwindbar. Daher eine kleine Anleitung in vier Bildern. Einfach immer dort klicken, wo der Pfeil hinzeigt:


Achtung! Fehler! Alarm! Problem! Na gut, machen wir mal eine Ausnahme.


Ja, Ausnahme hinzufügen.


Gut, nun das Zertifikat herunterladen.


Und nun speichern. Es ist natürlich auch sinnvoll, hier erst auf "Ansehen..." zu klicken und das Zertifikate nochmals zu überprüfen. Anschliessend wird die Seite geladen.

Wirklich kritische Dinge gibt es auf Planetknauer.net nicht. Da ich keine Bank bin, Eure Kreditkartendaten nicht abfrage etc pp. ist das Hinzufügen der Ausnahme wenig bedenklich. Bei e-Banking, Online-Shopping sowie sonstigen Dingen, bei denen es um Geld, personenbezogene, private oder Firmendaten geht, sollte man natürlich drauf achten, dass die Gegenseite ein gültiges Zertifikat einer offiziellen CA (Certificate Authority) verwendet. Dann erscheint auch diese Warnung nicht. Alles andere ist unseriös.