Beiträge von gunnarh

Deine IPTables Scripts behandeln nur IPv4, kein IPv6

UFW handled mir die IPv6-Regeln völlig automatisch und synchron dazu mit.

30x sudo iptables aufzurufen ist nicht grade hübsch, man legt sich dazu EIN Script an welches man von einem einzigen sudo iptables laden lässt.

Wo hängst Du das IP-Tables Script ein? Wie überwachst Du, dass die Regeln korrekt appliziert wurden und auch bei Restart von Networking oder der Maschine wieder zur Anwendung kommen? Alles Dinge, die man freilich auch selbst sich überlegen und wunderbar lösen kann, aber man kann freilich auch das Framework das sich andere dafür schon ausgedacht und implementiert haben nutzen -> UFW.

Wenn Du kein UFW verwenden möchtest, dann erfinde zumindest nicht die Lösung neu, sondern mache es so wie die Debian-Leute es empfehlen.

Welche Distribution setzt Du ein?

Ich bin mittlerweile davon abgekommen IPTables manuell mittels Scripts zu konfigurieren, verwende stattdessen das (zumindest bei Debian und Ubuntu) nutzbare Paket uwf (auf Ubuntu ohnehin per Default installiert, auf Debian über die Paketverwaltung nachinstallierbar).

Danke @Georg für den Hinweis auf Reseller-Account.

Nach Durchsicht des Threads Reselling von Domains: Geschlossene Beta-Phase gestartet denke ich aber, dass der Unterschied für Reseller nur die freie Handle-Verwaltung ist, andere Unterschiede hätte ich in den dort geposteten Screenshots jetzt nicht bemerkt. Vielleicht kann sich ja [netcup] Felix P. oder [netcup] Johannes B. hierzu äußern.

Wenn man also nicht bei der Bestellung bereits seine eigenen Nameserver angeben oder - noch besser - gleich alle Daten im Zuge des Transfers unverändert übernehmen kann, dann bliebe mir nur zu pokern.

Die Reload-Zeiten bei nic.at sind 1:00, 3:00, 5:00, 7:00, 9:00, 11:00, 13:00, 15:00, 17:00, 19:00, 21:00 und 23:00 Uhr (MEZ).

Wenn ich angenommen um 19:05 transferiere bleibt mir hoffentlich genügend Zeit bis 21:00, in der hoffentlich der Transfer abgeschlossen ist und ich alle Einstellungen (DNSSec und Nameserver-Einträge) wieder wie gewünscht übers Netcup-Domainverwaltungs-Interface konfiguriert habe, sodass die zwischenzeitlich gesetzten NetCup-Nameserver-Einträge gar nie nach außen sichtbar geworden wären. Hat jemand hier schon eine .at Domain transferiert? Geht das in "Echtzeit" und werden die Änderungen vom Roboter zeitnah in der nic.at Registry eingetragen, sodass sich dieser Plan zeitlich ausgeht?

Danke CmdrXay für den Screenshot - aber das scheint mir ein Screenshot aus Deiner Domain-Verwaltung NACH Abschluss der Bestellung bzw. des Transfers zu sein. Während des Bestell- bzw. Transfer-Prozesses wird offenbar NICHT angeboten eigene Nameserver einzutragen.

Dein Hinweis betreffend TTL zeigt mir zudem, dass Du meine Frage bzw. mein Wunschszenario offenbar missverstanden hast. Ich will nur den Registrar wechseln, ich will KEINE Nameserver wechseln. Ich betreibe drei authoritative Nameserver selbst und das soll auch so bleiben. Die in der nic.at-Registry hinterlegten Nameserver und DNSSec-Einträge sollen beim Transfer möglichst unberührt bleiben.

Ich möchte eine .at Domain ohne Unterbrechung zu Netcup transferieren. Im Zuge des Transfers sollen also die bei nic.at die hinterlegten Nameserver NICHT verändert sondern meine drei bestehenden Nameserver beibehalten werden.

Sehe ich das richtig, dass das nicht möglich ist? Der hier unter https://www.netcup-wiki.de/wiki/Domains_CCP#Bestellung skizzierte Bestellprozess sieht offenkundig keine Beibehaltung der bestehenden NS-Records oder die Angabe von Kunden-Nameservern vor, sondern provisioniert erst mal jedenfalls die NetCup-Nameserver, was natürlich eine Unterbrechung der Verfügbarkeit meiner Services auf dieser Domain zur Folge hat.

Welche Debian-Version nutzt Du?

Ich mutmaße Du hast nicht auf Debian 9 (Stretch) migriert, sondern nutzt die OldStable Debian 8 (Jessie) oder gar noch Debian 7 (Wheezy).

Bei Debian 9 käme PHP7 automatisch mit, ältere Releases bieten über die Paketverwaltung regulär aber nur PHP5 an.

Wenn Du Deine Debian-Release nicht auf 9 (Stretch) hochziehen willst oder kannst, kannst Du durch Nutzung alternativer Paketquellen wie z.B. https://www.dotdeb.org dennoch auf Debian 7 oder 8 bereits PHP7 einsetzen.

