Schlagwort-Archive: Proxmox

Design-Bug in Proxmox gefunden – evtl. gefährlich für Proxmox-Hoster

Wir haben den Bug bereits vor 2-3 Wochen  gefunden und auch schon im Proxmox-Bug-Center gelistet! Es ist bisher jedoch keine Reaktion erfolgt! Offensichtlich wird das Risiko nicht richtig eingeschätzt! Design-Bug in Proxmox gefunden – evtl. gefährlich für Proxmox-Hoster weiterlesen

Man in the Middle – iPhone (Apple-Shop) – ProxmoxR – Applikation

ProxmoxR - Man in the Middle ApplikationBeim Austesten von Erweiterungen für Server-Kunden, haben wir eine große Sicherheitslücke in einer Applikation mit dem Namen ProxmoxR gefunden, die durch den Apple-Store für iPhone und iPad vertrieben wird!

Viel schlimmer ist dabei, daß die Kommunikation dabei über Server eines Server-Hosters erfolgt, der bereits mehrfach gehackt worden ist, letztmalig vor einigen Tagen: im Januar 2016!

Es ist für uns unverständlich, daß hier Apple seine Entwickler nicht verpflichtet, nur Applikationen heraus zu geben, die nur direkt mit den Gegenstellen kommunizieren dürfen bzw. andernfalls Kunden von iPhones und iPads deutlich und mehrfach darauf hingewiesen werden müssen, daß die Applikation nur durch eine Umleitung kommuniziert, die unter Umständen nicht sicher ist!

Man in the Middle – iPhone (Apple-Shop) – ProxmoxR – Applikation weiterlesen

Schwachstelle in diversen Virtualisierungs-Plattformen gefunden CVE-2015-3456

Vulnerable RedHat CVE-2015-3456Heute bekannt geworden, ist ein Vulnerability cve-2015-3456, der in diversen Linux OS-Versionen, seit ca. 2004 vorhanden ist. Ein Angreifer, der Zugriff auf eine KVM (virtuelle Maschine) hat, kann diese Sicherheitslücke nutzen, um über die Disketten-Schnittstelle, Vollzugriff auf den Host und damit die gesamte Infrastruktur des Hosters zu bekommen! Davon sind betroffen, sehr bekannte Hoster-Administrationssystemen, Schwachstelle in diversen Virtualisierungs-Plattformen gefunden CVE-2015-3456 weiterlesen

Analyse des Ausfalls – Ein Grund dafür: PVE-Firewall blockte alle Verbindungen in/out

Proxmox - PVE-FirewallAus einem noch unklaren Grund, verursachte die PVE-Firewall auf den Hosts ein Blocking in beide Richtungen (in/out)! Die PVE-Firewall sorgt aber ansonsten für eine optimale Sicherheit! In beiden Fällen, war ein Zugriff über die Administrationswerkzeuge (z.B. SSH) nicht mehr möglich und es mußte jeweils der Host neu gestartet werden und damit wurde dann jeweils der neue Kernel aktiv, zu dem nicht die Einstellungen der Konfiguration passten, die jahrelang gültig waren! Dann stellt sich die nächste Frage, warum wurden diese überhaupt gesetzt? Keine Ahnung, aber wir finden diese in der GitHub-Dokumentation zu Proxmox, also waren die vorher auch notwendig! Warum aber die PVE-Firewall den gesamten Netztraffik von einem Moment zum anderen geblockt hat, ist noch vollkommen unklar und wir forschen, sofern daß noch möglich ist, auch weiter aus! Aber wir haben für uns und auch für andere Hoster, denen genau das gleiche passieren könnte, bereits ein Script entwickelt, daß im Falle einer plötzlich blockierenden PVE-Firewall, diese dann abschaltet, den Netzwerk-Verkehr wieder erlaubt und den Administrator des Hosts, darüber informiert, dringend einzugreifen, denn nichts ist schlimmer, als wenn ein Host in der Produktion, plötzlich nichts mehr rein oder raus läßt und in Folge womöglich auch weitere Probleme verursacht werden! Das Mini-Script, ist zu finden unter http://wiki.1awww.com/wiki/Proxmox_pve-firewall_Control-Script

