Strato-V-Server mit Opensuse 12.3 – III – Stop SSH Root Login

Im letzten Beitrag zur Konfiguration unseres Strato-Servers
Strato-V-Server mit Opensuse 12.3 – II
hatten wir uns ein wenig mit dem SSH-Zugang befasst und als erste Maßnahme den SSH-Port verschoben. Wir hatten gleichzeitig aber festgestellt, dass das keine ausreichend sichere Lösung ist. Einer der Gründe war u.a. der, dass "root" immer noch Zugang zu dem Server hat. Dies ist ein Sicherheitsrisiko, das wir im nächsten Schritt ausschalten wollen. Es ist ja auch gar nicht erforderlich, sich direkt als root auf dem Server einzuloggen. Vielmehr sollte der Zugang über einen unprivilogierten User vorgenommen werden. Von dessen Account wechselt man dann auf der Shell zum Root-Account.

Anlegen eines normalen, unpriviligierten Users

Bevor wir den direkten root-Zugang beenden können, müssen wir erst einen normalen User anlegen. Den User nenne ich nachfolgend der Einfachheit halber "xtarjax". Generell gilt auch hier, dass man einen Namen wählen sollte der nicht leicht zu erraten ist.

Die Erzeugung des user-Accounts nehmen wir z.B. mittels "yast >> Sicherheit und Benutzer >> User- und Gruppenverwaltung" vor. Oder wir checken auf der Shell per "useradd -D" kurz die Standardeinstellungen für die Useranlage und benutzen dann das Shell-Kommando

hxxxxxxx:~# useradd -m xtarjax

Das Passwort für den User setzen wir mit

hxxxxxxx:~# passwd xtarjax

"passwd" checkt das zu verwendende Passwort nach vorgegebenen Kriterien. Mit einem weiteren "passwd -S xtarjax" fragen wir dann den Zustand des angelegten Users ab. Ich gehe auf Details der Useranlage nicht weiter ein. Wir prüfen noch, dass unter "/home" das Homeverzeichnis "/home/xtarjax" angelegt wurde.

Nun weiß ich, dass einige Leute gerne mit der grafischen Version "yast2" von YaST arbeiten. Ich rate bei der Arbeit auf einem Remoteserver aus drei Gründen davon ab:

  • Es birgt Sicherheitsrisiken (auch wenn man das X-Protokoll unter ssh tunnelt).
  • Es erhöht den Datentransfer zwischen Server und Client doch beträchtlich und die Antwortzeiten sind nicht berauschend.
  • Es ist überflüssig, weil das ASCII yast für die Shell praktisch alle erforderlichen Möglichkeiten bietet.

Wenn man temporär doch mit grafischer Unterstützung arbeiten will, gilt:
Man muss SSH so konfigurieren, dass X-Forwarding erlaubt wird. Standardmäßig ist das abgeschaltet. Man muss dazu in der Datei "/etc/ssh/sshd-config" folgenden Eintrag von "no" auf "yes" ändern.

X11Forwarding yes

Dies macht man am besten mit "vi" oder "emacs". Danach

hxxxxxxx:~# rcsshd restart

oder

hxxxxxxx:~# systemctl restart sshd.service

ausführen und testen, dass ein Einloggen vom eigenen Client-System aus mittels

mylinux:~ # ssh -X root@xxxxxxx.stratoserver.net -p nnnnn

unter dem im letzten Beitrag definierten Port funktioniert. Danach kann man

hxxxxxxx:~# yast2 &

ausprobieren und die Antwortzeiten für seine Internetverbindung bzw. die 100MBit Anbindung des Stratoservers testen. Berauschend ist das nicht - aber es funktioniert zur Not. Wie gesagt: Ich rate vom Einsatz grafischer Tools ab. Will oder muss man zwischenzeitlich mit X11-Forwarding arbeiten, sollte man es danach durch Setzen von "X11Forwarding no" in der "sshd_config" wieder rückgängig machen.

Abschalten des ssh-Zugangs für root

Wir schalten nun den SSH-Zugang für den priviligierten User "root" in 2 Schritten ab. Zunächst editieren wir die Datei "/etc/ssh/sshd_config" und fügen folgende Zeile ein - z.B. nach dem Statement "Port 6XXXXX":

Port 6XXXX
AllowUsers xtarjax root

Dann starten wir den ssh-Service neu mittels

hxxxxxxx:~# rcsshd restart

Wir loggen uns aus dem Strato-server aus und versuchen einen Login per

mylinux:~ # ssh xtarjax@xxxxxxx.stratoserver.net -p nnnnn

Dies sollte anstandslos gelingen. Ist das sichergestellt wechseln wir zum root-Account mittels

mylinux:~ #su -

und editieren als root dann erneut "/etc/ssh/sshd_config". Dort entfernen wir root aus der Liste der AllowedUsers und fügen ein Zusatzstatement ein - bzw. editieren die im File ggf. auskommentierte Zeile in folgender Form

