Open Source und (IT-) Sicherheit

Im Zuge der Skandale um die Ausspähung von Internetaktivitäten deutscher Bürger kam in vielen Medien die Frage hoch, “wie sicher denn eigentlich Open Source” sei. Diese Frage wurde mir vor kurzem so pauschal auch von Freunden, Bekannten und Kunden gestellt. Die Frage ist schwer und in Kürze gar nicht zu beantworten. Zudem ist sie aus meiner Sicht im Kern falsch gestellt und legt Zeugnis von einem, aus meiner Sicht doch sehr unzureichendem Sicherheitsbegriff und zugehörigen, ggf. zu optimistischen Erwartungen an Technik ab.

Etwas sarkastisch fasse ich meine Meinung zu dem Thema Sicherheit, Internet, Open Source deshalb mal in folgenden 10 Thesen zusammen :

Erstens: Es gibt beim Einsatz von IT-Systemen keine 100%-ige Sicherheit. Man kann nur versuchen, Risiken zu erkennen, zu bewerten und zu minimieren. Das gilt selbtsverständlich auch für Open Source.

Zweitens: Der Transport unkryptierter Information (z.B. per E-Mail oder von und zu Web-Services) über das Internet ist grundsätzlich nicht sicher. Ferner: Die Lagerung unkryptierter Information in der Cloud ist grundsätzlich nicht sicher. Beides hat im Kern nichts mit Open Source zu tun. Wenngleich Linux als “Open Source”-Aushängeschild eine umfangreiche Palette an Tools für die Kryptierung von allem Möglichen und für alle möglichen Zwecke anbietet.

Drittens: Im Internet gibt es erstmal keine Freunde. Und wenn im Einzelfall doch, so sind da draußen viel, viel mehr Gegner oder im besten Fall Firmen, die ausschließlich an deinem wirtschaftlichen Nutzen interessiert sind. Im Internet gibt es auch nichts wirklich umsonst. Vielmehr ist das Internet in großen Teilen ein Markt, der nach wirtschaftlichen Kriterien bearbeitet und abgeerntet wird.

Viertens: Wer seine persönlichen oder firmenbezogene Daten, Emails, etc. aus Bequemlichkeit, Kostengründen oder schlicht wegen eines Lifestyle-Feelings den Providern elektronischer Services und von Social Media anvertraut, deren Server irgendwo in der Welt stehen, muss damit rechnen, dass diese Daten zu allen möglichen Zwecken ge- und mißbraucht werden. Das hat insofern etwas mit Open Source zu tun, als viele dieser Dienste mit Open Source Tools und auf der Basis von Open Source Libraries entwickelt wurden und auch auf Linux-Servern betrieben werden. Das bringt uns zu Fünftens.

Fünftens: Nicht nur ein grundsätzlich Böser, sondern auch ein Anbieter guter Werkzeuge, der primär von Profitinteressen getrieben wird, kann unter bestimmten Umständen zu einem potentiellen Gegner mutieren und dieses Werkzeug und die angebotenen Dienste dann auch gegen deine Interessen richten, gegen deine Interessen nutzen oder deine Daten an Dritte weitergeben. Das gilt im Besonderen dann, wenn Organisationen mit einem Zugriff auf umfangreiche Ressourcen jeder Art im Spiele sind. Auch wenn die “guten” Werkzeuge “Open Source” basiert sind.

Sechstens: Smartphone-Dienste, Google Android (gerade in puncto Sicherheit ein entkerntes Linux), Apple-Dienste etc. – die “schöne neue Welt” => siehe Zweitens bis Fünftens.

Siebtens: Weil es so schön passt und wir uns wieder deutschem Boden nähern wollen : Mail-Dienste, Web- und Web-Hosting-Dienste, DE-Mail, e@Post etc. : Die sind genau so sicher, wie man den Providern und deren Personal vertraut und hofft, dass eine Sicherheitszertifizierung ihrer Rechenzentren bedeutet, dass die Betreiber/Personal sich immer auch unter Druck ethisch einwandfrei und in deinem Interesse verhalten. Egal, ob und welche Open Source Tools dabei zu Einsatz kommen. [ Nur ein wenig Off Topic: Warum sind z.B. bei kaum einem Web-Hoster, der PHP-Services anbietet, Bibliotheken mit wirklich hochwertigen Zufallszahlen-Generatoren als Basis von zu entwickelnden Sicherheitsmechanismen verfügbar? Warum bieten einige der genannten E-Mail-Dienste für die Standardnutzer zwar einen sicheren Transportweg aber
keine Ende-zu-Ende-Verschlüsselung des transferierten Inhalts an?]

