Archiv für die Kategorie ‘Server’

Abgeheftet in: Server | Tags: , , | 19:03 Uhr | 0

SSH mit Google Authenticator

31
März

Dieses Blog läuft auf meinem eigenen Webserver. Neben diesem hier, administriere ich noch drei weitere. Einer davon ist der vom Hochzeitsfotografen aus Hamburg, Patrick Ludolph und sein Blog neunzehn72.de. So viel zur Einleitung.

So ein Webserver steht in der Regel in einem Rechenzentrum. Wenn man Änderungen an irgendeiner Software machen will, muss man über das Internet darauf zugreifen. Hierzu verwendet man (mal von wenigen Ausnahmen abgesehen) SSH, wenn es ein Linux Server ist (was wohl meistens der Fall ist). Wer bis hierhin weiter gelesen hat und bisher nur Bahnhof verstanden hat, dem kann ich versichern, dass es so weiter geht. Für alle anderen versuche ich mich kürzer zu fassen.

Zu Administrationszwecke arbeitet man immer mit dem root-User auf dem Server. Ja ja, ich weiß. Man sollte sich zu erst immer mit einem weniger privilegierten User auf dem System anmelden und dann zum root-User switchen, aber wer macht das schon? Wie auch immer. Da jeder Depp und jeder angehende Hacker aus Russland von der Faulheit vieler weiß, wird er versuchen, an das Passwort per Brute-Force Methode zu  kommen. Damit das nicht so schnell geschieht, sollte man ein kryptischen Passwort mit mehr als 8 Stellen haben. Nachteil ist, dass es einmal schwer zu merken und noch schwieriger ist, es einzutippen.

Die andere Möglichkeit ist, dass man per Public-Key-Authentifizierung sich an den Server anmeldet. Auf dem Server ist ein sogenannter privater Schlüssel hinterlegt und auf dem System, von dem man sich anmelden möchte, ist ein öffentlicher Schlüssel. Die Methode ist sehr sicher, hat aber einen entscheidenden Nachteil. Wenn man mal unterwegs ist, keinen Laptop mit seinem öffentlichen Schlüssel dabei und auch den USB-Stick wo der Schlüssel auch drauf ist, nicht in der Tasche hat, aber trotzdem dringend auf den Server zugreifen muss, dann ist man ganz schön gekniffen und wünscht sich die Sache mit dem Passwort zurück.

Hier kommt nun der Google Authenticator ins Spiel. Google hat vor einiger Zeit eine App für das Apple iPhone und für Android Smartphone herausgegeben, die im 30 Sekunden Takt einen sechsstelligen Code generiert. Mit der App und dem Code kann man seinen Code bei Google weiter absichern. Man ist dann gezwungen nicht nur seinen Usernamen und das Passwort bei der Anmeldung bei Google anzugeben, sondern auch diese, sich dauernd ändernde, sechsstellige Ziffer.

Ihr seid sicherlich schon selbst darauf gekommen, aber ja, man kann dieses Mechanismus auch für seinen eigenen Server nutzen. Dann meldet man sich auf dem Server mit dem Usernamen, Passwort und dem Google Authenticator an. Stimmt alles drei nicht überein, gelangt man nicht auf den Server.

Das Einrichten des Google Authenticator ist relativ einfach. Einmal installiert man Authenticator App auf sein Smartphone. Den Link dazu hänge ich an das Ende des Artikels.

Dann geht es auch schon auf dem Server weiter. Dort installiert man den Google Authenticator indem man per git den Code aus dem Reposittory holt.

1
git clone https://code.google.com/p/google-authenticator/

Nachdem das relativ schnell geschehen ist, wechselt man in das neue Verzeichnis und kompiliert die Sourcen mit:

1
make install

Anschließend fügt man die folgende Zeile in seine pam.d Konfiguration ein:

1
auth required pam_google_authenticator.so

Bei einem Gentoo System in der Datei /etc/pam.d/system-remote-login direkt nach

1
auth include system-login

Bei einem Ubuntu Server in die Datei /etc/pam.d/common-auth ganz am Ende. Weiter muss darauf geachtet werden, dass in der Konfiguration /etc/ssh/sshd_config die Zeile für die Challenge Response Authentication auf „yes“ steht, also wie hier.

1
ChallengeResponseAuthentication yes

Wenn dies nicht der Fall sein sollte, dann muss dies geändert werden und der SSHd neu gestartet werden.

