vServer gemietet: Sicherheit?

[wstuermer]

Obendrein kann man im Nachhinein besser nachvollziehen, was auf dem Server passiert ist und hat so mehr Informationen, um die ausgenutzte Sicherheitslücke zu finden.

Kommt auf die Ambitionen und die Vorgehensweise des Eindringlings, sowie den Einbruchsvektor, an - aber prinzipiell hast du recht.

 

[Bachsau]

Geht schon los... Man kann's ja mal probieren, so nach dem Motto.

bachsau.com:80 94.23.69.61 - - [13/May/2011:20:46:45 +0200] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 500 "-" "ZmEu"
bachsau.com:80 94.23.69.61 - - [13/May/2011:20:46:45 +0200] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 487 "-" "ZmEu"
bachsau.com:80 94.23.69.61 - - [13/May/2011:20:46:45 +0200] "GET /phpmyadmin/scripts/setup.php HTTP/1.1" 404 487 "-" "ZmEu"
bachsau.com:80 94.23.69.61 - - [13/May/2011:20:46:45 +0200] "GET /pma/scripts/setup.php HTTP/1.1" 404 480 "-" "ZmEu"
bachsau.com:80 94.23.69.61 - - [13/May/2011:20:46:45 +0200] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 484 "-" "ZmEu"
bachsau.com:80 94.23.69.61 - - [13/May/2011:20:46:45 +0200] "GET /MyAdmin/scripts/setup.php HTTP/1.1" 404 484 "-" "ZmEu"

 

[PapaBaer]

Grundrauschen. Das haben alle.

 

[Bachsau]

Es werden jeden Tag mehr. Der Bot wird nicht finden, was er sucht, aber er spammt mir die Logs voll.

Aber mal was anderes: Habe gerade munin aufgesetzt. In der Konfigurationsdatei von munin-node gibt es Einträge für User / Group. Hier steht "root". Macht es Sinn, diese zu ändern? Muss das als root laufen? Das Master-Paket hat sich extra einen user angelegt.

Edit / OT:
Trifft einen als Hoster eigentlich nicht eine gewisse Mitverantwortung? Man liest ja manchmal Sachen… http://forum.teamspeak.com/showthread.php/27441-TS-auf-vServer-installieren. Solchen Typen kann man doch keinen Root-Account in die Hand geben. Da sträuben sich ja selbst mir die Haare…

 

[Bachsau]

Eines ist mir nicht ganz klar. Warum verbraucht eine unter VMware betriebene Testmaschine mit nahezu der gleichen Konfiguration deutlich weniger RAM, als es auf dem vServer im Internet der Fall ist?

Der erste Munin-Graph zeigt die Auslastung des vServers, der Zweite die der lokalen Installation. Auch auf dem vServer finden derzeit noch keine Zugriffe statt, die das rechtfertigen würden.

 

[svenr]

Hat deine VM nur 1 GB Ram zugewiesen und dein Vserver 2 GB... dann solltest Du Dich damit vertraut machen wie unter Unix die Ressaurcen genutzt werden, was im Ram ausgelagert wird, oder auch was gecached wird .... usw...
Allgemein zu dem gesamten Postverlauf hier mag ich sagen, Du solltest Dich besser erstmal stärker mit der Marterie vertraut machen, denn jedes Fundstück in Logs hier zu Posten um die Unwissenheit zu kompensieren bringt Dich nicht weiter. Du hast irgendwie am falschen Ende angefangen, erst üben dann Server... nicht erst Server und dann nach Fundstücken fragen...
siehe zB dein Grundrauschen....
Gruß Sven

 

[Bachsau]

nicht erst Server und dann nach Fundstücken fragen...

Bisher hat dieses Vorgehen immer ganz gut funktioniert. Aus Fehlern wird man Klug.
Es ist ja nicht so, dass ich ganz ohne Vorwissen da dran gegangen wäre. Ich denk, ich weiß schon genug. Nur eben nicht alles.

