Monthly Archives: October 2013

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

Posted on by

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/

 

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

Posted on by

Wir entwickeln gerade ein User-Interface für eine PHP-basierte “Supply Chain Netzwerk-Simulation”. Dabei kommen Javascript, jQuery und Ajax zum Einsatz. Vor kurzem mussten wir uns mit dem Problem befassen, wie man mit periodischen Ajax-Jobs den zwischenzeitlichen Status von lang laufenden PHP-Berechnungs- und Simulationsjobs abfragt. Dabei sind wir in zwei Fallen getappt, die uns eigentlich hätten bekannt sein müssen. Aber inaktives Wissen schützt manchmal nicht vor naiven Herangehensweisen :-).

Ich stelle die relevanten Punkte in mehreren Blog-Beiträgen mal für interessierte Leser zusammen. Die erste potentielle Falle liegt auf der PHP-Seite und hat mit Sessions zu tun; die zweite Falle liegt im JS/jQuery-Bereich des Clients und hat damit zu tun, dass sich die Bedeutung der “this”-Referenz kontext-abhängig und damit trotz konsequenten Einsatzes von Objekt-Patterns ggf. unerwartet ändern kann.

Aufgabenstellung

Wir haben es mit folgender Aufgabe zu tun:
Ein lang laufender PHP Job [wir nennen ihn nachfolgend “RUN”] wird von einem User-Interface (Web-Seite im Browser – nachfolgend “CLIENT” genannt) gestartet. In unserem Fall ist RUN z.B. eine 60 Sekunden lang laufende PHP-Simulationsberechnung. Dieser PHP-Job schreibt seinen sehr langen fachlich-technischen Ergebnis-Output einerseits in Datenbanktabellen, aber Teile davon zur direkten User-Information sukzessive auch in ein separat geöffnetes zweites Fenster des Browsers. Gleichzeitig – d.h. während der Laufzeit – wollen wir aber zu verschiedenen Zwischenschritten des RUNs knappe Statusmeldungen abfragen und diese in speziellen DIVs des ursprünglichen CLIENT-Windows anzeigen. Um diese Zielsetzung zu erreichen, sehen wir 3 Schritte vor:

  1. Unmittelbar vor dem Start von RUN über eine Submit-Ereignis öffnen wir per Javascript ein zweites Browserfenster.
  2. RUN wird vom CLIENT-Window per Javascript und eine gezielte “submit”-Methode mit geeignetem Target so gestartet, dass sein primärer fachlich/technischer Output an das zuvor geöffnetes zweite Browserfenster übermittelt wird.
  3. RUN schreibt seine Statusmeldungen auf dem PHP-Server kontinuierlich in einen selbst verwalteten Message-Buffer.
  4. Vom CLIENT-Window aus starten wir kurz nach dem Submit von RUN mittels Javascript und JQuery periodisch Ajax-PHP-Jobs, die die Änderungen im Message-Buffer des Servers abfragen und zum CLIENT transferieren. Diese kurz laufenden Ajax-Jobs nennen wir nachfolgend “CHECKER”.
     
    Die durch die CHECKER ermittelten Statusdaten werden z.B. als JSON-Daten über den jeweils geöffneten Ajax-Kanal zum CLIENT transferiert. Dort werden sie über Callback-Methoden definierter Javascript-Objekte ausgewertet, aufbereitet und mit jQuery in die dafür vorgesehenen, speziellen DIVs des CLIENTs geschrieben.
    [Für den periodischen Start kann man Javascripts “setInterval” einsetzen und über die ermittelten Status-Daten den Timer am CLIENT nach dem Ende des RUN-Jobs auf dem Server auch wieder abbrechen.]

Unser erster naiver Ansatz für den Message-Buffer war der, den PHP-Sessionspeicher als Ort eines Message-Arrays zu nutzen. Ein Motiv dafür war der technisch einfache Zugriff auf die Daten des Sessionspeichers. Mit diesem Ansatz sind wir (natürlich) kläglich gescheitert.

Falle 1: Locked $_Session-Array

