Probleme mit dem SSH-Service (und dem Typen, der vor meinem Rechner hockt und meinen Kaffe trinkt ;) )

Hallo,

nach längerer Abwesenheit habe ich endlich mal wieder Zeit (und vor allem auch Lust) gefunden einen Beitrag zu schreiben 😉 In nächster Zeit wird es denke ich wieder etwas mehr zu lesen geben. Ich will mich hier nicht festlegen, aber ein Beitrag pro Monat sollte möglich sein.

Aber nun zum eigentlichen Thema:

Wie vielleicht einige meiner Leser wissen betreibe ich einen kleinen Server bei mir zu Hause. Gestern Abend wollte ich mich via. SSH anmelden, um nach dem Rechten zu sehen. Ich bekam ein „Server refused our key“ – gut, probieren wir es nochmal…wieder das gleiche. Tja.

Hier an dieser Stelle sei gesagt, dass ich mich einen Tag vorher auf dem Server angemeldet habe, um eine wenig am SSH-Server herumzuspielen, währenddessen habe ich das „authorized_keys2“ File aus meinem Home-Verzeichniss verschoben und später als root wieder zurückkopiert. Merkt ihr was? Ich war zu dieser Zeit jedenfalls nicht geistig in der Lage zu kapieren warum ich nicht auf den Server kam… (Wenn ihr an dieser Stelle schon wisst, warum, dann schreibt es in eine Kommentar – nicht schummeln 😉 )

Als ich nun nach ein paar Versuchen nicht auf den Server kam dachte ich an das „worst case szenario“. Da mein Server auch aus dem Internet erreichbar ist, kam die Vermutung auf, dass sich wohl ein Angreifer eingeschlichen hat (obwohl das eigentlich dank public-private-key Authentifizierung nicht möglich ist – aber der Angreifer hätte ja theoretisch eine Sicherheitslücke ausnutzen können…). Als erstes schaltete ich den Server aus und machte mit dd (für Windows-User empfehle ich Win32-DiskImager) ein Festplattenimage. Dieses konvertierte ich in mit dem Befehl

 VboxManage convertfromraw –format VDI [fileIn].img [fileout].vdi

und importierte es als virtuelle Festplatte in eine Ubuntu-VM. Dannach fiel mir ein, dass vlt. die externe Firewall etwas gemerkt haben könnte, allerdings fand ich nur das übliche „weiße Rauschen“ d.h. Bots, die verschiedene User-Accounts durchprobierten. Also zurück zu unserem Image: Zuerst inspizierte ich das keyfile in meinem Home-Verzeichniss und fand es leer vor, allerdings fand ich, als ich es als root öffnete, den key vor (auch hier habe ich noch nicht kapiert, was los war).

Ein paar logs, bash_historys und eine Kaffe später beschloss ich mich aufs Ohr zu hauen und einfach eine Nacht darüber zu schlafen. Als ich mich am nächsten Tag mit jemand anderem über das Problem unterhielt, viel es mir wie Schuppen von den Augen…

Zur Erinnerung ich war root, als ich die Datei in mein Home-Verzeichnis schob! Na? Genau, das heißt, dass nach dem kopieren auch root Besitzer der Datei war und der ssh-Service die Datei nicht mehr lesen durfte… Also änderte ich die Zugriffsrechte baute die Festplatte wieder ein und voilá, es klappt wieder 😉

Ich hoffe euch hat die kleine Story gefallen und ihr könnt im Nachhinein ebenso darüber lachen wie ich 😉 Wie auch immer, ich habe meinen Server zurück und ihr habt eine Story. Ende gut, alles gut.

Vielen Dank fürs Lesen! Anmerkungen? Fragen? Schreibt sie gerne in die Kommentare.

Liebe Grüße,

splix

Logdateien analysieren mit Logwatch

Hallo,

