Beiträge von mango

Zitat von TBT

TS wird funktionieren, aber nur "relayed", was nicht "direkt" ist und z.B. Latenzen und Übertragungsraten deutlich beeinflusst, da die Verbindung über TS Server relayed wird. Aus diesem Grund ist folgende NC Firewall Regel essentiell:

image.png

Sorry für die etwas späte Rückmeldung.

Ich hab es jetzt im der Firewall eingepflegt, dort wird mir das neue UI auch angezeigt.
Nun weiß ich nur nicht, was "beliebig" bedeutet wenn man keinen Eintrag in einem Feld gemacht hat. Bedeutet dass er lässt dann alles zu? Im alten Firewall UI war das ein *

TS.PNG

Zitat von TBT

TS wird funktionieren, aber nur "relayed", was nicht "direkt" ist und z.B. Latenzen und Übertragungsraten deutlich beeinflusst, da die Verbindung über TS Server relayed wird. Aus diesem Grund ist folgende NC Firewall Regel essentiell:

image.png

Sehr gut, danke für den Tipp. Dann werde ich das einrichten wenn ich TS auf den Server packe.

Zitat von terence

Ich würde „accept all outgoing TCP“ auch aus der Mail-Policy rausnehmen. Die Regel benötigst Du ja z. B. für die Update-Mirrors.

Stimmt macht Sinn. Danke für den Hinweis.

Zitat von TBT

Ich denke dass die stateless Firewall von Netcup wohl auf dem Switchport als Funktion des Switch OS implementiert ist. Alternativ könnte es auch eine Funktion der Virtualisierungslösung sein, auf der alle unsere Server laufen.

So nutze ich die Netcup FW:

- Als letzte Regel: Eingehend DROP all, Ausgehend ACCEPT all. Damit werden Anfragen von außen geblockt, es sei denn sie werden weiter oben erlaubt, der Server kann jedoch raus und z.B. Updates ziehen, DNS abfragen etc.