Achtens: Linux und Open Source Anwendungen sind so sicher wie das meist heterogene Umfeld, in dem sie zum Einsatz kommen. Sie sind ferner maximal so sicher, wie die Standards es sind, auf denen sie und ihre Sicherheitsmechanismen ruhen.

Neuntens: Linux und Open Source sind so sicher, wie das Wissen und Risikoanalysen der zugehörigen Betreiber und Anwender reichen. Die Sicherheit verschiebt sich ferner mit dem Zugriff auf und dem Einsatz von qualifizierten Ressourcen auf beiden Seiten.

Zehntens: A fool with a tool is still a fool. Und niemand meine, dass er dauerhaft unfehlbar sei …. Wir sind alle manchmal “fools”. Mit oder ohne Open Source. Als Anwender wie als Admin …

Nachtrag: Alle zehn Thesen gelten für den Einsatz von IT im privaten Bereich, Firmen und auch in der öffentlichen Verwaltung.

Ok, das war jetzt zugegebenermaßen ein wenig sarkastisch und pessimistisch. Natürlich gilt auch : Open Source kann den Einzelnen stärker in puncto Sicherheit machen. Open Source ist eine mächtige Ressource – gerade im Sicherheitsbereich.

Etwas ernsthafter setze ich mich mit der Frage nach der Sicherheit von Open Source in einem andern (von mir leider meist sträflich vernachlässigten) Blog auseinander. Hier der Link für Interessierte:

http://iso-blog.anracom.com/?p=246 oder
http://iso-blog.anracom.com/2013/10/open-source-sicherheit-und-die-sicherheit-des-umfelds/

Strato-V-Server mit Opensuse 12.3 – II – Installation / SSH-Port ändern

Im vorhergehenden Teil dieser kleinen Reihe zum Aufsetzen eines LAMP-Systems auf einem Strato-V-Server
https://linux-blog.anracom.com/2013/10/03/virtueller-strato-v-server-mit-opensuse-12-3-i/
hatten wir einen kurzen Blick auf die durchaus begrenzte Verwaltungsoberfläche für das Serverpaket geworfen, die Strato anbietet. In diesem Beitrag installieren wir auf dem bereitsgestellten V-Server zunächst Opensuse 12.3. Danach treffen wir erste Maßnahmen, um die Sicherheit des Systems etwas zu verbessern. Dies betrifft das Hochfahren einer einfachen Firewall, aber auch einige Maßnahmen in puncto SSH-Zugang. Die Nummern unserer “Schritte” zur Installation zählen wir einfach weiter hoch.

Schritt 2: Installation eines “Opensuse 12.3”-Minimalsystems

Die Linux V-Server von Strato sind nach ihrer Bereitstellung mit Ubuntu ausgestattet. Wir möchten jedoch gerne Opensuse 12.3 nutzen. (Liegt in diesem Fall nicht nur an mir, sondern auch am Kunden). Der Menüpunkt “Neuinstallation” des Strato-Verwaltungsmenüs hilft uns hier weiter. Dort können wir das zu installierende Betriebssystem auswählen.

strato_server_7_600

Der Neuinstallationsprozess dauerte bei uns ca. 45 Minuten. Danach war das Strato-System wieder zugänglich. Wer erwartet, nun eine umfangreiche Installation mit Serverdiensten vorzufinden, irrt. Es wird lediglich ein (32Bit-) Minimalsystem mit SSH-Zugang installiert. Die weitere Bestückung mit Serverdiensten obliegt dem Kunden selbst. Hierzu muss er entweder die Web-Administrationsoberfläche “Plesk” verwenden, oder er legt – wie wir – selbst Hand an. [ Ich werde hier nicht in eine unergiebige Diskussion einsteigen, warum ich aufgrund früherer Erfahrungen für die Einrichtung des Servers nicht Plesk verwende].

Um auf dem Server arbeiten zu können, benötigen wir einen Shell-Zugang über SSH.

Schritt 3: Erster SSH-Zugang