Dass diese "Fundstücke" nicht gefährlich sind, weiß ich auch. Ich wollte halt nur mal Fragen, ob das normal ist, dass soetwas so schnell auftaucht. Und ja, ich weiß auch, dass Linux ungenutzten RAM als Cache verwendet. Dummerweise geht das aus dem Munin-Graph des vServers aber nicht so hervor. Warum auch sollte das Hostsystem meinem VE Information über den Cache zukommen lassen?

Natürlich sind in einer echten VM die Systemwerte vollständiger als in einem VE. Der vServer hat 1GB RAM, 1GB BURST. Das kann die Software im VE aber nicht trennen. Dort erscheint alles als 2GB RAM. Wie du sehen kannst, ist aber der gesamte belegte Speicher als "Apps" ausgewiesen.

Ja, das bringt mich wirklich durcheinander. Also wo kommt der Speicherverbrauch her? Oder kann man den Graph in die Tonne treten? Dann wäre die Frage, wie komm ich an den wirklich belegten Prozess-Speicher meines vServers? Im Control-Panal des Hosters wird es nämlich auch ungefähr so angezeigt, siehe Anhang.

 

[cmeerw]

Der vServer hat 1GB RAM, 1GB BURST.

Am besten du fragst beim Support deines Anbieters nach, wie diese "1GB RAM, 1GB BURST" genau definiert sind (und postest die Antwort hier zusammen mit der Ausgabe von "cat /proc/user_beancounters"). Mit hoher Wahrscheinlichkeit wird die Antwort technisch nicht korrekt sein und/oder relativ wenig mit dem nutzbaren Speicher im vServer zu tun haben.

 

[Bachsau]

Okay, ich muss zugeben, was OpenVZ spezifische Dinge angeht hab' ich wirklich kein Plan.

Wollte meinen Hoster ohnehin schon mal fragen wegen dem "BURST", und habe das jetzt auch getan. Kommt auf jeden Fall nicht von OpenVZ, der Begriff. Antwort steht noch aus.

Aus den beancounters scheint sich ja einiges entnehmen zu lassen. Datei sitzt im Anhang.

 

[d4f]

Kommt auf jeden Fall nicht von OpenVZ, der Begriff. Antwort steht noch aus.

Nein, natuerlich kommen Marketing-Begriffe nicht von den Techies.
Der korrekte Begriff ist privvmpages gegen Oomguarpages und wird sich sicherlich NICHT an 0815-Publikum verkaufen.

Hier hast du eine recht gute Grunderklaerung zu burstable RAM:
http://www.webhostingtalk.com/showpost.php?p=4835133&postcount=4

Hinzu zu fuegen ist lediglich dass die Hostmachine noch entscheiden kann zu swappen (also RAM auf die Festplatte aus zu lagern).
Da Festplatten sehr viel langsamer sind als RAM haben einige findige Hoster die Swap auf eine oder mehrere SSD's verbannt. Es waere ja schoen wenn nun jeder zB 1GB RAM und 1GB SSD-Swap haette, aber so funktioniert OpenVZ nicht.
Nicht OpenVZ oder der Benutzer entscheidet was in die RAM und was in die Swap soll, sondern der Kernel. Falls also die Machine ueberbucht ist und sie anfaengt zu swappen kann es auch mal Unschuldige treffen da der Kernel nach Leistung (Benutzung) und nicht nach Benutzer entscheidet.

 

[Bachsau]

Hier nun die Antwort des Hosters:

Unter "Burst-RAM" wird ein nicht ständig zugesicherter, aber temporär nutzbarer zusätzlicher RAM bezeichnet. Zum Vergleich: der Dispo-Kredit eines Kontos für den Fall, dass Sie temporär einmal mehr RAM benötigen als Sie bei uns angemietet haben.