Security Bug in Proxmox-Firewall gefunden

Wir haben gestern in der neuen Firewall von Proxmox (pve-firewall Version 3.0-9), der neuen Proxmox – Version 3.3, einen extremen Sicherheits-Bug gefunden! Inzwischen arbeiten die Entwickler offensichtlich unter Hochdruck daran, diesen Bug zu beseitigen, wie gefährlich jedoch dieser Bug ist, wollen wir nachfolgend beschreiben: Security Bug in Proxmox-Firewall gefunden weiterlesen

#Proxmox ubpdatedb.mlocate verursacht D-State Prozess und frist Resourcen#Proxmox updatedb.mlocate much D-State Processes – use much Resources#Proxmox updatedb.mlocate – mucho D-State Processes y bajo de Velocidad

ACHTUNG: Nicht nur ein Problem unter Proxmox!

Von Tag zu Tag wurde der Resourcen-Verbrauch immer größer und vServer litten unter massig D-State-Prozessen, die unter anderem durch updatedb.mlocate verursacht wurden! Dies hatte die Folge, daß die IO-Wait-Time von Tag zu Tag drastisch stieg!

Läuft updatedb.mlocate zu lange, dann liegt dies sicher an einer ungünstigen Konfiguration, nicht jedoch, ist an einen Fehler von updatedb.mlocate zu denken!

Wir haben vorher geprüft mit htop und Sortierung nach S, welche D-State Prozesse lange liefen und immer wieder fanden wir hier updatedb.mlocate. Nach einem kill (ohne -9), ging die IO-Wait-Time drastisch wieder runter! Also klar und eindeutig ein Indiz, daß updatedb.mlocate unsere Resourcen gefressen hat!

Hier unsere Tricks für Analyse und Abhilfe:

#Proxmox ubpdatedb.mlocate verursacht D-State Prozess und frist Resourcen#Proxmox updatedb.mlocate much D-State Processes – use much Resources#Proxmox updatedb.mlocate – mucho D-State Processes y bajo de Velocidad weiterlesen

Proxmox 2.1 Bug – vzctl create – Error: Not enough parameters, diskspace quota not set

Nächster Bug in #Proxmox:

wenn ein #Container über Shell-Script angelegt wird, mit folgendem Befehl:
vzctl create 958 –ostemplate debian-6.0-confixx_6.0-4_i386 –root /var/lib/vz/root/958 –private /var/lib/vz/private/958 –ipadd 123.123.123.123 –hostname CT958.Top-Server.1awww.com

kommt es zu folgender Fehlermeldung:
Creating container private area (debian-6.0-confixx_6.0-4_i386)
Initializing quota …
Error: Not enough parameters, diskspace quota not set
Creation of container private area failed

Das mitgeben von Diskspace-Daten ist aber in vzctl create nicht möglich!

Workarround:

Kopieren Sie ein Container-Config-Script als Vorlage, z.B.
cd /etc/vz/conf
cp ct123 ve-default.conf-sample

Dieses Vorgabe-Sample sollte in etwa die Mindest-Anforderungen eines Containers erfüllen, denn wir wollen ja vielleicht im nächsten Schritt (vzctl set) alle weiteren Parameter anpassen

Des weiteren, müssen Sie nun nur noch Ihr Create-Script erweitern um den config-Parameter

vzctl create 958 –ostemplate debian-6.0-confixx_6.0-4_i386 –root /var/lib/vz/root/958 –private /var/lib/vz/private/958 –ipadd 123.123.123.123 –hostname CT958.Top-Server.1awww.com –config default

Danach funktioniert der vzctl create wieder und der Container wird erstellt. Im nächsten Schritt können Sie dann via vzctl set 958 –diskspace 30G:30G –save