Nach der Suse-Installation kann der Standard “ssh-Port 22” für den Shell-Zugang genutzt werden. Die erforderlichen Informationen zum Root-Zugang erhält man unter dem Strato-Verwaltungs-Menüpunkt “Serverkonfiguration >> Serverdaten”. Also auf dem eigenen System (hier mit “mylinux” bezeichnet)

mylinux:~ # ssh root@hxxxxxx.stratoserver.net

mit seiner Serverkennung hxxxxxx eingeben und die Frage nach dem Passwort beantworten. Man landet dann auf einem normalen (roten) SuSE-Shell-Prompt

hxxxxxxx:~#

Die Opensuse Paketverwaltung für die ASCII-Terminaloberfläche ist über das Kommando “yast” selbstverständlich zugänglich. Mit dem SW-RPM-Management (yast-Punkt: “SW installieren oder löschen”) kann man sich dann mal ansehen, was alles installiert ist. Das ist nicht viel. Die vorhandenen Installationsquellen beschränken sich auf die elementaren Repositories und die installierten SuSE-Paketgruppen bzw. Patterns im wesentlichen auf das Basissystem.

strato_server_8_600

Um das System zu beschäftigen, während wir uns gleich weiteren administrativen Aufgaben zuwenden, installieren wir im Hintergrund mittels “yast” die RPMs des Patterns “WEB- und LAMP-Server”. Ferner installieren wir das RPM-Paket “rkhunter”.

strato_server_10_600
strato_server_14_600

Letzteres Paket liefert ein Programm, das den Host nach Rootkits durchforstet. Wenn man die anlaufende Installation parallel verfolgen will, z.B. um ein Gefühl für die die Netzperformance zu bekommen, öffne man einfach eine zweite Shell auf dem Server.

Schritt 4: Firewall aktivieren

Ein Absetzen des Befehls

hxxxxxxx:~# iptables -L

und ein Blick mit “yast >> Sicherheit und Benutzer >> Firewall” belehren einen darüber, dass auf dem Minimalserver keine Firewall läuft. Andererseits zeigt ein

hxxxxxxx:~# lsof -i

doch einige offene Ports an (sunrpc, ipp,..). Das gefällt uns erstmal nicht. Um die Ports nicht gleich schließen zu müssen, aber doch den Schutz etwas zu verbessern, fahren wir deshalb eine minimale Firewall in Form der Suse-Firewall2 (“yast >> Sicherheit und Benutzer >> Firewall”) hoch.

Achtung- im Umgang mit einer Firewall auf einem Remote-System gibt es ein paar wichtige “Trivialitäten” zu beachten :

  • Beim Einrichten einer Firewall auf einem Remote-Server ist eine regelmäßige Grundübung die, darüber nachzudenken, dass man sich nicht selbst aussperrt. Dies impliziert die Freigabe bestimmter Dienste (für bestimmte eigene IP-Adressen) und ggf. auch ein Nicht-Hochfahren der Firewall bei einem Reboot als letztem Rettungsanker.
  • Wir müssen bei der Konfiguration der SuseFirewall und vor deren Start erst einmal den Standard “SSH-Port/SSH-Dienst” freigeben. Das ist essentiell, sonst sperren wir uns mit dem Start der Firewall unmittelbar selbst aus.
  • Den automatischen Start der Firewall haken wir auf der entsprechenden YaST-Konfigurationsseite (zunächst) nicht an. Dies gibt uns die Chance, bei Fehlern mit der Firewall zumindest über einen Reboot wieder Zugang zum Serversystem zu erlangen.

Nachdem man mal eine laufende und getestete FW-Konfiguration erstellt hat, wird man einen entsprechenden Service zum Anlegen der iptables-Regeln natürlich mit dem Start des Systems automatisch hochfahren lassen. Bei dieser Gelegenheit ist die Anmerkung angebracht, dass Strato technisch begründete Restarts der V-Server oder deren Hosts normalerweise vorab mit E-Mails ankündigt. Man kann sich dann im Bedarfs- oder Zweifelsfall zur Not auch auf ein manuelles Hochfahren seiner Firewall einstellen.

Also:

strato_server_11_600

strato_server_12_600

Erst jetzt starten wir die Firewall [FW] mit Hilfe der entsprechenden Optionen unter der YaST-Oberfläche für die SuseFirewall. Nach deren Start sollte man direkt in der geöffneten Shell weiterarbeiten können. Ein erneutes “iptables -L” zeigt uns nun allerdings eine Reihe aktiver Regeln an. Eine Abbildung der wichtigsten Regeln der SuSE-Firewall liefere ich weiter unten nach einer weiteren Einstellung nach.

