Beiträge von m_ueberall

Zitat von jah

• Warum sollte netcup keine Details preisgeben? Gibt ja nur zwei Möglichkeiten, das Problem zu beheben. Aus dem zweiten Post von Christina kann man ja schon schließen, daß als erste Maßnahme das "chicken bit" gesetzt wurde und die ucode-Updates später kommen.

Es gibt grundsätzlich drei Möglichkeiten (die dritte wurde ebenfalls angedeutet im vorgenannten zweiten Post), aber Details (lies: warum/wann welche Möglichkeit gewählt wird) würden Rückschlüsse auf die von Netcup verwendeten Dienstleister (Linux-Distribution, Hardware) erlauben; hierzu wurden auch in der Vergangenheit keinerlei Aussagen mit Ver­weis auf das "Be­triebs­ge­heim­nis" getroffen, wie man in diesem Forum (oder an anderer Stelle, wo beispielsweise der frühere Geschäfts­führer aktiv war) nachlesen kann.

Diese gibt kein größerer Anbieter heraus und bis auf die Tatsache, dass Exploits nicht mehr funktionieren, können sie insbesondere Nutzern von VPS (welche nur eine Teilmenge der CPU-Features nutzen können und bei deren Angeboten die Verwendung einer konkreten CPU auch nicht im Vertrag steht) auch dann egal sein, falls hier eine Migration auf neuere/andere Systeme stattfindet.

Zitat von jah

Was ist das für ein Server?

Die Ausgabe stammt von einer RS-KVM-Instanz, die auf einem nclabs-Host läuft.

DerRené : War dieser Post als Antwort für RAD750 gedacht?

Zitat von jah

Könnt Ihr sagen, wie das gefixt wurde? uC-Update wäre naheliegend, aber bei laufendem System wohl nicht einfach so machbar. Oder wurde erstmal nur das o.g. chicken-bit gesetzt?

Wenn auf dem Host keine "EPYC Rome"-CPU zum Einsatz kommt, gibt es noch kein Microcode-Update von AMD, siehe hier. Und Netcup wird sicherlich keine eigenen Microcode-Updates einspielen. Allerdings hat Netcup eben auch vorgenannte CPU-Modelle im Einsatz. Details werden sie aber wohl eher nicht preisgeben.

[2023-07-26T09:21:56+0200] root@vserver02<kvm>:~# canonical-livepatch status --verbose | sed -e 's|\(machine.*\) \(.*\)|\1 (protected)|g' | head -7
client-version: 10.6.0
machine-id: (protected)
architecture: x86_64
cpu-model: AMD EPYC 7452 32-Core Processor
last-check: 2023-07-26T09:15:00+02:00
boot-time: 2023-07-19T14:05:09Z
uptime: 161h16m51s
[2023-07-26T09:22:01+0200] root@vserver02<kvm>:~# dmidecode|grep -iE 'Vendor:' -A2
        Vendor: SeaBIOS
        Version: 1.15.0-1~nc11+3
        Release Date: 04/01/2014
[2023-07-26T09:22:03+0200] root@vserver02<kvm>:~# 

skyslycer : Normalerweise formuliert man eine Content-Security-Policy so restriktiv wie möglich. Aktuelle Browser sollten auf der Konsole mitteilen, welche Verstöße gegen die aktuelle Policy erkannt wurden; auf dieser Basis kann man dann Ergänzungen vornehmen. Ohne Wissen um die konkrete Summe aller verwendeten Webseiten ist hier aber keine Hilfestellung möglich. Bei Verwendung von spezifischen Applikationen finden sich vielleicht in zugehörigen spezialisierten Foren oder der Dokumentation entsprechende Anforderungen bzgl. der jeweiligen Policy.

Gegebenenfalls hilft es, wenn man verschiedene Anwendungen an eigene Unterdomänen "bindet", um hier mit alternativen CSP-Definitionen arbeiten zu können.

EDIT: Neben der Webbrowser-Konsole gibt es auch spezialisierte Plugins, welche damit werben, Policies zu generieren, vgl. bspw. Policy Generator (bislang nicht selbst ausprobiert).