Normalerweise nutzen wir Ajax im Rahmen unseres CMS-Frameworks “ixCMF”. Damit werden Formular- und Webseiten des CMS selbst, wie später auch die Ergebnisseiten dynamisch auf Basis von Datenbank-Inhalten und PEAR-ITX-Templates erstellt. Das funktioniert zuverlässig und
schnell. Die zum Browser übermittelten HTML-Seiten nutzen dann wiederum Ajax-Funktionalitäten, um bestimmte Transaktionen wie ein Zwischenspeichern oder Abfragen von Daten im Hintergrund asynchron zu bewältigen.

Für Transaktionen des CMS wird auch der PHP Session-Speicher genutzt. Strukturell und vom Bedienungsablauf sind die Verhältnisse allerdings so, dass über die ixCMF-PHP-Programme und Ajax-Jobs ein Zugriff auf den Sessionspeicher während einer Websitzung des Users sequentiell und damit synchron abläuft. Über parallele, asynchrone Abfragen des Sessionspeichers durch mehrere gleichzeitig arbeitende PHP-Ajax-Jobs mussten wir uns bislang nie Gedanken machen. Da die Ajax-Jobs den Sessionspeicher lesend nutzen, gab es auch keinen Anlass, sich über potentielle Inkonsistenzen aufgrund parallel schreibender Jobs Sorgen zu machen.

Denkt man über das oben als Aufgabe beschriebene Szenario aber erst einmal in allgemeingültiger Form nach, dann fallen einem jedoch zwei Dinge auf:

  • Es kann zu Race-Conditions kommen. Parallel laufende Jobs können sich gegenseitig Session-Daten zerstören, wenn sie gleichzeitig schreibend auf ein und denselben Sessionspeicher zugreifen dürfen.
  • Sequentielle Zugriffe auf den Sessionspeicher lassen sich vom Webserver und nicht zuletzt auch von den PHP-Programmen selbst besser steuern und überwachen. Dies dient u.a. der Sicherheit. Ein parallel erlaubter Zugriff würde viele mögliche Schutz-Mechanismen wie die sequentiell Vergabe und Überwachung von kryptierten zufälligen Transaktionsnummern oder zusätzliche zeit- und ID-bezogene Schutzmechanismen über sequentiell vergebene kryptierte Cookies, die über eine Session hinweg verfolgt werden sollen, von vornherein aushebeln.

Der erste Punkt ist aufgrund der speziellen Session-Behandlung von PHP im Detail ggf. noch komplexer, als man meinen möchte. Siehe hierzu die gründliche Diskussion unter folgendem Link.
https://00f.net/2011/01/19/thoughts-on-php-sessions/

Der zweite Punkt hätte uns eigentlich selbst sofort zu denken geben müssen, da wir entsprechende Session-Schutz-Mechanismen im Rahmen unseres ixCMF-Frameworks selbst programmiert und immer wieder genutzt haben.

Jedenfalls gilt: Aus den genannten Gründen wird der Standardzugriff auf Sessions von PHP sequentialisiert:

PHP -Programme können nur sequentiell auf einen Standard-Session-Speicher zugreifen. Der Job, der sich gerade über session_start() den Zugriff verschafft hat, sperrt den Sessionspeicher gegen Zugriffe von anderen Programmen vollständig, bis er die Session über “session_commit” oder “session_write_close” freigegeben hat. Oft geschieht dies erst implizit am Ende der Laufzeit eines PHP-Programms.

Zu welchem Verhalten führt das in unserem Szenario ? Ganz einfach:

RUN blockt den Sessionspeicher bis zum Ende seiner Laufzeit und alle zwischenzeitlich gestarteten Ajax-Jobs müssen bis dahin warten. Damit aber wird eine zwischenzeitliches Verfolgen der Statusmeldungen von RUN unmöglich. Sprich: der ganze geplante parallele und periodische Abgriff von Statusinformationen, die RUN in S_SESSION hinterlegen sollte, funktioniert nicht. Es kommt vielmehr zu einem sinnlosen Stau der CHECKER-Jobs und jeder dieser Jobs ermittelt nach Abschluss von RUN Statusdaten raus, die bereits veraltet sind.