Wenn dies alles geschehen ist, muss man noch den Authenticator auf dem Handy konfigurieren. Hierfür führt man auf dem Server noch

1
google-authenticator

auf dem Kommando-Zeile des Servers aus. Die Ausgabe, die man erhält, sollte man sich sicher weg speichern. In der Ausgabe ist auch ein Link enthalten. Diesen per Browser aufrufen und den QR-Code den man sieht mit der Google App auf dem Smartphone abscannen.

Nun kann man etwas ruhiger schlafen und falls man mal von irgendwo auf der Welt sich einloggen will, kann man dies nun mit dem Authenticator sicher machen.

Google Authenticator (AppStore Link) Google Authenticator
Hersteller: Google Mobile
Freigabe: 4+
Preis: Kostenlos Download
Abgeheftet in: Server | Tags: , , , | 12:02 Uhr | 0

Nur ein Test-User

9
Februar

Ich könnte mir ja soetwas von in den Hintern beissen, wenn ich nur könnte.

Gestern wurde massig Spam-eMails über meinen Server verschickt. Mehrere Hundert. Und ich konnte das Einfallstor nicht ausfindig machen. Ich bin die Logfiles des Mail-Daemons durchgegangen und für mich sah es so aus, dass die eMails auf dem lokalen Netwerk-Interface, also localhost, eingereicht werden. Ich ging also davon aus, dass entweder ein lokaler Dienst eine Sicherheitslücke hat oder aber ein Skript von einem Freund, was auf dem Server läuft. Letzteres konnte ich aber in den eMail-Headern nicht entdecken, denn normalweise steht dort drin, über was für ein Skript die Dinger versandt werden. War aber nicht so.

Also deaktivierte ich alle nicht benötigten Programme auf dem Server und löschte die verbleibenden eMails auf dem eMail-Queue. Heute Morgen waren aber wieder alle eMails da. Nur in den Logfiles konnte ich nichts entdecken, woher diese kamen. Bis ich dann endlich mal den Anfang im Log gefunden habe, wo es Anfing, dass die eMails eingekippt wurden. Da konnte ich mich dann auch wieder an etwas erinnern, was ich auch wieder löschen wollte.

Ich habe einen eMail-User mit dem Namen ‚test‘ angelegt. Passwort war natürlich auch ‚test‘.

Ganz dummer Fehler! Wirklich, ganz dumm!

Nach fast zwei Jahren habe ich es endlich geschafft, meinen zweiten Server auf Kernel 2.6 upzudaten und auch alle restlichen Pakete auf einen aktuellen Stand zu bringen. Gut Ding will eben Weile haben!

11.05.09 13:44 Uhr Keine Kommentare
1
April

In den heutigen Tagen muss man zurück zu den Wurzeln. Der ganze neumodische Schnickschnack ist überflüssig und kostet unnötige Resourcen. Darum habe ich auch auf meinem Server OpenSSH deinstalliert und nutze ab jetzt wieder telnet. Wer braucht schon verschlüsselte Datenübertragung?

Abgeheftet in: Server | Tags: , , | 17:02 Uhr | 0

Logwatch, die automatische Logauswertung

27
Februar

Seit 2003 habe ich meinen eigenen Server. Dazu kam noch der Webserver meines Cousins auf dem sein Motorrad-Zubehör-Shop läuft, sowie ein kleiner VServer. Und eines vernachlässige ich seit 2003 vehement — die tägliche Logfile-Auswertung.

Wenn Fehler auftreten schaue ich schon mal rein um den Fehler zu finden, aber die tägliche Auswertung fand ich bisher ziemlich nervig. Überflüssig sicherlich nicht, aber wenn man jeden Tag immer die gleichen Meldungen sieht, die mir mitteilen, dass ein Programm korrekt lief, dann hat man nach zwei Tagen die Lust verloren. So ist mir über die Jahre sicherlich einiges durchgerutscht oder erst sehr viel später aufgefallen, was ich viel früher hätte stoppen können.

Damit ist nun Schluss, den ich habe Logwatch entdeckt. Logwatch ist ein Perl-Skript, dass die Logfiles automatisch auswertet und dem Admin eine Zusammenfassung der wichtigsten Ereignisse des Servers einmal täglich per eMail zuschickt. Und wenn bestimmte Programme nicht von Haus aus unterstützt werden, kann man Logwatch einfach erweitern. Die Programmiersprache hierfür ist egal.