Zitat von [netcup] Claudia H.

Vielen Dank für deine Frage. Diese habe ich so ans entsprechende Team weitergegeben. Sobald ich mehr Infos dazu habe, werde ich hier ein Update geben.

[netcup] Claudia H. : Gibt es hierzu schon zeitnah Neuigkeiten, nachdem die aktuellen VPS-/RS-Angebote wieder mit dem Hinweis "Die Standortauswahl erfolgt automatisch" ohne zusätzliche Erläuterung beworben werden? Kaum vorstellbar, dass alle Bestandskunden hier blind ordern …

Zitat von NaN

Du lässt ja auch nicht alle Programme als root laufen, obwohl die das, was über die Rechte eines normalen Users hinausgeht, einfach sein lassen könnten. Meine Fritzbox, Wetterstation, Webcam, Waschmaschine, Staubsauber, Kühlschrank, UPS, Kontaktformular, etc. müssen halt nicht Mail an irgendjemanden als an mich schicken können.

Grundsätzlich können sie das – oder besser gesagt ein Nutzer, welcher dort eindringt oder das Gerät dazu bringt, Befehle für ihn auszuführen – aber, selbst ohne Root-Rechte. Wie einfach das ist, wenn nur Zugriff auf eine Shell besteht, zeigt etwa dieses Script: How to send e-mail from bash. Das geht auch problemlos am eigenen Mail-Gateway vorbei (wodurch die Verwendung/Kontrolle von SPI/DKIM/DMARC auf Domäneninhaber-/Empfängerseite als Schutz fungieren kann), erlaubt aber dennoch grundsätzlich die Verwendung einer beliebigen, ggf. zuvor ermittelten Domäne. Denn mit Shellzugang kann man beliebige Funktionalität einschleusen (Stichwort Turing-Vollständigkeit).

Dies zu unterbinden gelingt nur durch eine Firewall, die diesen Geräten jeglichen Kontakt von "innen" nach "außen" verwehrt, der nicht über ein Gateway läuft, welches ggf. mittels Stateful Packet Inspection (SPI, also zustandsorientierte Paketüberprüfung) potenziell zulässige Kommunikation genauer unter die Lupe nimmt. Und diese muss vor oder auf der vorgenannten Fritzbox stehen und die gesamte Kommunikation überwachen können, wenn es um die Absicherung des heimischen Bereichs geht. Ein Dienstleister wie Netcup steht hierfür schon "zu weit weg".

layd : Die Bereitstellung eines Add-ons – zumal nicht nur für Thunderbird, sondern auch für Outlook – dürfte etwas zu viel Aufwand bedeuten.

Die Möglichkeit, SPF/DKIM/DMARC zu verwenden sowie zumindest eigene (E-Mails mit angehängten) Rechnungen zu signieren ist sicherlich gegeben und einige Dienstleister machen hiervon auch Gebrauch. (Ob diejenigen Nutzer, welche bislang auf Phishing-E-Mails hereingefallen sind, von diesen zusätzlichen Regeln profitieren würden, lasse ich einmal dahingestellt – ein Blick ins CCP zeigt doch den maßgeblichen Stand der laufenden Verträge an, wenn dieser sonst nirgendwo hinterlegt ist. Und diese zwei Minuten sollte man immer investieren.)

Andererseits ist es auch von Kundenseite her recht einfach, von Anfang an eine E-Mail-Adresse zu hinterlegen, welche ausschließlich in Verbindung mit Netcup-Verträgen/-Rechnungen zum Einsatz kommt. Bislang ist hier noch keine einzige Spam-/Phishing-E-Mail eingetrudelt, welche diese verwendet. Und alles, was nicht im korrekten Ordner (dank E-Mail-Adressen-Filterregeln) landet, wird einfach ignoriert, Punkt.

Zitat von perryflynn

Würde mich freuen, wenn Ihr das Ganze mal auf unterschiedlichen Plattformen testen könntet.

Keine riscv64-Binaries? (Ok, zugegeben, dafür habe ich auch nur eine emulierte Umgebung, bis es endlich passende Hardware für Homeoffices gibt …)

