seeseekey.net - Invictus Deus Ex Machina

Dank der Heartbleed-Sicherheitslücke, soll­ten Appli­ka­tio­nen wel­che OpenSSL nut­zen, neue Zer­ti­fi­kate erzeu­gen. Dies trifft auch auf den Mail­ser­ver Dove­cot zu. Um hier ein neues Zer­ti­fi­kat zu erzeu­gen gibt man im Ter­mi­nal fol­gen­des ein:

openssl req -new -x509 -days 3650 -nodes -out /etc/dovecot/dovecot.pem -keyout /etc/dovecot/private/dovecot.pem

Die zeit­li­che Gül­tig­keit des Zer­ti­fi­kats sollte man dabei je nach sei­nen Bedürf­nis­sen über den Para­me­ter „days“ anpas­sen. Anschlie­ßend muss Dove­cot neu­ge­star­tet werden:

service dovecot restart

Nach dem Neu­start wird das neue Zer­ti­fi­kat genutzt.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://wiki2.dovecot.org/SSL/CertificateCreation

Für Ubuntu sind eine Reihe von Pro­xy­ser­vern ver­füg­bar. Die meis­ten die­ser Dienste sind rela­tiv schwer­ge­wich­tig, was sich unter ande­rem auf die Kon­fi­gu­ra­tion aus­wirkt. Tiny­proxy und Polipo dage­gen gehö­ren zu den leicht­ge­wich­ti­ge­ren Vari­an­ten. Tiny­proxy schei­det aller­dings aus, da er keine Authen­ti­fi­ka­tion anbie­tet. Es exis­tiert zwar ein ent­spre­chen­der Bug­re­port, aber augen­schein­lich wird die­ser nicht bear­bei­tet. So bleibt nur noch Polipo. Um die­ses ein­zu­rich­ten muss es im ers­ten Schritt instal­liert werden:

apt-get install polipo

Anschlie­ßend kann die Kon­fi­gu­ra­tion bear­bei­tet werden

nano /etc/polipo/config

In die­sem Fall soll ein Ser­ver kon­fi­gu­riert wer­den wel­cher von außen mit­tels Authen­ti­fi­zie­rung erreich­bar ist. Dazu müs­sen fol­gende Optio­nen akti­viert werden:

### Basic configuration
### *******************

proxyAddress = "::0"        # both IPv4 and IPv6

### Authentification
### *******************

authCredentials=seeseekey:geheim

Nach­dem die Kon­fi­gu­ra­tion geän­dert wurde muss der Dienst neu­ge­star­tet werden:

service polipo restart

In den Proxy­ein­stel­lun­gen für die Cli­ent­seite muss der Ser­ver, Port, Nut­zer­name und das Pass­wort ange­ge­ben wer­den. Polipo nutzt dabei stan­dard­mä­ßig den Port 8123. Bei der Authen­ti­fi­zie­rung sollte man beach­ten das diese unver­schlüs­selt erfolgt und somit nicht wirk­lich sicher ist.

Die Proxy-Einstellungen von FoxyProxy

Für den Fire­fox emp­fielt sich auf Cli­ent­seite das AddOn Foxy­Proxy, wel­cher die Proxy-Konfiguration von Fire­fox erheb­lich ver­bes­sert. Damit auch DNS-Anfragen beim Proxy auf­ge­löst wer­den, sollte unter „about:config“ die Option „Network.proxy.socks_remote_dns“ auf true gesetzt wer­den. Foxy­Proxy erle­digt dies in der Stan­dard­ein­stel­lung automatisch.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://wiki.ubuntuusers.de/Polipo

Betreibt man einen Minecraft-Server auf einem Ubuntu basier­ten Ser­ver, so möchte man meist, das die­ser mit dem Ser­ver star­tet. Dafür benö­tigt man ein Init-Skript. Natür­lich kann man sich die­ses selbst schrei­ben und damit einige Minu­ten bis Stun­den ver­brin­gen. Mit Hilfe des in der Mine­craft Wiki ste­hen­den Skrip­tes geht das ganze aber wesent­lich schnel­ler. Auf der ent­spre­chen­den Seite der Wiki fin­det sich das Skript neben einer Instal­la­ti­ons­an­lei­tung. Wenn man das ganze auf sei­nem Ser­ver ein­ge­rich­tet hat, star­tet Mine­craft auto­ma­tisch und kann mit­tels des „service“-Kommandos kon­trol­liert werden.

Mit­tels des „ln“-Kommandos ist es unter Linux mög­lich sym­bo­li­sche Links zu erstel­len. Das Kom­mando eig­net sich dabei im ers­ten Moment nur für ein­zelne Dateien. Möchte man ganze Ver­zeich­nisse behan­deln, lohnt sich der Griff zu „lndir“. Unter Ubuntu muss das Kom­mando mit dem pas­sen­den Befehl nach­in­stal­liert werden:

apt-get install xutils-dev

Anschlie­ßend kann „lndir“ genutzt werden:

