Beiträge von gunnarh

Zitat von Bud

Kann ich einen (sehr langen) CalDAV link via CNAME hinter einer Subdomain verstecken - ohne Funktionsverlust?

Nein, Du kannst aber einen URL-Shortener-Dienst verwenden oder einen Link der auf einen von Dir kontrollierten vHost/WebServer zeigt per HTTP-Redirect weiterleiten.

Mein "Nein" bezieht sich auch auf den Vorschlag damit den Host-Part shorten zu können - das wird nicht gelingen, da der Zielserver über kein Zertifikat lautend auf den CNAME aufweisen wird (außer dieser ist unter Deiner Kontrolle, aber dann bräuchtest Du diese Konstruktion ja gar nicht).

Interessantes Finding aRaphael ... ich hatte es (ohne es zuvor in den englischsprachigen AGB nachgeschlagen zu haben) sinngemäß immer so in Erinnerung, dass die Produkte mit dedizierten CPUs dies erlauben, jene mit shared CPUs eben nicht. Also dann über netcup.de statt netcup.eu bestellen und bessere AGB erhalten

According to the T&C this is prohibited:

• Operation of mining-services such as "Bitcoin", "Ethereum", "OneCoin" or "Monero".
• Running server services that cause a particularly high CPU load; this does not apply in the case of dedicated and root servers [a VPS is not a root-server!]

Using the provided RAM ist not a problem. Acting permanently with 100% CPU Load will raise attention.

Wie Paul schon völlig richtig schrieb, wertet die Website offenbar den Referer aus

Mit folgenden exemplarisch geprüften Referern erhält man einen Fehlercode:

• https://www.google.com/
• https://www.google.de/
• https://www.yahoo.com/
• https://www.bing.com/

Versucht man es hingegen mit anderen Referern, wie z.B. https://www.netcup.de/ dann klappt der Abruf.

Somit hat da jemand in der Website irgend eine "Sonderbehandlung" für Aufrufe mit Suchmaschinen als Referer konfiguriert.

Zitat

Option --reuse-key

Wenn man es "händisch" aufruft oder scriptet und der verwendete CertBot dies so unterstützt vermutlich die einfachste Variante.

Wer das Renewal dem Certbot-Cronjob-Automatismus überlässt kann je nach Implementierung "reuse_key = True" in der Config setzen.

Wenn kein CertBot / Let's Encrypt verwendet wird kann man auch den TLSA-Record beim Zertifikatstausch zeitgerecht ändern, bedeutet es müssen überschlagend mindestens zwei gültig sein. Braucht halt Vorlaufzeit, weil DNS ja bekanntlich Zeit zum Propagieren braucht. Den TLSA-Record unverändert beibehalten zu können hat jedenfalls Vorteile.

Mich wundert, dass hier noch keiner die Frage des Lifecycles des verwendeten Schlüsselmaterials und Zertifikats gestellt hat.

Zitat von H6G

Dann: DANE-EE, Use public key, Digest deiner Wahl (256, oder 512), PEM Format vom Zertifikat selbst einfügen, Port 25, TCP, FQDN vom Mailserver.

Ja, das kann man so machen.

ABER: Man muss auf Let's Encrypt / CertBot Seite auch zwingend dafür sorgen, dass das Schlüsselpaar bei der Erneuerung des Zertifikats wiederverwendet werden muss! Wie man das "zu Fuß" durchführt habe ich vor Jahren mal hier aufgeschrieben. Mittlerweile können die CertBot-Implementierungen das aber auch selbst, und man muss nicht mehr einen CSR mit OpenSSL selbst generieren.

Ein paar der genannten Punkte könnte man denke ich seitens Netcup elegant und mit wenig Aufwand lösen, indem man den kostenpflichtig buchbaren NFS-Storage für die Snapshots nutzbar machen könnte.

Nochmal zurückzukommen auf den orangen Mitbewerber aus Berlin. Sicher, dass da kein IPv6 möglich ist? Immerhin gibts in den FAQ sogar einen Abschnitt zur Einrichtung von IPv6 auf Linux Servern ... waren das dann andere Server (die nun nicht mehr angeboten werden) bei denen das möglich war?

Ich hoffe ja doch, dass man über Deine Postfix Instanz ausschließlich mit Anmeldung Mails versenden kann?

Insofern verstehe ich die Frage nicht - jemand der nicht authentifiziert ist soll doch gar nichts versenden können.

Wie dem auch sei. Die Search-Keywords Postfix Conditional use of relayhost sollten zu Treffern führen.

Ich vermute mal das Hilfe-Gesuch fällt unter "Satire":

• Klingt nach Google-Translate vom Prinz aus Afrika.
• Die verlinkte Site ist ein nur ein HTML-OnePager ohne Text-Inhalt.
• Einziger Inhalt eine von https://www.mercedes-benz.com/…m/benz-patent-motorwagen/ ohne Urheberrechts-Kennzeichnung (Rechte-Situation unbekannt) übernommene, dafür statt im 16:9 Original-Format ins 4:3 Format verzerrte Grafik.
• Im HTML-Header / TAB-Beschriftung steht "Patentmann sincesince 1994", auf der Seite selbst in großen Lettern in die Grafik eingebettet allerdings "Patentmann since 2000" ... nun gut, 6 Jahre auf oder ab ist vermutlich nur ein Richtwert.
• Google-Analytics-Einbettung ohne DSGVO-konformer Einwilligung
• Fehlendes Impressum

... ob diese "Visitenkarte" und dieses Gesuch daher seriöse Dienstleister anzieht .... ich selbst hätte jedenfalls kein Interesse.