EDIT1: Versionsnummern im Dateinamen wären ggf. von Vorteil, sofern nicht gewährleistet ist, dass es sich immer um die aktuelle Upstream-Version handelt.

EDIT2: Aha, sie stehen in der info.txt-Datei, die niemand liest (der hier vor der Tastatur sitzt).

[netcup] Claudia H. / Moderatoren : Es wäre schön, wenn die FAQ zu den Aktionen auch eine deutliche Erklärung enthielte, was unter "Automatische Standort Auswahl" in der Produktbeschreibung zu verstehen ist (d.h., ob Netcup hier berücksichtigt, dass ein Bestandskunde Rechner ausschließlich an einem Standort gebucht hat und VLAN-Verbindungen und Failover-IP(-Netze) nicht zwischen verschiedenen Rechenzentren schaltbar sind – Wie wird hier verfahren? Es wäre nämlich dämlich, einen am falschen Standort platzierten RS gleich wieder kündigen zu dürfen, weil er nicht in Verbindung mit bereits gebuchten Produkten nutzbar ist.)

Zitat von tab

Gibt es eigentlich noch einen Hersteller, der (zum Schreiben) benutzbare Tastaturen herstellt? MS war halbwegs vernünftig benutzbar, aber die Buchstaben auf den Tasten sind nach etwa einem Jahr nicht mehr lesbar.

Das ist natürlich ein Feature – entweder man ist in der Lage, innerhalb eines Jahres blind zu tippen, oder sonst (lernt man es ganz schnell). Es gibt unbeschriftete Keyboards, die viel teurer sind und dieses hilfreiche Feature nicht mitbringen!

Der Domänenname gehört nicht in die Spalte "Host". Für eine Subdomäne "sub1.example.org" würde in der Host-Spalte lediglich "sub1" stehen. Für die Domäne "example.org" selbst würde die Host-Spalte ein "@" (Platzhalter für den reinen Domänennamen) enthalten. Das ist so auch im Netcup-Wiki dokumentiert.

(Erklärung: Der Domänenname wird intern immer automatisch angehängt. Der aktuelle TXT-Eintrag für "xxxxxx.de" sollte dementsprechend derzeit unter "xxxxxx.de.xxxxxx.de" abrufbar sein.)

Zitat von NaN

Ist mail.example.com wirklich bei Korea Telecom? Ist das ein externer Server oder ein Mailserver von Netcup oder dein eigener?

Zitat von Bud

What. Wo kommt das denn her?

Die Nutzung öffentlicher IP-Adressen zur Anonymisierung ist so ungünstig wie die Nutzung von Nicht-Beispiel-Domänennamen (anstelle von bspw. example.org) :

pasted-from-clipboard.png

Zitat von Virinum

Sollte jetzt nochmal jemand gesperrt werden, weil er helfen wollte, wäre das sehr peinlich.

Und mit einer Abstimmung für Netcup bei der nächsten "Hoster des Jahres"-Veranstaltung unvereinbar, um es einmal deutlich zu sagen.

Zitat von ArtCore7

[…] Somit bist du ziemlich sicher vor Bruteforce und auch Erpressung gegen deine Person, da du das Passwort ja auch nicht kennst. […]

Als ob ich Versicherungen vertrauen würde, das Passwort sei unbekannt:

https://imgs.xkcd.com/comics/security.png

Tip: Das "Rauskommen" ist bei manch( ander)en telnet-Tests ein Problem; hier nutze ich allgemein immer gerne timeout 10 telnet ip-des-nodes 4949 o. ä.

Zitat von Telly

ich habe für meine Domain erfolgreich SPF & DKIM eingerichtet, nun fehlt nur noch DMARC. Zu letzterem habe ich mich schon ein wenig eingelesen, habe aber noch ein paar kurze Fragen. […] Freue mich über Feedback!