Das gleiche Sperr- und Warteverhalten erleben viele User und Administratoren in schlecht durchdachten Systemen, wenn schnell hintereinander gestartete PHP-Jobs die gleiche Session nutzen sollen oder müssen.

session_write_close() ist keine Lösung!

Nun empfehlen viele durch ähnliche Probleme Betroffene in Internet-Beiträgen die frühest mögliche Anwendung von “session_write_close()” als
Lösung. Siehe hierzu die am Ende des Beitrags als Beispiele angegebenen Links. Die Idee ist eine frühzeitige Freigabe des Sessionspeichers durch das jeweilige Programm, das aktuell auf den Sessionspeicher zugreift. Das mag ja in vielen Fällen gehen, nicht aber in unserem:

Hat ein Programm den Sessionspeicher über “session_commit()” oder “session_write_close()” erst einmal freigegeben, können zwar andere Programme auf den Sessionspeicher zugreifen, es selbst aber während seiner Laufzeit nicht mehr !

Die kurz laufenden Ajax-CHECKER-Jobs könnten session_write_close() nutzen – nicht aber RUN. Denn RUN muss fortwährend Statusinformationen in den Sessionspeicher schreiben – und die erste Session-Freigabe über die genannten Kommandos würde nachfolgende Schreibaktionen in die Session unmöglich machen.

Lösung für Falle 1: Nutze eine Datenbank zum Schreiben von Statusinformationen lang laufender Jobs

Wir haben uns dann sinnvollerweise entschlossen, als Ort für den Status-Message-Buffer von RUN eine spezielle Tabelle in einer MariaDB/MySQL-Datenbank zu nutzen, die für die Simulationsrechnungen sowieso erforderlich ist. Eine Alternative wäre ein File als Message-Buffer gewesen. Wir haben Files aber verworfen, weil sie aus unserer Sicht wieder andere Nachteile haben und uns der Zugriff auf einen Datenbank-Tabelle letztlich einfacher, flexibler und ausbaufähiger erschien. Zumal in unserem auf Datenbank-Nutzung ausgelegten Framework.

Die Nutzung einer Datenbank hat über die Lösung des oben besprochenen Session-Locks hinaus noch andere Vorteile:

  • Es zwingt zur sauberen Strukturierung der Status-Information. Das vereinfacht zudem auch den XML- oder JSON-Transfer der Daten im Zuge der periodischen Ajax-Prozess.
  • Erweiterungen sind zügig möglich. Die Feldstruktur ist über Schema-Verfahren insgesamt schnell geändert.
  • Es ist einfach, nur die seit dem letzten CHECKER-Zugriff neu eingetragenen Daten zu selektieren.
  • Liegt die Datenbank auf ein- und demselben LAMP-Server , ist sowohl der schreibende Zugriff durch RUN als auch der lesende Zugriff durch die CHECKER wegen der Kürze der Tabelle extrem performant. Man kann das Intervall für die zu startenden Ajax-CHECKER auf diese Performance hin anpassen.
  • Man kann die Timestamps der Datenbank nutzen, um genaue Zeitinformationen über das Ende der Zwischenschritte zu erhalten.
  • Die Statusinformation kann über die Laufzeit und Garbage Collection Time hinaus aufbewahrt und in weiteren Tabellen historisiert werden.
  • Für eine Historisierung von RUNs kann man in der Bank noch andere nützliche Daten hinterlegen.

Je nach Netz-Anbindung an den Server und dessen Leistungsfähigkeit können wir durch Nutzung der Datenbank als Message-Buffer von RUNs nun mit CHECKER-Jobs im Abstand von 250 bis 500 msec arbeiten, ohne Server und Client übermäßig zu belasten. Damit eröffnen sich während der Laufzeit der Simulationen alle Möglichkeiten einer kontinuierlichen, sehr fein-granularen Statusinformation im gleichen CLIENT-Window, von dem aus der RUN-Job ursprünglich gestartet wurde. Eine Darstellung von fachlich-technischem Output in einem zweiten Browserfenster während der Laufzeit bleibt davon unberührt und ist unbenommen möglich.