Log-Datein verbergen viele wertvolle Informationen über Probleme und Angriffe unter Bergen belangloser Statusmeldungen. Linux/Unix ist ein sehr gesprächiger Geselle und für einen sicherheitsbewussten Administrator wird die tägliche Suche nach Problemen im System zur „Suche nach der Nadel im Heuhaufen“.

Logwatch nimmt euch diese Arbeit ab und schickt täglich eine Mail mit den wichtigsten Infos aus den Log Dateien.

Installation

Zuerst muss logwatch aus der Paketquelle installiert werden (wie immer als root):

sudo su
apt-get update
apt-get install logwatch -y

Das -y am Ende des install Befehls bewirkt, dass die Frage, ob logwatch auch wirklich installiert werden soll automatisch mit ja beantwortet wird.

Als nächstes bearbeiten wir das cron-script für logwatch:

nano /etc/cron.daily/00logwatch

Den aktuellen Befehl erweitert ihr wie folgend:

/usr/sbin/logwatch --range 'yesterday' --output mail --mailto email@beispiel.de --detail 0

Unter range gebt ihr, wie der Name schon sagt, den Zeitraum der logwatch Analyse an. Es kann entweder ein einzelner Tag sein, z.B. ‚yesterday‘ oder ein Zeitraum, wie ‚between 5 days ago and yesterday‘.

Bei mailto gebt ihr eure Email-Adresse an – natürlich muss das System einen Weg kennen, wie es die Email verschicken kann. Dafür eignet sich z.B. ssmtp aus meinem vorherigen Beitrag.

Zum Schluss müsst ihr noch angeben, wie detailliert die Ausgabe sein soll.

Das war es auch schon. Am nächsten Tag solltet ihr eine Email von logwatch mit der Tageszusammenfassung bekommen. Vielen Dank fürs Lesen! Anmerkungen? Fragen? Schreibt sie gerne in die Kommentare.

Liebe Grüße,

splix

Ein ungewöhnliches Projekt – AutoIT NetzAdmin

Hallo liebe Leser,

heute geh es um ein etwas ungewöhnliches Projekt von mir. Hier muss man dazusagen, dass ich eher ungern programmiere (ok – Arduinos sind ne Ausnahme 😉 ), aber manchmal muss es nun mal sein. Konkret geht es um ein kleines Projekt, dass ich für mein NAS im Heimnetz geschrieben habe, um es einfach zu machen es ein und auszuschalten ohne aufzustehen und hin zulaufen. Es kann den Server aufwecken (WOL = WakeOnLAN, d.h. über das Netzwerk wecken), ihn neu starten und herunterfahren. Das Programm habe ich für unsere beiden Windows PCs geschrieben, es sollte aber auch in einer Emulation auf Linux laufen (Stichwort wine). Für das WOL kann das Script entweder selbst ein Paket verschicken oder über ssh einem anderen Server den Befehl geben das NAS aufzuwecken (z.B. ein Script aufrufen, dass auf einem MikroTik liegt 😉 ). Für das Neustarten und das Ausschalten wird mithilfe des Tools PLINK eine ssh Session zum NAS aufgebaut (da es nur fürs Heimnetz ist trage ich das Passwort im Klartext ein, weil es aufwendiger wäre ssh-Keys zu verteilen – na gut ich bin zu faul 😀 ). Außerdem ist eine Echtzeitanzeige über den Onlinestatus des Server vorhanden (einfacher Ping). Damit das Script funktioniert muss wie im Kommentar beschrieben die PLINK.exe vorhanden sein.

