Genau diese Möglichkeiten sind der Grund, warum DNS auch dann funktionieren muss, wenn die Domain billig ist. Domains sind die zentralen Verteiler. Wenn du die Möglichkeit verlierst, Einträge im DNS zu ändern oder die Domain gleich gar nicht mehr auflösbar ist, dann sitzt du mehr oder weniger fest, bis der Domainprovider das wieder im Griff hat. Der sollte also auf Probleme gut vorbereitet sein, um schnell wieder handlungsfähig zu sein.
Beiträge von NaN
-
-
Kommt auf das Problem an. Grundsätzlich sollte es schnell gehen, weil Domains ja schon sehr wichtig und zentral für alle möglichen Dienste sind, so dass ich auch bei billigen Domains einige Vorbereitungen für Problemsituationen erwarte. Dazu würde ich auch zählen, dass man Systeme bereithält, die nicht auf der gleichen Softwarebasis laufen und auf die man bei Bedarf umschalten kann. Aber man hat nicht immer alles selbst in der Hand und man kann nicht erwarten, dass der Provider für ein paar Euro in zeitaufwändiger Einzelsupportarbeit das Eisen aus dem Feuer holt, wenn jemand anders etwas verbockt hat.
-
Bei allen Firewalls, die ich kenne, ist die erste zutreffende Regel entscheidend. Alles nachfolgende wird dann ignoriert und implizite Regeln, die den Rest erledigen stehen am Ende.
Das ist bei nftables so einfach nicht mehr korrekt, aber die üblichen Frameworks machen das so, ja. Die default policy von iptables Firewalls ist allerdings keine Regel im eigentlichen Sinn und wird deshalb manchmal auch nicht in der praktisch relevanten Reihenfolge aufgelistet.
-
Es reicht UDP 53 IN, TCP sollte ja dank stateful funktionieren - so hab ichs gelöst. Zusätzlich hab ichs noch auf die IPs meiner beiden externen Resolver eingegerenzt.
Diese Auflösung funktioniert wahrscheinlich in den meisten Fällen auch ohne die UDP 53 IN Regel, weil der Resolver dann auf TCP umschaltet. Deswegen fällt es vielleicht erst durch den Performanceverlust auf, dass man diese Regel braucht. Dass die UDP-Regeln stateless sind, führt allerdings die UDP-Firewall fast ad absurdum, weil ein Angreifer nur einen dann praktisch immer freizugebenden Source Port wie DNS verwenden muss, um beliebige UDP-Ports auf dem Server erreichen zu können. (Man kann die Regeln auf den Portbereich einschränken, der für abgehende "Verbindungen" verwendet wird, aber wer macht das schon.)
-
verwirrend, da die impliziten Regeln von der Reihenfolge ausgenommen sind
Nichts ist ausgenommen, aber die Verarbeitung stoppt beim ersten Treffer. Damit ist das Paket entsprechend der ersten zutreffenden Regel erlaubt oder verboten und alle weiteren Regeln spielen für dieses Paket keine Rolle mehr. Das ist eine sehr übliche Semantik solcher Regelsätze.
-
Die neue Firewall
Is' scho' Weihnachten?
-
Ich sehe die als statische quasi-IP-Adresse, für die man auch ein nicht-selbst-signiertes Zertifikat bekommen kann. Natürlich sind .de Domains zum Angebotspreis kaum teurer, aber vielleicht interessiert das auch Kunden, die keine .de Domain haben können oder wollen, mangels
StrohmVerantwortendem mit deutscher Adresse. -
Passend zum heutigen Türchen wäre mal cool gewesen, wenn Netcup 1.111B-class .xyz Domains anbieten würde.
-
Mir ist klar, dass das nicht wirklich geht, aber dir ist auch klar, dass es auf Dauer nicht funktioniert, wenn Emails willkürlich nicht angenommen werden, oder? Dieser Blödsinn, dass man beim richtigen Anbieter sein muss, um Mails zustellen zu können, treibt durch die Unzuverlässigkeit die Menschen zu zentralistischen Systemen. Sippenhaft und Geiselnahme sind keine akzeptablen Antispammethoden.
-
Es wird echt langsam Zeit, dass das Nichtannehmen von Mail wegen Gründen, die nicht im Inhalt der Email oder der Person des Absenders selbst liegen, sanktioniert wird.
-
Wer steckt denn Geld ins Einkaufswagenchipfach? (Bei uns sind die alle dauerhaft entsperrt.)
-
Irgendwo her sollte ja ssllabs schon wissen, wo sie nach der Domain suchen müssen.
SSLlabs hat den Server ja gefunden, denn sonst könnte das Zertifikat nicht analysiert werden. Ich halte es für wahrscheinlich, dass es einen AAAA-Record für die Domain selbst gibt, aber keinen A-Record. Das würde die beobachteten Probleme vollständig erklären. VPNs unterstützen IPv6 oft nicht, machen ihre Nutzer also zu IPv4-only Besuchern, die ohne A-Record den Server nicht finden. Sonst ist IPv6 verbreitet genug, dass der fehlende A-Record nicht schnell auffallen muss.
-
@ A x.x.x.x
Den wirst du schon brauchen, wenn mit der Domain selbst der Webserver angesprochen werden soll. Alternativ ginge auch ein AAAA, aber das würde dich auf Clients mit IPv6-Unterstützung einschränken, und das könnte erklären, warum das über VPNs nicht geht. Das wäre dann kein Konfigurationsfehler des Servers sondern deiner Domain.
-
WIe kann ich das Problen angehen?
Anderen Hoster wählen oder Cloudflare* oder anderen Reverse Proxy Dienst vorschalten.
*) Die Besucher sehen dann öfter mal ein Captcha, bevor sie auf deine Seite kommen.
Ich denke nach wie vor, dass es ein serverseitiges Konfiguratiuonsproblem ist.
Ich nicht. Schöner fände ich, wenn die Firewall dokumentiert würde, also dass sie da ist und was sie sperrt. Aber daran, dass du mit einigen VPNs nicht auf den Webserver kommst, würde das nichts ändern.
-
Alles anzeigen
Certificate #1: RSA 4096 bits (SHA256withRSA)
Revocation status Validation error
CRL ERROR: IOException occurred
DNS CAA No (more info)
Certificate #2: RSA 2048 bits (SHA256withRSA) No SNI
Common names Plesk
Alternative names - INVALID
Ich denke, du hast beim ersten Zertifikat die Domain wegzensiert und nur das gequotet, was dir als Fehler erscheint. Das ist das Zertifikat, das du bekommst, wenn du beim Server korrekt mit dem Domainnamen im SNI anfragst. Es ist das richtige Zertifikat, und dass SSLlabs nicht nachschauen kann, ob das Zertifikat zurückgerufen wurde, ist normal. Du hast keinen CAA-Record im DNS deiner Domain hinterlegt. Das könnte man verbessern, also wird das markiert, aber es ist kein Fehler (orange, nicht rot). Das zweite Zertifikat ist das selbstsignierte Default-Zertifikat, das du bekommst, wenn du den Server ohne SNI befragst. Es ist normal, dass das nicht valide ist, weil der Server gar nicht weiß, mit welcher Domain du reden möchtest und deshalb auch kein dazu passendes Zertifikat präsentieren kann.
Warum die Website über VPNs nicht erreichbar ist, kann man nur mutmaßen. Die Webhosting-Systeme hier haben eine Firewall vorgeschaltet, die Angriffe abwehrt und Blacklisten führt. Es kann sein und ist wahrscheinlich, dass von den VPN-Exitnodes viel Schindluder getrieben wird, weil sich die Täter hinter dem VPN in Sicherheit fühlen. Dass man mit VPN-IP-Adressen nicht überall gerne gesehen ist (um es vorsichtig auszudrücken), kennt jeder, der sowas schon mal verwendet hat.
-
Wireguard ist einfacher zu verstehen, wenn man sich daran erinnert, warum da von Peers die Rede ist: Es gibt keinen "Server", nur "ich" und "die andere Seite". Der [interface] Abschnitt ist man selbst, und der [peer] Abschnitt ist die andere Seite. Nur von letzterem kann es auch mehrere geben.
Die eigene Adresse legt man selbst fest. In dem Abschnitt für die andere Seite legt man fest, welche Adressen die andere Seite im Tunnel als Absenderadressen verwenden darf. Das ist eine rein lokale Einstellung und wird der anderen Seite nicht mitgeteilt. Es gibt keine Zuteilung vom Server für den Client oder sowas. Alle sind gleichberechtigte Peers. Wenn man es nicht abschaltet, werden für diese Adressen auch Routen angelegt, so dass Pakete an diese Adressen zum Wireguard-Device geroutet werden. Wireguard schickt Pakete, die in das Wireguard Device geschickt werden, durch den Tunnel zu dem Peer, der die Zieladresse verwenden darf. Deshalb dürfen die AllowedIPs verschiedener Peers nicht überlappend angegeben werden.
-
Decreasing Certificate Lifetimes to 45 Days
Wer sich "old news" denkt, sollte trotzdem mal reinschauen. Erstens ist der Zeitplan jetzt konkretisiert und zweitens wird auf einen neuen Challenge-Typ hingewiesen, den es ab 2026 geben soll: DNS-PERSIST-01. Damit werden keine ständigen Änderungen am DNS mehr nötig sein, um Wildcard-Zertifikate ausgestellt zu bekommen.
-
Du kannst die Mail vom Sievefilter löschen lassen, aber der Absender denkt dann, die wurde zugestellt. Ablehnen "geht nicht", auch nicht mit dem Sieve-Filter, egal wo und wie du den konfigurierst. Der läuft erst, nachdem die Mail angenommen wurde. Zu dem Zeitpunkt ist es zu spät, dem Absender mitzuteilen, dass die Adresse nicht existiert. Das kann man versuchen, und Sieve hat die Möglichkeit Mail "abzulehnen", aber damit erzeugt man Backscatter. Deshalb sollte man das tunlichst nicht tun.
Weil es bei Netcup keine Blockierliste gibt, die vor der Annahme der Mail greift, ist folgendes das Beste, was du machen kannst: Diese Adressen als Alias eines Dummy-Mailaccounts anlegen, diesem Mailaccount nur eine winzige Speichermenge zuteilen und volllaufen lassen. Der Absender bekommt dann die Fehlermeldung, dass der Empfängeraccount voll ist, und wichtig dabei: Diese Fehlermeldung erzeugt der Mailserver des Absenders, weil der Mailserver von Netcup die Mail gar nicht erst annimmt. So entsteht kein Backscatter.
-
Schreib das nächste mal direkt dazu, dass du zuerst einen Zufallsgenerator gefragt hast. Dann kann ich mir die Antwort sparen.
-
Der Transferlock geht vor Januar nicht weg, aber der stört nichts, was du machen müsstest. Ignorier den.
Du kannst die DNS-Einträge jederzeit in deinem CustomerControlPanel anpassen.
(Stell dir das so vor, dass der Transferlock einen Teil des Whois betrifft, nicht das DNS. Dein aktueller Provider, also Netcup, könnte sogar fremde Nameserver für die Domain eintragen, wenn du das wolltest. Nur die Kontrolle über die Domain an einen anderen Provider abgeben, so dass ein anderer Provider deine Nameserver ändern könnte, geht nicht).