Technisch theoretisch zwar möglich, aber ich wüsste ad-hoc nicht wie du das auf einer bei NetCup gehosteten VM korrekt lizenzierst. Microsoft lizenziert keine VMs, sondern physisches Blech mit physischen CPUs bzw. Kernen. Ich würde für so ein Vorhaben daher einen Hoster wählen, der dir die Windows-Lizenz mitvermietet oder gleich in der Microsoft Azure Cloud hosten, dann brauchst Du Dich um die Lizenzierung nicht zu kümmern. Was das VPN angeht würde ich mich in Direct Access und Offline Domain Join einlesen.

Hier habe ich gelesen, dass IPv4 + IPv6 GLUE Records funktionieren sollten - jedenfalls habe ich das so interpretiert. Wäre nett zu erfahren ob es geht, das Wiki schweigt sich dazu ja leider aus.

Fehlercode SC-001 scheint mir nicht zu bedeuten, dass Du auf der Microsoft-Blacklist stehst, eher das du auf irgend einer Blacklist stehst, prüfe das mal z.B. mit http://rbl-check.org/

Man kann dir übrigens schlecht helfen, denn mir scheint Du hast im Ursprungsposting Angaben verschleiert die zur Beurteilung nötig wären - denn die teils unkenntlich gemachte IP-Adresse Deines MTA passt mit mail.xy.eu nicht zusammen, ich bezweifle, dass es um die Domain xy.eu geht.

Mein Feedback: Schließe mit thys und Hecke29 an. Euer Engagement ist gut gemeint - und vermutlich macht es euch Spaß und ihr lernt was dabei. Aber auch mir ist die Zielgruppe dieser Lösung unklar.

Was ihr hier tun möchtet ist klassische "Desired State Configuration".

Server nehmen, sagen welche Dienste drauf sollen, und ein Mechanismus soll sich vollautomatisch um die Provisionierung kümmern.

Das löst man heute nicht mehr mit Scripts, sondern mit Puppet oder dem schon genannten Ansible. Module auf denen man aufsetzen kann finden sich zur Genüge, man kümmert sich nicht mehr um das "wie konfiguriert man das" sondern legt schlicht nur mehr fest wie die Konfiguration aussehen soll.

Ist der Server mal "verkonfiguriert" wird der Agent einfach erneut aufgerufen und stellt die gewünschte Konfiguration wieder her. Ist nichts zu tun, weil die Config bereits wie gewünscht vorliegt tut der Agent auch nichts (desired state config / idempotent aufrufbar).

Jemand der ein gehobenes Schutzniveau benötigt wird wohl kaum ein Shared-Webhosting dafür nutzen.

Immerhin teilt man sich dabei nicht nur die TLS-Settings mit allen anderen Kunden. Man teilt sich das OS, die Webserver- und die Datenbank-Instanz. Wer ein überdurchschnittliches Schutzniveau sucht oder benötigt, wird daher Wert auf Abschottung des Systems legen und sich nicht die angesprochenen Software-Instanzen mit anderen Unbekannten teilen, sondern im Minimum eine eigene (virtuelle) Maschine für seine Bedürfnisse nutzen.

Auch für Android 4 und Java 7 gibts es keine Patches mehr.

Der Verbreitungsgrad ist dennoch nicht auf 0% abgesunken.

Als Anbieter von Content habe ich die freie Wahl des Anbieters, der Lösung und des Schutzniveaus.

Was ich mir jedoch nicht direkt aussuchen kann ist, mit welchen Clients meine Nutzer zugreifen.

Auf meinem eigenen Server kann ich freilich eine Entscheidung treffen, und den Trade-Off Kompatibilität versus Security in Richtung Security verschieben. Damit nehme ich dann eben in Kauf, dass nicht mehr alle Anwender meine Inhalte nutzen können.

Auf einer Shared-Hosting-Plattform (die man sich ja mit anderen teilt) muss dieser Trade-Off jedoch ausgewogen und dem typischen Content und Schutzbedarf angepasst gewählt werden. Hier zu fordern, dass TLS 1.0 und 1.1 ausgeschaltet werden müssen erscheint mir persönlich überzogen. Immerhin hosten darauf die Mehrzahl der Kunden vermutlich nur einfache Informationsangebote, deren Interessenten dann eventuell ausgesperrt sind. Oder wie erklärst Du dem Betreiber einer Frühstückspension, warum die Windows XP nutzenden Kunden aus Asien plötzlich ausbleiben und nicht mehr Preise und Zimmerausstattung nachschauen können?

Die Diskussion hier vergisst aus meiner Sicht auf einen sehr wesentlichen Aspekt: Welchen Wert haben denn die Daten, die auf shared Webhosting-Accounts bei NetCup liegen? Ich mutmaße mal, dass die Vertraulichkeits- und Integritäts-Anforderungen für 99% der Kunden die hier Webhosting-Accounts nutzen völlig egal sind. Da liegen vermutlich ohnehin nur die im Public-Web frei verfügbar gemachten Inhalte drauf.

