Beiträge von KB19

    Der Host Header ist das, was in der Adresszeile angegeben ist.

    Wenn du im ip Block plötzlich den Host Header ip4 findest, stimmt da etwas nicht und du kannst Error 421 zurück spielen.

    Nein, so einfach ist es leider nicht. :(

    Vorweg: Ich hatte vorhin einen gemeinsamen server Block für alle drei Hosts.

    Ich habe das jetzt mal auf eigenständige Blöcke umgebaut und online gestellt.…

    • Wenn die ip4/ip6 Blöcke jeweils nur auf der passenden IPv4/IPv6 Adresse lauschen, wirft mir Nginx beim zweiten Request einen Error 404 um die Ohren. Der Request erreicht somit gar keinen location Block, in dem ich das abfangen könnte. Prinzipiell ist die Website dann erst recht kaputt, weil sie gar nicht mehr erreichbar ist.
    • Wenn die ip4/ip6 Blöcke hingegen immer auf beiden IPv4/IPv6 Adressen lauschen, tritt das vorher diskutierte Fehlerbild auf. Aber auch hier kann ich mit dem HTTP-Host-Header baden gehen, weil er immer "korrekt" ist und daher keine Unterscheidung möglich ist:

      server_name=http-debug4.fnx.li
      http_host=http-debug4.fnx.li
      remote_addr=2a02:[…]
      request_uri=

    Falls Du es testen willst: http-debug.fnx.li / http-debug4.fnx.li / http-debug6.fnx.li

    Code
    location /
    {
        default_type text/plain;
        return 200 "server_name=$server_name\nhttp_host=$http_host\nremote_addr=$remote_addr\nrequest_uri=$request_uri\n";
    }

    In dem Fall müsstest du den Host Header ein zweites Mal überprüfen innerhalb eines Location Blockes.

    Der HTTP-Host-Header, den der Client übermittelt? Aber der ist doch immer korrekt, an dem erkennt man diesen "Bug" gar nicht?

    Vorausgesetzt ich habe das nicht falsch in Erinnerung. Ich bin mir ziemlich sicher, dass ich das mit den Entwicklertools sofort geprüft habe.

    Wenn man das wie beschrieben mit der Origin erkennen kann müsste ich ja einfach nur in der API nen Status 421 schicken wenn da sowas kommt.

    Habe ich irgendwas überlesen? Wie kann man das erkennen, ohne Unterstützung durch den Webserver?

    eine Möglichkeit wären natürlich keine SAN / Wildcard Zertifikate zu verwenden.

    Das ist nun auch mein Workaround. Gefällt mir zwar nicht, weil der interne Hostname dadurch im Certificate Transparency Log auftaucht, aber das Ding hat sowieso einen speziellen Pfad, den man nicht so leicht errät. Durch die negativen Erfahrungen von perryflynn mit den massenhaften Requests durch Schadsoftware, möchte ich die genaue Adresse nämlich keinesfalls öffentlich verbreiten.

    Das scheint noch ein alter Tarif zu sein, der über das zentrale WCP (Parallels Plesk Automation / webhostingcontrolpanel.de) verwaltet wird. So einen habe ich hier auch noch, in der Variante Expert Light.

    muetsni Gehe mal auf mxtoolbox.com und gib Deinen Domainnamen ein, um den MX-Record abzufragen. Als Ergebnis sollte dann so etwas auftauchen:

    Screenshot 2023-11-14 at 02-23-08 Network Tools DNS IP Email.png

    Sollte dort als Hostname nur ein mail.<DOMAIN> auftauchen, klicke einmal die blaue IP-Adresse (im Beispiel 46.38.249.72) an. Dadurch wird der PTR-Record der IP-Adresse abgefragt:

    Screenshot 2023-11-14 at 02-24-26 Network Tools DNS IP Email.png

    Spätestens jetzt solltest Du den korrekten mxf___.netcup.net Hostnamen sehen können. ;)

    Diese Diskussion fand ursprünglich im "Längsten Thema" statt. Danke an die Moderator:innen fürs Splitten in einen eigenen Thread!

    --------------------------------------------------------------------------------

    Ich glaube, ich habe gerade einen Bug in Firefox gefunden. Oder soll das wirklich so sein? :/

    • https://ip.example.net/ aufgerufen: Verbindung wird über IPv6 hergestellt.
    • https://ip4.example.net/ aufgerufen: Verbindung läuft weiterhin über IPv6?!

    ip4 hat aber gar keinen AAAA-Record! (Genauso wie ip6 logischerweise keinen A-Record hat.)

    ip hat natürlich A und AAAA-Records und alle drei Hostnamen sind mittels Wildcard im SAN des Zertifikats abgedeckt.

    Chrome verhält sich übrigens korrekt und mischt hierbei nicht die Verbindungen.

    [EDIT] Interessanter Lesestoff, wobei das nicht ganz mein Szenario beschreibt: https://bugzilla.mozilla.org/show_bug.cgi?id=1420777

    ich habe das gleiche problem.

    Du erhältst ebenfalls die gleiche 403 Fehlermeldung, wie der Threadersteller?

    Falls nicht: Bitte einen neuen Thread eröffnen und nicht 1,5 Jahre alte Threadleichen ausgraben. :)

    PROBLEM --> meine kunden rufen die seite mit www. auf. Hier kommt ein Fehler. Ohne www geht SSL.

    Hast Du bei der Erstellung des Zertifikats überhaupt das Häkchen bei "WWW" gemacht? Sonst gilt es logischerweise nicht für die WWW-Variante.

    Bud Wenn es wichtig ist und irgendwo halbwegs dazu gehört: Interner Bugtracker (MantisBT) oder z.B. GitHub/GitLab Issues, wenn das Projekt dort zuhause ist.

    Ansonsten meistens in meinem internen Wiki (MediaWiki), da habe ich einige allgemeine Sammelseiten für genau solche Zwecke. :)

    Normalerweise laufen Domains eigentlich nicht einfach so ab, die werden in der Regel automatisch verlängert. :/

    War das eine Inklusivdomain oder eine Zusatzdomain? Hast Du sie vielleicht versehentlich gekündigt? Oder Deine E-Mail-Adresse im CCP geändert und nie auf den Bestätigungslink geklickt?

    [netcup] Alexander W. Wenn wir schon beim Thema sind, was uns Kunden stört: z.B. Tickets, die 9 Tage (!) offen sind und noch immer keinerlei Antwort von der Fachabteilung bekommen. Feiertag und zwei WE hin oder her, da hält sich mein Verständnis selbst bei komplexen Themen langsam in Grenzen. Man könnte wenigstens einmal von selbst eine kurze Rückmeldung geben :(

    Es geht dabei übrigens um den mysteriösen rDNS-Bug im CCP/SCP. Beim Thema DNS (DNSSEC & Resolver) habe ich sowieso kaum Hoffnung und entsprechende Workarounds (externe Nameserver & lokaler Unbound) in Betrieb. Die rDNS-Problematik passt da leider sehr gut ins Minenfeld "DNS" und die kann man als Kunde nicht umgehen. ;(

    Wie schon mal erwähnt, eure KVM-Instanzen, sind grundlegend stabile Arbeitstiere. Aber die "Kleinigkeiten" drumherum vermiesen die gute Laune. Man hat manchmal das Gefühl, dass netcup um jeden Preis expandieren möchte, aber in (fast) allen Abteilungen mit diesem Tempo und Volumen nicht mithalten kann. Außer in der Marketing/PR-Abteilung...

    Aber das sind doch Cyphers von vorgestern.

    Da bin ich inhaltlich durchaus bei Dir :thumbup:

    Das Problem im Shared Hosting Bereich ist halt, dass dann schnell eine kleine Masse der Kunden schreit (bzw. den Support blockiert), die das für irgendeine (veraltete) Software unbedingt brauchen.

    Zum Vergleich, so sieht auf einem ncLabs-Webhosting aktuell aus:

    ssllabs-1.png ssllabs-2.png

    Mal sehen ob ich da mal jemanden anschreibe.

    Lass uns die Antwort wissen, das würde sicher einige Forenuser interessieren. :)

    Denn wenn du Dritten nur zu bestimmten Domains oder zu einer bestimmten Domaingruppe in dessen Unterverzeichnisse lassen möchtest, weil sie die dazugehörigen Webseiten dort pflegen sollen können, so kannst du auch schon im kleinsten Webhosting-Paket zusätzliche Zugänge als FTP-Zugänge mit persönlichem Nutzernamen und Paßwort einrichten.

    Bei so etwas ist übrigens Vorsicht geboten: Mithilfe von z.B. PHP (und eventuell .htaccess Dateien) kann man aus so einem eingeschränkten FTP-Zugang über HTTP schnell "ausbrechen" und hat dann Zugriff auf den gesamten Webspace des Kunden. So einen Zugang würde ich daher wirklich nur Personen geben, denen ich auch das Plesk-Passwort anvertrauen würde. Oder sie in einem Ordner außerhalb des Dokumentenstamms einsperren, dort können sie in der Regel keinen größeren Schaden anrichten. (Außer dort werden PHP-Scripts eingebunden/ausgeführt, dann ist es die gleiche Gefahr wie oben beschrieben.)

    Da so eine Einstellung alle Kunden auf einem Shared Server betrifft: Nein, das kannst Du bei eine normalen Webhosting Tarif nicht selbst konfigurieren.

    Alternative: Support anschreiben und um eine allgemeine Aktualisierung/Verbesserung bitten; oder z.B. auf einen eigenen (Managed) vServer wechseln.

    Zudem finde ich es extrem schade, dass man das aktuelle Angebot eines Minimalst-VPS nicht einfach so buchen kann… Bei I0n0s fangen VPS ja auch bei 1€ an und sind normal buchbar..

    Gewinn macht man mit so etwas in Zeiten von akuter IPv4-Knappheit aber höchstwahrscheinlich keinen mehr, eher im Gegenteil. Die verbuchen das bestimmt als Werbeausgaben, was sich für den Anbieter natürlich trotzdem lohnen kann, wie man an den Forenbeiträgen deutlich sieht. ;)

    Nein, das ist nicht vorgesehen. Maximal bei den Reseller oder Managed PS Tarifen kann man in Plesk so etwas realisieren.

    Du kannst in Plesk aber ein Passwort festlegen und das weitergeben, damit man ohne CCP rein kommt. Damit wäre dann aber trotzdem der Zugriff auf alle Domains eines Webhostingpakets möglich! Da hilft dann maximal das Buchen mehrerer Webspace-Pakete, wenn man es sauber trennen möchte. Die Funktionen im CCP wären für einen Anderen halt dennoch nicht nutzbar.

    […] Scheißegal […]

    […] aber Mr.Schlaui muss dann reinballern "Anspruchsdenken" .

    Ich will der Netcup ja nicht mal was böses unterstellen, aber es ist einfach mal Kaka!

    Mit Verlaub, aber auf so einem Niveau muss man im Forum auch nicht diskutieren! Man kann Kritik halbwegs sachlich formulieren, ohne irgendwen anzugreifen oder eine meiner Meinung nach unpassende Wortwahl zu verwenden.