- Ich erstelle mir im SCP unter Optionen des Accounts Firewall Policies als Paket für einen Anwendungszweck. Dabei separiert wenn nötig (z.B. HTTP und HTTPS sind zwei getrennte Policies) und zusammen wenn sinnvoll (z.B. für eine Anwendung, die mehrere eingehende Ports oder Portranges braucht.

- Dann werden beim jeweiligen Server nur die Policies aktiviert, die nötig sind.

- Ich nutze als VPN https://tailscale.com/ , das ist auch auf jedem Server drauf. Nach der Einrichtung eines solchen VPN ist es z.B. ohne weiteres möglich, die SSH Policy zu deaktivieren, dann geht SSH nur mehr über das VPN. Wie viele 24/7 "Anklopfversuche" man sich damit ersparen kann, brauche ich wohl nicht weiter ausführen.

- Die Firewall kann zudem Verwaltungsoberflächen, die eigentlich nicht über das Internet erreichbar sein müssen, schlicht wegblocken (da braucht man gar nichts spezifisches machen). So ist z.B. der Verwaltungsport für https://dockhand.pro/ , meiner Dockerverwaltung auch nur übers Tailscale VPN erreichbar, nicht jedoch übers Internet. Das war vorher nur bedingt möglich ohne Gefahr sich selbst auszusperren. Auch das Verwaltungsinterface von https://nginxproxymanager.com/ auf Port 81 braucht nicht im Internet sein. Zudem ist es damit relativ egal, ob solch ein Interface HTTP oder HTTPS ist.

Firewalls korrekt zu konfigurieren hat schon immer grundlegendes Verständnis von Netzwerken erfordert. Ein solches zu entwickeln wird nicht nur für einen Netcup Server nützlich sein, sondern für jegliches Netzwerkgeschehen. Die Regeln, die die Netcup Firewall bietet sind absoluter Standard, das ist bei so ziemlich jeder FW so.

Alles anzeigen

Danke für die Infos, so habe ich das auch vor.
Zum Thema Tailscale - wenn man nur paar Incoming Ports zulässt wie 443/80/SSH und den Rest auf DROP hat, aber alle TCP und UDP Ports für Outgoing offen hat, funktioniert dann Tailscale problemlos? Oder muss man auch noch irgendwelche Incoming UDP Ports aufmachen?

Zitat von Zierleiste

Lt. Doku soll das so funktionieren. Würde ich auch so machen, außer deine VM hat kein IPv6 aktiviert.

Ich hatte noch einen Nachtrag in #21 vorgenommen, der ist aber lediglich Kosmetik. Ansonsten sollte alles passen. Du kannst ja nochmal einen aktuellen Screenshot deiner Regeln hier einstellen, dann können auch andere Mitglieder des Forums nochmal drüber schauen.

Sehr gut, vielen Dank. Habs gerade mal noch angepasst, so sieht es eigentlich recht gut aus, IPv6 habe ich auch noch angefügt.

So sieht es aktuell aus

firewall4.PNG

Zitat von Zierleiste

Bei den drei Regeln XXX response stateless-udp gehört die Port-Angabe jeweils in die Spalte Source Port(s) (wie auch im in #20 verlinkten Artikel beschrieben), bei Dir stehen sie momentan unter den Destination Port(s).

Ich hätte hier jetzt einen DNS-Namen erwartet für den man beispielsweise mit nslookup die Adressen ermitteln kann. Wenn Du jedoch nur eine IP-Adresse hast, dann wird das schon stimmen.

Ah danke, das habe ich übersehen und gerade angepasst. Würdest du sagen das passt jetzt soweit alles?

Damit sollte die Gefahr mit den Mail Ports eigentlich behoben sein, da ja nur die Verbindung zu dem einen Netcup Mailserver erlaubt ist.

Zitat von Zierleiste

Ich hätte hier jetzt einen DNS-Namen erwartet für den man beispielsweise mit nslookup die Adressen ermitteln kann. Wenn Du jedoch nur eine IP-Adresse hast, dann wird das schon stimmen.

Also es gibt einen DNS Namen der auch die SMTP Adresse ist (xxxxx.netcup.net) - dahinter steht auch die IP, aber eben keine IPv6. Ich hab diese über nslookup nun rausgefunden, macht es denn Sinn die auch noch einzutragen? Kann ich die einfach mit Komma hinter die IPv4 packen?

Zitat von Zierleiste

Der Mail_01-Abschnitt deiner Regeln schaut für mich plausibel aus, wobei ich nochmals nachhaken möchte, ob dein Mail-Server nur eine einzige IP-Adresse besitzt, oder beispielsweise auch über IPv6 erreichbar ist.

Also im Netcup Backend für das Hosting Paket, indem auch der Mailserver ist, wird mir nur diese IP angezeigt. Beim Webserver wird mir auch eine IPv6 Adresse angezeigt. Ist das ein Problem wenn ich nur diese IP angebe? Außer eben dass ich regelmäßig checken sollte, dass diese noch aktuell ist.

Zitat von Zierleiste

Im Moment werden aber ausgehend sämtliche UDP-Pakete verworfen, also insbesondere DNS und NTP. Bei DNS ist das kein Problem, falls Du nur die netcup-DNS-Server benutzt. Bei NTP hingegen wirst Du erst nach einiger Zeit feststellen, dass die Systemzeit deines Servers von der korrekten Zeit abweichen wird.

Okay, danke nochmal für den Hinweis. Ich hab gerade mal etwas dazu nachgelesen. DNS habe ich bei diesem Server tatsächlich die Netcup Server, aber auch andere Server wo ich die Firewall vielleicht awenden möchte. Wie müsste ich dies denn hier als Regel freigeben, dass ich keine Einschränkungen (und auch keine Sicherheitsprobleme) habe? Einfach Ausgehend -> ACCEPT -> UDP -> All?

Und Thema NTP war mir bisher noch nicht richtig bekannt. NTP läuft wie ich nachgelesen habe auch über UDP, wenn ich hier alles zulasse, soltle das auch hier dann keine Probleme geben, richtig?

Ich hab jetzt auch mal noch Eingehende Regeln erstellt, habe eigentlich nur SSH und die Webports bei den meisten Servern. Habe mich an dem verlinkten Post orientiert (RE: Ab sofort: Firewall für netcup vServer verfügbar)

Das sollte soweit passen, oder habe ich irgendwas übersehen/vergessen?

Vorteil ist halt hier auch, dass andere Ports dann auch wirklich zu sind, wir hatten z.B. auch schonmal das Docker Ports in ufw überschrieben/aufgemacht hat, sowas kann jetzt ja nicht mehr passieren.

firewall3.PNG

Danke nochmal für die Hilfe!

Zitat von terence

Zum Beispiel wie von NaN vorgeschlagen: Du erstellst eine Policy, die ausgehend TCP und UDP für alle Ports zulässt und fügst sie nach Deiner Mail-Policy ein. Oder Du definierst entsprechende Policys für genau die Ziele, die Dein Server erreichen können muss, wie beispielsweise Update-Mirrors. Da gilt dann aber halt, was weiter oben schon gesagt wurde: Falls sich die IP-Adressen ändern, müssen die Regeln angepasst werden. Da ist es dann sinnvoll, ein Skript zu schreiben, welches regelmäßig prüft, ob sich die Adressen geändert haben.

Zitat von tab

Im konkreten Fall eines ein oder ausgehenden IP-Pakets wirklich verwendet werden kann nur eine spezifische Regel. Oder gar keine, dann gilt eben die Default-Policy. Insgesamt können natürlich mehr Regeln verwendet werden, je nach IP/Port/Protokoll eben immer die erste, die für das betreffende Paket greift. Das kann dann auch mal die zweiundvierzigste Regel sein.

Danke für eure Antworte, das war sehr hilfreich.

Ich habe nun mal etwas probiert und ich glaube so sollte es passen. Ich habe nun Port 25 und Port 587 geblockt und Port 465 nur für die IP des Netcup SMTP Server freigegeben (hab die genaue IP mal geschwärzt). So sollte es doch korrekt sein oder?

Ich habe es getestet und der Nodemailer funktioniert auch. Habe auf dem VPS auch mal "nc -vz IP 465" ausgeführt und kam dann auch nur bei der IP
"...465 port [tcp/submissions] succeeded!"

Die drop Regel nach dem Zulassen des 465 Ports für die IP musste ich auch noch einfügen, da sonst alle Ports offen waren und die Regel für 465 Port für die IP nicht gegriffen hat.

Damit sollte ich dann eigentlich auch in gar keine Probleme laufen weil eben nur die IP benutzt werden kann.

Zitat von NaN

Genau so ist das gedacht. Wenn du Mail verschicken willst, machst du dir die nötigen Gedanken, welche Konsequenzen das haben kann, und schaltest das dann selbst in der Firewall idealerweise so eng eingegrenzt wie möglich frei. Die Sperrung ist nur die Voreinstellung, als Schutz für und vor Kunden, die sich keine Gedanken darüber gemacht haben.

Die Regeln werden von oben nach unten abgearbeitet, bis eine Regel passt. Das heißt, wenn du eine Sperre für bestimmte Ports einrichtest, kannst du danach einfach alle ausgehenden Verbindungen erlauben, ohne dass das die gesperrten Ports wieder öffnet. Dann hast du default-allow mit einzelnen gesperrten Ports, was ausgehend meistens praktikabler als default-deny mit explizit erlaubten Ports ist.

Zitat von tab

Habe das Eingangsposting gerade nochmal gelesen. Du brauchst Port 25 ja gar nicht. Port 465 erfordert sowieso zumindest eine Authentifizierung bei deinem netcup-Mailserver. Prinzipiell bei einem Server mit einem gehackten Root-Zugang natürlich ein lösbares Problem . Aber zumindest irgendwie eingeschleuste Malware, die ohne Root-Rechte funktoniert, hätte es dann eventuell nicht ganz so leicht.

Du könntest den entsprechenden per Default gesetzten Block für Mail ausgehend also in der Firewall durch einen eigenen ersetzen. Mit den selben Regeln, aber eben nur für die Ports, die du nicht benutzt, insbesondere also Port 25.. Den Default-Block (ausgehend) kannst Du dann löschen und Port 25 und eventuell 587 bleiben trotzdem blockiert.

Danke für Eure Hilfe.

Ich hab gerade mal probiert das in der Netcup Firewall einzustellen, hab davor mit UFW das auch getestet, die Ports 25 und 587 bockiert und nur 465 freigeben, das hat geklappt und konnte mit Nodemailer die Mails verschicken.

Nun wollte ich das übertragen in die Netcup Firewall, jetzt wird der Nodemailer aber blockiert, ich hab das so eingestellt.

firewall.PNG

Sollte das nicht gehen nun? Jetzt sollte Ausgehend alles blockiert sein bis auf 465, oder? Warum verbindet er dann nicht?

Und wie implizierte Regel ist nun auch auf Drop gesprungen bei Ausgehend, das heißt dann ja das alles geblockt ist. Ich komm auch nicht mehr raus (außer mit ping). Wie kann ich denn jetzt wieder den Rest zulassen?

Wie ist das zu verstehen mit Regelen werden von oben nach unten angewendet? Mach Drop all dann nicht wieder den Port 465 bei der Implizierten Regel dicht?

Zitat von tab

Das wird mittlerweile bei sehr vielen Anbietern per Default blockiert. Ich denke, das ist teilweise auch ein wenig als Schutz für den Kunden und vor allem als Selbstschutz des Anbieters gedacht.

Wer zwingend Mails direkt von seinem Server versenden und/oder auch darüber empfangen will oder muss, der kann sich - zumindest hier bei netcup -die Ports mit 1-2 Klicks in der Firewall wieder freischalten.

Anderswo muss man zumindest Port 25 augehend teilweise über den Support freischalten lassen. Damit trägt er dann auch die Verantwortung für eventuelle Folgen, die von Missbrauch seines Servers - durch den Kunden selbst oder Hackern - verursacht werden. Die trägt er zwar sowieso immer, aber hier dann eben explizit nochmal ganz besonders für vesendeten Spam und die Folgen, was mit blockierten Port 25 in der Anbieter-Firewall nicht so leicht passieren würde.

Wer als Kunde seinen Server nicht für Mail verwndent will und die Default-Einstellung für die Mail-Ports belässt, der hat zumindest die Sicherheit, dass sein Server - auch wenn er gehackt wird - jedenfalls keine Spam-Mails direkt vom Server über Port 25 verschicken wird.

Und um den Selbstschutz des Anbieters noch etwas auszuführen, ein so geschützter Server wird somit auch nicht sein gesamtes Subnetz auf irgendwelche DNS-Blocklisten oder gar interne Listen von MS, Google & Co katapultieren. Damit entfällt für den Anbieter die Arbeit, das Problem zu beheben und sich danach noch mit mit z.B. Microsoft rumschlagen zu müssen, um das Subnetz zeitnah wieder entsperrt zu bekommen.

Danke für die ausführliche Antwort.

Ich verstehe das natürlich und würde die Ports auch nicht freigeben, wenn nicht nötig. Aber da über die Website per Nodemailer E-Mails über ein Formular versendet werden müssen, sehe ich hier auch kein anderen Weg. Außer evtl. den Port dann nur für die jeweilige Domain des SMTP Server freizugegeben die der Mailer benutzt.

Zitat von Zierleiste

In erster Linie will man mit einer Firewall seinen Server vor externen Zugriffen schützen und öffnet daher eingehend nur die Ports, die man wirklich benötigt. Ausgehender Traffic wird erst dann relevant, wenn der Server missbraucht wird. Meistens ist daher ausgehend jeglicher Traffic erlaubt, ausgenommen SMTP, was netcup per Default blockiert. Natürlich kannst Du auch ausgehend nur gezielt die Ports öffnen, die wirklich benötigt werden, aber dafür müsstest Du genau Bescheid wissen über jede Komponente des Betriebssystems.

Zu beachten ist, dass die netcup-Firewall den Default „ausgehend ist alles erlaubt“ wechselt auf „ausgehend ist alles verboten“, sobald Du eine eigene ausgehende Regel definierst (dies gilt separat für TCP und UDP und analog für eingehenden Traffic).
Ich habe es bei meinen Servern nicht gemacht.

Im Prinzip möglich, aber: Normalerweise sprichst Du einen Mailserver über seinen DNS-Namen an. Ändern sich die hinterlegten IP-Adressen (das können ja mehrere sein, insbesondere IPv4 und IPv6), stimmen deine Firewall-Regeln nicht mehr.

Okay verstehe. Dann ist vermutlich der einfachste weg, ich entferne die Regel von Netcup für die SMTP Ports und lasse damit dann allen Outgoing Traffic zu. Sonst kann ich den Nodemailer ja auch nicht nutzen. Wenn ich dann eigene Regeln wieder hinzufügen würde z.B. die SMTP Ports blocken, die ich nicht nutze, müsste ich ja auch sonst alle anderen Outgoing Ports wieder hinzufügen, das wäre vermutlich recht kompliziert. Oder gibts da ein anderen Weg die vordefinieriten SMTP Ports zu bearbeiten? Ich habe keinen gefunden bei mir.

Und generell, macht es Sinn die Netup Firewall als primäre Firewall zu nutzen und UFW garnicht mehr zu nutzen? Beide zu nutzen finde ich etwas blöd da man dann vielleicht leicht irgendwelche Regeln in der anderen vergißt/übersieht und immer beide aktuell halten muss.

Zitat von Zierleiste

Das ist schon mal gut.

Nein, das ist der Webserver.

Doch, per Default ist normalerweise ausgehend alles offen. Außerdem könntest Du sonst keine E-Mails versenden.

Ich empfehle Dir, folgenden Artikel zu lesen und dann die netcup-Firewall einzuschalten: RE: Ab sofort: Firewall für netcup vServer verfügbar

Danke dir für die Rückmeldung.

Den Artikel bin ich gerade durchgegangen. Bei der Konfiguration TCP-Server-Dienste im Artikel geht es aber ja "nur" um Eingehende Verbindungen, das macht sicherlich Sinn das einfach auch noch zusätzlich zur UFW zu aktivieren.

Aber wie sieht es mit Ausgehenden Verbindungen aus? Im Artikel sind hier alle zugelassen,

Das heißt dann aber dass alles SMTP auch offen sind. Richtig? Das wäre soweit auch in Ordnung?

Theoretisch bräuchte ich nur Port 465 für den SMTP Versand, und zwar geht dieser über nen Netcup Mailserver den ich in nem Webhosting Paket habe. Würde es Sinn machen, dass ich den Port dann nur für diese Domain/IP freigebe (wenn das geht über die Firewall)?

Zitat von salzigessalz

geht darum Spam zu vermeiden der (manchmal auf unbewusst) entsteht z.B. durch nen gehackten Server. UFW ist super, nur das Filtert auf zusätzlicher Ebene nochmals ab auch ein UFW kann ausfallen.

Hast du das Standard Ruleset drin bei UFW ? Da wäre allow outgoing drin, daher musst du explixit nicht SMTP Ports freigeben.

Danke für die schnelle Antwort.
Okay das macht Sinn.

Ich hab bei UFW alles erstmal geblockt mit "deny all" und dann eben nur die 3 Ports freigebenen (443/80/SSH). Meines Wissens bedeutet das dass nur die 3 Ports für Incoming Traffic offen sind, richtig?
Outgoing sollten alle Ports offen sein, oder?

So stehts auch bei ufw status verbose: Default: deny (incoming), allow (outgoing), deny (routed)

Bisher hatte ich allow outgoing auch immer so, ist das denn ein Problem, oder sollte ich hier noch etwas blocken?
Ich hatte mir notiert zur Servereinrichtung dass es vorallem in UFW wichtig ist die incoming Ports zu blocken und nur das freizugeben was wirklich offen sein muss.

Hallo Forum,

ich habe eine kurze Frage. Habe ein RS1000 kürzlich geholt und war mir nicht bewusst dass die SMTP Ports in der Firewall im SCP automatisch geblockt sind.

Ich hab eine NestJS Website mit Ngnix und Nodemailer und konnte keine Mails versenden, bis ich auf die Ideen gekommen bin, dass die Netcup Firewall den SMPT Port (465) blockieren könnte. Nachdem ich die Firewall ausgemacht habe, hat es nunr auch geklappt mit dem Mailversand mit Nodemailer.

Den Server habe ich soweit abgesichert, nur Login mit SSH Key, mit UFW alle Ports geblockt außer 443 / 80 für Web und Custom SSH. Mailversand geht trotzdem, ich vermute weil das über Ngnix läuft? Die SMTP Ports sind aufjedenfall nicht offen in UFW.

Nun meine Frage, warum die Ports in der Netcup Firewall standardmäßig blockiert sind? Welchen Grund hat das?

Und hab ich irgendwie ein Sicherheitsrisiko wenn ich die SMTP Ports nicht über die Netcup Firewall blocke? Wenn die Ports in UFW zu sind, ist das doch auch okay, oder?

Zitat von heppel

Mach Dir nicht zu viele Sorgen. Es gibt einen Bug in der Firmware von AMD Zen 5 Prozessoren, der unter bestimmten Umstaenden dazu fuehrt, dass die RDSEED CPU-Instruktion den falschen Wert 0 liefert, aber per Statusbit behauptet, der Wert sei gueltig.

Die Meldung, die Du siehst, besagt, dass Dein Kernel so eine Situation bemerkt hat, und das Featurebit fuer RDSEED in der CPUID abgeschaltet hat. Er stellt also einen sichereren Zustand fuer Dich her. Zufallszahlen koennen diese Prozessoren mit Hilfe der RDRAND-Instruktion trozdem erzeugen.

Der Vollstaendigkeit halber: https://www.amd.com/en/resources/p…md-sb-7055.html

Okay prima, das heißt ich kann den Server problemlos nutzen, und ich habe, auch wenn der Bug weiter besteht, keine wirklichen Einschränkungen, da ich Zufallszahlen auch mit einer anderen Instruktion erzeugen kann?

Wenn das dann gefixed wird, kann ich das aber vermutlich nicht selbst updaten, oder?

Und kurze Frage wenn ich hier schon Experten habe, welches Debian 13.4.0 Image - Bios oder gleich mit UEFI?

Zitat von andreas.

Und wie verhält sich deine VM, wenn du den Kernelparameter von der Reihenfolge wie folgt setzt?

GRUB_CMDLINE_LINUX_DEFAULT="rdseed=0 quiet"

und dann die VM mit dem Befehl poweroff herunterfährst und danach neu startest?

In einer VM emuliert der Hypervisor die Hardware. RDSEED ist eine echte CPU-Funktion des physischen Prozessors und VM´s haben keinen direkten Zugriff auf echte CPU-Features wie RDSEED.

Was ist RDSEED? RDSEED ist eine CPU-Instruction, die vom Prozessor echte Zufallszahlen aus physikalischen Quellen erzeugt, anstatt pseudo-zufällige Zahlen zu berechnen.

Wenn RDSEED auf dem Hypervisor defekt ist, können folgende Probleme für die VM entstehen:

• Sicherheitsrisiko: Kryptografische Schlüssel könnten vorhersagbarer sein.
• Performanceeinbußen: Der Kernel muss auf langsame Software-RNGs ausweichen.
• Potenzielle Blockaden: Bei hoher Last kann /dev/random blockieren, wenn nicht genug Entropie verfügbar ist.

Alles anzeigen

Ich bin noch nicht dazugekommen das mit den Kernelparamtern zu testen und hatten auch gehofft dass der Netcup Support mir Hilfe geben kann, da ist aber seit einer Woche Funkstille (leider).

Zum Test habe ich aber mal Ubuntu 24.04.4 aufgespielt, hier wird mir der Fehler nicht angezeigt. Ich war halt bisher immer auf Debian unterwegs da nach meine Recher das am besten für VPS ist.

Ich habe Grundkenntnisse in Linux und Severadministration, weiß jetzt aber nicht wie "kritisch" es ist wenn RDSEED nicht auf dem Server funktioniert und überlege ob ich diesen daher widerrufen soll. Wie groß könnte hierdurch ein Sicherheitsrisiko sein oder auch potentielle Anwendungen die ich auf dem Server laufen lasse?

Zitat von notfound404

4 Tage? Ich warte seit über einem Monat Häufige Ausfälle SMTP Webhosting Zwischenzeitlich gab es nur eine sinnfreie - wohl von K"I" erstellte - Info

Oh das ist ja bitter, das ist natürlich viel zu Lange. Bei mir kam bei der Frage zum schnelleren Einlösen im CCP glaube auch eine KI Antwort, bzw. mit so Baukasten-Sätzen ohne wirkliche Hilfe.

Also kann ich mich wohl auf längere Wartezeit einstellen, schade.

Hallo Forum,

gibt es aktuell irgendwelche bekannten Verzögerungen beim Support? Ich habe zwei Anfragen am Sonntag gestellt - bei beiden habe ich nach einem Tag eine Antwort bekommen, dass sich darum gekümmert wird, aber jetzt sind schon 4 Tage vorbei und ich habe für beide Fragen noch keine Antwort/Lösung.

Bei der einen Frage ging es darum, dass ich ein Server im Forum übernommen habe, aber den Code nicht eingeben kann weil ich noch eine offene Lastschriftrechnung habe. Ich habe natürlich keinen Einfluss darauf wann die Lastschrift abgebucht wird und habe darum gebeten das zu beschleunigen oder evtl. auch manuell freizuschalten, dass ich im CCP den Code eingeben kann. Der Server ist nun seit 5 Tagen ungenutzt und ich bräuchte den dringend für ein Projekt.

Die zweite Frage war zum Thema dass ich hier erstellt habe, dazu hätte ich gerne noch Rückmeldung von Netcup direkt selbst gehabt. RE: Debian 13 - Boot Meldung "RDSEED32 is broken"

Nun meine Frage, ob das normal ist dass man so lange auf Antwort warten muss? Gerade Punkt 1 mit dem Server Umzug wäre für mich wichtig da ich den Server die Woche noch gerne zum Laufen bringen würde.

Zitat von andreas.

Es gibt noch eine Alternative: Wenn der o.g. Befehl bei einer VM nicht funktioniert, so könnte auch der Kernelparameter rdseed=0 in der Datei grub zur Umgebungsvariable GRUB_CMDLINE_LINUX_DEFAULT hinzugefügt werden. Denn damit wird zwar das ursprüngliche Problem nicht gelöst, welches auf dem Hypervisor zu suchen ist, aber die o.g. Ausgabe wird während des Systemstarts zukünftig unterbunden.

Okay verstehe, das wäre dann nur um die Meldung eben nicht mehr anzuzeigen.

Ich habs gerade mal probiert und eingefügt bei GRUB_CMDLINE_LINUX_DEFAULT="quiet rdseed=0"
Danach habe ich gemacht.

sudo update-grub
sudo reboot

Seltsamerweise wird die Meldung immernoch beim Booten angezeigt.

Ich weiß nicht ob ich das RDSEED überhaupt brauche, bin damit noch nie in Kontakt gekommen. Wenn ich ein Server aber neu aufsetze der lange Zeit halten soll, wollte ich halt alles richtig machen.

Zitat von andreas.

Diese Meldung [0.084436] RDSEED32 is broken. Disabling teh corresponding CPUID bit ist kein kritischer Systemfehler – sie wird lediglich als Warnung ausgegeben.

Der Linux-Kernel hat erkannt, dass deine CPU bzw. der RDSEED-Befehl fehlerhaft ist und entsprechende Funktionen deaktiviert.

Abhilfe könnte aufgrund einer fehlerhaften Firmware der Befehl apt upgrade linux-firmware bringen.

Okay, danke für die Antwort, dann ist das also kein kritisches Problem. Anscheinend kann bei virtualisierten CPUs RDSEED durch den Hypervisor falsch durchgereicht werden, aber da kann ich ja nichts machen. Oder?

Zitat von Mordor

Wie willst Du auf einem VServer denn Firmware Updates einspielen?

Und den Befehl "apt upgrade linux-firmware" habe ich gerade probiert, aber scheint nicht zu gehen.