Den Quellcode findet ihr auf meinem Github Account (https://github.com/Spl1x/AutoIT-NetzAdmin) unter einer MIT License. Ich hoffe es gefällt euch und ihr findet Verwendung dafür.

Viele Grüße,

splix

Linux: Mails ohne großen Aufwand verschicken (ssmtp)

Hallo,

heute geht es um das Thema Emails. Besser gesagt geht es um das verschicken von Emails, denn es gibt Fälle, in denen das eigene Linux System Mails verschicken soll, z.B. Logwatch oder ein Webserver, der über Mail-Funktion von PHP Mails verschicken soll. Doch für solche kleinen Aufgaben wäre es viel zu aufwendig Postfix, Sendmail etc. einzurichten. Außerdem ist es Privatleuten ohne feste IP (die meisten Mail-Server verwerfen Emails von Privaten IPs, um Spam zu vermeiden) und ordentliche Zertifikate ohnehin nicht möglich einen solchen Server zu betreiben. Um dieses Problem zu lösen kann man einen sogenannten SMTP-Ralay-Server einrichten. Dieser nimmt die Emails entgegen und verschickt diese über den Mailserver eines „legitimen“ Anbieters. Lange Rede kurzer Sinn, es geht um die Einrichtung des netten Tools ssmtp, das für das oben genannte Problem eine gute Lösung ist:

Als muss ssmtp aus der Paketquelle installiert werden. Hier nochmal der Hinweis: Installiert und konfiguriert wird als root!

sudo su
apt-get update
apt-get install ssmtp

Jetzt geht es an die Einrichtung von ssmtp, hierbei müssen 2 Konfigurationsdateien an die eigenen Bedürfnisse angepasst werden. Fangen wir mit der Datei ssmtp.conf an (ich verwende wie immer nano, aber ihr könnt gerne den Editor eurer Wahl nehmen). Hier wird der zu nutzende Mailserver inklusieve Passwort Benutzer usw. eingetragen werden:

nano /etc/ssmtp/ssmtp.conf

Das Beispiel zeigt die Einrichtung für ein GoogleMail Konto, die FETT geschriebenen Zeilen müsst ihr an eure Situation anpassen. Wenn ihr einen anderen Anbieter habt, googelt einfach den Namen zusammen mit „Postausgangsserver“ und ihr werdet die notwendigen Daten finden.

root=NAME@gmail.com
mailhub=smtp.gmail.com:587
hostname=NAME@gmail.com
UseSTARTTLS=YES
AuthUser=NAME
AuthPass=PASSWORT
FromLineOverride=YES

Wie ihr hier seht wird das Passwort leider im Klartext gespeichert, richtet euch am besten ein extra Email-Konto für ssmtp ein.

Also Nächstes müssen wir noch festlegen, wer den Mailserver benutzen darf, das passiert in der revaliases Datei:

nano /etc/ssmtp/revaliases

Hier tragt ihr in diesem Format ein welche Benutzer den Server verwenden dürfen:

BENUTZER:NAME@gmail.com:smtp.gmail.com:587

Das würde bedeuten, dass der Benutzer BENUTZER Mails von NAME@gmail.com über den Server smtp.gmail.com (Port 587) verschicken darf.

Zum Schluss will das Setup natürlich auch getestet werden:

echo „Test“ | mail EMPFÄNGER@BEISPIEL.DE -s „Betreff“

Das wars auch schon für dieses mal. Vielen Danke fürs Lesen! 🙂 Falls ihr noch irgendwelche Fragen oder Anmerkungen habt stehe ich in den Kommentaren gerne zur Verfügung.

Liebe Grüße,

splix

2 Faktor Authentifizierung für ssh mit Google Authenticator

Hallo,

dieses mal geht es um die 2-Faktor-Auhtentifizierung für den ssh Service. Ein Passwort alleine ist heutzutage fast schon wieder überholt, aber eine sonst übliche Authentifizierung über einen ssh-Schlüssel ist umständlich, denn jedes Gerät, das auf den Server zugreifen soll braucht diesen Schlüssel. Nun ist es auch keine Option, den Schlüssel einfach auf einen öffentlichen Server hochzuladen und sich bei Bedarf zu besorgen, denn sonst könnte man ja gleich drauf verzichten, wenn jeder Zugang zu dem Schlüssel hätte.

Ein möglicher Lösungsansatz ist die sogenannte 2-Faktor-Auhtentifizierung. Hierbei braucht man zusätzlich zu dem Benutzernamen und Passwort noch ein Einmalpasswort. Eine tolle Möglichkeit um dieses Konzept umzusetzen ist die Google-Authenticator App. Dabei generiert der Server auf dem der ssh Dienst läuft und das Smartphone ein Einmalpasswort. Das tolle daran ist, dass hierbei keinerlei Verbindung zwischen dem Server und dem Smartphone bestehen muss, d.h. man kann auch auf einem Gerät ohne mobile Datenverbindung jederzeit funktionsfähige Passwörter generieren (nützlich wenn man sich von einem fremden Rechner aus anmelden muss).

Wie geht das?

Am Anfang tauschen Server und Smartphone einmalig einen gemeinsamen Schlüssel aus. Mithilfe diesem und der aktuellen Uhrzeit (die auf beiden Geräten gleich sein muss) wird dann das Einmalpasswort generiert. Toll oder? 😉

Also, wie richte ich das jetzt ein…?

Ihr seit so weit gekommen? Super 😉 Die folgende Schritt für Schritt Anleitung zeit euch, wie ihr die 2-Faktor-Auhtentifizierung auf einem Debian/Ubuntu u.Ä einrichtet:

Als erstes braucht ihr das Google Authenticator Paket, installiert wird natürlich als root:

Vorher stellen wir mit einem update nochmal sicher, dass eure lokale Paketliste auf dem aktuellen Stand ist, dann wir installiert.

apt-get update
apt-get install libpam-google-authenticator

Also Nächstes müsst ihr noch ein paar Dateien anpassen, ich benutze dazu bevorzugt den Editor nano, weil er Syntax Highliting beherrscht und einfach zu bedienen ist.

nano /etc/pam.d/sshd

Dort fügt ihr folgende Zeile hinzu und verlasst mir Strg+x

auth required pam_google_authenticator.so

Nurnoch eine Datei, dann seit ihr auch schon fast fertig 😉

nano /etc/ssh/sshd_config

Hier müsst ihr folgende Zeile finden und das aktuelle no durch ein yes ersetzen:

ChallengeResponseAuthentication yes

Ob ihr es glaubt oder nicht, der großteil ist schon erledigt. Wechselt zu einem Benutzer eurer Wahl, der sich mit der 2-Faktor-Auhtentifizierung anmelden soll und führt folgende Befehl aus:

google-authenticator

Es werden euch ein paar Fragen gestellt, beantwortet die ersten beiden mit „y“. Den Rest könnt ihr wählen, wie ihr wollt. Ich empfehle die nächste mit „y“ und die folgenden beiden mit „n“ zu beantworten. Noch eine kleine Anmerkung zur letzten Frage, bei der ihr gefragt werdet, ob ihr ein Einlogglimit einrichten wollt: Das kann man auch sehr schön mit fail2ban machen, dazu wird es in Zukunft vielleicht auch einen Blog geben.

Wie auch immer, zu den Einstellungen: Installiert euch die Google-Authenticator App aus dem Playstore und scannt den Barcode. Zum Schluss solltet ihr noch die Notfallcodes an einem Sicheren Ort verwahren, denn solltet ihr, aus welchem Grund auch immer keinen Zugriff auf euer Hany haben, habt ihr auch keinen Zugriff auf euren Server. Diese Codes können euch dann den Hals retten.

Wechselt zu root und macht einen Neustart des ssh Service:

sudo su
/etc/init.d/ssh restart

Bleibt zur Sicherheit noch mit root eingeloggt, bis ihr sicher seit, dass es klappt.Herzlichen Glückwunsch, ihr habt jetzt eine funktionierende 2-Faktor-Auhtentifizierung! 😉

Liebe Grüße,

splix