lndir quellverzeichnis zielverzeichnis

In der Stan­dard­ein­stel­lung gibt „lndir“ jedes ver­linkte Ver­zeich­nis aus, bis es mit dem gesam­ten Quell­ver­zeich­nis fer­tig ist. Der Para­me­ter „-silent“ ver­hin­dert dies.

Wenn man beim Aus­füh­ren einer Mono-Applikation auf einem Ubuntu-Server Feh­ler­mel­dun­gen wie diese:

Unhandled Exception: System.TypeLoadException: A type load exception has occurred.
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: A type load exception has occurred.

zu sehen bekommt, so lässt sich die­ses Pro­blem meist leicht lösen, indem man die pas­sen­den Mono-Bibliotheken durch Instal­la­tion des Pake­tes „mono-complete“ hinzufügt:

apt-get install mono-complete

Danach sollte die ent­spre­chende Anwen­dung ohne Pro­bleme starten.

Seit der neuen Ubuntu-Version Saucy Sala­man­der (13.10) befin­det sich die JSON Unter­stüt­zung für PHP nicht mehr im Standard-PHP-Paket. Aus die­sem Grunde muss das ganze mittels:

apt-get install php5-json

nach­in­stal­liert wer­den. Nach einem Neu­start des PHP-Service (in die­sem Fall der Fast­CGI Variante):

service php-fpm restart

kann die PHP JSON Unter­stüt­zung unter Ubuntu 13.10 genutzt werden.

Linux-Distributionen gibt es förm­lich wie Sand am Meer. Eine Dis­tri­bu­tion, wel­che ein wenig her­vor­sticht ist dabei „ele­men­tary OS“. Wenn man auf der Web­seite umschaut, wird man fest­stel­len, das die Ober­flä­che etwas an Mac OS X erin­nert. ele­men­tary OS kon­zen­triert sich dabei dar­auf, dem Nut­zer eine kon­sis­tente Ober­flä­che und ein ent­spre­chen­des Nut­zer­er­leb­nis zu liefern.

Das führt dazu, das es unter ele­men­tary OS im Stan­dard­um­fang nur Anwen­dun­gen gibt, wel­che GTK+ als Tool­kit nut­zen. Alle Stan­dar­d­an­wen­dun­gen nut­zen somit das glei­che Tool­kit, was dem Look & Feel zu gute kommt. Wer hier einen Fire­fox sucht, wird ent­täuscht werden.

Tech­nisch basiert ele­men­tary OS auf Ubuntu 12.04, ist aller­dings im Gegen­satz zu die­sem nur für die Platt­for­men x86 und x86-64 ver­füg­bar. Eine Por­tie­rung auf ARM Pro­zes­so­ren wäre wün­schens­wert. Durch die Deak­ti­vie­rung unnö­ti­ger Dienste, fühlt sich das ganze in der Bedie­nung sehr flott an. Die offi­zi­elle Seite von ele­men­tary OS ist unter http://elementaryos.org/ zu finden.

Wei­tere Infor­ma­tio­nen gibt es unter:
https://de.wikipedia.org/wiki/Elementary_%28Software%29#elementary_OS

Wenn man einen Ser­ver betreibt ist ein Backup sehr prak­tisch. Viele Hos­ter bie­tet mitt­ler­weile Back­up­spei­cher an, auf wel­chen man seine Daten sichern kann. In die­sem Arti­kel wird dabei davon aus­ge­gan­gen das sich auf dem Ser­ver grö­ßere Image­da­teien befin­den, wel­che inkre­men­tell gesi­chert wer­den sol­len. Im ers­ten Schritt wird der Back­up­spei­cher ein­ge­bun­den. Viele Ser­ver las­sen sich dabei mit SFTP anspre­chen. Um die­ses ein­zu­bin­den muss das pas­sende Paket instal­liert werden:

apt-get install sshfs

Danach erstel­len wir einen Mountpunkt:

mkdir /mnt/backup

Anschlie­ßend kann das ent­fernte Datei­sys­tem ein­ge­bun­den werden:

sshfs nutzer@example.org:/ /mnt/backup

Für das Backup wird „rdiff-backup“ genutzt, wel­ches über die Paket­ver­wal­tung instal­liert wer­den kann:

apt-get install rdiff-backup

Pro­ble­ma­tisch an „rdiff-backup“ ist die Tat­sa­che, das die­ses unter ande­rem mit Hard­links arbei­tet und diese bei SFTP unter Umstän­den nicht zur Ver­fü­gung ste­hen. Des­halb muss im ers­ten Schritt ein Image erzeugt wer­den und die­ses ein­ge­bun­den wer­den. Mittels:

rdiff-backup /etc/ /mnt/backup/etc/

kann dann anschlie­ßend das Backup ange­legt wer­den. Möchte man ermit­teln wel­che Back­up­ver­sio­nen sich im Ver­zeich­nis befin­den, so kann dies durch

rdiff-backup -l /mnt/backup/etc/

