Bits, Bytes and my 5 cents

Vor noch nicht allzu langer Zeit habe ich mir Subversion auf meinem Server installiert, da die 2GB Freespace von Dropbox einfach nicht mehr gereicht haben.

Die Installation war dank einer hervorragenden Anleitung im UU.de-Wiki überhaupt kein Problem. Jedoch, da mein svn nicht öffentlich jedem zugänglich sein soll, habe ich in der /etc/apache2/mods-enabled/dav_svn.conf einen fixen User eingetragen:

<Location /svn>
    DAV svn
    SVNPath /var/local/svn
    AuthType Basic
    AuthName "svn"
    AuthUserFile /etc/apache2/dav_svn.passwd
    Require user compr00t
</Location>

Nach der Installation dann ist mir aufgefallen, das Subversion den ganzen Traffic per http transportiert, was mir nicht so wirklich zusagen wollte.

Also habe ich meinen Apache2 auf Port 443 verschoben, so dass alles per SSL gesichert wird.

Das “Umkonfigurieren” ist eigentlich überhaupt kein Problem, wenn man weiss wie Doch leider hatte ich nur eine wage Ahnung, weshalb sich das ganze über mehrere Stunden in die Länge zog.

Ich versuche hier nochmals wiederzugeben, was ich so alles rumgebastelt habe

Als erstes habe ich einen neuen Virtualhost angelegt unter /etc/apache2/sites-available/ mit dem Namen ssl und mit folgendem Inhalt gefüllt:

<VirtualHost *:443>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/svn/
    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

Nun wird der neue Virtualhost aktiviert und der alte deaktiviert

sudo a2ensite ssl
sudo a2dissite default

Danach wird Port 443 aktiviert. Dazu überschreibt man die Datei /etc/apache2/ports.conf mit folgendem Eintrag:

Listen 443

Jetzt fehlt noch ein Zertifikat für die gesicherte Verbindung. Dazu muss das Packet openssl installiert sein:

sudo apt-get install openssl

Nun kann man sein Zertifikat erstellen:

mkdir -p /etc/apache2/ssl
openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem\
-keyout /etc/apache2/ssl/apache.pem

Jetzt muss nur noch das Module ssl aktiviert werden:

sudo a2enmod ssl

Jetzt gilt es noch den Apache neuzustarten:

sudo /etc/init.d/apache2 restart
sudo /etc/init.d/apache2 force-reload

Und wenn beim restart kein fail als Antwort rauskommt, so sollte ab sofort die Weboberfläche nun über https://localhost/svn verfügbar sein.

Ich hoffe mal, ich habe nichts vergessen

Als nächstes ist nun geplant, die etwas zu schlichte Weboberfläche von Subversion durch Websvn zu ersetzten.

Ich habe mich in letzter Zeit mal wieder mit dem Absichern meiner Ubuntu Server beschäftigt.

Dabei wollte ich vorallem den SSH-Zugang besser schützen, mindestens vor automatisierten Bruteforce-Attacken.

Dabei bieten sich mir diverse Möglichkeiten:

• Keyfiles
• PermitRootLogin
• AllowUsers
• Portänderung
• fail2ban
• PortKnocking
• OTP

Als erstes habe ich mal das einloggen vom User “root” verboten. Damit sind bereits 80% aller automatisierten Attacken erfolglos.

PermitRootLogin

Dazu setzt man unter

/etc/ssh/sshd_config

hinter dem Punkt PermitRootLogin ein

no

AllowUsers

Noch besser als das Login als root zu verbieten, ist es, nur bestimmte User zuzulassen.

Dazu muss man in der Datei

/etc/ssh/sshd_config

unter dem Punkt AllowUsers alle Benutzer eingeben, welche Zugriff haben dürfen:

AllowUsers user1 user2 user3

Keyfiles

Keyfiles sind auch noch eine gute Möglichkeit um automatisierte Angriffe abzublocken. Denn, wer die passenden Keyfiles nicht hat, kann sich auch mit dem richtigen Passwort nicht einloggen.