Die 2GB RAM (1GB zugesicherter RAM + 1GB Burst) werden Ihrem System vollständig als fester Ram angezeigt da es sich um "echten" RAM handelt und kein SWAP-Speicher auf einer HDD. Um sicherzustellen, dass Ihr VPS den ihm zur Verfügung stehenden Burst-RAM auch ohne weiteres nutzt wenn er benötigt wird, ist es erforderlich diesen im System als fest installierten RAM zu deklarieren.
Da die RAM-Nutzung durch eine Virtualisierungsplattform verwaltet wird ist zudem sichergestellt, dass Ihr VPS den Burst-RAM auch nur nutzt wenn er diesen tatsächlich benötigt. Dass bei Linux bekannte "Ich nehme alles was da ist"-Verhalten tritt nicht auf.

Den Burst-RAM können Sie demnach jederzeit verwenden. Solange das Host-System ausreichend freien RAM zur Verfügung hat, steht Ihnen der Burst-RAM uneingeschrängt zur Verfügung. Sollte das Host-System Ihren Burst-RAM kurzfristig für andere Aufgaben benötigen, werden alle Ihre Prozesse die im Burst-RAM liegen beendet und Ihrem VPS stehen nurnoch die zugesicherten 1GB zur Verfügung.
Der Burst-RAM eignet sich also für temporäre Nutzungen, jedoch nicht für eine dauerhafte Nutzung.

Kannst du mit meinen Beancounters-Werten was anfangen bzw. was dazu sagen?

 

[d4f]

cmeerw hatte Recht, die Antwort ist nicht (vollstaendig) korrekt.

Die 2GB RAM (1GB zugesicherter RAM + 1GB Burst) werden Ihrem System vollständig als fester Ram angezeigt da es sich um "echten" RAM handelt und kein SWAP-Speicher auf einer HDD.

Das stimmt so nicht. OpenVZ-Container kennen das Konzept von SWAP nicht, sondern kriegen alles, also auch geswappte RAM als RAM angezeigt.
Dies hat mit der in meinem letzten Beitrag erlauterten kernel-basierten Verteilung zwischen RAM und Swap zu tun auf welche OpenVz keinen Einfluss nehmen kann und will. Falls keine Swap vorhanden ist schiesst der Kernel Prozesse der VM's ab welche im "BUrst"-Bereich sind sobald eine andere VM oder der Host selbst die RAM braucht, wo dann swapping vor zu ziehen ist

Da die RAM-Nutzung durch eine Virtualisierungsplattform verwaltet wird ist zudem sichergestellt, dass Ihr VPS den Burst-RAM auch nur nutzt wenn er diesen tatsächlich benötigt. Dass bei Linux bekannte "Ich nehme alles was da ist"-Verhalten tritt nicht auf.

Das hat rein gar nichts mit der Virtualisierungsplattform zu tun sondern damit dass der Kernel nicht im Container sondern geshared auf dem Hostnode lauft und somit einen globalen, aus den Container nicht einsehbaren, Cache betreibt. Natuerlich belegt er auch weiterhin alle verfuegbare RAM mit Cache.

Den Burst-RAM können Sie demnach jederzeit verwenden.[...] Sollte das Host-System Ihren Burst-RAM kurzfristig für andere Aufgaben benötigen, werden alle Ihre Prozesse die im Burst-RAM liegen beendet

Au ja spitze. Apache waehrend der Auslieferung einer Webseite oder MySQL-Threads bei Belastung ab zu schiessen mag man als Webserver-Besitzer natuerlich sehr
Man sollte den Server konfigurieren dass er _NIE_ Burst-RAM benutzt. Falls es dennoch mal eng wird und er sich kurzzeitig welches holt ist natuerlich nicht schlecht aber Gigabyte-Weise Burst-RAM ist nichts ausser Marketing.

Kannst du mit meinen Beancounters-Werten was anfangen bzw. was dazu sagen?

Du warst seit dem letzen Reboot noch nicht an einem Limit. Was willst du noch hoeren? "GUt" ist Definitionssache

 

[Bachsau]

Naja, sie haben es aus Sicht des VEs beschrieben. Sind halt Support-Leute.