In einem kommenden zweiten
Fallen beim Statuscheck lang laufender PHP-Jobs mit Ajax – II
befassen wir uns prophylaktisch mit potentiellen “this”-Fallen auf der Javascript/jQuery-Seite der Ajax-Prozesse. In späteren Beiträgen werden wir dann die gewonnen Erkenntnisse zu einem Verfahren
zusammensetzen, das es erlaubt den “RUN” wie die “CHECKER”-Jobs systematisch mit Ajax zu behandeln. .

Links

Nutzung von commit_session oder write_close-session
http://konrness.com/php5/how-to-prevent-blocking-php-requests/
http://blog.preinheimer.com/index.php?/archives/416-PHP-and-Async-requests-with-file-based-sessions.html
http://www.held.org.il/blog/2008/02/php-session-locks/

Sicherheit
http://php.net/manual/de/session.security.php
http://phpsec.org/projects/guide/4.html

Strato V-Server mit Opensuse 12.3 – I

Posted on by

Manchmal wollen Kunden ihren eigenen Web-Apache- und LAMP-Server als gehosteten virtuellen Server betreiben. In letzter Zeit hatten wir die Aufgabe, solche Server unter Opensuse 12.2 und Opensuse 12.3 beim Hoster Strato aufzusetzen. Hier ein mehrteiliger Bericht dazu, wie wir dabei vorgegangen sind. Ich kann dabei allerdings nicht auf Details des LAMP- und des Sicherheits-Setups eingehen und verweise an passender Stelle auf passende frühere Artikel dieses Blogs oder andere Beiträge im Netz.

Vorbemerkungen zum V-Server-Paket

Ein paar Anmerkungen vorweg zum Strato-Angebot, das unsere Kunden typischerweise nutzen. Ich beziehe mich hier auf ein Strato V-Server-Paket des Typs “V-Server Linux Level 3”. Beworben wird dieses Paket wie folgt:

V-Server Linux Level 3 (Stand 02.10.2013)

  • zwei zugewiesene CPU-Cores,
  • ein garantierter RAM von 4 GB (dynam. max. 6 GB),
  • Plattenplatz: 200 GB.

Interessanterweise findet man in den aktuellen Informationen (02.10.2013) der Hauptwebseite zu diesem Paket keine Aussage zu den 2 zugewiesenen Cores. Enthalten ist eine entsprechende Feststellung aber auf folgender Seite
https://www.strato-pro.com/ ger/ virtual-server/#/ linux/

Strato hält diese etwas versteckte Zusage von 2 CPU-Cores jedenfalls ein. Auch bzgl. des RAMs hat sich die Zuteilung in den von uns betreuten Verträgen bislang als großzügig erwiesen. Im Schnitt standen uns mehr als die zugesagten 4 GB zur Verfügung. Als Virtualisierungsplattform wird Parallels eingesetzt. Als Admin hat man die Möglichkeit, die Web-Oberfläche “Plesk” für 10 Domainen einzusetzen

AMD Opteron CPU und Linux als 32-Bit Gast begrenzen die Leistungsfähigkeit des V-Server-Systems

Als CPU wird ein “AMD Opteron(tm) Processor 6128” eingesetzt. Infos zu den Eigenschaften des kostengünstigen und bereits betagten Prozessors sowie zu seiner Performance findet man z.B. unter folgenden Links :

http://products.amd.com/ en-us/ opteroncpuresult.aspx? f1=AMD+Opteron%E2% 84%A2+6100+Series+Processor& f2=6128&f3=Yes&f4=2000& f5=512&f6=G34& f7=D1&f8=45nm+SOI& f9=115+W& f10=6400&f11=8&

http://www.cpu-world.com/ CPUs/ K10/ AMD-Opteron%206128%20-%20 OS6128WKT8EGO%20 %28OS6128WKT8EGOWOF%29.html

http://www.cpubenchmark.net/ cpu.php?cpu=AMD+Opteron+6128

http://www.jaxbeachtech.com/ content/ processor-performance-rank

http://browser.primatelabs.com/ geekbench2/391840