Doch für mich persönlich sind Keyfiles eher unpraktisch, da ich mich oft von verschiedenen Maschinen aus einloggen soll, und meistens da die Keyfiles dann fehlen würden.

Portänderung

Gegen automatisierte Angriffe kann auch eine Umstellung der Ports über welche SSH (22) kommuniziert, helfen.

Das Problem jedoch, mit einem kurzen Scan kann man aufdecken, auf welchem Port SSH nun wirklich läuft.

Ändern kann man den Port unter dem Punkt

Port

in der Konfig von SSH unter

/etc/ssh/sshd_config

fail2ban

Mittels dem Tool fail2ban kann man eine IP Adresse nach einer vordefinierten Anzahl fehlgeschlagener Logins automatisch sperren.

Dies ist besonders praktisch, da ich somit nicht nur ein Mittel gegen automatisierte sondern auch gegen jegliche andere SSH Attacken habe.

Und mitels fail2ban kann man nicht nur den Zugriff auf SSH, sondern auch noch für unzählige andere Dienste wie Appache, DNS, FTP und viele mehr.

fail2ban gibt es auf den Ubuntu Packetservern über

sudo apt-get install fail2ban

Nach der Installation heisst es erst mal Einstellungen bearbeiten. Die Konfig ist unter

/etc/fail2ban/jail.conf

abgelegt.

Um den SSH Zugriff überwachen zu lassen, gilt es folgenden Textschnippsel noch zu ergänzen:

