Und wieder ein schönes Beispiel, warum Debian irgendwie zuverlässiger ist als Ubuntu.
Mein Deb12 war weder von copy fail noch dirty frag betroffen, Deb13 wurde schnell gefixed und mein Ubuntu 26.04 ist noch genauso ungepatched wie mein Xubuntu 24.04...
Unsere Regierung kann Dir kein Backup bieten.
Hinter der besagten Tür ist ja auch nicht unsere Regierung, sondern eine, für die Technik kein Neuland ist.
Bei Anbietern, welche einen ein kleineres ipv6 Netz als /64 anbieten würde ich keine ipv6 Dienste betreiben. Laut IETF ist das kleinste Netz, welches einen Endbenutzer zugewiesen wird, ein /64. Auch DNSBLs filtern nur auf /64. Heißt, kann gut sein, dass Dein SMTP dann geblockt wird, sobald jemand in "Deinem" /64 Spam versendet.
Zur Info, der RAM scheint auch bei kleinen 1GB Maschinen nach dem Update auf 26.04 nicht --wie befürchtet-- zu knapp zu werden.
Der Speicherverbrauch ist ziemlich genau so wie vorher auch.
Snapd installiert, keine Neuinstallation (do-release-upgrade), ursprünglich auch normales ISO (kein cloud-init).
Ich hatte mit meiner RS IPv4 öfter mal Probleme bei Google. Dort kam eine Seite mit dem Hinweis, dass aus meinem IP Bereich automatische Anfragen kommen und ich gesperrt sei und es in 24 Stunden nochmal probieren soll. Ohne Captcha. Nach Umzug des RS auf eine neue Generation mit neuer IP war der Spuk vorbei.
War wohl Sippenhaft.
deSEC? Wenn du da regelmäßig was änderst, bekommst du auch keine Nervmails, ob du das noch nutzt. Und auch wenn es da ein Limit auf eine Domain gibt, kannst du dir Subdomains anlegen, wie du lustig bist, und separat updaten
+1 für deSec. Da kann man auch ganz wilde Konstrukte zusammenbasteln mit IPv4 NAT und dazu mehreren dynamischen ipv6 Adressen. Ganz tolle API und TTLs von nur 60 Sekunden.
Die Limitierung auf eine Domain wird übrigens automatisch aufgehoben, sobald man für die Domain DNSSEC einschaltet. Oder alternativ ganz nett beim Support nach mehr Domains fragt, falls man aus irgendwelchen Gründen DNSSEC nicht einschalten möchte.
Server sent fatal alert: handshake_failure
Joa, und schau Dir den Rest der SSL Labs Beurteilung auch mal noch an. Das "Certificate #2" ist übel.
Hm, ist da nicht alles gut auf der Seite? Das zweite Zertifikat ist doch für ne andere Domain, wenn auch nicht trusted. Das sollte Deinen Browser überhaupt nicht interessieren, oder kann der kein SNI?
Bei mir ist bei Firefox/Chrome auch alles gut..
Hi,
Ich habe zwar kein Pico aber einen 1GB RAM Server bei der günstigeren Konkurrenz. Der lief bislang unter Ubuntu Server 24.04 und ich habe mich eigentlich schon aufs 26.04 Upgrade nächste Woche gefreut. Dann ist mir aufgefallen, dass die minimale RAM Empfehlung von 1GiB auf 1.5GiB steigt (https://documentation.ubuntu.com/release-notes/26.04/)
Wollte hier nur mal informieren, bevor ihr ein LTS Upgrade macht und es dann vielleicht aufgrund vom swapping zu langsam wird...
Gerade mal geschaut, mein Ubuntu Server LTS braucht als Idler derzeit tatsächlich um die 800 MiB, könnte also zu wenig RAM sein, wenn da nochmal 50% mehr drauf kommen. Mein Debian 13 Idler verbraucht nur 430MiB RAM. 
Kommentiere mal in Deiner /etc/apt/apt.conf.d/50unattended-upgrades die Zeilen 29 und 30 ein. Momentan werden nur Security Updates installiert.
Auch nützlich ist oft ein
unattended-upgrade --dry-run -v
zum debuggen.
ot: du brauchst nicht zufällig lto ultrium 4 bänder? 6neue + 1 cleaning tape?
Ich habe genug Bänder, danke!
Wäre aber sogar LTO4 
Ich bin wahrscheinlich wieder der einzige, der mit tar auf LTO sichert, oder?
Der Transparenz halber, falls es jemand nicht aufgefallen ist: mein obiger Beitrag wurde mit Hilfe von KI erzeugt.
Ich bin mir sicher, dass er für den Threadersteller hilfreicher ist, als die Lösungsversuche mit den seltsamen Fragen der Forenteilnehmer...
Im Netcup Forum versucht ein Benutzer in seiner chroot Umgebung Dateien zu löschen, die in der chroot Umgebung benötigt werden, da er denkt, dass diese nach einem Hack dort vom Angreifer hinterlegt wurden. Erkläre dem Benutzer bitte seinen Fehler
Der Fehler des Benutzers liegt in einem grundlegenden Missverständnis darüber, wie chroot funktioniert.
Eine chroot-Umgebung ist keine eigene Installation und kein eigener Server, sondern nur ein anderes Root-Verzeichnis für Prozesse.
Das bedeutet:
Wenn er also in der chroot Dateien löscht, löscht er nicht nur in der chroot, sondern auf dem echten System.
Der Benutzer denkt vermutlich:
„Diese Dateien liegen in der chroot, also gehören sie nur zur chroot. Wenn sie von einem Angreifer kommen, kann ich sie dort löschen.“
Das ist falsch, weil:
Wenn man diese löscht, funktionieren Programme, SSH, apt, bash usw. nicht mehr.
Kurz gesagt:
Er löscht möglicherweise sein eigenes System kaputt, nicht die chroot.
Wichtig: Nach einem möglichen Hack löscht man nicht einfach Dateien, sondern:
Warum?
Ein Angreifer kann Dateien überall verstecken, nicht nur in der chroot.
Eine chroot ist KEINE Sicherheitsumgebung.
Sie ist nur eine Einschränkung des Dateisystemzugriffs, aber:
Wenn Root kompromittiert ist, ist auch die chroot kompromittiert.
Du kannst dem Benutzer ungefähr das hier sagen:
Du machst einen Denkfehler: Die chroot ist kein eigenes System, sondern benutzt dieselben Dateien wie das Hostsystem. Wenn du in der chroot Dateien löschst, löschst du möglicherweise Systemdateien des Servers. Die Dateien sind sehr wahrscheinlich keine Hacker-Dateien, sondern benötigte Libraries, Binaries oder gemountete Systemverzeichnisse. Nach einem möglichen Hack sollte man nicht blind Dateien löschen, sondern Logs prüfen oder den Server neu installieren. Eine chroot ist außerdem keine Sicherheitsumgebung und schützt nicht vor einem kompromittierten Root-System.
Wenn du willst, kann ich dir auch erklären, woran man erkennt, ob wirklich ein Hack stattgefunden hat.
Wenn du doch aber davon ausgehst, dass Netcup ohnehin auf den Key aus dem RAM zugreifen kann, was sind deine Beweggründe trotzdem FDE einzusetzen?
Wie so manches im Leben: Risikominimierung. Sobald ich meinen Server runterfahre/ hart ausschalte, hat keiner mehr Zugriff auf meine Daten. Sollte mal ein anderer Kunde aus seinem KVM ausbrechen oder der Node von außen kompromittiert werden, sind die Daten durch einen Dritten auch nicht direkt aus dem Dateisystem auslesbar.
Ich setze einfach darauf, dass ein möglicher Angreifer sich erst einmal bei den low hanging fruits (dh unverschlüsselte Instanzen) bedient, bevor er Speicher Abbilder erstellt oder meinen Bootprozess manipuliert, das sind bei Netcup noch mögliche Angriffsvektoren (kein secure boot, kein SEV. Beides wäre übrigens mit bestehender Hardware bei Netcup möglich)
Ich habe auch mal yabs mit/ohne LUKS gebenchmarkt und konnte keinerlei Performanceverlust feststellen.
aaah, guter Hinweis. Wie bekomme ich das denn mit dem trim raus? Es ist ein aktuelles ubuntu-System.
Trim wird über einen systemd timer aufgerufen, nach Installation eigentlich aktiv. Machmal ein sudo systemctl list-timers --all und halte nach fstrim.timer ausschau, auf meine Debian 13 (auch als Deb13 installiert) läuft es einmal die Woche. Ich habe allerdings noch ein paar uralte Server, die ich immer geupgraded habe, dort war es zum Installationszeitpunkt nicht mitinstalliert worden. (Vermutlich daher auch der Satz im SCP -- betrifft aber wirklich nur Installationen von 10 Jahren und älter) Bei meinem Ubuntu 24.04 ist es aktiv (ich glaube der war als 20.04 installiert).
Damit LUKS trimmed, muss man das wollen, weil es die Verschlüsselung schwächen kann.
Ich würde mich als sehr vorsichtigen Nutzer bezeichnen, manch einer mich schon fast als Paranoid. Ich kenne das potentielle "data leakage" was Du zitiert hast, aber mal ehrlich: Netcup könnte sowieso (theoretisch) auf einen Encryptionkey im Arbeitsspeicher zugreifen, wozu sollte ich dann darauf auchten, dass ich Netcup den Füllstand meiner vda vorenthalte? Das ergibt wernig Sinn. Und "plausible deniability" geht bei Netcup eh nicht.
Daher, denke ich, sollte man fair sein und trim auch bei LUKS anlassen, da Netcup Deinen freien Plattenplatz besser (und damit kostengünstiger(!) für alle) verwenden kann. Außerdem sterben nicht getrimmte NVMes schneller, daher habe ich es auch bei meiner eigenen Hardware immer an.
meine 38 GB Dateisysteme in einem verschlüsselten LUKSContainer sind? Also daß es - so mein Verständnis - für netcup immer so aussieht, daß da 38 GB belegt sind?
Ist zwar für deine Frage nicht direkt relevant, aber falls Du LUKS benutzt und Dein OS ein regelmäßiges trim in dem verschlüsselten Dateisystem macht, zeigt Dir Netcup im SCP auch nur die tatsächlich benutzten Blöcke an, d.h. auch ggf. weniger als 38GB
Alles anzeigenGuten Tag zusammen,
irgendwie sind die Preisangaben "etwas" verwirrend:
RS 2000 G12
Auf der ersten Seite der Server-Auswahl:
"bereits ab monatlich 17,36 € inkl. MwSt."
dann nach der Auswahl (günstigste Variante):
12 Monate Vertragslaufzeit 19,95 €
und im Warenkorb dann plötzlich:
24,65 € ohne Angabe MwSt.
Das hat mich nun von der Bestellung abgehalten.
Schade, dass ich keine Screenshots direkt einfügen kann.
Ich kann das Problem nachvollziehen. Nach dem Löschen des Browsercaches wird es dann aber richtig angezeigt, zumindest für den RS 2000.
Für den RS 1000 ist es selbst nach dem Löschen des Caches noch falsch. Auf der Produktseite 10,41€ inkl. MwSt DE und IPv4, im Warenkorb dann 12,79 €. Scheinbar wird da gerade noch dran "gebastelt"...
Ohje, bei +18,51% netto Aufschlag kommt ja auch noch die MwSt drauf, wo landen wir dann brutto?
Ich finde das persönlich schon einen heftigen Aufschlag für Bestandskunden, mir wäre es da deutlich lieber den Preis so zu lassen und den RAM um 18,51% zu reduzieren. Also 6.5 GB RAM beim RS1000 anstatt 8GB.
Du hast also zwei Möglichkeiten
Ich sehe noch als dritte Möglichkeit einen Reverse Proxy (Apache oder nginx), da Deine Anwendung http ist. Hätte den Vorteil, dass Du auch HTTPS verwenden könntest. Ansonsten wie hier schon erwähnt einfach auf der 10.121.1.1 lauschen.
Das sind böse Bots im Internet, die versuchen Dein Passwort zu erraten.
Schnelle, aber wirklich keine gute Lösung: Gibt dem Admin Benutzer einen anderen Namen.
Bessere Lösung: Benutze die Netcup Firewall und lasse RDP Verbindungen nur von einer (festen) IP von Dir zu. Im gleichen Zug am besten auch alle anderen Ports zu nageln, ein Windows Rechner ohne Firewall im Internet ist nie eine gute Idee.
Beste Lösung: installiere wireguard und schließe alle eingehenden Ports in der Netcup Firewall bis auf wg. Da dies UDP ist, ist das ein bisschen ein gebastel, da stateless. Suche mal im Forum danach. Dann ein wg Tunnel aufmachen und RDP darüber ist dann auch sinnvoll verschlüsselt.
