Beiträge von m_ueberall

    Nun erhalte ich folgenden Fehler wenn ich versuche ein Zertifikat zu erstellen:

    Bash
    […]
    [Do 7. Okt 13:50:36 CEST 2021] No Credentials given
    […]

    Verstehe auch nicht warum er als CA Zerossl verwendet und nicht Lets Encrypt.

    Da hilft wohl wirklich nur ein erster Blick ins Log nach Nutzung von "--debug". Wie es aussieht, werden den Zugangscodes nicht übernommen.

    Der Wechsel auf ZeroSSL (wohl aufgrund eines Sponsorings) wurde bei Erscheinen der Version 3.0.0 bekanntgegeben, vergleiche hier.

    Moin, jemand Interesse an dem Script?

    Ich könnte mir das als Beitrag für das Serverhoarder-Wiki vorstellen (wenn es in Gang kommt), da dieses Thema anlagemäßig für mehrere Anbieter Sinn macht und entsprechende Scripts über die Zeit sicherlich mehrere Anpassungen benötigen (etwa bzgl. "safeguards" gegenüber geänderter Eingabemasken usw.)

    Gegen einen initialen Gist oder eine anderweitige Veröffentlichung via GitHub/GitLab/Codeberg spricht aber auch nichts. :)

    I wish I could reset / reboot / shutdown / other via my web panel using netcup api via a token server

    Unfortunately, there is only a limited set of actions you can trigger, see this topic on the Netcup wiki. If I recall correctly, though, at least one user managed to access the SCP using the Apache Selenium framework which should allow to reuse all available actions (the downsides being that you'd need to use the SCP login credentials, and that this takes considerably more effort than using a pre-defined web service). EDIT: If this (still) sounds like an option, see this thread.

    Aktuell haben wir ein Multidomain-Zertifikat für mehrere unterschiedliche Websites über die Telekom (die Website liegt derzeit noch bei der Telekom). Ich wüsste nicht wie ich dieses duplizieren könnte. Wir haben es nicht selbst installiert. Erstellung und Installation wurde über die Telekom vorgenommen.

    Nun, in diesem Fall steht vor Nutzung der neuen Webpräsenz sowieso das Thema Zertifikatserstellung an, selbst wenn alle Domänen umgezogen werden sollen – die Telekom oder einer ihrer Partner wird sich dann um die Erzeugung/Verlängerung der für Netcup-Hosts verwendeten Zertifikate eher nicht kümmern (oder es sich ggf. ausgesprochen gut bezahlen lassen). Ohne ein entsprechendes (Einzeldomänen?-)Zertifikat ist an einen "transparenten" Umzug der Domäne (und die fortgesetzte Nutzung) nicht zu denken.

    Erinnerung: Spätestens jetzt sollten Nutzer von Apache2 v2.4.49 ein Update eingespielt haben, welches CVE-2021-41773 adressiert; hier findet sich eine Docker-Testinstallation, mit der man üben kann, wie man sensitive Dateien "abgreift".

    Da der Exploit ein paar Tage bekannt war, empfiehlt sich bei früherer Nutzung der verwundbaren Version in diesem Fall unbedingt ein Blick in die Webserver-Logs…

    Hierzu sollte es reichen, nach '%nn' zu suchen (Kollege unten war hier leider – u. a. – etwas spät 'dran; '%2e' ist dabei nur ein Beispiel, Kombinationen mit '%5c' o. Ä. gibt es na­tür­lich auch):

    Code
    [2021-10-06T09:47:04+0200] root@vserver19<kvm>:/var/log/apache2# grep '%2e' *_access.log*
    […]
    domain.tld_access.log.1:196.65.227.79 - - [05/Oct/2021:22:27:38 +0200] "GET /cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e//etc/passwd HTTP/1.1" 400 226 loc:"-" ref:"-" ua:"curl/7.74.0" port:80
    […]

    Die Website läuft derzeit parallel noch am alten Server. Wir möchten die DNS-Einträge erst ändern, wenn die Website am neuen Server läuft, daher gibt es keine Möglichkeit das vorhandene Zertifikat vom "alten" Server zu übernehmen.

    Das "Ausrollen" (Installieren) eines Zertifikats ist unabhängig von den DNS-Einträgen und ein solches kann beliebig dupliziert werden, d. h., es ist keine Verschiebung notwendig.

    Die vorgenannten Schritte zur lokalen Änderung einer "DNS-Auflösung" sorgen dafür, dass der/die betroffenen Rechner – und nicht die breite Öffentlichkeit – eine Kopie dieses Zertifikats unter der neuen IP-Adresse erwartet/n und bei Anfragen den korrekten/zukünftig dieser IP-Adresse offiziell zugeordneten Domänennamen "im Voraus" verwendet/n. Eben zu internen Testzwecken.

    Da muss ich mir dann wieder die Hände auf den Rücken fesseln lassen, damit ich nichts bestelle, das ich dann doch nicht brauchen werde..

    Hilfsweise mir temporär alle Vermögenswerte übertragen (inklusive Ausnutzung des Dispokredits für alle Bankkonten, versteht sich!). Sobald die Gefahr vorüber ist, geht das dann wieder zurück, minus einer klitzekleinen Servicegebühr…

    Im Internet gibt es diverse Dienste, welche anbieten eine Mail Adresse auf Existenz bzw. Zustellbarkeit zu prüfen. Wie kann ich im MTA, hier Postfix, dies für einen eigenen Dienst unterbinden?

    Wenn du an deinem Haus das Klingelschild abbaust weiß auch niemand mehr dass du da wohnst, Post kriegste aber halt auch keine mehr…

    Um bei dieser Analogie zu bleiben: Die einzige Möglichkeit im Clearnet – ohne dass ich es empfehlen würde oder in diesem Fall für sonderlich praktikabel hielte! – wäre, ggf. zwar ein Klingelschild anzubringen (d.h. einen MX-DNS-Eintrag bekanntzumachen[*]), aber die Klingel abzuschalten (nicht auf Anfragen reagieren), sodass der Klin­geln­de wissen muss, wie er sie anschaltet (über ein der Allgemeinheit nicht bekanntes Signal), oder die Klingel nur für von vornherein bekannte Klin­geln­de funktioniert (IP-basierte Freischaltung). Diese Taktik wird normalerweise am ehesten für den SSH-Port 22 angewendet, kann jedoch auch für Port 25 (MTA-zu-MTA-Kommunikation) ein­ge­setzt werden. Das Hilfswerkzeug der Wahl für die Identifizierung durch ein zuvor ausgehandeltes Signal (durch vorheriges "Anklopfen" an TCP-/UDP-Ports) ist knock.

    In der Praxis besteht das Problem darin, dass Nutzer dieses Anklopfen vor Versendung von E-Mails bewerkstelligen müssen, was kein bekannter MTA von Haus aus kann; außerdem setzt man sich hier über RFC2142 hinweg, wonach bestimmte Empfängeradressen immer "bedient" werden sollten.

    [*] Theoretisch könnte man natürlich auch versuchen, E-Mails an Port 25 einer nicht weiter namentlich identifizierten IPv4-/IPv6-Adresse zuzustellen, aber auch hier sind auf Empfängerseite entsprechende Vorkehrungen zu treffen, um nicht die Postfix-Standardantwort "501 5.1.3 Bad recipient address syntax" auszulösen. Der Verzicht auf ei­ne registrierte Domäne umgeht natürlich damit verbundene Vorschriften bzgl. einer Erreichbarkeit der Ansprechpartner. In der Praxis würde man bei gewünschter Ano­ny­mi­tät und entsprechendem Willen aller Beteiligten allerdings E-Mails über das Darknet austauschen (siehe beispielsweise hier), und die Überprüfung existierender Emp­fän­ger über die obengenannten diversen Dienste wird dadurch zumeist ausgehebelt.

    Ich tue mich ja immer ein bisschen schwer mainziman auch mal Recht zu geben ;), aber die Angabe kann man tatsächlich durchaus leicht missverstehen.

    Zumal es auch Angebote gab, bei den x 4 auch effektiv x 4 bedeutete. (Ich habe zwei VPS 500 G8 SSDx4, die statt 160 GB statt 40 GB haben)

    (Aber zumindest sieht man die korrekt Größe dann, wenn man weiterklickt)

    Das ist richtig, da steht das "x4" aber auch an anderer Stelle im Produktnamen. Deswegen auch meine Meinung, dass man hier bei den Angeboten explizit einmal "Brutto"- und "Netto"-Präfixe bei Kapazitätsangaben einführen sollte. Wenn das Wiki ein wenig überarbeitet werden soll (im Kontext der Community-Artikel), wenn ich das richtig mitbekommen habe, ist das eine ausgesprochen gute Gelegenheit, dorthin zu verweisen, wenn Platz hierzu "auf der Angebotsseite fehlen sollte".

    • Auf der Angebotsseite wird sehr wohl mehrfach RAID10 bzw. bei der Übersicht ein Festplattenverbund erwähnt, 320GB ist hierbei die Nettokapazität (nur daran zu erkennen, dass nicht von vier Platten die Rede ist, folgt wiederum implizit aus dem Verständnis über RAID10; werden vier Platten genannt, ist das immer[*] die RAID10-Bruttokapazität).
    • Dass Netcup von mehreren Nutzern geteilte RAID-Arrays einsetzt (vgl. hier, war eine Bezugnahme auf entsprechende offizielle Produktankündigungen der 24-Fest­platten-Arrays), findet sich an vielen Stellen, unter anderen in Diskussionsfäden, an welchen auch ein gewisser mainziman teilgenommen hat. Die Forensuche oder Suche via Google ist ggf. ein wenig mühsam, über "Felix", "IOPS" und/oder "RAID" kommt man aber an die ent­sprech­en­den Aus­führungen u.a. von der frü­he­ren Geschäftsleitung (sowohl hier als auch in anderen einschlägigen Diskussionsforen). Die Größe/Art der SAS-Platten bzw. SSDs wird nicht genannt, man kann sich aber ebenfalls aus den Diskussionsfäden ableiten, dass hier wohl eine unterschiedliche Aufteilung zwischen VPS/RS bzgl. Anzahl der Kunden vorgenommen wird.
      • Technisch wird hier dem Nutzer o.B.d.A. höchstwahrscheinlich ein einzelnes "logical drive" durchgereicht (vom Hardware-RAID-Controller verwaltet), welches das Betriebssystem nur als Einzelfestplatte erkennen kann, aber dennoch über vier Platten à 1/4 der Netto-Kapazität definiert ist. Dazu gibt es in der Do­ku­men­ta­tion der Controller-Hersteller wie Adaptec oder in den Wikis mehrerer Mitbewerber von Netcup entsprechende Erläuterungen (mit Ab­bild­ungen). Net­cup selbst hat dies meines Wissens bislang allerdings nicht in dieser Formulierung erläutert. (Ich vermute allerdings, dass auch Netcup nur mit Wasser kochen kann, was diese Schlussfolgerung zulässt…)

    [*] Fast immer… Es gab schon Aktionsangebote, die mit so heißer Nadel gestrickt waren, dass Netto-/Bruttokapazität initial durcheinander geworfen wurden. Das hat sich in jüngster Zeit aber gebessert. Auch dieser Umstand findet sich hier im Forum "irgendwo" dokumentiert.

    ich hätt nämlich gerne die SAS Variante mit wirklich echten 4 x 120 GB;)

    Genau diese wird doch verkauft – fest in einem RAID10-Array verschaltet (wie angegeben), was (inmplizit) eine Netto-Kapazität von 4 x 120GB / 2 = 240GB ergibt.

    Gegen eine Ergänzung um die letztgenannte Angabe bei den Angeboten spricht allerdings wirklich nichts… ;)