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.

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.

Das schöne an einem XMPP-Server ist die Tat­sa­che das man ihn rela­tiv ein­fach auf­set­zen kann. Wenn er dann funk­ti­ons­tüch­tig ist, stellt man sich nicht sel­ten die Frage, wie sicher das ganze kon­fi­gu­riert ist. Hier hilft das IM Obser­vato­ry­mit sei­ner Web­seite.

Eine Aus­wer­tung des IM Observatory

Dort gibt man die URL zum XMPP-Server ein und anschlie­ßend wird die­ser eini­gen Tests unter­zo­gen. Nach Ablauf des Tests bekommt man eine Note von A bis F zuge­wie­sen, wobei F das schlech­teste Ergeb­nis dar­stellt. Dane­ben bekommt man detail­liert auf­ge­lis­tet wel­che sicher­heits­re­le­van­ten Fea­tures aktiv sind.

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.

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.

Möchte man Instant Mes­sa­ging mit­tels XMPP (frü­her unter dem Namen Jab­ber bekannt) nut­zen, so kann man natür­lich zu einem der vie­len Dienste wie GMail, GMX und ähn­li­ches gehen. Damit bekommt man dann neben den Vor­tei­len auch den Nach­teil, das man sich nicht sicher sein kann was mit den eige­nen Daten pas­siert. Eine andere Lösung ist es hier den XMPP Ser­ver selbst auf­zu­set­zen. Dazu bie­tet sich „ejab­berd“ an. Mittels:

sudo apt-get install ejabberd

wird das pas­sende Paket instal­liert. Der Ser­ver „ejab­berd“ unter­stützt dabei die Ver­wal­tung meh­re­rer Domains, so das eine Ser­ve­r­in­stanz die Adres­sen user1@example.org und user2@example.com bereit­stel­len kann. Um dies umzu­set­zen, geht es im ers­ten Schritt an die Kon­fi­gu­ra­tion. Dazu wird die Datei „/etc/ejabberd/ejabberd.cfg“ mit­tels „nano“ geöffnet:

nano /etc/ejabberd/ejabberd.cfg

Die Syn­tax der Datei ist dabei im Gegen­satz zu ande­ren Kon­fi­gu­ra­ti­ons­da­teien etwas gewöh­nungs­be­dürf­tig, da sie auf der Pro­gram­mier­spra­che Erlang basiert. Kom­men­tare z.B. wer­den in die­ser Datei mit einem Pro­zent­zei­chen ein­ge­lei­tet. Im ers­ten Schritt wer­den die Domain respek­tive Host­na­men defi­niert, wel­che „ejab­berd“ ver­wal­ten soll. Dazu wird der Punkt „hosts“ gesucht und mit den ent­spre­chen­den Domains gefüllt.

{hosts, ["xmpp.example.com", "xmpp.example.org"]}.

Die Ser­ver­spra­che kann man für einen deutsch­spra­chi­gen Ser­ver geän­dert werden:

{language, "de"}.

Damit wer­den Nach­rich­ten vom Ser­ver in Deutsch anstatt in Eng­lisch aus­ge­ge­ben. Stan­dard­mä­ßig ist der Ser­ver so ein­ge­stellt, das nie­mand außer dem Admi­nis­tra­tor Nut­zer anle­gen kann. Natür­lich wäre es auch denk­bar, einen Ser­ver zu betrei­ben, bei wel­chem sich jeder regis­trie­ren kann. Damit man Nut­zer anle­gen kann, muss ein Nut­zer mit den ent­spre­chen­den Rech­ten defi­niert werden:

{acl, admin, {user, "seeseekey", "xmpp.example.com"}}.

Damit ist der Nut­zer „seeseekey@xmpp.example.com“ ein Nut­zer mit admi­nis­tra­ti­ven Rech­ten. Aller­dings muss die­ser Nut­zer noch erstellt werden:

service ejabberd restart
ejabberdctl register seeseekey xmpp.example.com geheimespasswort

Wei­tere Nut­zer kön­nen anschlie­ßend über die Webober­flä­che ange­legt wer­den. Zu errei­chen ist diese dabei unter:

http://xmpp.example.com:5280/admin

Die Zugangs­da­ten ent­spre­chen dabei denen des admi­nis­tra­ti­ven Nutzers.

Wei­tere Infor­ma­tio­nen gibt es unter:
https://wiki.archlinux.de/title/Ejabberd

Wenn man sich einem unsi­che­ren Netz bewegt, z.B. in einem freien WLAN emp­fielt es sich ein VPN zu nut­zen. Dafür gibt es die unter­schied­lichs­ten VPN-Dienste, wel­che dies gegen einen monat­li­chen Obo­lus anbie­ten. Besitzt man einen eige­nen Ser­ver, so kann man sich mit­tels OpenVPN einen sol­chen Dienst sel­ber auf­set­zen. Im ers­ten Schritt wird OpenVPN installiert:

