Beiträge von NaN

www ist ein CNAME, der auf den Host in Tel Aviv zeigt. Deswegen gelten alle anderen Einträge nicht für www, insbesondere nicht der AAAA Eintrag für *. Für die Domain selbst kannst du keinen CNAME eintragen, aber dafür hast du die IPv4-Adresse des Wix-Servers im A-Record hinterlegt. Der AAAA-Record für die Domain selbst ist aber immer noch die IPv6-Adresse des Netcup-Servers. Wenn dein Client also die Seite über IPv6 aufruft, was heutzutage auf den meisten Clients bevorzugt wird, dann landet der bei Netcup, nicht bei Wix. Den AAAA-Eintrag für @ müsstest du also entweder anpassen oder löschen.

Wer wählerisch bei der Annahme von Mail ist, bekommt halt weniger Mail. "Ihre IP Adresse gefällt uns nicht", "Ihr Reverse DNS hat zu viele Punkte / zu viele Ziffern", "Sie verwenden das übliche Internet-Protokoll". Kommunikation funktioniert anders.

Zitat von CuzImBisonratte

in einem E-Mail-Hosting-Paket bei 10n0s, welches ich aber ehrlichgesagt u.a. Preislich echt nicht gerne weiterführen möchte

Ich rate davon ab, den Wechsel jemals so gegenüber einem der "Betroffenen" zu rechtfertigen. Du wechselst, weil dir dort ein wichtiges Feature fehlt, OK? Irgendwas wird nämlich durch den Wechsel kaputtgehen, und dann ist in den Augen deiner Familie deine Geizigkeit Schuld daran: Email kaputt, weil CuzImBisonratte die Familie nichts wert ist...

Zitat von AquaPhantom

Kann mir mal bitte jemand erklären was das ganze mit Wireguard sicherer werden soll?

Hauptsächlich geht es um Ruhe in den Logs. Nach Wireguard VPNs kann man nicht effektiv scannen, deswegen tut das auch niemand und die Logs schweigen. SSH-Zugänge sind heiß begehrt und endlose Versuche mit Account- und Passwortlisten füllen die Logs. Selbst wenn der Server bei jedem Versuch "nur mit Key" antwortet, werden munter weiter Passwörter durchprobiert. Ruhige Logs sind auch ein Sicherheitsaspekt, weil die wichtigen Informationen sonst leicht untergehen.

Man kann dem aber auch direkte Sicherheitsvorteile abgewinnen: Ein Eindringling muss zwei kryptographische Zugangskontrollen überwinden, um Zugang zu bekommen: das VPN und den SSH-Login. Die Firewall kann den SSH-Server besser abschotten, wenn man den z.B. in Verbindung mit einem Jump-Host noch direkt für bestimmte IP-Adressen erreichbar machen möchte, oder man bindet den SSH-Server überhaupt nur an das VPN-Interface. Das macht Fehlkonfigurationen des SSH-Servers weniger gefährlich. Bei Wireguard gibt es keinen Passwortmodus (bzw. nur zusätzlich zum Schlüssel), während man andere VPNs sehr leicht völlig unsicher konfigurieren kann.

Vor allem aber: Ruhe.

Wenn du die Email-Adresse anklickst, kommst du auf eine Seite mit den Einstellungen für die Adresse. Ganz oben, unter der groß geschriebenen Email-Adresse, hat diese Seite mehrere Tabs, und eins davon ist "E-Mail-Aliase".

Wenn du wirklich Ruhe haben willst, mach dir ein Wireguard VPN und lass den SSH-Server nur auf dem VPN-Interface laufen. Nach Wireguard VPNs kann man nicht effektiv scannen, weil die keinerlei Fehlermeldung ausgeben: Wenn der Client den Key nicht kennt, bekommt er einfach gar nichts zurück, genau wie bei einer "drop" Firewall.