Abgeheftet in: Server | Tags: , , | 14:07 Uhr | 4

Confixx mit fcgid

19
Juli

Ich habe ja einen eigenen Server, der den ganzen Schnickschnack drauf hat, um eben diese (und ein paar Seiten von Freunde) zu generieren. Damit die Konfiguration für meine Freunde und mich etwas einfacher ist, nutze ich Confixx von SWSoft. Bei Confixx kann man über eine Weboberfläche Domainen anlegen, diesen Verzeichnisse zuordnen, etc. pp.. Dieses Confixx erstellt dann — nachdem man alle Eintragungen in der Weboberfläche gemacht hat — alle Konfigurationsdateien für den Webserver usw.

Confixx benötigt auch dringend PHP. Diese Skriptsprache, auf der auch diese Seite beruht. PHP kommt in verschiedenen Ausführungen daher. Einmal als Apache-Modul. Dieses hat den Vorteil, daß es sehr schnell ist, aber den Nachteil, daß jeder Benutzer auf dem Webserver jedem anderen in die Verzeichnisse schauen kann, weil alle PHP-Skripte unter einem einzigen Systemuser (dem des Webservers) ausgeführt werden.

Seit einiger Zeit kann Confixx auch mit suPHP umgehen. Hier ist der Vorteil, daß alle PHP-Skripte unter einem seperaten Systemuser ausgeführt werden, d. h. keiner kann dem anderen in die Karten schauen. Nachteil ist, daß jedesmal wenn eine Seite aufgerufen wird, ein grosser Overhead erzeugt wird, der in der Regel grösser ist, als das Ausführen des PHP-Skripts selbst, d. h. die Seiten werden sehr langsam und der Server ist immer sehr stark ausgelastet.

Der Kompromiss zwischen den beiden o. g. Möglichkeiten stellt fcgid dar (der Nachfolger von fastcgi). Es ist schnell, hat wenig Overhead und alle Skripte werden unter einem seperaten User ausgeführt. Der Nachteil ist, daß Confixx dies von Haus aus nicht unterstützt.

Ich habe mich zumindest daran gesetzt und ein kleines Skript erstellt, welches vor dem confixx_counter-Skript ausgeführt werden muß. Dieses erstellt für alle User die entsprechenden fcgid-Wrapper-Skripte, mit denen die PHP-Skripte ansich dann aufgerufen werden.

Zusätzlich wird eine weitere Apache-Konfigurations-Datei (confixx_special_vhost.php) erstellt, welche am Ende der httpd.conf eingefügt werden muss.

Wenn man soweit ist, trägt man in Confixx unter http-Special noch dies ein

# FCGI
AddHandler fcgid-script .php
AddHandler fcgid-script .php4
AddHandler fcgid-script .php5
AddHandler fcgid-script .phtml
#/suPHP_ConfigPath .*/
# FCGI

und die Sache sollte laufen.

Ich setzte dies nun seit ca. einer Woche ein, und der Server wurde merklich entlastet und die Seiten rauschen sehr viel schneller an.

Das Skript downloaden und auf dem Server ausführen. Wenn Fragen sind, diese in den Kommentaren stellen und ich werde ggfs. diese Ausführung erweitern.

Abgeheftet in: Server | Tags: , , | 10:07 Uhr | 0

Spamassassin DNS Probleme

13
Juli

Ich bin nun seit Mittwoch krank und habe nichts besseres zu tun, als Heissgetränke zu mir zu nehmen und an meinem Server zu schrauben.

Spamassassin machte mir schon seit einige Zeit Probleme, doch hatte ich bisher nicht die Lust, der Sache auf den Grund zu gehen. In den Log-Dateien kam immer der Fehler

spamd[13416]: dns: sendto() failed: Connection refused at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/DnsResolver.pm line 340

und Spamassassin benötigte ewig bis die eMail gescannt war. Ich tippte zu erst darauf, daß die DNS-Auflösung nicht mehr funktionierte, doch das konnte ich definitv ausschliessen.

Das Problem liegt an Spamassassin, bzw. der Perl-Klasse selbst. Es nimmt aus der resolv.conf nur den ersten, eingetragenen DNS-Server und versucht zu diesem eine Verbindung herzustellen. Schlägt dies fehl oder dauert dies zu lange, kommt der o. g. Fehler.

Ich habe nun den ersten DNS-Server Eintrag geändert und nun läuft wieder alles einwandfrei.

Hanging Monk
Beam me up!