Port 6xxxx
AllowUsers xtarjax
...
...
PermitRootLogin no

Danach starten wir den ssh Service erneut und beten, dass wir über den normalen User reinkommen. Dann machen wir den Gegencheck und versuchen

mylinux:~ # ssh root@xxxxxxx.stratoserver.net -p nnnnn

Das sollte zum Scheitern verurteilt sein. Interessanterweise wird das Passwort mit zwischenzeitlicher Zeitverzögerung 3 mal abgefragt - - auch bei Eingabe des korrekten Passwords. Danach erfolgt ein zwischenzeitlicher Abbruch des Zugangsversuchs.

Mit diesem Schritt haben wir unsere Grundsicherheit wieder etwas erhöht. Root hat keinen direkten Serverzugang per SSH mehr. Im nächsten Beitrag stellen wir den SSH-Zugang zusätzlich auf ein schlüssel- bzw. zertifikats-basiertes Zugangsverfahren um. Siehe:
Strato-V-Server mit Opensuse 12.3 – IV – SSH Key Authentication

Fallen beim Statuscheck lang laufender PHP-Jobs mit Ajax – II

Im ersten Beitrag dieser Serie - siehe
"Fallen beim Statuscheck lang laufender PHP-Jobs mit Ajax – I" -
hatten wir uns angesehen, warum man bei der asynchronen Zustandsabfrage eines lang laufenden PHP-Jobs auf einem Server mittels Ajax eher auf zwischenzeitlich gespeicherte Zustandsdaten in einer Datenbank zuzugreifen sollte, anstatt korrespondierende Zustandsdaten in einem Sessionspeicher abzufragen.

Wir nennen in Anlehnung an den ersten Beitrag den einmalig auf dem Webserver zu startenden und danach asynchron zu beobachtenden PHP-Hauptjob "RUN", während wir die vielen per Ajax auf dem Server periodisch gestarteten PHP-basierten Zustands-Prüf-Jobs als "CHECKER" bezeichnen.

In diesem Beitrag befassen wir uns mit einer ersten Tücke der Client-Seite - also mit dem Javascrip/jQuery-Programm, das sowohl den Hauptjob (einmalig) als auch die asynchronen, parallel zum Hauptjob laufenden Abfragen (periodisch) auf dem Server startet und die Ergebnisse auswertet. Das betrachtete Problem hat wie auch die in späteren Beiträgen angerissenen Fälle letztlich mit der Variabilität des "this"-Operators unter Javascript/jQuery zu tun.

Der Einsatz von Kontroll-Objekten unter Javascript und ihre Kopplung an Formulare oder andere DOM-Elemente der Oberfläche mittels jQuery

Eine vernünftige Programmierung unter JS wird sich an MVC-Grundprinzipien orientieren. Anstelle permanent direkt und über globale Javascript-Funktionen mit den DOM-Objekten des HTML-Interfaces zu interagieren, wird man sich eine korrespondierende Struktur von reinen JS-Objekten aufbauen, die die Behandlung der grafischen DOM-Objekte in entsprechenden Methoden kapseln. In unserem Beispiel liegt es u.a. nahe,

  • ein Objekt zu verwalten, das den Start und ggf. auch den Output des PHP-Hauptjobs kontrolliert, dessen Zustand wir während seiner Laufzeit abfragen wollen.
  • ein Objekt zu konstruieren, das einerseits die stetige, periodische Ajax-Interaktion des Web-Interfaces mit dem Server managed und andererseits die benötigten DOM-Objekte der Oberfläche zur Anzeige der asynchron ermittelten Zustandsdaten des Server-Jobs steuert.

Im ersten Fall spielt in der Regel ein Button eines Formulars die Hauptrolle beim Start des Serverjobs. Zeitgleich kann auf dem Client dann ein zusätzliches Browser-Fenster gestartet werden, das den produzierten regulären Output des RUN-Jobs während seiner Laufzeit aufnimmt. Weitere Aktionen auf der Web-Oberfläche mögen zudem anstehen. Es liegt also nahe, all diese Aktionen in Methoden mehrerer Kontrollobjekte für die erforderlichen Aufgaben (und zugehörige,abgegrenzte HTML-Objekte) zu bündeln und zu kapseln.

Auch im zweiten Fall wird es vermutlich erforderlich sein, den per Ajax zu startenden "CHECKER"-Programmen Parameter (z.B. die Nummer der zuletzt empfangenen Statusmeldung) zu übergeben. Man kann das intern im Kontrollobjekt oder aber in besonderen Fällen auch mal über versteckte oder sichtbare Input-Felder eines weiteren Formulars erledigen.
[Die Daten des (evtl. versteckten) Formulars sind dann zuvor in einem Ajax-tauglichen Datenobjekt zu serialisieren. Auch hierbei würde jQuery natürlich über seine formularbezogene "serialize"-Funktion helfen.]