Keine weiteren Zugriffe zuzulassen leert ja nicht den Warenkorb, und ob jemand online ist, ist in einem zustandslosen Protokoll auch nicht so leicht zu entscheiden. Schau in die Logfiles, ob noch weitere HTTP-Requests von der IP-Adresse beantwortet werden.

Sowohl die Version von webbi als auch die kürzere mit der anderen order sind geeignet, eine IP-Adresse auszusperren.

Zitat von MyMattes

Müsste die Reihenfolge nicht umgekehr sein

It's complicated. Wenn man nur eine Art von Regeln braucht, zulassen oder aussperren, dann kann man grundsätzlich beide Reihenfolgen nehmen. Die Semantik ist aber nicht intuitiv. Die Reihenfolge ist wichtig, wenn man Ausnahmen von Regeln festlegen will.

"order allow,deny" heißt aussperren, wenn keine Regel oder eine deny-Regel zutrifft.

"order deny,allow" heißt zulassen, wenn keine Regel oder eine allow-Regel zutrifft.

Zitat von webbi

order allow,deny

deny from 147.xx.xx.x

Allow from All

"Aussperren, wenn keine Regel oder eine deny-Regel zutrifft."

Wegen allow from all trifft immer ein Regel zu. Ausgesperrt wird nur die Adresse in der deny-Regel.

Man könnte das auch kürzer umgekehrt formulieren:

order deny,allow
deny from 147.xx.xx.x

"Zulassen, wenn keine Regel oder eine allow-Regel zutrifft." Hier trifft fast immer keine Regel zu, was zulassen bedeutet.

Na dann bezahl doch das Schutzgeld und lass deine IP Adresse von der UCEprotect Level 3 Liste ausnehmen. Der hat extra eine Domain, wo du das Schutzabo gegen seine Sippenhaft abschließen kannst. Es ist ja nicht Netcup sondern UCEprotect, das deine IP-Adresse durch den Dreck zieht, obwohl du hoffentlich alles richtig machst.

Zitat von Bensen

mit vorheriger Freigabe für den IT-Administrator

Es gibt Admins, die sowas wissentlich in ihr Netz lassen? Was machen die beruflich?

Mit der Verschlüsselung ist der Festplatteninhalt allerdings überall geschützt, wo er losgelöst vom Hostsystem gespeichert oder übertragen wird, z.B. im SAN, in Backups, auf defekten ausgetauschten Festplatten...

Zitat von Aljoscha

Was mich Ende noch interessieren würde (Aber nur wenn du irgendwann mal Lust und Zeit hast), wäre eine Skizzierung, wo du wie deine Records setzt und wo du die Challenge initiierst.

Ich nutze das so, wie ich das beschrieben habe, mit einem CNAME von hier zu einer Domain bei deSEC. Daher weiß ich, dass das funktioniert. Der Client schickt den Certificate Signing Request an Letsencrypt (für ein Wildcard-Zertifikat für die Domain bei Netcup), setzt dann den TXT-Record bei deSEC, lässt Letsencrypt darüber die Kontrolle über die Domain verifizieren, holt sich das Zertifikat ab und sorgt dann noch dafür, dass der Server das neue Zertifikat verwendet. Das Umleiten der _acme-challenge Subdomain per CNAME oder Delegation ist ein offiziell unterstütztes Feature. Ich hatte weiter oben schon die Seite verlinkt, wo das steht. Da es unzählige Clients gibt und ich keinen bestimmten empfehlen möchte, belasse ich es bei dieser Konzeptbeschreibung.

Wildcard-Zertifikate gelten nur für die direkten Subdomains, also *.example.com für sub.example.com aber nicht für sub.sub.example.com oder www.sub.example.com.

Mir ist nicht klar, wofür du den CNAME brauchst. Wenn du die Domains sowieso bei deSEC hostest und deren API für den ACME-Client verwendest, kannst du den TXT-Record direkt dort anlegen, wo er gebraucht wird. In meinem Vorschlag verbleibt der größte Teil der DNS-Records bei Netcup und nur die _acme-challenge Subdomain wird zu deSEC ausgelagert, eben per CNAME (oder per Delegation mittels NS-Records).