Diese schon etwas ältere CPU hat 8 Cores (16 Threads unter Linux) und wird normalerweise mit 2 GHz getaktet. Im Normalbetrieb läuft der Core bei Strato allerdings mit 1.725 GHz. Linux Opensuse Guests kommen nur in 32-Bit Versionen zum Einsatz. Zusammen begrenzt das das Leistungsvermögen. Man darf hinsichtlich der Performance also wirklich keine Wunder erwarten.

Um einen eigenen Überblick zu erhalten, haben wir uns verschiedene eigene PHP/MySQL-Programme auf virtuellen Servern unter KVM auf eigenen Systemen im Vergleich zum Strato-V-Server angesehen. Das Spektrum reichte dabei von einfachen CMS-Anwendungen zur Generierung von Webseiten
bis hin zu CPU-intensiven Simulationen. Zusammenfassend kamen wir zu folgendem Ergebnis :

Auf einem meiner eigenen älteren Server-Systeme schlägt ein virtueller 64-Bit Gast mit Opensuse 12.3,

  • der unter KVM mit virtio-Treibern und direkten Zugriff auf Raid10-Partitionen genutzt wird und
  • dem nur ein (!) CPU Core einer Intel Quad 9550 CPU zugewiesen wurde,

das Strato-V-Server-System bei etlichen CPU- und datenbankintensiven LAMP-Aufgaben klar, wenn auch nur mit Faktoren zwischen 1.2 bis 1.5. Ein Grund ist sicher das eigene, sehr gut gepufferte Plattensystem.

Deutlich schlechter sieht der Vergleich allerdings bei Einsatz aktueller Intel i7-CPUs und SSD-Platten aus. Hier sehen wir im Schnitt Faktoren > 2 – 3 – vor allem bei CPU-intensiven Prozessen.

Aber wir wollen nicht klagen. Ein großer Provider muss sich um ganz andere Dinge kümmern, als wir mit unseren Haus-Serverchen. Für den Betrieb normaler PHP-generierter Webseiten reicht das Paket in der Regel durchaus aus :

Typische Dinge, die bei uns 80-90 msec mit unserem eigenen PHP-basierten CM-Framework dauern, nehmen auf dem Strato-Server 200 msec in Anspruch. Typische totale Antwortzeiten (ohne Caching-Verfahren, inkl. Internet-Transfer der Daten ) – die wir mit Browser-Tools für einzelne, durch unser CMS generierte Seiten gemessen haben – liegen dauerhaft im Bereich von 350 msec. Das ist aus meiner Sicht OK und deutlich besser als für billige Web-Hosting-Pakete bei anderen Providern, wie z.B. 1&1. Dort schwankt die Antwortzeit für PHP-basierte Sites tagsüber deutlich und um Faktoren; sie ist zudem stark vom Preis des Hosting-Pakets abhängig.

Einer unserer Kunden betreibt CPU-intensive aber auch datenbank-lastige Simulationen von Supply Chain Netzwerken – er muss im direkten Vergleich zu Systemen mit aktueller HW einen Faktor 2,5 an schlechterer Performance als auf KVM-Guests auf Servern mit aktueller HW hinnehmen.

Nebenbei : Bei 1&1 erhält man aktuell zwar 64-Bit-Gast-Systeme, zahlt aber gemessen an garantiertem RAM und Plattenplatz deutlich mehr. U.a. aus diesem Grund haben wir Strato gewählt. Hinzu kommt die kurze Kündigungsfrist von 1 Monat bei Strato. An Support erwarte ich von beiden Providern nach schlechten Erfahrungen beim Webhosting und auch bei DSL (1&1) schlicht wenig bis nichts. Plesk als Server-Verwaltungsoberfläche nutze ich nicht. Wer eine echte Backup-Strategie fahren muss, sollte sich ein Verfahren überlegen, bei dem man mit Rsync-basierten Tools wesentliche Bereiche auf eigene Serverplatten abgleicht – oder aber gegen Aufpreis eine der möglichen avancierteren Backup-Zusatzpakete bestellen.

Schritt 1: Blick in die schlichte Web-Verwaltungsoberfläche zum Strato-Server

