Bits, Bytes and my 5 cents

Nein, hier geht es nicht um die steigende Überwachung durch Vater Staat, hier geht es um das Monitoring von Servern, Computern, Diensten und vieles mehr.

Ich habe vor längerer Zeit mal Nagios, ein sehr komplexes Überwachungstool, aufgesetzt, aber aus Zeitmangel habe ich mich nie wirklich mit der raffinierten, aber doch sehr komplizierten Konfiguration beschäftigt.

Nun aber ist mir das ganze wieder in die Hände gefallen und ich habe mich mal aufgemacht und wollte Nagios nicht nur zum laufen bringen, sondern auch richtig konfigurieren und überwachen lassen.

Im uu.de-Wiki, welches sonst meistens meine erste Anlaufstelle für so Fragen ist, gibt es leider nur ein unfertiger Artikel. (Wenn ich die Zeit finde, werde ich mich da dann mal ran machen) Also habe ich mir meine Informationen selbst zusammengesucht.

Die Installation von Nagios ist relativ einfach. Nagios2 gibt es sogar in den Paketquellen, Nagios3 lässt sich problemlos selbst kompilieren.

Für mich reicht aber Nagios2 voll und ganz und somit habe ich mittels der Paketverwaltung mal die Pakete installiert:

sudo apt-get install apache2, nagios2, nagios2-common, nagios-plugins

Für die Installation war es das eigentlich schon! Doch ganz so einfach ist es dann doch wieder nicht.
Unter http://localhost/nagios2 ist jetzt schon die Weboberfläche zu sehen. Jedoch fehlt noch die gesamte Konfiguration, also weiter im Konzept.

Da mein Webinterface natürlich nicht für jeden Zugänglich sein soll, habe ich mir noch ein Passwortschutz angelegt:

htpasswd -bc /etc/nagios2/htpasswd.users

Nun gilt es noch den Apache neu zu starteten, damit die Änderung auch wirksam werden:

sudo /etc/init.d/apache2 restart

Nun sollte man bereits beim Aufrufen von Nagios, immer noch unter http://localhost/nagios2, nach einem Benutzernamen und einem Passwort gefragt werden.

Nun geht es los mit der Konfiguration.
Dabei sollte ich vielleicht noch ein paar Worte über das Konzept verlieren.
Wenn man den Aufbau mal verstanden hat ist es eigentlich gar nicht mehr so kompliziert

Für meine Server habe ich ein neuer Ordner angelegt:

sudo mkdir /etc/nagios2/meinnetzwerk/
cd /etc/nagios2/meinnetzwerk/

Darin werden nun alle Dateien angelegt.
Die wichtigsten Dateien, auf welche Nagios zurückgreift, sind hosts.cfg, templates.cfg, services.cfg und hostgroups.cfg.

Besonders die templates.cfg spielt in grösseren Netzwerken mit vielen Servern eine besondere Rolle. Doch dazu später.

Wir beginnen erstmal mit dem formellen Teil. Die Datei contacts.cfg birgt den Namen und die eMail-Adresse des Systemadministrators.
Dazu erstellen wir die Datei erst neu:

sudo touch contacts.cfg

Diese füllen wir mit folgendem Inhalt:

define contact{
contact_name administrator
alias DEIN-NAME
service_notification_period 24×7
host_notification_period 24×7
service_notification_options w,u,c,r
host_notification_options d,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email DEINE@EMAIL.ADRESSE
}

define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members administrator
}

Nun können wir unsere ersten Server hinzufügen.
Diese werden in der hosts.cfg aufgelistet. Doch einfach die IP-Adressen einzutragen wäre natürlich viel zu einfach

define host{
host_name SERVERNAME
alias BESCHREIBUNG
address IP.ADRESSE.HIER.EINGEBEN
use generic-host
}

Hier muss für jeden Host ein neuer “define host{}” angelegt werden.

Bis auf use sind eigentlich alle Punkte selbst erklärend. Und damit kommen wir auch schon zum gut durchdachten Konzept von Nagios.
Wir könnten jede einzelne Option wie Prüfintervalle, verwendete Kommandos, Benachrichtigungen, Maximale Überprüfungen etc für jeden Host einzelne definieren. Das wären dann pro Host alleine schon 40 Zeilen.
Nun kann man sich mal überlegen, was passiert wenn ich 20 oder sogar 100 Server eintragen und überwachen will – die Komplexität steigt und es wird schnell mal unübersichtlich.

read more »

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]

Heute war ich in der Schule und wollte auf meine Remote-Console über iLO auf meinen Server zu Hause zugreiffen. Dummerweise habe ich es nicht fertig gebracht, die auf Java basierende Konsole durch die Firewall zu schleusen, weshalb ich auf SSH und die ASCII basierte Konsole ausweichen wollte.

Doch als ich mich mittels dem openssh-client und dem Befehl “ssh user@meinserver.ch” einloggen wollte erhielt ich einen Fehler:

shell request failed on channel 0

Also habe ich auch gleich versucht mich mittels Putty zu verbinden, um eine zweite Meinung einzuholen, weil ich erst dachte, mein Router hätte mich blockiert…

Doch komischerweise hatte Putty überhaupt keine Probleme!!

Als nächstes dachte ich mir, ob es vielleicht an der Version liegen kann, da, wie mir mal zu Ohren gekommen ist, iLO 1 nur SSH1 funktionieren soll. Doch leider wollte auch dies nicht funktionieren.

Also habe ich mich nochmals mittels “SSH” versucht zu verbinden, nur dass ich mir diesmal die Debug Informationen anzeigen liess:

ssh -v user@meinserver.ch

Abgebrochen wurde die Verbindung sobald der openssh-client versuchte, meine Sprache zu übertragen:

debug1: Sending env LANG = de_CH.UTF-8

Nach längerem hin und her, und mehreren gescheiterten Versuchen habe ich dann mit “unset LANG” meine Sprache “gelöschen”. Und man glaubt es kaum, ich konnte mich auch mit dem openssh-client verbinden.

Dummerweise muss ich das nun jedes mal machen, bevor ich mich verbinden kann.

Wenn also jemand eine Lösung hat, immer her damit