Das stimmt so nicht. OpenVZ-Container kennen das Konzept von SWAP nicht, sondern kriegen alles, also auch geswappte RAM als RAM angezeigt.

Laut Hoster werden die Systeme nach Berechnung des zugesicherten Speichers nicht überbucht, und es gibt keinen Swap auf dem Hostsystem. Das deshalb, weil sie nicht kontrollieren können, für was der VZ-Kernel diesen Nutzt, und es somit passieren könnte, dass andere Kunden innerhalb ihres Grundspeichers die Sache ausbaden müssen, und es außerdem das ganze System verlangsamt.

Das hat rein gar nichts mit der Virtualisierungsplattform zu tun sondern damit dass der Kernel nicht im Container sondern geshared auf dem Hostnode lauft und somit einen globalen, aus den Container nicht einsehbaren, Cache betreibt. Natuerlich belegt er auch weiterhin alle verfuegbare RAM mit Cache.

Natürlich, aber dieser Speicher wird in den VEs eben angeblich als Verfügbar angezeigt, was er ja im Endeffekt auch ist. Deshalb wundert es mich, dass in meinem VE so viel Speicher als Belegt angezeigt wird.

Au ja spitze. Apache waehrend der Auslieferung einer Webseite oder MySQL-Threads bei Belastung ab zu schiessen mag man als Webserver-Besitzer natuerlich sehr

Das selbe hab' ich mir auch gedacht, und dazu meinten die dann, eben genau das: "Man sollte den Server konfigurieren dass er _NIE_ Burst-RAM benutzt."
O-Ton:

Wie bereits gesagt, ist der Burst-RAM auch nur für eine temporäre Nutzung vorgesehen - nicht für den Dauerbetrieb eines MySQL-Servers. Wenn Ihr VPS durchgehend mehr RAM benötigt als Sie bei uns einkaufen und Ihnen damit zugesichert ist, dann können wir Ihnen auch nicht zusichern, dass unser Hostsystem den MySQL-Server nicht stoppt.

Sollten Ihnen 1GB-RAM dauerhaft nicht ausreichen ist es daher erforderlich ein Paket-Upgrade durchzuführen um sicherzustellen, dass Sie sich durchgehend in dem Ihnen zugesicherten RAM bewegen. In diesem Fall bleiben Ihre Prozesse selbstverständlich unangetastet.

Falls es dennoch mal eng wird und er sich kurzzeitig welches holt ist natuerlich nicht schlecht aber Gigabyte-Weise Burst-RAM ist nichts ausser Marketing.

Das Ding ist halt: Ist das okay so, oder wäre es besser, wenn der "Burst" gar nicht zur Verfügung stehen würde? Kann ich ihn davon abhalten diesen im Regelbetrieb zu Nutzen, ohne einen riesen Aufwand zu betreiben? Nicht, dass sich irgendwelche Prozesse denken: "Es ist ja da, also kann ich es benutzen!". Weil, das Gefühl hab ich nämlich. Mir ist nach wie vor nicht klar, warum es auf der OpenVZ-Büchse heißt: 800 MB durch Apps belegt, während es in der VMware gerade mal 150 MB sind. Und diese hat mehr (aus der Umgebung sichtbare) Prozesse zu verwalten, als der Bereich innerhalb des VE.

Der Wert "commited" verläuft in VMware ungefähr auf dieser Marke. Was bedeutet er?

800 MB belegten Speicher!!! Das hab ich auf meinem Desktop nicht, wenn die komplette grafische Oberfläche läuft, inklusive Plugins, Widgets, Opera und Flash! Auf dieser VZ-Büchse läuft, mal abgesehen von (noch) arbeitslosen Server-Diensten, gar nix.

 

[d4f]

Laut Hoster werden die Systeme nach Berechnung des zugesicherten Speichers nicht überbucht, und es gibt keinen Swap auf dem Hostsystem.

