Posts by H6G

    Dürfen wir euch den Verdienstausfall für die Zeit dann in Rechnung stellen?

    Sie sollten evtl. mal ihre Vertragsunterlagen genaustens studieren.

    Bei einer vertraglich garantierten Verfügbarkeit von 99,9% im Jahresmittel darf ihr System bis zu 8,76h nicht erreichbar sein (bei 99,6% resp. 35,04h).

    Insbesondere bei einem solchen Bug ist Schnelligkeit gefragt. Aber auch so dürfte ich mir nicht aussuchen, wann ich denn die 8,76h Ausfall haben möchte.


    Stichwort Risiko. Um ein Risiko zu minimieren kann man nun auf mehrere Server zurückgreifen (z.B. zwei Loadbalancer + zwei Applikationsserver).

    So wie sich das bei mir abzeichnet arbeitet bei NC derzeit die ganze Mannschaft und auch der Geschäftsführer nachts und am Wochenende, um die Systeme zu patchen. Das verdient meinen Respekt - das Team macht eine super Arbeit. Deswegen kann ich Ihren Beitrag nur als Frechheit abstempeln.


    Wo gehobelt wird fallen Spähne. Alle sonstigen Probleme die derzeit auftreten müssen natürlich behandelt werden, jedoch sollte der besondere Umstand der vorliegt beachtet werden und auch mit dem nötigen Weitblick betrachtet werden.

    Oben hatte ich nur die SHA256SUM gepostet und vergessen dazuzuschreiben, welcher Hash es ist.


    EDIT: Das wichtigste habe ich natürlich vergessen zu fragen... was ist mit den 3/7 restlichen Maschinen?

    Hatte ich übersehen. SHA256 stimmt auch überein. Initramfs schonmal neu generieren lassen?

    Zwei Maschinen haben eine andere Distro und die dritte ist ein Deb. 9 mit noch nicht geupdateten Kernel.

    Code
    root@zeta:/home/pzillmann# sha1sum /boot/vmlinuz-4.9.0-5-amd64 
    65911c2e164b577ae0822936a60c0816e2434bae  /boot/vmlinuz-4.9.0-5-amd64

    Nur mal so als Idee.

    Ansonsten würde ich wirklich auf die Hardware tippen. Scheint aber bei einigen Probleme zu geben. Der Kernel läuft ber bei mir momentan auf 4/7 Maschinen ohne Probleme.

    Gepatcht werden muss natürlich zeitnah, was ich aber als "Wochen" und nicht als "Tage" auffasse.

    Theoretisch ist der Angriffsvektor da. Damit besteht die Möglichkeit aus seiner Netcup VM auszubrechen und Daten anderer VMs anzusehen - läuft ja auf dem selben Prozessor. Wenn meine VM jetzt Daten verarbeitet (Adressen, Mailadressen, Kontodaten, Nutzerzugänge, Betriebsvorgänge) und du könntest mitlesen - das gefällt keinem. Deshalb sind "Tage" besser als "Wochen"...

    dass die Lücke nicht auf allen Betriebsystemen geschlossen sei, mich würde es interessieren wie es dann Netcup möglich ist die Lücke zu schließen

    Debian und RHEL haben bereits Updates draußen. Ebenfalls ist im Linux Kernel Upstream einiges gefixed - NC kann sich die Kernel auch selber zusammenstellen und kompilieren, ist also nicht auf die Paketmaintainer der Betriebssysteme angewiesen. Ist also nicht abhängig vom Betriebssystem.

    Hui, ein sattes Plus :|

    Bei unseren VMs sieht das ein wenig anders aus.

    Wir haben momentan 7 VMs im produktiven Einsatz. Heute Vormittag / Mittag habe ich Kernel gepatcht.


    Auf drei Systemen wurde von Linux 4.9.32 mit GrSecurity und PaX Härtung auf 4.9.65 mit KAISER Patches aber ohne weitere Härtung.

    Die CPU Util. Graphen dieser Systeme zeigen einen Lastrückgang von 2 bis 3 Prozentpunkte auf. (Hostnodes noch nicht geupdatet).


    Auf einem System hatten wir ein Update von einem regulär ungehärtetem Kernel auf die 4.9.65 mit KAISER Patches. (Hostnode bereits geupdatet).

    Auf dem einen System konnten wir einen Lastzugang von bis zu 5 Prozentpunkten feststellen. Die Grafik halte ich für eher interessant und habe sie einmal angehängt.


    So dramatisch zeichnet sich das also nicht ab. Wenn die entsprechenden Kernel mit GrSecurity, PaX und Kaiser gepatcht sind, erwarte ich am Ende einen Zuwachs von evtl. zwei Prozentpunkten. Dazu kommt ja noch, dass die Patches im Laufe der Zeit besser werden (und die nächste[n] Prozessorgenerationen und Iterationen der Netcup VMs stehen auch noch da). Alles in Allem: Don't panic.


    Ich könnte mir gut vorstellen, dass das ganze bei Xen PV noch ein wenig anders aussieht (Xen PV wird bei einigen Cloudanbietern bevorzugt genutzt).

    Also 9,5M sind für eine Linux-Boot Partition zu wenig. Muss also etwas anderes sein. Type BIOS?!

    Müsste mich jetzt hier ausklinken. Was mir noch einfällt: das könnte evtl. auch eine UEFI Partition sein bzw. eine andere in der nur Grub installiert ist.


    Im Zweifelsfall so lassen. Deine Daten sind soweit sicher - kann nur passieren, dass die Kiste irgendwann nicht mehr durchbootet.

    Da fehlt vermutlich eine Partition (die Boot Partition resp. /dev/sda1)

    Weißt du was da drauf ist?


    Du könntest die einfach mal mounten und reinschauen. Wenn der Kernel und das Initramfs drinne sind, und das Dateisystem ext2 ist - ist das deine Bootpartition.

    Dann einfach im /etc/fstab die Zeile:

    Code
    /dev/sda1 /boot ext2 defaults 0 1

    einfügen.


    Hast du das automatisch partitionieren lassen bzw. die Partitionierung eines voherigen Betriebssystems übernommen?

    There are some troubles getting Windows 10 running inside an KVM / Xen environment.

    On my private computer I use a Windows 10 VM via KVM (uefi-based)


    On bios based KVM solutions (like netcup provides it) you could try to make a remaster of the windows disk with integrated virtio-drivers. Therefor these drivers don't need any signatures.

    An other solution could be to switch the blockdevice from VirtIO / SCSI to SATA or IDE inside SCP and try install Win 10

    Es lässt sich ganz gut arbeiten mit dem WebVNC. Einige Eingaben werden doppelt und dreifach getätigt.

    Ich habe zwei Server, bei denen der SSH Daemon nur bei Bedarf gestartet wird.


    Hinter einem Corporate Proxy wird das hingegen sehr unbrauchbar (TLS wird nicht aufgebrochen).

    Ich habe schon bei anderen KVM Hostern VNC nativ benutzt, die das direkt anbieten.

    (sehr gut wenn man gleichzeitig über KVM als kernelbased virtual machine und keyboard, video, mouse reden möchte...)

    Die hatten ein zentrales VNC-Gateway - jede VM hatte eine Portnummer auf dem Gateway. Authentifizierung mit Benutzer / Passphrase.


    Evtl. ist das ja auch ein Weg für Netcup die native VNC Verbindung auszuleiten und anzubieten.

    Hast Du daran gedacht, dass das standardmäßig enthaltene Subnetz nicht geroutet ist und somit ein NDP-Proxy o.ä. verwendet werden muss?

    Die werden nicht geroutet? Das ist ungünstig. Da kann ich ja stunden an der Firewall herumfummeln. Wie macht man das mit den NDP Proxies am besten, ohne die Adressen auf ein Interface am Server zu binden?


    Was genau bleibt wo "hängen"? Mehr Details bitte :)

    Ein Export im Log zeigt, dass Test-ICMP Pakete in der FORWARD Chain vom Server ankommen. Da keinerlei Response ankam, bin ich davon ausgegangen, dass die Pakete den Server nicht verlassen haben und entsprechend hängengeblieben sind.


    Danke schonmal für den Input. Das mit den NDP Proxies klingt vielversprechend.


    //Edit:


    Lösung gefunden: IPv6 – Proxy the neighbors (or come back ARP – we loved you really) « ipsidixit.net
    Der Eingangssatz "come back ARP – we loved you really" beschreibt es eigentlich recht gut.
    Danke

    Ich verzweifel gerade daran ein Netzbereich hinter einem meiner Server erreichbar zu gestalten.
    An einer virtuelle Schnittstelle ist ein Bestandteil des IPv6 Netzes geroutet.


    Routen stimmen, FW (ip6tables) steht offen (soll auch offen sein), sysctl forwarding für IPv6 ist aktiviert, ausgehende Pakete bleiben trotzdem in der Forward Chain hängen.
    Ich habe schon sämtliche möglichen Acceptance Regeln in der Chain probiert, leider ohne Erfolg.
    Kann mir da jemand weiterhelfen?

    Hallo Christian,


    danke für Deinen Input. Ich stelle das nochmal als Shellscript hier zur Verfügung.
    Läuft auch soweit.


    Kann ich dennoch den Typ 128 (echo-request) auf bestimmte Source Adressen reduzieren zzgl. des fe80::/10 Subnetzes?


    Guten Tag Zusammen,


    ich versuche derzeit einen unserer Server abzuschotten. Das gelingt auch soweit ganz gut, nur dass ICMP Pakete in IPv6 von bestimmten erlaubten Hosts nicht durchkommt. Eine Umleitung auf den Log bietet auch keine neuen Erkenntnisse, außer dass die Pakete nicht in der entsprechenden Chain landen, sondern vorher abgefangen werden.


    Die Eingangsregel habe ich auch schon weiter erleichtert, bishin zu jedem ICMPv6 Traffic zu erlauben - führt leider auch nicht zum gewünschten Ergebnis.
    Hoffe, dass mir jemand noch einen Anhaltspunkt liefern kann.


    Was auch verwunderlich ist, dass nach jedem 4. Paket ein Adress unreachable zurückwirft.



    Danke für die Unterstützung.