apt-get install openvpn

Aus den Bei­spiel­da­teien wird das Skript „easy-rsa2“ zum Erstel­len der Zer­ti­fi­kate an den ent­spre­chen­den Ort kopiert:

cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa2

Für die Erzeu­gung der Zer­ti­fi­kate müs­sen einige Para­me­ter ange­passt wer­den. Dazu wird die ent­spre­chende Datei im Edi­tor geöffnet:

cd /etc/openvpn/easy-rsa2
nano vars

Der Wert Key­size „KEY_SIZE“ wird von 1024 auf 2048 erhöht. Am Ende der Datei befin­den sich dann fol­gende Einträge:

export KEY_COUNTRY="US"
export KEY_PROVINCE="CA"
export KEY_CITY="SanFrancisco"
export KEY_ORG="Fort-Funston"
export KEY_EMAIL="me@myhost.mydomain"
export KEY_CN=changeme
export KEY_NAME=changeme
export KEY_OU=changeme
export PKCS11_MODULE_PATH=changeme
export PKCS11_PIN=1234

Nach der Kon­fi­gu­ra­tion sollte das ganze dann in etwa so aussehen:

export KEY_COUNTRY="DE"
export KEY_PROVINCE="MV"
export KEY_CITY="Neubrandenburg"
export KEY_ORG="Example Inc."
export KEY_EMAIL="webmaster@example.org"
export KEY_CN="vpn.example.org"
export KEY_NAME="Example VPN"
export KEY_OU="VPN"
#export PKCS11_MODULE_PATH=changeme
#export PKCS11_PIN=1234

Die „vars“-Datei wird den Umge­bungs­va­ria­blen hin­zu­ge­fügt und anschlie­ßend das Mas­ter­zer­ti­fi­kat erstellt:

source ./vars
mkdir /etc/openvpn/easy-rsa2/keys
sudo -E ./clean-all
sudo -E ./build-ca

Damit ist die Cer­ti­fi­caty Aut­ho­rity (CA) erstellt. Nun geht es an die Erstel­lung der Schlüs­sel für den Server:

sudo -E ./build-key-server server

Beim Com­mon Name, gibt man die Domain ein unter wel­cher der VPN Ser­ver spä­ter erreich­bar sein soll (z.B. vpn.example.org). Nach der Erstel­lung wird man im „keys“ Ver­zeich­nis die Dateien „server.crt“, „server.csr“ und „server.key“ fin­den. Für den Diffie-Hellman Schlüs­sel­aus­tausch müs­sen ent­spre­chende Para­ma­ter erzeugt werden:

sudo -E ./build-dh

Nun feh­len nur noch die Zer­ti­fi­kate für die ent­spre­chen­den Nut­zer. Ein Nut­zer wird dabei mittels:

sudo -E ./build-key nutzerOderClientName

erstellt. Damit sind alle benö­tig­ten Zer­ti­fi­kate und Schlüs­sel erstellt, so das nun die rest­li­che Kon­fi­gu­ra­tion des Ser­vers vor­ge­nom­men wer­den kann. Als Basis wird dabei die mit­ge­lie­ferte Bei­spiel­da­tei genutzt:

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
sudo gunzip /etc/openvpn/server.conf.gz

Nach dem Kopier­vor­gang wird die Datei „/etc/openvpn/server.conf“ mit­tels „nano“ geöff­net. Fol­gende Ein­stel­lun­gen wer­den dabei ange­passt werden:

ca ca.crt -> ca ./easy-rsa2/keys/ca.crt
cert server.crt -> cert ./easy-rsa2/keys/server.crt
key server.key -> key ./easy-rsa2/keys/server.key 

dh 1024.pem -> dh ./easy-rsa2/keys/dh2048.pem

;user nobody -> user nobody
;group nogroup -> group nogroup

;push "redirect-gateway def1 bypass-dhcp" -> push "redirect-gateway def1 bypass-dhcp"

Damit jeg­li­che Kom­mu­ni­ka­ton vom Cli­ent über den Ser­ver läuft, muss die Datei „/etc/rc.local“ auf dem Ser­ver um einige Ein­träge ergänzt werden:

iptables -t nat -F POSTROUTING
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source IP_DES_SERVERS

Nun ist der Ser­ver kon­fi­gu­riert und kann mittels:

reboot

neu­ge­star­tet werden.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://wiki.ubuntuusers.de/OpenVPN
https://de.wikipedia.org/wiki/OpenVPN