Nach der Bestellung seines V-Server-Paketes erhält man seine Zugangsdaten zum Server per E-Mail und das zugehörige Passwort per SMS. Lobenswert ist die Trennung. Das zeigt zumindest an, dass man sich (ISO 27000 Zertifizierung der Strato-Rechenzentren) um Sicherheit grundsätzlich Gedanken macht. (Ob die aber in Zeiten wie diesen wirklich viel hilft, sei mal dahingestellt. Warum verwenden solche Provider eigentlich nie Verschlüsselungsverfahren oder bieten deren Nutzung im Zusammenhang mit dem Austausch von Zugangsdaten zumindest an?).

Mit Hilfe der übermittelten Daten meldet man sich unter folgender Oberfläche an.

strato_server_1_600

strato_server_2_600

Dort erwartet einen ein schlichtes Verwaltungsmenü, das
bei genauerem Hinsehen mit vielen Links zu Zusatzpaketen gespickt ist. Auch wird man mit aktuellen Werbe-Nachrichten und Nachrichten zu Sicherheitslücken in Plesk/Parallels konfrontiert. Letzteres finde ich allerdings nicht schlecht. Was bieten die Menüpunkte? Ich picke nur die wichtigsten heraus:

  • Zugangsdaten : Hier ändert man den Zugang zu eben dieser Verwaltungsoberfläche.
  • Traffic Control : Infos und Grafiken zum ein- und ausgehenden Netzwerkverkehr. Das ist durchaus von Bedeutung – sollte man ab und zu einen Blick hinein werfen. Denn wirklich frei ist der Traffic nicht : Ab 1000 GB / Monat wird die Anbindungsgeschwindigkeit auf 10 MBit/sek – also Unbrauchbarkeit – gedrosselt. Siehe hierzu das Kleingedruckte am Ende der oben angegebenen Webseite zu Details des V-Server-Pakets. Dies ist insbesondere dann interessant, wenn – wie in einem unserer Fälle – der LAMP-Server Simulationen mit erheblichem Output für Downloads durchführen soll.

    Die Grafiken kann man sich in verschiedenen Varianten anzeigen lassen – eine hinreichende Analyse in Kombination mit anderen eigenen Tools wie vnstat, cacti etc. ist damit möglich.

strato_server_4_600

  • Serverkonfiguration : Hier erhält man relevante Submenüpunkte:
  • Backup Control: Schlichte Liste über tägliche, automatisch angelegte Backups. Für komplexere Backups, die einer Backupstrategie folgen sollen, ist ein zahlungspflichtiges Upgrade erforderlich. Spätestens hier fängt man an, über eigene Backup-Verfahren für wichtige System- und Datenbereiche (u.a. /etc, /srv, /var …) nachzudenken.
  • Serverdaten: relevante Daten wie das intiale root Passwort, IP-Adresse des Servers
  • Neuinstallation: Wichtig, wenn man – wie wir – initial ein anderes Betriebssystem als das vorinstallierte Ubuntu haben möchte. Interessant aber auch in einem ernsten Schadensfall.
  • Revovery Manager: Möglichkeit zum Reboot oder Starten eines Notfall-Systems. Hier denkt man nicht nur an ein aus irgendeinem Grunde hängendes System. Im Auge haben sollte man auch so hübsche Dinge wie ein sich selbst Aussperren bei Experimenten mit einer Firewall. Ein durchaus interessantes Thema, das einen später zu der Frage führt, in welchen restriktiven Zustand eine Firewall nach einem Restart hochfahren soll. Dies ist deswegen von Bedeutung, weil auch Strato ab und zu Neustarts der Systeme vornimmt.
  • IP-Adressen: Zuschalten einer IPV6-Adresse bei Bedarf.
  • Optionen: Regeln von Quotas / automatischen Backups / resolv.conf-Politik

strato_server_5_600

strato_server_6_600

Im nächsten Teil

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

beschreiben wir kurz den SSH-Zugang, eine Verlagerung des SSH-Ports und das Starten einer ersten einfachen SuSE-Firewall mit relativ restriktiver Einstellung.