Beiträge von NaN

    Wenn ich durch Portverlegung die Angriffe auf 1% reduziere, dann reduziere ich (falls es überhaupt eine Lücke gibt) auch die Wahrscheinlichkeit, dass einer der Angriffe erfolgreich ist um diesen Faktor.

    Das absolut meiste, was auf Port 22 minütlich passiert, würde ich nicht als ernstzunehmenden Angriff bezeichnen. Das hat auf einem normal konfigurierten System ohne Trivialpasswörter Null Aussicht auf Erfolg. Für gezielte Angriffe auf bestimmte Lücken gibt es Datenbanken, aus denen auch dein SSH-Server mit alternativem Port abrufbar ist und die gleich die nötigen Informationen mitliefern, ob der Server in der wahrscheinlich vulnerablen Population ist oder nicht. Du reduzierst die Anzahl der Leute, die mal deine Klinke runterdrücken, um zu sehen, ob überhaupt abgeschlossen ist, aber für die Leute, die mit Plan und Werkzeug kommen, ist ein alternativer Port kein Hindernis. Die Wahrscheinlichkeit eines erfolgreichen Angriffs reduzierst du damit wenig bis gar nicht.

    Die VMs können bekanntlich auf andere Hosts umgezogen werden und bekommen dann keine andere IP-Adresse. Das Netzwerk muss also mindestens soweit virtualisiert sein, dass die VM "ihre" Broadcastdomain von unterschiedlichen Hosts erreichen kann, aber umgekehrt können auf einem Host wahrscheinlich auch VMs aus unterschiedlichen Broadcastdomains laufen. Es gibt folglich vor dem Gateway eine nicht-triviale Netzwerkinfrastruktur und das LAN der VM ist mit Sicherheit nicht identisch mit dem LAN, über das der Hypervisor und die VNC-Konsole für die virtuellen VGA-Karten angesprochen werden. Dafür braucht man nicht mehrere Netzwerkkarten. Die naheliegende Umsetzung wäre mit VLANs oder VXLANs. Mehrere Hardwareinterfaces kann man stattdessen für Ausfalltoleranz nutzen.

    Das Subnetz mit rund 1000 Adressen läuft wahrscheinlich nicht komplett auf einem Host, und der Fehler sieht schwer danach aus, dass die Netzwerkanbindung eines Hostsystems nicht korrekt funktioniert. Da ist vielleicht ein VLAN nicht richtig konfiguriert oder sonst irgendwie die Verbindung der VMs auf diesem Host zu ihrer Broadcastdomain abgeschnitten. Das muss keinen Einfluss auf VMs auf anderen Hosts haben. Wenn man mal schaut, ob man andere IPs aus der Broadcastdomain anpingen kann, wäre das durchaus aufschlussreich, aber lösen kann man das Problem dann trotzdem nicht. Ein VPS mit Default-Konfiguration und Default-Image hat bei Netcup eine funktionierende Netzwerkanbindung. Alles andere ist ein Fehler, aber keiner des Kunden.

    Die Netzwerkkonfiguration in #6 und #8 sieht richtig aus. Wenn man neugierig ist, könnte man noch testen, ob irgendwelche anderen Adressen in der Broadcastdomain erreichbar sind. Die werden nicht geroutet und einige liegen sehr wahrscheinlich auf dem selben Host. Lösen wird man das Problem so aber nicht.

    Bitte meldet euch doch beim Notfallsupport. Wenn ein frisch installierter VPS mit voreingestellter Hardwarekonfiguration und einem Standardimage keine Netzwerkverbindung hat, und auch im Rescue-System kein Netz funktioniert, dann ist aller Wahrscheinlichkeit nach etwas auf dem Host verkehrt. Wenn ihr das nicht dringend genug findet, dann sagt dem Support, dass sie es niedrig priorisieren können, aber die Techniker dort sind dafür da, um akute Probleme zu beheben.

    Ergänzung: Ihr beiden fragt im Forum, aber auf dem Host laufen wahrscheinlich noch andere VPS, die genauso nicht funktionieren, und die Kunden ärgern sich dann auch. Ihr tut Netcup einen Gefallen, wenn ihr solche Fehler umgehend beheben lasst.

    Wenn das Netz im Rescue-System nicht funktioniert, wirst du das Problem nicht selbst lösen können. Ob dir das Problem dringend genug ist, kannst du dir natürlich selbst überlegen. Aber der Notfallsupport wird nicht extra für dich eingeflogen: Den sollen die Kunden nur nicht ständig anrufen, wenn sie Unterstützung bei etwas brauchen, was sie selbst machen wollen oder verbockt haben. Dann kostet der Notfallsupport. Wenn Netcup etwas individuelles vergeigt hat (also nicht irgendeine bekannte und bekanntgegebene Störung vorliegt), und die Zeit drängt, dann steht dir der Notfallsupport offen. So habe ich jedenfalls die Info auf dem Community-Event 2024 verstanden (44:12 bis 47:08).

    Es gibt eine DNS-API bei Netcup und Letsencrypt Clients, die diese API unterstützen. Wenn die Delegation an einen anderen DNS-Betreiber eine Option ist: Cloudflare unterstützt CNAME flattening. Damit kann man einen CNAME für den Zone Apex verwenden. Netcup und der hier oft empfohlene DNS Hoster Desec.io unterstützen das nicht. Eine weitere Alternative ist ein HTTPS Record. Der geht (noch) nicht bei Netcup, aber schon bei Desec.io.

    Wenn LANCOM die Software als Testversion zur Verfügung stellen würde, hätte ich die schon ausprobiert, aber so kann ich dir nur sagen, dass mir dmidecode auf meinem VPS eine UUID anzeigt. Da müsste LANCOM mal sagen, was ihnen genau fehlt. LANCOM kann sich mal einen Server mieten und das klären. Die stundenweise Abrechnung ist zwar wegen der Einrichtungsgebühren Augenwischerei, aber ein kleiner Server kostet ja trotzdem weniger als einen Zehner.

    Ich habe es mir angeschaut. Mein Verständnis: Der Verweis auf das Gesetz ändert sich, wenn man einen solchen Verweis angibt, aber das ist nicht Pflicht. Die Rechtsgrundlage ist jetzt §5 DDG statt §5 TMG. Alles andere hat sich zumindest nach dem, was dem Video zu entnehmen ist, nicht in letzter Zeit geändert. Keine Änderung auch für mein Weltbild bezüglich Anwälten.

    Wenn irgendeine Subdomain einer Domain existiert, dann gibt es die Domain implizit und dadurch gilt der * nicht für diese Domain. Ein TXT auf _acme-challenge.sub.example.com für die DNS-01 Challenge verhindert z.B., dass ein *.example.com Record für sub.example.com angewendet wird. Wenn Wildcards im Spiel sind, muss man sich auch alle anderen Records genau ansehen.

    Zusätzlich zu den Ecken und Kanten eines ungeliebten design-by-committee Protokolls hat IPv6 bei Netcup noch einige Besonderheiten, die besonders dann unangenehm werden, wenn man nicht nur eine Adresse für den Host benutzt sondern Container mit eigenen Adressen ausstattet. Wenn es IPv6 sein muss (meiner Meinung nach muss es das nicht), dann sollte man hier die selbe Konstruktion wie mit IPv4 nutzen: Reverse Proxy auf dem Host oder in einem Container, der die IPv6-Adresse trägt. In den Containern braucht man dann keine öffentlichen IPv6-Adressen und damit eigentlich gar kein IPv6.

    was sind denn die Alternativen?

    Z.B. könnte man sich bei dem beschweren, der die Mail fälschlicherweise ablehnt. Kunden informieren, dass sie bei einem Provider sind, der wichtige Mail für sie nicht annimmt, wäre auch ein Ansatz. Wenn es anhält, könnte man im Fall von abgelehnten Emails den entsprechenden Kunden über eine andere Mailadresse darüber informieren, dass eine Mail für ihn abgelehnt wurde und er Dokumente für sich über seinen Kundenaccount abrufen kann*, aber eben nicht alles über einen anderen Hoster verschicken, als wäre nichts gewesen, und so das Verhalten des Providers auch noch zu belohnen.

    Spambekämpfung ist viel zu oft Bullying der Kleinen durch die Großen. Das belohnt man nicht.

    Wenn es wirklich ein Wechsel zu einem andere Mailprovider sein muss, dann wechselt man nicht zu dem, der Briefkästen durch falsche Ablehnungen "sauber" hält, sondern seine Absender mit ausgehenden Filtern besser unter Kontrolle hat. Das könnte der Provider auch durchsatzabhängig machen: Wer als Kunde eine gute Reputation hat und kleineren Durchsatzlimits zustimmt, geht über die Gateways mit der besseren Reputation raus.

    * KEINE LINKS in der Mail! Jeder weiß, wie ordentliche Email geht, aber alle wollen es ihren Kunden bequem machen und erziehen sie in die falsche Richtung. Wieso ist klicken auf Links in Email auch 2025 noch üblich? Eigentlich müsste der Reflex sein: Link oder URL in der Email, das ist sicher Phishing!