Ich bin auch kein Fan davon, alte CipherSuites bis zum Sankt-Nimmerleinstag weiter zu unterstützen. Aber auf Shared-Webhosting legt doch hoffentlich niemand sensible Daten ab, die dann ausschließlich mittels starker Chiffren ausgeliefert werden dürfen? Wenn jemand solche Anforderungen hat, dann wird er mit diesem Requirement wohl eher einen Managed-Server wählen oder sich der Sache selbst annehmen - immerhin werden diesbezüglich ja im Produkt-Angebot auch keinerlei Zusagen gemacht.

Wer sich einen Überblick verschaffen möchte, welche Clients welche Crypto-Merkmale unterstützen, dem sei diese Übersicht hier ans Herz gelegt:

https://www.ssllabs.com/ssltest/clients.html

Man muss übrigens gar kein Windows XP einsetzen, um von der Thematik betroffen zu sein. Ein 3 Jahre altes Android-Phone mit Android 4 oder eine Java7-Applikation reichen auch aus, um mit einem "streng" konfigurierten Server nicht mehr kommunizieren zu können.

Um welche Domain / Subdomain gehts?

plausible Gründe könnten ins Blaue geraten sein:

1. ein oder mehrere autoritative Nameserver ausgefallen bzw. gestört
2. Nameserver nicht synchron
3. DNSSec aktiviert? Wenn ja eventuell Signaturen abgelaufen / ungültig (geworden).
4. IPv6 enabled? Eventuell Records inkl. Glue-Records zu groß um in einem UDP Paket beauskunftet werden zu können.

Das müsste eigentlich die Funktion "Herunterfahren (ACPI)" aus dem Server Control Panel sein.
Wenn das jemand über das SCP ausgelöst hat, dann wird das im SCP Protokoll mit "Server ACPI Stop Signal gesendet" vermerkt.
Würde mal das SCP Protokoll prüfen, eventuell konnte sich jemand auf das SCP Zugriff verschaffen.

Wenn dort nichts verzeichnet ist, würde ich den Support fragen - vermutlich musste der Host neu gestartet werden.

Ich kann in https://cabforum.org/2017/03/08/bal…king-mandatory/ keinerlei Pläne erkennen, dass ein CAA-Check in Browsern geplant wäre.
Da geht es bislang nur um Certificate Authorities, die CAA Records im Zuge der Zertifikats-Ausstellung prüfen sollen bzw. bald müssen.

Ich kenne Plesk nicht, aber eine kurze Google-Recherche zeigt mir, dass man mit Plesk sehr wohl die Firewall als auch die Settings der nginx vHosts konfigurieren kann.

Wenn Du meinst das fällt in den Aufgabenbereich von Netcup, dann wende Dich an den Support. Ich persönlich würde angesichts der Produktbeschreibung aber davon ausgehen, dass alles was über Plesk konfiguriert werden kann eher in deine Sphäre fällt. Vielleicht kann Dir hier im Plesk-Subforum jemand weiterhelfen, andernfalls halt ein spezialisiertes Plesk-Forum, die Doku oder doch den Support bemühen.

Du hast uns keinerlei Infos zu Deinem System gegeben.
Kaffeesud-lesen ist daher etwas schwer.

Meine Glaskugel sagt mir, dass Du nginx und Plesk 12.5.30 auf einem Debian 8 System einsetzt?

Offenbar gibts bei diesem vHost ein Problem mit der ServerNameIndication, sodass zumindest zeitweise das falsche Plesk-Default-Zertifikat ausgeliefert wird.
Ich mutmaße mal, doppelt angelegter vHost/Alias-Name oder sowas in der Richtung. Ohne Deine Configs zu kennen ist das aber nur herumraterei.

Übrigens: Dein System exponiert eine mySQL/MariaDB ohne Firewall nach außen - das ist aus Security-Sicht eher nicht best practice.

Auf https://forum.literaturschock.de meldet sich (wenn man ein paar Requests absetzt) abwechselnd ein Let's Encrypt und ein Plesk Zertifikat, mal so mal so.

file "/var/cache/bind/123.de.zone.signed";

Das ist falsch, du musst in der Zone das unsignierte, menschenlesbare Textfile konfigurieren, nicht das signierte!
Das .signed File sowie die Journale .jnl werden dann aufgrund der Konfiguration mit "auto-dnssec maintain; inline-signing yes;" völlig automatisch von Bind verwaltet.

Wenn Bind die zone neu signiert, dann ändert sich auch automatisch die Serial um ein paar Ticks nach oben.

Du kannst die signierte Zone (die ja nicht menschenlesbar ist, also ein Binärfile, kein Textfile) folgendermaßen prüfen:

named-checkzone -D -i full -f raw $domain $ZONEDIR/$domain.signed >/tmp/$domain.txt
ldns-verify-zone /tmp/$domain.txt -S -V 4 -k $KSK -k $ZSK