seeseekey.net - Invictus Deus Ex Machina

Wenn man sich für sei­nen SSH Zugang nur noch mit einem ent­spre­chen­den Schlüs­sel­paar anmel­det, kann man die Authen­ti­fi­ka­tion per Pass­wort deak­ti­vie­ren. Dazu wird die „/etc/ssh/sshd_config“-Datei in einem Edi­tor geöffnet:

nano /etc/ssh/sshd_config

Dort wird die Option:

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

gesucht und in:

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

geän­dert. Anschlie­ßend muss der SSH Ser­ver mittels:

service ssh restart

neu­ge­star­tet wer­den. Damit ist die Anmel­dung per Pass­wort nicht mehr mög­lich und der Ser­ver ein Stück sicherer.

Um die Ver­si­ons­num­mer eines instal­lier­ten Post­fix zu ermit­teln, reicht es im Ter­mi­nal fol­gen­des einzugeben:

postconf -d mail_version

Anschlie­ßend erhält man eine Aus­gabe nach dem Schema:

mail_version = 2.11.0

Da die Para­me­ter aus der main.cf aus­ge­le­sen wer­den, ist es wich­tig den Para­me­ter –d anzu­ge­ben. So wer­den nicht die über­schrie­be­nen Werte zurück­ge­ge­ben, son­dern die Stan­dard­werte, in die­sem Fall die kor­rekte Versionsnummer.

Da sitzt man vor sei­nem Ubuntu-Upgrade und eine unbe­dachte Hand­be­we­gung spä­ter hat man das Upgrade abge­bro­chen. In einem sol­chen Fall sollte man das Upgrade natür­lich fort­set­zen, wer möchte schon gerne ein halb­fer­ti­ges Sys­tem. Wurde die SSH Ver­bin­dung unter­bro­chen, muss sich im ers­ten Schritt mit dem Ser­ver ver­bun­den wer­den. Anschlie­ßend gibt man im Ter­mi­nal fol­gen­des ein:

dpkg --configure -a
apt-get dist-upgrade
apt-get autoremove
apt-get autoclean
reboot

Danach sollte der Ser­ver auf dem aktu­ells­ten Stand sein und das Upgrade durch­ge­führt sein. Sollte man das Upgrade vor dem Umstel­len der Paket­lis­ten abge­bro­chen haben, dürfte ein ein­fa­ches „do-release-upgrade“ genü­genum den Upgrade-Vorgang erneut zu starten.

Stan­dard­mä­ßig hört der Mail Trans­fer Agent Post­fix auf dem Port 25. Möchte man nun das Post­fix auch auf einem zusätz­li­chen Port hört, so muss man die „/etc/postfix/master.cf“-Datei bear­bei­ten. Dort sucht man die Zeile:

smtp      inet  n       -       -       -       -       smtpd

Unter der Zeile fügt man die Zeile:

587      inet  n       -       -       -       -       smtpd

hinzu. Anschlie­ßend muss der Dienst noch neu­ge­star­tet werden:

service postfix restart

Damit hört Post­fix neben Port 25 nun auch auf Port 587, dem bevor­zug­ten Port für die Mai­l­ein­lie­fe­rung von Clients.

Wenn man eige­nen Ser­ver ein­ge­rich­tet hat, auf wel­chem auch Web­dienste lau­fen, so möchte man diese even­tu­ell einem Last­test unter­zie­hen, damit man sieht wo die Gren­zen des Ser­vers bzw. des ent­spre­chen­den Set­ups liegen.

Ein mit loader.io durch­ge­führ­ter Test

Mit dem Dienst loader.io ist mög­lich sei­nen Web­ser­ver unter­schied­lichs­ten Last­test zu unter­zie­hen. In der kos­ten­lose Vari­ante sind die maxi­ma­len Anfra­gen begrenzt, aller­dings sind die Begren­zun­gen so hoch gewählt, das ein sinn­vol­ler Test ohne Pro­bleme mög­lich ist. Last­test frem­der Ser­ver sind auch nicht mög­lich, da man die ent­spre­chende URL vor­her veri­fi­zie­ren muss, in dem man eine bestimmte Datei auf dem Web­ser­ver ablegt oder alter­na­tiv die DNS-Konfiguration anpasst.

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.