1. Ja, es ist keine gute Idee. Insbesondere, wenn man auf größeren Mailinglisten aktiv ist.
2. Es kann eine beliebige E-Mail-Adresse sein. Ich verwende gerne "dmarc@". "postmaster@" wird wahrscheinlich häufig verwendet, weil sie laut RFC vorgeschrieben ist. (Filtern kann man ja immer, vgl. 4)
3. Das ist durchaus sinnvoll für erste Tests. Bei Unternehmensdomänen würde ich mit der Umstellung ggf. allerdings nicht lange warten.
4. Genau so handhabe ich das auch.

noone1 : Please remember that this is a customer forum, we (fellow customers) cannot help you with the above. You need to directly contact the customer support (either by email or phone).

Zitat von friend_of_root

Das ist eine tolle Antwort, die mich noch eine Weile beschäftigen wird

Lets encrypt SSL Challenge würde mit 2 A Records funktionieren?

Natürlich, wenn die Antwort stimmt. Vgl. etwa Will Let’s Encrypt work for me? (Multiple servers serving one domain). Alternativ kann man auch entsprechende Schlüssel für die DNS-Challenge hinterlegen, wie es für Wildcard-Zertifikate sowieso unabdingbar ist, die ich beispielsweise im Intranet einsetze (funktioniert einwandfrei bei deSEC).

Zitat von friend_of_root

Das finde ich spitze.. aber was genau meinst du.. wie kann das mit 2 redundanten VPS-KVM-Instanzen klappen?

Ich hatte schon so ein Setup bei dem der 1. RS die IP für das A Record der verweisenden Domains stellte, sowie die Let's Encrypt SSL Zertifikate ermöglichte. Darauf lief ein Nginx als Reverse Proxy, der alle Anfragen auf einen 2. RS dahinter weiterleitet... umgesetzt war das mit Nginx Proxy Manager.
Das hat mir sehr gut gefallen, allerdings dachte ich dann, dass man mit der Abhängigkeit von noch einem Server weit mehr als die doppelte Ausfallwahrscheinlichkeit hat.

Und diesem vorgenannten "1. RS" kann man einfach einen Zwilling an die Seite stellen, wobei alle Domänen im einfachsten Fall eben zwei öffentliche IP-Adressen erhalten (genau die der Gateways). Fällt einer aus, werden Clients heutzutage in der Regel einfach die andere IP-Adresse probieren (gerade beim https-Protokoll). Eine Sitzungsverwaltung sollte sicherstellen, dass einmal aufgebaute Sessions bei einem Gateway bleiben ("sticky sessions"), alternativ können sich diese auch gegenseitig über die gültigen Sitzungen austauschen. "Round Robin DNS" sorgt hier schon einmal für eine initiale Lastverteilung zwischen den Gateways. Einschlägige mächtigere/komplexere Softwarelösungen wie HAProxy sind eigentlich auch gut dokumentiert.

Sofern man Dienste im "Multi-Master-Betrieb" in einem Cluster installiert, kann man auf zusätzliche Gateways mbMn ggf. aber auch einfach verzichten – denn wenn die Clients immer mehrere IP-Adressen zur Auswahl haben, ist es nicht sonderlich schlimm, wenn sich einmal ab und zu eine ändert.

(Der Vorteil aller vorgenannter Ansätze gegenüber Failover-IPs liegt bzgl. Dienstleister-Unabhängigkeit auf der Hand.)

Zitat von friend_of_root

Viel, viel besser wäre, wenn man eine bestehende Server IP mit Aufzahlung zur Failover-IP machen könnte!
Oder mit zB 30 Euro Einmalgebühr 1xmal umsiedeln.

Wenn es darum geht, eine IP-Adresse langfristig beizubehalten – warum dann nicht zwei kleine VPS-KVM-Instanzen (Redundanz!) als Gateways davorhängen? Solange das Transfervolumen überschaubar ist, hat man hiermit eine relativ günstige, flexible Alternative (die hinreichend ausfallsicher sein sollte – ggf. rechnen sich hier auch kleine RS, welche von dem zubuchbaren "Root-Server Service Level A+" abgedeckt wären). Als Seiteneffekt hätte man damit auch die Möglichkeit, (später) ein transparentes Load-Balancing einzuführen.