[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3

Damit wird jede IP-Adresse, welche sich 3mal mit falschem Passwort einloggen will, automatisch gebannt.

Portknocking

Eine weitere, sehr effektive Massnahme ist das sogenannte Portknocking. Das beschreibt ein Verfahren, bei welchem man zuerst mit dem geheimen Zeichen anklopfen muss, bevor man sich per SSH einloggen kann.

Wird das geheime Zeichen nicht vorweg gesendet, so erscheint der Port 22 nach aussen als geschlossen.

Realisieren lässt sich dies mittels knockd, welches wiederum in den Packetquellen verfügbar ist

sudo apt-get install knockd

Konfiguriert wird das Programm über eine zentrale Datei

/etc/knockd.conf

Um knocked nun auf den SSH Port vorzubereiten, muss man die Datei mit folgenden Eintrag ergänzen:

[openSSH] sequence = 1234,1234,1234 seq_timeout = 5 command =
/sbin/iptables -A INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn

[closeSSH]
sequence = 1234,1234,1234
seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -j DENY
tcpflags = syn

Will man sich nun per SSH einloggen, so muss man zuerst mittels

knock ip 1234 1234 1234

den Port freischalten. Nach vollbrachter Arbeit wird der Port über selbiges Kommando auch wieder geschlossen.

OTP

OTP ist ein Verfahren, mittels welchem für jedes Login ein neues Passwort generiert wird. Hier bedanke ich mich bei Benjamin für den Gedankenanstoss und die ausführliche Anleitung.

Er beschreibt dabei wie OTP in Kombination mit seinem Android Handy verweden kann. Doch auch iPhone-Benützern wie mir wird mit dem Tool “OTP Generator” von Dragon Technology Ltd geholfen, welches für CHF 3.30 im Appstore verfügbar ist.

Fazit

Für mich ist fail2ban und PermitRootLogin am besten geeignet. Obwohl ich der Meinung bin, das Portknocking wohl das effektivste wäre, weiss ich noch nicht, ob ich mein “Geheimzeichen” auch von anderen Betriebssystemen aus versenden kann. Deshalb ist dieses Verfahren vorerst mal auf Eis gelegt.

OTP ist für mich schon fast wieder übertriebene Sicherheit, und der Aufwand, jedes mal ein neues Passwort zu generieren ist mir einfach zu gross.

Natürlich ist ein offener SSH Port immer ein Sicherheitsrisiko, aber mit den obig aufgezeigten Möglichkeiten, sollte man 95% aller Attacken abwehren können.

Und sonst gilt halt immer noch: Wählt ein sicheres Passwort

[Quellen: 4t2, Horst und FreiesMagazin]

Wie schon früher berichtet laufen seit neustem einige Anwendungen auf meinen Servern zu Hause. Das Problem dabei ist nur, dass mein Server hinter einem Router hängt, wodurch ich nur eine öffentliche IP erhalte.

Um auch einzelne Server innerhalb meines Netzwerkes anzusprechen, so habe ich dafür ein Portforwarding eingerichtet. Doch was, wenn ich nun zwei Webserver im Netzwerk habe. Wie kann ich beide ansprechen? Ich kann den Port 80 ja nicht auf mehrere Server weiterleiten.

Die Lösung heisst Reverse Proxy. Dabei kann ich die Anfrage vom Router, über den Proxy auf den passenden Server weiterleiten.

Somit kann ich also als Beispiel einen Webserver und eine Groupware beide auf Port 80 betreiben. Von aussen angesprochen werden Sie dann mittels http://ip.com/webserver/ oder http://ip.com/groupware/. Der Proxy entscheidet und leitet auf den entsprechenden Server weiter.

Die Installation ist auch ganz einfach
Alles was man tun muss, ist ein Paket aus den Paketquellen zu installieren

sudo apt-get install libapache2-mod-proxy-html

Danach muss man noch die folgenden drei Module aktivieren

sudo a2enmod proxy
sudo a2enmod proxy_html
sudo a2enmod proxy_http

und den Webserver neu zustarten.

sudo /etc/init.d/apache2 force-reload

Nun kann man mit der Konfiguration beginnen. Ein Beispiel kann in etwa so aussehen:

<VirtualHost *>
…
ProxyRequests Off

Order deny,allow
Allow from all
ProxyPass /webserver/ http://192.168.1.2:80/
ProxyPassReverse /webserver/ http://192.168.1.2:80/

ProxyPass /groupware/ http://192.168.1.3:80/
ProxyPassReverse /groupware/ http://192.168.1.3:80/
…
</VirtualHost>

Nun gilt es einfach alle Server einzutragen und dann den Webserver nochmals neu zustarten. Nun trägt man ein Portforwarding im Router ein und kann somit beide Server auf Port 80 ansprechen.

Vielen Dank an das Ubuntuusers-Wiki

In letzter Zeit habe ich mich sehr oft mit ESXi beschäftigt. Dabei bin ich über ein zwei sehr hilfreiche Tipps gestolpert.

Einer der besten Tipps ist der SSH-Zugriff. Dieser ist zwar nicht offiziell unterstützt, ist aber eine in ESXi integrierte Funktion, es sind also keine weiteren Installationen nötig.

Um SSH zu aktivieren muss man zuerst in eine Konsole wechseln. Dies geht wie unter Linux mit ALT + F1. Im Gegensatz zu einem normalen Linux ist hier nur eine Konsole aktiv und nicht alle 6.

Nun folgt der schwierigste Part

Man muss blind und ohne Rückmeldung das Wort “unsupported” und das eigene Passwort eintippen.

Ab nun hat man eine normale Konsole:

~ #

Nun muss man in der inetd.conf SSH aktivieren. Dazu öffnet man diese in einem Editor,

vi /etc/inetd.conf

suchen den Eintrag

#ssh

und entfernt die Rauten wodurch bei der Zeile der Kommentar entfällt. Nun heisst es den physikalischen Server neustarten und man kann von nun an per SSH zugreifen.

Nun kann man sich per SSH alle VM’s ausgeben lassen,

vim-cmd vmsvc/getallvms

einzelne VM’s starten

vim-cmd vmsvc/power.on ID

oder den aktuellen Status abfragen.

vim-cmd vmsvc/power.getstate ID

Es gibt sicher noch unzählige mehr, aber ich denke das sind mal die wichtigsten

Einen weiteren Tipp, ist die Möglichkeit mehrere VMs automatisch mit dem Serverstart zu starten. Für mich ist diese Funktion sehr nützlich da ich meinen Server per WOL boote, wenn ich ihn brauche.