Zu einem vollautomatischen Ablauf gehört noch etwas mehr: Du musst den ACME-Client natürlich regelmäßig aufrufen und solltest das Ergebnis, das neu ausgestellte Zertifikat, auch dem/den Nutzer(n) des Zertifikats (Reverse Proxy, Webserver, etc.) automatisch zur Verfügung stellen und auch automatisch dafür sorgen, dass das eingewechselte Zertifikat verwendet wird und nicht etwa das, was beim Start geladen wurde.

Zitat von KB19

Für die DNS-API braucht man keinen Resellervertrag.

Danke für die Korrektur. Ich habe die APIs fälschlicherweise zusammengeworfen, was möglicherweise daran liegt, dass die API-Seite "unsere-api" heißt und mit "Die netcup API im Detail" überschrieben ist (Einzahl). Unter "Beantragung eines API-Passworts und API-Keys" steht dann im Screenshot "Um auf dem API Domainfunktionen zu nutzen, schließen Sie bitte einen Domainresellervertrag mit uns." Das kann man vielleicht klarer darstellen.

Wenn du für die Domains verschiedene Zertifikate beantragen wolltest, könntest du das so machen. Mit der DNS-01-Challenge kannst du stattdessen ein Wildcard-Zertifikat für alle direkten Subdomains von server.example.com ausstellen lassen und brauchst dafür nur einen TXT-Record unter _acme-challenge.server.example.com. Dieser Name kann über einen CNAME auf einen anderen Namen verweisen, wo dann der entsprechende TXT-Record sein muss. Das Wildcard-Zertifikat deckt dann api1.server.example.de, api2.server.example.de, webs.server.example.de und alle anderen direkten Subdomains von server.example.com ab (*.server.example.com), was die Konfiguration eines Reverse Proxy für alle diese Domains sehr einfach macht. Du brauchst dann auch nicht so viele Zertifikate ausstellen zu lassen und läufst weniger Gefahr, in Rate-Limits zu stolpern. Ein Zertifikat, das alle Subdomains auflistet (statt *), würde u.U. sehr groß werden und müsste immer neu ausgestellt werden, wenn neue Subdomains dazukommen.

Zitat von DerRené

Ich sehe hier beim TO aber gar keine Anforderung dafür?

Vorteile: Keine Gefahr, irgendwas kaputt zu machen, weil weder der ACME-Client noch sonst etwas auf dem Server Zugang zur Konfiguration der Domain bekommt. Das Risiko, dass jemand mit Zugang zum Server Zertifikate für die Domain ausstellen kann, ist auch bei der HTTP Challenge unvermeidlich. Alles andere kann so aber nicht passieren. Das DNS-API-Risiko scheint ja schon ein Grund zu sein, warum die DNS-Challenge gemieden wird, oder warum sonst wird folgende Warnung zitiert?

Zitat

Beachten Sie, dass die Angabe Ihrer vollständigen DNS-API-Anmeldedaten auf Ihrem Webserver die Auswirkungen eines Hackerangriffs auf den Webserver deutlich erhöht.

Solange man bei Netcup keine API-Credentials erzeugen kann, die auf bestimmte Subdomains oder sogar auf bestimmte Records eingeschränkt sind, halte ich diese Aufteilung für sehr empfehlenswert, auch wenn nicht explizit danach gefragt wird. Wenn man die API auch sonst nicht braucht, spart man sich den Resellervertrag, der das Betriebsrisiko des Accounts ja doch erheblich ansteigen lässt, weil man über die API auch Domains bestellen oder auch wegtransferieren kann.

Mit der CNAME-Lösung muss man außerdem nicht gleich das DNS-Management komplett umziehen, was vielleicht auch eine Hürde ist, die man als Anfänger nicht zusätzlich nehmen möchte.