In beiden Situationen stößt man also auf folgende Thematik:

  • Es gibt ein Formular "F", das per jQuery mit einem Submit-Event verknüpft wird, der direkt aus einer Javascript-Funktion oder über eine besonderes Element (Button) ausgelöst wird.
  • Man hat ferner ein Javascript-Kontroll-Objekt "K". Sein Prototyp-Objekt heiße "Ctrl_K". Eine spezielle, z.B. über
     
    "Ctrl_K.prototype.submit_event = function (e) { ...}"
     
    definierte "Methode" des Objektes soll im Zuge des Formular-Submit-Events eine (einmalige oder periodische) Programm-Aktion auf dem Server und gleichzeitig mehrere Aktionen auf der Weboberfläche auslösen. Dabei sollen weitere Eigenschaften und/oder Methoden von "K" benutzt und über den "this"-Operator (also mit Bezug zu "K") angesprochen werden.
  • Man will den Submit-Event des Formulars "F" an die für das "K"-Objekt definierte Methode "submit_event" als Callback binden. Dabei soll ein unter "submit_event" benutztes "this" wie gewöhnlich auf "K" verweisen.

Falle: Das "this" des Eventhandlers ist nicht das "this" des den Eventhandler definierenden Kontroll-Objekts

Hier tritt dann die erste Falle auf, in die man trotz besseren, theoretischen Wissens immer mal wieder reinfallen kann. Nehmen wir mal an, das Formular habe die ID "formx". Nehmen wir ferner an, wir haben irgendwo innerhalb einer Funktion von "K" das Statement

this.id_form = "formx";
$(this.id_form).submit( this.submit_event );

zur Bindung der Eventhandler-Funktion an das Formular abgesetzt. Die Frage ist, ob dann ein späteres innerhalb von "K" abgesetztes

$(this.id_form).submit();

oder ein Klick auf den evtl. vorhandenen Formularbutton funktionieren wird ? Die Antwort ist Nein.

Der Grund hierfür ist, dass innerhalb von Eventhandlern - also den zur Behandlung des Events aufgerufenen Funktionen - "this" auf den Auslöser des Ereignisses innerhalb der DOM-Hierarchie zeigt. Das gilt auch für Funktionen von (externen) JS-Objekten, die dem Event eines DOM-Objektes per Referenz zugeordnet wurden. "this" verweist in diesem Fall also auf das Formular (oder einen zugehörigen Button) und nicht auf das Kontroll-Objekt "K". "submit_event" wird zwar ausgelöst, aber "this" zeigt innerhalb dieser Funktion leider nicht - wie erwartet - auf "K". Dies führt natürlich zu Fehlern, sobald innerhalb von "submit_event" auf weitere Funktionen/Methoden oder Eigenschaften von "K" über den "this"-Operator zugegriffen werden soll.

Lösung: Einsatz der "$.proxy"-Funktion von JQuery

Es gibt mehrere Lösungsansätze, wie man mit dem Problem umgehen kann. Die eleganteste ist aber aus meiner Sicht die Verwendung von "$.proxy". Mit Hilfe dieser Funktion des jQuery-Objekts kann man den zu geltenden Kontext für das "this" in der Eventhandler-Funktion explizit setzen. Man definiert die Event-Handler-Funktion dabei innerhalb von "K" wie folgt:

$(this.id_form).submit(
    jQuery.proxy(this, 'submit_event')
);

Nach dem Auslösen des Events und dem Aufruf von "K.submit_event" weist "this" innerhalb der auszuführenden Funktions-Statements von "submit_event" dann tatsächlich wie gewöhnlich auf "K". Man kann also die Eventhandler, die man DOM-Objekten der HTML-Oberfläche zuordnen will, sehr wohl auch bei Benutzung von JQuery als Methoden ordentlich strukturierter Modell- und Kontroll-Objekte zugeordneter Javascript-Programme kapseln.

In unserem Beispiel kann die "$.proxy"-Funktion bereits beim Aufruf von "RUN" aber auch beim periodischen Aufruf der "CHECKER"-Programme genutzt werden, wenn man im letzteren Fall einen Umweg über ein (ggf. verstecktes oder offenes) Formular der Web-Oberfläche gehen muss oder will.

Im folgenden Beitrag dieser Serie
Fallen beim Statuscheck lang laufender PHP-Jobs mit Ajax – III
vertiefe ich den eben andiskutierten Punkt und betrachte dann die Bedeutung von "this" im Rahmen einer definierten Callback-Funktion, des "K"-Objektes die im Fall einer erfolgreichen Ajax-Transaktion aufgerufenen wird. Auch hier ist oder bleibt "this" nicht unbedingt das, was man vielleicht erwartet.

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/