Erkunde Deinen Server und schließe ihn schnell ab!

Zum Start sollte der eigene Server, gleich ob vServer oder rootserver, ersteinmal erkundet werden. Eigentlich sollte das Betriebssystem bekannt sein, immerhin musstest Du es ja selbst auswählen. Ein kurzer Check zeigt die installierte Betriebssystemversion, inklusive Kernel und Systemarchitektur:

Für Hilfe zu uname tippen wir (wie immer, wenn einen das Gedächtnis gerade verlässt):

Jetzt wollen wir den Server absichern, damit wir wenigstens keine allzu leichte Beute im Internet sind.

Ob es in der Zwischenzeit schon Login-Versuche gegeben hat, könnt Ihr den logfiles (Systemprotokoll-Dateien) entnehmen. Unter Debian/Ubuntu zu finden unter /var/log/ – also einfach eine Ausgabe (Befehl: cat für ) des logfiles mit einem effektiven Filter (grep) auf einen fehlgeschlagenen Login (fail) und diese Nennungen in der gesamten Log-Datei zählen (wc, wordcount – der Parameter hier ist übrigens ein „kleines L“ für die Anzahl der Zeilen „lines“, in denen das Gefilterte vorkommt.

Bei mir waren das schon einige und es geht munter weiter nach oben, wenn man den Befehl wiederholt und wiederholt absetzt…

Darum wollen wir nur den SSH-Zugang absichern. Grundsätzlich gibt es dafür mehrere Möglichkeiten – genannt seien hier einmal derer zwei:

  1. Login für Nutzer root deaktivieren. Das ist das, was wir machen werden.
  2. Login nur über eine Authentifizierung (z.B. via Key-Dateien/Zertifikate). Vielleicht schreibe ich hierüber auch noch später etwas.

Vorarbeiten:

Es sollte ein Systembenutzer angelegt sein, der sich später dann statt root einloggen können soll. Ansonsten wäre dieser natürlich erst einmal anzulegen. Hier exemplarisch ErsatzNutzer genannt:

Also die Einstellungen für den ssh-daemon sind unter Debian/Ubuntu in /etc/ssh/sshd_config – einfach im Editor der Wahl (hier: nano) öffnen:

Hierin finden sich die Zeilen:

die ändern wir zu:

Weiter geht’s mit der ganzen Passage der sshd_config:

Damit kommt dann immer noch eine Menge „Rauschen auf dem Server an und vielleicht sollte an dieser Stelle noch einmal darauf hingewiesen werden, dass grundsätzlich ein Login mittels Authentifizierung über Zertifikate statt der „alten“ Passwort-Methode bevorzugt werden sollte, aber für diese Stelle zunächst einmal „Convenience Over Security“ …

Eine weitere (auch viel diskutierte) Maßnahme ist das Ändern des Ports auf dem der SSH-Daemon lauscht. Auch dies können wir in der gleichen Datei sshd_config ändern – hier z.B. auf den Port 1007:

Davor sollte man vielleicht noch einmal kurz recherchieren, welche Ports für welche Anwendungen, Protokolle oder ähnliches reserviert sind (hierzu eine einfache Übersicht der standardisierten Port in der Wikipedia).

Dahinter hängen wir dann einmal fail2ban. Dieses kleine Programm sorgt dafür – wie der selbsterklärende Name eigentlich suggeriert -, dass IP-Adressen (also andere Rechner/Daemons/Skript-Kiddies…), von denen fehlerhaft Login-Versuche ausgehen, gebannt werden.

Anschließend müssen wir fail2ban noch an unsere Bedürfnisse anpassen. Die entsprechenden Dateien hierzu finden wir natürlich wieder an der üblichen Stelle /etc/fail2ban/.

Hiermit schalten wir grundsätzlich ein (enable), auf dem SSH-Port des SSH-Daemons den Dienst fail2ban zu betreiben. Dabei ignorieren wir die den Zugriff über die lokale IP-Adresse (localhost), bannen aber IP-Adressen für einen Tag (=84600 Sekunden), die innerhalb einer Stunde (=3600 Sekunden) öfter als dreimal (maxretry) versuchen, sich auf unserem Server einzuloggen. Protokoll führen wir in der üblichen log-Datei (/var/log/auth.log).

Nun ist der Server zunächst einmal etwas verschlossener, wenn gleich das auch keine völlige Sicherheit bietet, so ist das doch einmal ein guter Anfang.

Möglichkeiten zur Verbesserung sind natürlich noch, wie schon angedeutet:

  • Einführung von Zertifikaten für einen sichereren Login über eine entsprechende Authentifizierung.

KDE auf Kubuntu aktualisieren

Nachdem ich den initialen Gedanken, von Kubuntu auf KDE neon zu wechseln verworfen hatte, hier eine Anleitung, wie auch unter Kubuntu eine aktueller Version von KDE zu installieren ist – bei mir ist es im Moment eine Installation von KDE 5.x unter Kubuntu 16.04.

Hierzu ist natürlich, wie so oft sonst auch, eine alternative Paketquelle notwendig:

Die folgende Abfrage einfach mit <Enter/Eingabe> abnicken und weiter gehts:

Nun sollte das Herunterladen bzw. Installieren von mehr oder weniger vielen Updates stattfinden. Anschließend kann KDE einfach installiert werden:

Nach einen Reboot sollte alles nun funktionieren.

Google Chrome auf Kubuntu installieren

Hinsichtlich verschiedener Plugins für eigene Serverlösungen sind leider Mozilla Firefox sowie Google Chrome in Bezug auf „fertige“ Add-Ons einen Schritt weiter als Chromium oder z. B. der von mir eigentlich neuerdings präferierte Browser Vivaldi (hier online zu finden).

Google bietet auf Ihrer Website eine Versionen seines Browsers zum Download (für verschiedene Linux-Distributionen Debian/Ubuntu/Fedora/openSUSE) an: https://www.google.com/chrome/browser/desktop/index.html

Hinter diesem Link findet sich dann jeweils eine 32/64-Bit-Version von .deb-Paketen für Debian bzw. Ubuntu (und seine Derivate) sowie .rpm-Paketen für Fedora bzw. openSUSE.

Also für Kubuntu ist das .deb-Paket auszuwählen und die Nutzungsvereinbarungen (nach dem Lesen natürlich!) abzunicken. Es folgt eine geführte/automatisierte Installation, die selbsterklärend ist. Viel Spaß!