setzen!

Schnelle Migration von Proxmox 1.9 auf Proxmox 2.0

Schnelle Migration auf Proxmox 2.0: Damit haben wir nun alle Server, die unter der bisherigen Host-Technik von Proxmox 1.9 auf Proxmox 2.0 liefen, umgestellt.

Proxmox 2.0 sieht von der Bedienung und den Möglichkeiten besser aus, setzt aber auf die bestehenden Techniken von vzOpen auf. Wichtigster Grund für einen Upgrade auf Proxmox 2.0 war, daß das Host-Operationg-System in der alten Version unter Debian Lenny, nicht mehr supportet wird und damit überholt und sicherheitskritisch geworden ist. Die neue Version Proxmox 2.0 (und die 2.1 ist gerade auch erschienen), läuft unter Debian-Squeeze, der derzeitigen Debian-Stable-Version.

Unter Proxmox 2.0 kann man von einer hohen Sicherheit ausgehen. Die mitgelieferten Backup-Funktionen, sind leider nicht besonders schön, denn sie belasten den Host über mehrere Stunden (insbesondere das File-System) und die Nacht reicht nicht aus, für einen normalen Backup-Satz und das bei noch relativ wenig virtuellen Servern.

Ebenfalls hätte der Upgrade via Script – bei uns zumindest – zu einem Totalausfall geführt! Daher können wir nur warnen, via Script den Upgrade von Proxmox 1.9 auf 2.0 durch zu führen. In den Requirements für einen Upgrade wird nicht erwähnt, den Grub (Bootloader) auf den neuesten Stand zu bringen. Mittels Supergrub konnte auch das Problem ebenfalls nicht beseitigt werden, es fand nämlich nicht die LVM – Drives (alle Options, wie LVM, SCSI etc. wurden enabled – mehrfach auf alle Arten und Weisen getestet)! Ferner wurden diverse Fehler während der Installation angezeigt! Also eine einfach unschöne Lösung. Wir haben auf einem Host, von dem bereits alle Container auf den neuen Host verschoben wurde, einen Upgrade via Script probiert. Danach haben wir fast 14 Stunden vergeblich versucht, eine Problemlösung zu finden – es half nichts – wir haben aufgegeben!

Die Methode via vzdump + vzrestore bei Container mit 100 GB und mehr, die Server zu verschieben, würden zeitliche Ausfälle wenigstens einzelner Server über viele Stunden, nämlich jeweils denen, die gerade verschoben werden, verursachen. Für den m6server hätten wir ca. 10 Stunden diesen Server „offline“ schalten müssen. Ca. 4 Stunden für vzdump – ca. 2 Stunden für scp zum anderen Host und weitere 4 Stunden für vzrestore.

Wir haben eine andere Methode gefunden, die Server von einem alten auf einen neuen Host zu migrieren und die Ausfallzeit für Kunden pro Server, auf nur 15 Minuten (dies war die echte Ausfallzeit des m6server´s) zu reduzieren!

Artikel schnelle und sichere Migration von Proxmox 1.9 auf 2.0

 

 

Hosts-Umstellungen für mehr Power und Sicherheit

1awww hat 90 % aller Server auf #Proxmox 2.0 upgedatet. Im Laufe des morgigen Tages, wird der letzte Server mit knapp 200 Kunden innerhalb von nur gerade 30 Minuten auf den neuen Host verschoben und nach einer knappen Reserverzeit, wird auch der letzte Host auf Proxmox 2.0 upgedatet.

Manche Kunden haben sich sicherlich gewundert, warum die Geschwindigkeit in den letzten 3 Tagen erheblich abgesunken ist. Dies war aber aufgrund der diversen System-Unverträglichkeiten zwischen Alt und Neusystemen, leider nicht anders möglich!

In Kürze erfahren Sie weitere verbesserte Leistungsmerkmale und die neuen Vorteile der Umstellung für Root-Server von 1awww.com