Ich wiederhole nochmal den Hinweis aus meiner ersten Antwort: Es ist nicht nötig, die Netcup API zu verwenden und folglich auch nicht, die API-Zugangsdaten auf dem Server zu hinterlegen, nur um die Letsencrypt DNS-01 Challenge zu absolvieren. Man kann die dafür nötige Subdomain mit dem TXT-Record, über den der Domainbesitz nachgewiesen wird, als CNAME anlegen und den TXT-Record dann z.B. bei deSEC mit deren API setzen, wenn man den CNAME auf eine Domain dort zeigen lässt. Das ist offiziell unterstützt, siehe die oben verlinkte Dokumentation. Durch das Anlegen eines CNAMEs für _acme-challenge.<YOUR_DOMAIN> macht man auch nichts kaputt und der ACME-Client hat gar keine Möglichkeit, auf die eigentliche Domain Einfluss zu nehmen, nur auf die Records am Ziel des CNAME. Das größte Problem an der Sache ist, dass deSEC im Moment keine Registrierungen für deren DynDNS Dienst zulässt.

Die DNS-Challenge ist sehr zu empfehlen, weil damit auch Wildcard-Zertifikate möglich sind. Die sind besonders für Reverse Proxies sehr praktisch, die mehrere und z.B. für Testzwecke öfter mal wechselnde Subdomains bedienen sollen. Außerdem veröffentlicht man mit einem Wildcard-Zertifikat keine Liste der Subdomains, die man verwendet, an einer Stelle, wo sie von unzähligen Portscannern abgegriffen werden (in den CA-Logs).

Zitat von Win98SE4ever

Die Formulierung in den AGB gefällt mir nicht, denn wie die anderen bereits geschrieben haben gibt es bei netcup keine dedizierten Server zu mieten

Dedizierte Server für den professionellen Einsatz

Ein Problem für Hostingunternehmen überall, nicht nur für Netcup, ist, dass das Preisgefüge auf einer Mischkalkulation beruht(e), die nur funktioniert, wenn Kunden ihre gemieteten Ressourcen nicht dauerhaft auslasten. Seit der Cryptoschwemme gibt es etliche parasitäre Systeme, die Ressourcen zu Geld machen, die sie über die Teilnehmer billig beziehen, für die es sich wiederum nur lohnt, wenn sie die Ressourcen unter Wert bekommen.

Warum sind SSDs teuer? Weil es Cryptosysteme gibt, bei denen du dafür belohnt wirst, wenn du nachweislich SSD-Speicher belegst. Warum ist CPU-Leistung teuer? Weil es Cryptosysteme gibt, bei denen du dafür belohnt wirst, wenn du nachweislich CPU-Leistung verbrätst.Warum sind "Grafik"-karten teuer geworden? Weil man damit Cryptomining betreiben kann. Jetzt kommt auch noch "AI" dazu. Und so weiter. Es gibt auch Cryptosysteme, wo du explizit Ressourcen zur Verfügung stellst, die als "Web 3.0" an andere vermietet werden - und dabei natürlich voll ausgelastet werden. Warum sind Reseller-Systeme teurer als Endkundenprodukte? Weil man bei Resellern von einer höheren Auslastung ausgeht. Aber diese Cryptojünger machen das mit Endkundenprodukten und ruinieren damit die Mischkalkulation. Die hosten das nicht in den diversen Clouds, denn dort wird man für jeden CPU-Takt und jedes übertragene Byte zur Kasse gebeten. Damit lohnt sich das nicht.

"Crypto" ist Arbitrage der übelsten Sorte, denn da werden ganze Produktklassen unbrauchbar gemacht, die nur funktionieren, wenn sich die Nutzer anständig verhalten und nicht alles schrabben, was sie kriegen können, wie sprichwörtliche Heuschrecken, die über ein All-you-can-eat Buffet herfallen.