Nachteil daran ist dass die RAM viel schneller vollaufen kann (da halt weniger verfuegbar ist) und selbst prima cachebare Sachen in der RAM vorgehalten werden; das Risiko dass ein im Burst laufender Prozess beendet werden muss erhoeht sich drastisch.
Hat natuerlich den vom Hoster erwaehnten Leistungsvorteil.

Das Ding ist halt: Ist das okay so, oder wäre es besser, wenn der "Burst" gar nicht zur Verfügung stehen würde?

In einer Serverumgebung sollte es nichts unberechenbares geben und es ist nichts unberechenbar als Prozesse welche wegen anderen Benutzer abgeschossen werden oder fehlschlagende malloc() trotz "verfuegbarer" RAM.

Mir ist nach wie vor nicht klar, warum es auf der OpenVZ-Büchse heißt: 800 MB durch Apps belegt, während es in der VMware gerade mal 150 MB sind.

Fuehr mal auf beiden folgendes Bash-Vodoo aus:

ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS

Und haeng dann beide Ergebnisse (unverfalescht) als txt an.
Der Code listet die Prozesse absteigend nach RAM-Verbrauch.

 

[cmeerw]

Das Problem bei der Sache ist, dass sowohl die Erklaerung des Supports als auch die Erklaerung von webhostingtalk relativ wenig mit der Realitaet zu tun haben.

In user_beancounters sind 2 Limits gesetzt: ein soft-limit fuer 1 GB RAM und ein hard-limit fuer 2 GB "virtueller Adressbereich". Das heisst, dass die Applikationen im vServer auf max. 2 GB privaten "virtuellen Adressberich" limitiert werden. Da es auf einem normalen Linux-System dafuer jedoch kein Limit gibt, geht Linux relativ freizuegig mit dem "Verbrauch" von virtuellem Adressbereich um - so wird auf einem 64-bit System gern mal 10 MB davon fuer den Stack reserviert (wobei jedoch nur ein Bruchteil davon wirklich genutzt wrid).

Laut den Werten in user_beancounter wurden nur etwa 50 MB RAM tatsaechlich genutzt (oomguarpages), jedoch etwa 780 MB "virtueller Adressraum".

Um das ganze auch noch etwas zu veranschaulichen - hier ist ein kleines Python Test-Script, das nur 10 Threads startet und dann 10 Sekunden wartet:

#!/usr/bin/python
import threading, time

def f():
    time.sleep(10)

threads = [threading.Thread(target=f) for i in range(0, 10)]
[t.start() for t in threads]
[t.join() for t in threads]

Vergleiche doch mal den "Speicherverbrauch" (Ausgabe von "free" vor/waehrend/nach der Ausfuehrung) fuer dieses Script unter OpenVZ mit einem normalen Linux-System. Waehrend auf einem normalen Linux-System das Script kaum Auswirkungen auf die Ausgabe von free haben wird, duerfte es unter OpenVZ (64-bit) fast 100 MB Speicher "verbrauchen".

Im Prinzip wird bei deiner OpenVZ Konfiguration der Begriff "Speicherverbrauch" grundlegend anders definiert als bei einem normalen Linux System.

BTW, probier dann noch "ulimit -Ss 256" vor Ausfuehrung des Test-Scripts...

 

[Bachsau]

Laut den Werten in user_beancounter wurden nur etwa 50 MB RAM tatsaechlich genutzt (oomguarpages)

Dürfte auch kaum mehr sein...

Waehrend auf einem normalen Linux-System das Script kaum Auswirkungen auf die Ausgabe von free haben wird, duerfte es unter OpenVZ (64-bit) fast 100 MB Speicher "verbrauchen".

Ja, kommt etwa hin. 2 vs. 83.

jedoch etwa 780 MB "virtueller Adressraum".
[...]
Im Prinzip wird bei deiner OpenVZ Konfiguration der Begriff "Speicherverbrauch" grundlegend anders definiert als bei einem normalen Linux System.

Ja, irgendwie so habe ich auch gedacht. Aber wenn dieser virtuelle Adressraum mit da rein gezählt, ob die VM "zu viel" Speicher frisst, dann ist das doch voll der Beschiss, oder?

 