Hinweis: Diese Firewall-Regeln werden uns später nicht mehr genügen. Im Bereich eingehender Verbindungen ist nun nur noch der SSH-Zugang erlaubt. Die FW läßt im Moment aber noch jede Art von ausgehender Verbindung zu. Das macht es später deutlich schwerer, illegale Aktivitäten
des Servers zu entdecken. Am Ende dieser Artikel-Reihe werden wir deshalb auch ausgehende Verbindungen drastisch beschränken.

Schritt 6: Root Kit-Scan

Bevor wir uns intensiver mit SSH befassen, ist es durchaus sinnvoll, zunächst einen Scan auf bekannte Linux-Root Kits durchzuführen. Als Grund führe ich die Welle an SSH-RootKits an, die Ende Februar dieses Jahres viele gehostete Server betroffen haben. Siehe hierzu die Links am Ende des Beitrags. Wir sollten uns vor weiteren sicherheitsrelevanten Maßnahmen sicher sein, dass wir uns über die Installation und den eigenen SSH-Zugang nicht bereits etwas auf dem System eingefangen haben.

Also :

hxxxxxxx:~# rkhunter -c

Es werden verschiedene Checks durchlaufen – u.a. eben auch auf RootKit-Merkmale. Auf dem Stratoserver mit Opensuse 12.3 kommt es dabei auch zu einigen interessanten Warnungen.

strato_server_15_600

Im Bereich der RootKit-spezifischen Suchen sollte – oder besser muss – aber alles OK sein.

strato_server_18_600

Danach tauchen weitere Warnungen auf:

strato_server_16_600

strato_server_17_600

Die Warnungen sollte man übrigens durchaus ernst nehmen und ihnen durch Studium des Logfiles

/var/log/rkhunter.log

einzeln nachgehen. Ich habe das gemacht und in allen Fällen sehr plausible Gründe dafür gefunden, warum die bemängelten Dinge auf dem frisch installierten System dennoch in Ordnung waren. Die Warnungen zu den Kernel-Modules rührt u.a. daher, dass auf dem mit Parallells virtualiserten Systemen keine Kernelmanipulationen der Hosts erlaubt sind und “lsmod” und “modprobe” wegen des fehlenden Hostzugriffs nicht funktionieren. [Das ist anders als z.B. bei KVM.]

Schritt 6: SSH-Port verlagern

Es ist keine gute Idee, den SSH-Port auf der Standardeinstellung 22 zu belassen. Das hilft nur den Script-Kiddies. Ich wähle deshalb für die SSH-Kommunikation immer einen Port weit jenseits normaler hoher Ports. Diese werden nach meinen Erfahrungen nicht so häufig von scripts durchsucht. [Natürlich nutzt eine Port-Verlagerung nichts gegenüber professionellen Angreifern – aber getreu der Weisheit, mehrere Hürden zu staffeln, ist das ein erster ablenkender Schritt.]

Zur Umlenkung des SSH-Ports gilt es, als root einen entsprechenden Port-Eintrag am Anfang der Datei “/etc/ssh/sshd_config” vorzunehmen:

Port XXXXX

Natürlich mit einer vernünftigen großen Zahl für den Port – ggf. oberhalb 60000. Wir speichern die Zeile in der sshd-config ab; wir starten den SSH-Service aber natürlich noch nicht neu. Achtung – vor dem Restart des SSH-Services ist zweierlei zu beachten :

  • Den neuen Port muss man sich unbedingt merken ! Sonst kann man sich von seinem lokalen System aus später nicht mehr einloggen.
  • Die laufende Firewall muss zuerst für den neuen Port geöffnet werden.

Letzteres erledigen wir wieder mit yast: Auf der Seite “Erlaubte Dienste” nutzen wir den Punkt
“Erweitert” und fügen folgende eigene Regel hinzu:

strato_server_13_600

Achtung auch hier: die “6xxxx” sind natürlich nicht wörtlich zu nehmen; hier ist insgesamt exakt die oben in der sshd-Konfigurationdatei angegebene neue Nummer des SSH-Ports zu wählen. Mit F10 speichern wir die neue Firewall- Einstellung ab; den Standard-SSH-Port lassen wir auch noch erstmal offen.