bewerk­stel­ligt wer­den. Damit man das ganze nicht immer per Hand erle­di­gen muss (was bei Back­ups nicht rat­sam wäre), habe ich das ganze in ein Skript gegos­sen wel­ches auf Git­Hub zu fin­den ist.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://wiki.ubuntuusers.de/FUSE/sshfs
http://www.nongnu.org/rdiff-backup/
http://www.thomas-krenn.com/de/wiki/Backup_unter_Linux_mit_rdiff-backup

Betreibt man einen Ser­ver, so wird man mit der Zeit fest­stel­len, das man nicht der ein­zige ist, der gerne Zugriff auf den Ser­ver hätte. Um zu häu­fige Log­in­ver­su­che abzu­blo­cken gibt es Fail2ban. Die­ses Pro­gramm­pa­ket durch­sucht die ent­spre­chen­den Logs und blo­ckiert bös­wil­lige Ver­su­che in das Sys­tem ein­zu­bre­chen. Damit gehört Fail2ban zu den Intru­sion Preven­tion Sys­te­men. Die Instal­la­tion auf einem Ubuntu-Server geht dabei leicht von der Hand:

apt-get install fail2ban

Anschlie­ßend kann mit der Kon­fi­gu­ra­tion begon­nen werden:

nano /etc/fail2ban/jail.conf

In den ers­ten Ein­stel­lun­gen unter „[DEFAULT]“ fin­det man die Zeit (in Sekun­den) wel­che angibt wie lange ein Angrei­fer geblockt wer­den soll. Stan­dard­mä­ßig sind dies 10 Minu­ten respek­tive 600 Sekun­den. Im Bereich „[JAILS]“ kann Fail2ban nun für bestimmte Dienste akti­viert wer­den, indem der Wert bei „enab­led“ auf „true“ gesetzt wird. Selbst­ver­ständ­lich ist es auch mög­lich eigene Jails zu defi­nie­ren. Alle vor­ge­fer­tig­ten Fil­ter­re­geln fin­det man unter „/etc/fail2ban/filter.d“. Die Über­wa­chung des SSH Diens­tes ist dabei stan­dard­mä­ßig akti­viert. Nach der Anpas­sung der Kon­fi­gu­ra­tion, sollte der Dienst mittels

service fail2ban restart

neu­ge­star­tet wer­den. Das Log in wel­chem alle Fail2ban Aktio­nen ver­zeich­net sind, ist unter „/var/log/fail2ban.log“ zu finden.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://cup.wpcoder.de/fail2ban-ip-firewall/

Vor eini­ger Zeit beschrieb ich wie man einen Mail­ser­ver unter Ubuntu mit­tels Post­fix und Dove­cot auf­setzt. Der dort instal­lierte Ser­ver ist, in der Lage Mails zu sen­den und zu emp­fan­gen. Aller­dings ent­hält er kei­ner­lei Maß­nah­men zum Schutz vor uner­wünsch­ten Mails. An die­ser Stelle setzt Post­grey, eine Grey­lis­ting Imple­men­tie­rung für Post­fix, an. Beim Grey­lis­ting wer­den Mails von einem unbe­kann­ten Sen­der erst ein­mal mit einem tem­po­rä­ren Feh­ler beant­wor­tet. RFC kon­forme Mail­ser­ver sen­den die Mail nach einer Ver­zö­ge­rung noch­mal. Beim Spam­ver­sen­dern ist dies meist nicht der Fall, womit der Spam nicht im Sys­tem auf­taucht. Die Instal­la­tion ist dabei rela­tiv einfach:

apt-get install postgrey

Nach der Instal­la­tion muss die „/etc/postfix/main.cf“ Datei ange­passt wer­den. Der Zeile „smtpd_recipient_restrictions“ wird dabei der Wert „check_policy_service inet:127.0.0.1:10023″ hin­zu­ge­fügt. Nach­dem der Ser­vice mittels:

service postfix restart

neu­ge­star­tet wurde, ist das Grey­lis­ting aktiv. In der Log­da­tei „/var/log/mail.log“ fin­det man, sobald man eine Mail von einem unbe­kann­tem Sen­der bekommt fol­gende Zeile:

Oct 10 10:32:39 service postfix/smtpd[22287]: NOQUEUE: reject: RCPT from mail.example.org[178.19.71.5]: 450 4.2.0 <mailinglists@example.com>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/example.com.html; from=<mail.example.org> to=<mailinglists@example.com> proto=ESMTP helo=<mail.example.org>

Wenn die Mail erneut emp­fan­gen wird und die Grey­lis­ting­zeit vor­bei ist, wird Post­grey die Mail anneh­men. Möchte man die Grey­lis­ting­zeit ändern, so muss die Datei „/etc/default/postgrey“ bear­bei­tet wer­den. Für eine Ver­zö­ge­rung von 60 Sekun­den könnte das ganze dann wie folgt aussehen:

POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=60"

Natür­lich muss der Ser­vice für diese Ände­rung neu­ge­star­tet werden.