Meine Server (ebenfalls Standort NUE) waren von der gestrigen Abschaltung/Ausfall NICHT betroffen. Habe davon nur hier im Forum gelesen.
Mir wird nun aber ein KVM-Update im SCP angeboten, welches ich soeben durch Ausschalten + wieder Einschalten der Server angewendet habe.
Möglicherweise besteht also ein Zusammenhang zwischen KVM-Update und euren Ausfällen ... scheinbar wurde ja jedenfalls am Hypervisor was geändert.
Hatte Netcup mir da aus versehen kurz eine andere (nicht meine) vdisk angeschlossen?
Ich sehe da kein Indiz für eine angeschlossene Disk.
Diese Speed-Messungen macht dieser raid6-Treiber doch vermutlich bei jedem Neustart?
Welche Arbeitsleistung steckt denn in so einem Setup?
Ist eine ernst gemeinte Frage!
Die Gründe (explodierende, unkalkulierbare Hardware-Kosten bei RAM/NVME durch die AI-Spekulationen) sind im verlinkten Artikel eigentlich nachvollziehbar dargestellt.
heißt aber auch ich kann mit src port 53 alle deine udp services nutzen.
Ja. Alle Nameserver die der eigene Resolver abfragen könnte als Source-IP-Adressen in der Firewall einzutragen ist nicht bewerkstelligbar. Den Aufwand das auf einzelne IP-Adressen zu beschränken kann man sich aber machen, wenn man nur well-known-resolver verwendet (z.B. 1.1.1.1, 8.8.8.8, ...) aber selbst keinen Resolver der interatives Lookup durchführt betreibt.
Falls jemand einen VPS Nano, Piko oder Lite1 in Wien erhält würde ich diesen übernehmen.
Ich habe freilich auch keinerlei Einblick wie Netcup die Lösung realisiert. Aber meine Vermutung wäre, dass das KVM/Libvirt Feature nwfilter genutzt wird. Da montiert man eine XML-Policy direkt am Interface der KVM-VM. Meiner Einschätzung nach wird aus der zusammengeklickten Policy genau so ein XML-File erstellt und der VM als Konfiguration mit nwfilter-define angefügt.
Die UFW bleibt weiterhin aktiv.
Wenn Du bereits eine aktive und gepflegte UFW hast, dann gehe einfach deine UFW-Regeln durch und übertrage sie in die Netcup-Firewall
Geoblocking möglich ?
nein
Eigentlich ist die Sache ja im Wiki https://helpcenter.netcup.com/de/wiki/server/firewall ausreichend erklärt. Aber ich muss gestehen, ich bin jetzt beim Erst-Versuch auch drüber gestolpert, und wenn ich mir diese Diskussion hier so durchlese hab ich den Eindruck: Es stolpern auch andere darüber.
Da die Meisten vermutlich ihre Server mit diesen abschließenden Default Regeln betreiben ("Accept all | AUSGEHEND") müsste man sich ja eigentlich nur um Server-Dienste kümmern:
| Beschreibung | Typ | Aktion | Protokoll | Source(s) (IPs / Netzwerke) | Source Port(s) | Destination(s) (IPs / Netzwerke) | Destination Port(s) |
| Drop all | EINGEHEND | DROP | ANY | * | * | * | * |
| Accept all | AUSGEHEND | ACCEPT | ANY | * | * | * | * |
Die Firewall ist für TCP-Verbindungen stateful, das heißt man muss KEINE Regel für die Antworten konfigurieren.
Einfache TCP-Server-Dienste sind daher hiermit abgedeckt:
| Beschreibung | Typ | Aktion | Protokoll | Source(s) (IPs / Netzwerke) | Source Port(s) | Destination(s) (IPs / Netzwerke) | Destination Port(s) |
| http | EINGEHEND | ACCEPT | TCP | * | * | * | 80 |
| https | EINGEHEND | ACCEPT | TCP | * | * | * | 443 |
| ssh | EINGEHEND | ACCEPT | TCP | * | * | * | 22 |
| smtp | EINGEHEND | ACCEPT | TCP | * | * | * | 25 |
| smtps | EINGEHEND | ACCEPT | TCP | * | * | * | 465 |
| submission | EINGEHEND | ACCEPT | TCP | * | * | * | 587 |
| pop3 | EINGEHEND | ACCEPT | TCP | * | * | * | 110 |
| pop3s | EINGEHEND | ACCEPT | TCP | * | * | * | 995 |
| imap | EINGEHEND | ACCEPT | TCP | * | * | * | 143 |
| imaps | EINGEHEND | ACCEPT | TCP | * | * | * | 993 |
Wer einen DNS-Server betreibt: denkt daran, dass DNS sowohl UDP als auch TCP nutzt:
| Beschreibung | Typ | Aktion | Protokoll | Source(s) (IPs / Netzwerke) | Source Port(s) | Destination(s) (IPs / Netzwerke) | Destination Port(s) |
| dns-server-tcp | EINGEHEND | ACCEPT | TCP | * | * | * | 53 |
| dns-server-udp | EINGEHEND | ACCEPT | UDP | * | * | * | 53 |
Was ist mit den DNS-UDP-Antworten? ... Die sind bei einem DNS-Server ja ausgehend und mit der "Impliziten Regel / Ausgehend" bereits abgedeckt.
ABER: Die Firewall ist in Bezug auf UDP vollkommen stateless, das bedeutet man muss z.B. für ausgehendes DNS, NTP, DHCP eine Regel für Antworten konfigurieren!
Das betrifft: Antworten auf DNS-Queries, also DNS-Responses, NTP-Responses und DHCP-Responses: auch wenn man selbst keinen solchen Server betreibt sondern diese Dienste lediglich konsumiert!
Also denkt daran, folgendes zu ergänzen, UDP Regeln mit Source Ports für:
| Beschreibung | Typ | Aktion | Protokoll | Source(s) (IPs / Netzwerke) | Source Port(s) | Destination(s) (IPs / Netzwerke) | Destination Port(s) |
| DNS response stateless-udp | EINGEHEND | ACCEPT | UDP | * | 53 | * | * |
| DHCP response stateless-udp | EINGEHEND | ACCEPT | UDP | * | 68 | * | * |
| NTP response stateless-udp | EINGEHEND | ACCEPT | UDP | * | 123 | * | * |
Anmerkung: Wer ausschließlich die Netcup eigenen DNS-Server nutzt muss gemäß Netcup-Firewall-Wiki keine UDP-Source-Port-53 Regel anlegen, da diese automatisch immer erlaubt sein dürften.
Ich kann zum geschilderten Problem mangels Betroffenheit nichts beitragen, aber OpenJDK bzw. die JRE-Pakete z.B. von Azul etc... haben ja allesamt gar keinen WebStart-Mechanismus der JNLP-Files verarbeiten könnte mehr integriert. Hier kommt denke ich das angesprochene IcedTea-netx ins Spiel, das es so aber glaube ich nicht mehr gibt, sondern durch das leider ebenfalls ins Stocken geratene IcedTeaWeb abgelöst wurde (welches es z.B. von Azul zwar noch kostenfrei zu beziehen gibt, aber leider schon seit 2 Jahren nicht mehr erneuert wurde). Insofern denke ich das hier OpenWebStart als einziges noch aktiv gewartetes Projekt übrig geblieben ist, und würde ich dieses daher versuchen.
Danke MichaelOF für das Status-Update / Insights.
Ehrlich gesagt weiß ich nicht, was an meinem Vorschlag aus 2018 so aufwändig in der Umsetzung wäre. Im CCP statt nur 2 E-Mail-Adressen (Vertragspartner, Rechnungen) einfach noch 2 weitere (Notfallkontakt, Whois) hinzuzufügen und initial aus Vertragspartner zu übernehmen aber ab nun änderbar zu machen würde die laufenden Probleme in dieser Causa zu 99% lösen und wäre doch hoffentlich auch vom Junior-Developer mit einem Personentag Aufwand umgesetzt.
Diese Thematik poppt immer wieder auf, ich selbst hatte in CCP: E-Mail Adresse(n) damals 2018 vorgeschlagen
Als Default-Wert kann für Notfallkontakt und Domain-Inhaber ja initial die Vertragspartner-Email-Adresse befüllt werden.
Damals hat [netcup] Johannes B. uns wissen lassen, dass Netcup den Vorschlag aufgreifen möchte ... leider ist bis heute daraus nichts geworden.
sollte Netcup nicht eigentlich jede MAC Adresse und die zugehörigen IP-Adressen in diesen Netzen kennen?
Dein Vorschlag lautet also auf den Juniper-Core-Routern zig-tausende statische ARP-Einträge (alle VMs) zu hinterlegen?
... wie viel Aufwand das wäre und ob das praktikabel ist weiß ich nicht. Bedenke auch: Wenn Du deine VM kündigst und ein neuer Kunde eine andere VM mit "deiner" ehemaligen IP-Adresse ausgehändigt bekommt müssten dann diese statischen ARP-Einträge nachgeführt werden.
Da würde ich eher vorschlagen: Ingres-Filtering, alle Scans auf IPs die gar nicht vergeben/eingeschaltet sind könnte man wegfiltern, sodass erst gar keine Zustellung versucht wird. Solche Filter-Regeln dynamisch zu generieren ist vermutlich ohnehin usus und daher eine besser automatisierbare Aufgabe als mit statischen ARP-Einträgen zu experimentieren.
Aus Neugier: Ist es eigentlich normal, wenn ein VPS hier rund 300 ARP request broadcasts pro Sekunde sieht, fast ausschließlich von den Gateways kommend?
Auf 300/Sek komme ich hier nicht, aber ca. 100/Sek sehe ich auch.
Auf meinem VPS wird eine /22 Subnet-Mask verwendet, hätte also "Platz" für etwas mehr als 1000 Hosts.
Das Problem sind hier denke ich die aktuell im Subnet NICHT verwendeten (nicht antwortenden) IPs.
Jene IP-Adressen die aktiv genutzt werden, die sich auf ARP-Requests melden werden auf den Gateways ja für einige Zeit im ARP-Cache gehalten und müssen nicht neu per Broadcast angefragt werden.
Aber wie im Internet üblich werden ja ständig alle IPv4-Ranges von unzähligen Bots abgegrast ("gescannt").
Wenn nun ein IP-Paket für $IP-Adresse eintrifft und der Last-Hop-Router kennt die MAC-Adresse des Gerätes nicht versucht er diese per ARP Request zu ermitteln.
Wenn das Gerät mit $IP-Adresse aber gar nicht existiert bzw. online ist, verläuft das ohne Antwort. Es kommt somit auch zu keinem Arp-Cache-Eintrag.
Ein paar Sekunden später will der nächste der über das Subnet scannt auch was von der IP-Adresse ... mittlerweile könnte das Gerät ja online sein, also fragt der router wieder per Arp-Request nach.
Was du also siehst ist mit Masse die Folge von IP-Paketen (z.B. Netzwerk-Scans) die an IP-Adressen gesendet werden, die derzeit nicht online sind.
Geht das inzwischen wieder? Ich hatte damals unachtsamerweise Frankfurt angegeben und da ist ARM seit Jahren "nicht verfügbar"
Du musst für die Erstellung eines OCI Free Tier in Frankfurt den undokumentierten Trick #17 nutzen:
Schritt 1: VM.Standard.A2.Flex (kostenpflichtig) anlegen (Sizing egal, die Boot-Disk aber am Besten gleich so groß machen wie Du sie brauchst)
Schritt 2: Sobald die erstellt ist (also 2min später) das Sizing mittels Edit auf VM.Standard.A1.Flex (Free Tier / Always Free-eligible) ändern.
Mir wurde für die 3min im A2 Flex Tarif bislang nicht verrechnet und ich hab das schon 2x so problemlos praktiziert. Selbst wenn noch eine Rechnung kommen sollte wäre das nur 1ct.
Dass DNS für forward-Lookup stets DNSSEC abgesichert sein soll steht außer Frage.
Wie gesagt, welcher UseCase soll das sein, wo man als Angreifer ein ReverseLookup fälschen würde - um was bitte damit zu erreichen?
Wie gesagt: Die dort hinterlegten Informationen sind ja ohnehin nicht validiert, egal ob mit oder ohne DNSSEC.
Was bei den Reverse-Zonen halt schon problematisch mit DNSSEC ist: das geht iterativ beim Resolven ganz schön in die tiefe. Und wenn die Zonen dann alle DNSSEC signiert sind brauchen die auch alle NSEC3 um nicht-existente Records kryptographisch gesichert als nicht-existent nachzuweisen. Und das geht auch bei den iterativ arbeitenden Resolvern dann ganz schön in die CPU-Zyklen ... bei IPv4 gehts ja grad noch so, aber bei IPv6 muss da folgendes iterativ abgearbeitet werden, z.B.: 2a03:4000:6:71ec::cafe resultiert in: E.F.A.C.0.0.0.0.0.0.0.0.0.0.0.0.c.e.1.7.6.0.0.0.0.0.0.4.3.0.a.2.ip6.arpa
Das sind 34 Signaturprüfungen / NSEC3 Hash + Signaturprüfungen. Das belastet so einen Resolver dann schon etwas.
Welcher UseCase & Schutz-Ziel soll denn mit kryptographischem DNSSec-Schutz eines Reverse-DNS-Eintrages erreicht werden?
Ich hoffe ja doch, es gibt niemanden der basierend auf einem Reverse-DNS-Eintrag irgendwelche Zugriffe trustet etc...
Selbst wenn die Reverse-Zone mit DNSSec abgesichert wäre könnte ja dennoch jeder hier beliebiges hinterlegen. Es gibt konzeptionell hier ja keinerlei Schutz, dass ich auf meiner Zone mich als whitehouse.gov ausgebe.
"DDOS-Protection" ... da müsste - wie der Name schon sagt - von vielen verschiedenen Endpunkten viel UDP-Traffic einlangen.
Die Wireguard UDP-Verbindungen betreffen aber klarerweise nur die vernetzten Endpunkte. Im Falle der Wireguard-Einbindung Heimnetzwerk mit vServer also 2 bis n ... aber das wars auch schon. Ich denke diese These ist nicht zutreffend. Man könnte auch den UDP-Port auf etwas legen was "well known" UDP-Traffic in großer Menge üblicherweise liefert, z.B. 443 (für dtls üblich bei anderen VPN-Clients wie z.B. Cisco).
Man kann bei Windows Servern einfach über die optionalen Features den OpenSSH Server installieren und dann per SSH zugreifen.
Geht nicht nur bei Windows-Server, sondern dieses FeatureOnDemand gibts auch für Win10 und Win11.
Allerdings wartet Microsoft dieses FeatureOnDemand leider nicht, wenn man das benutzt hat man eine veraltete OpenSSH-Version am System.
Ich empfehle stattdessen das von Microsoft herausgegebene, letztgültige MSI-Paket von https://github.com/PowerShell/Win32-OpenSSH/releases zu installieren. Das bekommt häufiger Updates, beides wird von Microsoft maintained.
KB19 ich muss gestehen ich habe es mir zuvor nicht so im Detail überlegt, war intuitiv der irrigen Annahme damit gäbe es keine Überbuchung. Aber du hast freilich recht: auch jetzt konnte man damit im worst-case 150% des gebuchten Speichers belegen (Disk-Size 50% + Copy-on-Write Snapshot-Size im Worst-Case 100%). Wobei es statistisch halt eher so ist, dass sich die bereits belegten 50% nicht zu 100% ändern werden, in der Praxis wird man daher bisher vermutlich nur geringere Überbuchungen gehabt haben.
Danke [netcup] Lars S.
das klingt nach großartigen Neuigkeiten.
Wobei mir noch nicht klar ist, wie ihr euch dann nun vor Über-Nutzung schützt?
Angenommen ich hätte einen Server mit 100GB Disk, 80GB sind belegt und ich erstelle einen Snapshot.
Wenn meine VM anschließend mehr als 20GB Daten ändern würde (Copy-on-Write-Speicherbedarf) würde ich eines Tages mehr als 100GB belegen.
Wird dann die VM gestoppt, oder was passiert dann?