Mit “iptables -L” überzeugen wir uns, dass nun extra Regeln gesetzt wurden, in denen der von uns gewählte Port auftaucht.

strato_server_19_600

Erst jetzt – also nach dem Speichern und Starten der Firewall mit der neuen Zusatzeinstellung – starten wir den SSH-Service neu. Danach können wir auf der geöffneten Shell nicht nicht mehr weiterarbeiten, den der sshd-Dämon arbeitet nicht mehr auf dem von uns geöffneten Kommunikationsport. Also beenden wir auf dem lokalen System die Shell mit CTRL-C. Wir müssen uns neu mittels SSH anmelden – nun aber unter Angabe des zu verwendenden Ports:

mylinux:~ # ssh root@hxxxxxx.stratoserver.net -p 6xxxx

Und schon sind wir wieder drin.

Schritt 6: Standard SSH-Port in der SuSE-Firewall schließen

Hat unser Zugang über den neuen Port funktioniert, kann man nun den Standard SSH-Port aus der SuSE-Firewall ausschließen. Hierzu entfernt man in den zugehörigen YaST-Firewall-Einstellungen (s. oben) einfach wieder den anfänglich erlaubten SSH-Serverdienst – natürlich aber ohne aber unsere Zusatzeinstellung unter “Erweitert” für den anderen Port zu ändern.

Nächste SSH-Themen

Aber auch das ist bei etwas Nachdenken natürlich nicht eine hinreichend sichere Lösung. Denn:

  • Der SSH-Port wurde zwar verschoben – aber er ist immer noch von überall her erreichbar.
  • Die Möglichkeit eines Brute Force Angriffes bleibt durch den Passwort-bezogenen Authentifizierungsmechanismus bestehen.
  • Root hat SSH-Zugang

Gerade der letzte Punkt ist ein latentes Sicherheitsproblem:

In den vergangenen Jahren gab es mehrere Beispiele dafür, wie Systeme durch Brute-Force-Angriffe auf ssh-Verbindungen auf einfache Weise kompromittiert werden konnten. Der root-User ist ja der am einfachsten zu erratende User-Account und der Brute-Force-Angriff kann sich auf das Knacken des Passwortes beschränken.

Es ist deshalb eine gute Idee, gar keinen SSH-Zugang für den User root, sondern nur für einen unpriviligierten User auf einem geänderten Port zuzulassen. Dadurch muss der Angreifer den Port ermitteln, den User-Namen und ein Passwort erraten. Und wenn ihm dann der Zugang geglückt sein sollte, hat er immer noch keine Root-Rechte, sondern muss nun zusätzlich auch das root-Passwort erraten. Das Sperren des SSH-Zugangs für root erhöht also den Aufwand für Angreifer.

Wie wir root vom SSH-Zugang zu unserem Stratoserver ausschließen, werde ich im nächsten Beitrag
Strato-V-Server mit Opensuse 12.3 – III – Stop SSH Root Login
beschreiben. Danach gehe ich dann auch auf einen zertifikatsbasierten SSH-Zugang ein.

Links

Rootkit Checks
http://xmodulo.com/ 2013/05/ how-to-scan-linux-for-rootkits.html

http://www.rackspace.com/ knowledge_center/ article/ scanning-for-rootkits-with-chkrootkit

Denjenigen, die am Sinn der hier besprochenen und noch kommenden SSH-Maßnahmen zweifeln, empfehle ich, sich in zwei ruhigen Stunden mal folgende Threads im Internet zu SSH-Rootkits, die im Frühjahr dieses Jahres gehostete virtuelle Server befallen haben, durchzulesen und einige der immer wieder auftauchenden Ratschläge bzgl. der Absicherung von SSH zu Herzen zu nehmen:

http://www.webhostingtalk.com/ showthread.php?s=714ab2598f1b14729348957 db7196325&t=1235797

http://forums.cpanel.net /f185/ sshd-rootkit-323962-p5.html

Sonstiges zur SSH-Absicherung
http://www.ibm.com/ developerworks/ aix/ library/ au-sshlocks/
http://www.rackaid.com/ resources/ how-to-harden-or-secure-ssh-for-improved-security/
http://stackful-dev.com/ linux-101-hardening-ssh.html
http://www.lowendguide.com/ 3/security/ how-to-harden-and-secure-ssh-for-improved-security/
http://linuxmoz.com/ how-to-secure-ssh-servers/