Aber immerhin die korrekte Kategorie "Smalltalk" hierfür gewählt.

js.org unterstützt laut Beschreibung nicht nur GitHub-Pages, in https://github.com/js-org/js.o…b/master/cnames_active.js findet man durchaus auch einige extern (nicht auf Github) gehostete Domains.

js.org stellt nur den DNS CName von themes.js.org -> themesjs.de bereit.

Du musst themes.js.org hierfür als externe Domain anlegen, der vHost des WebHostings muss diesen ServerAlias kennen. Möglich ist das mit dem WebHosting denke ich, sofern Du noch eine externe Domain im Kontingent "frei" hast.

Basierend auf den mir inzwischen vorliegenden E-Mails kann ich folgendes zur "Datenqualität" dieses Phishing-Angriffs sagen:

• Die Adressaten sind jeweils nicht E-Mail-Adressen aus dem Whois, die mit der Domain "verknüpft" wären. Sondern es sind E-Mail-Adressen die ziemlich sicher von den entsprechenden Websites z.B. mittels Crawling "entnommen" wurden. Also E-Mail-Adressen, die auch teils gar nicht die gleiche Domain-Endung tragen. wie die Domain von der behauptet wird eine "Verlängerung" wäre nötig.
• Die betroffenen Websites sind alle auf netcup vServern gehostet, da muss also jemand jeweils wirklich geprüft haben, dass der Webserver in einem Netcup-IP-Subnetz läuft. Die Domains selbst sind hingegen gar nicht bei Netcup sondern bei anderen Domain-Registraren registriert.
• Der Link scheint jeweils einheitlich auf die gleiche oben bereits genannte URL-Shortener URL zu zeigen. Ist also nicht an den Adressaten individuell angepasst.
• Der Angriff ist deshalb für die Empfänger besonders "irreführend", weil da eben nicht die Webmaster oder die Domain-kundigen Personen aus dem Whois mit diesem Phishing-Versuch gespammt werden (denen würde ja z.b. auffallen, dass die Domain gar nicht bei netcup registriert ist und wären auch fachkundig genug die gefälschte ControlPanel-Domain aus Indien zu erkennen), sondern irgendwelche Kontaktadressen die von den Websites gecrawlt wurden und daher potentiell bei nicht-IT-affinen Personen landen.

Zitat von DaSch22

Eine Frage. Schaut sich ein Laie nicht die ganze "Von" Adresse an?

Der Screenshot stammt ja von mir, bei den Adressaten auf Smartphones ist die Adresse nicht so prominent dargestellt, wäre aber außerdem ohnehin auch einfach fälschbar gewesen. Vermutlich haben die Täter hier bewusst keine reply-fähige Netcup-Adresse eingesetzt, damit Netcup nicht gleich durch Antworten/Rückfragen auf diesen Angriff aufmerksam wird.

Zitat von aRaphael

Bei mir schlägt sofort Chrome an

Hmm.. erfreulich wenn er das mittlerweile tut. Wobei ich nicht wüsste warum / basierend auf welchen Daten oder welcher Heuristik das so wäre.

Denn soeben um 12:57 geprüft, keine Meldung vorliegend: https://transparencyreport.goo…olpanel.netcup.co.in%2Fde

pasted-from-clipboard.png

Siehe bereits existierender Thread nebenan

bugwelle zeigt Dein erhaltener Link auch nach is.gd/nFpv3v oder eine andere URL die man ebenfalls noch melden sollte?

Vorsicht!

Ich und mehrere Bekannte haben in den letzten Stunden E-Mails erhalten, die vermeintlich von Netcup stammen.

Die E-Mails sehen für einen Nicht-IT'ler auf den ersten Blick authentisch aus, Netcup GmbH ist als From-Display-Name angeführt, das original-Netcup-Logo befindet sich in der E-Mail. Eingeliefert wurden die Mails aber über yandex.net/

Betreff ist stets: Domain xxxxxx.at mit auslaufendem E-Mail-Konto

wobei der domain-Name, die verwendeten E-Mail-Adressen etc... "passend" zum Kunden sind.

pasted-from-clipboard.png

Man wird aufgefordert seine Domain zu verlängern. Dazu soll man auf einen Link klicken der diesen URL-Shortener benutzt: is.gd/nFpv3v (ich habe bei is.gd diesen Link bereits als Fraud gemeldet, bislang ist aber noch keine Sperre erfolgt).

Man landet damit auf customercontrolpanel.netcup.co.in/de ... ein gefälschtes NetCup CustomerControlPanel.

pasted-from-clipboard.png

Dort kann man sich mit beliebiger Kundennummer und beliebigem Kennwort "erfolgreich" anmelden (also Phishing) und landet auf einer Kreditkarten-Eingabemaske:

pasted-from-clipboard.png

Moderatoren bitte um interne Beurteilung, man sollte denke ich versuchen diese über CloudFlare gehostete Domain down zu nehmen!

ah... netcup's Netzwerk-Connectivität ist zurück. Erleichterung kehrt ein.

Zitat von https://www.netcup-status.de/

Wir nehmen am Donnerstag, 26.01.2023, von 22:45 Uhr, bis voraussichtlich Freitag, 27.01.2023, 00:15 Uhr, Wartungsarbeiten am Netzwerk vor.

Die durchzuführenden Arbeiten werden keine Einschränkungen verursachen.

... naja. die letzte Aussage kann ich derzeit nicht bestätigen. Alles unerrreichbar bis auf dieses Forum und die netcup-status.de site.

Zitat von frank_m

Link Aggregation

Hast das schon mal jemand versucht und die 100MBit vervielfacht?