[Bachsau]

Fuehr mal auf beiden folgendes Bash-Vodoo aus:

ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS

Und haeng dann beide Ergebnisse (unverfalescht) als txt an.
Der Code listet die Prozesse absteigend nach RAM-Verbrauch.

Die "Bash-Vodoo" sagt:
OpenVZ / VMware

Also kein großer Unterschied. Demnach zieht OpenVZ wohl definitiv dieses "commited" mit rein, wo ich noch immer nicht genau weiß, was das sein soll. Eine Art "Grenzwert", den sich ein Prozess selber setzt?

 

[d4f]

Ein schoenes Zitat das den Unterschied zwischen "commited" und benutzt erklaert

Linux is seriously broken. It will by default answer "yes" to most requests for memory, in the hope that programs ask for more than they actually need. If the hope is fulfilled Linux can run more programs in the same memory, or can run a program that requires more virtual memory than is available. And if not then very bad things happen.

OpenVZ zaehlt also den angefragten Speicher, nicht den tatsaechlich benutzten.

 

[Bachsau]

Macht Windoof das denn anders? Wahrscheinlich nicht, oder? Denn das ganze macht ja Sinn, es zeigt es nur nicht an.

Aber die können doch den Speicherverbrauch des VE, wenn es um das Beenden von Prozessen geht, nicht am commited Memory messen! Das ist doch Betrug!?!

Ich werde mich wohl darauf verlegen, den tatsächlich beanspruchten Speicher zu überwachen. Und wehe ich vermisse einen Prozess.

 

[Firewire2002]

Vielleicht lest ihr mal die Dokumentation zu OpenVZ/Virtuozzo eh ihr hier wild spekuliert.
So ganz recht hat cmeerw nämlich auch nicht.

Nur um erstmal klar zu stellen, von was wir hier reden:
Eine VE mit einem zugesicherten Speicher von 1GB und Burst/Flex/Dynamischen (wie auch immer) Speicher von bis zu 2GB.

Ein Standard Linux System kennt erstmal nur ein Limit: sein maximaler Ram + Swap
Wenn man sich die UBCs mal anschaut, stellt man aber recht schnell fest, das VZ mehr Limits kennt, als einfach nur Ram. Die Unterschiede von Barrier und Limits (Soft und Hard Grenzen, wie sie cmeerw ansprach, lass ich mal aussen vor, weil sie erstmal nichts mit dem eigentlichen "Problem" hier zu tun haben).

Wenn wir also 1GB Speicher zugesichert haben, sprechen wir von oomguarpages. Der Speicher steht der Anwendung definitiv zu.
Dann kommen wir zu dem "virtuellen" Adressraum (malloc()). Die Grenze wird von vmguarpages vorgegeben. Alle malloc() Calls bis zu der Speichergrenze werden erfolgreich sein.
Und nun zu dem maximum von 2GB: Das wird in privvmpages definiert.

In vServer Angeboten wird üblicherweise oomguarpages und privvmpages angegeben. Ein Kunde, der sich mal Ansatzweise damit beschäftigt, was er da eigentlich mietet, weiß, dass es da aber noch wesentlich mehr Limits geben kann. (Sofern VZ mit UBCs eingesetzt wird, es gibt auch noch SLM)
Entsprechend sollte man sich also über alle Limits vorher informieren. Support und Vertrieb der Hoster geben die in der Regel auch auf Nachfrage bekannt. Einige Hoster haben sie auch in den eigenen FAQ abgelegt.

Eh hier also nach Betrug geschrien wird, sollte man sich erstmal schlau machen, wovon man redet.
@Bachsau, das hat Joe dir die letzten Tage aber auch schon mal gesagt.

Das Bild im Anhang hatte ich mal irgendwann im Netz gefunden, es stammt nicht von mir. Quelle finde ich leider nicht mehr. Beschreibt das ganze aber in Kurzform recht treffend.