Beiträge von gunnarh

Ist das ein KB19-privilege-Feature oder geht das nun generell?

Und wenn generell, wo liegt nun das Limit?

Ist das ein Server mit zugebuchtem bzw. zubuchbarem Local-Block-Storage?

Dein Mailing muss ja nicht geändert werden, evtl. die Kennwörter (falls da was kompromittiert ist, z.B. weil Credentials in den PHP-Scripts irgendwo hinterlegt waren).

Dein Webhosting leerst du komplett aus und spielt einen sauberen Stand aus einem Backup ein.

Anmerkung/Nachtrag: Ich gehe davon aus, der Fragesteller benutzt ein Webhosting und keinen vServer (andernfalls würde die gewählte Rubrik hier keinen Sinn machen!)

> Optimistisch und offen für Ideen & Anregungen

Sorry, das klingt jetzt hart: Aber mit Deinen Skills wird Dir das nicht gelingen.

Du kannst freilich alles "cleanen" und dann dein Access-Log überwachen und das Filesystem auf Änderungen überwachen und die Zeitstempel wenn ein neues File entsteht oder eines geändert wird mit den Requests korrellieren ... daraus dann ableiten wo eine Eintritts-Stelle sein muss ... aber das Teil ist garantier zig-fach mit derleit Backdorrs versehen. Das ist einfach eine endlos-mühsame Arbeit und du wirst nie Gewissheit haben.

Zitat von ichhalt033

Heißt aber auch dass die Fa. "Monarx" - obwohl Seriöser Auftritt nur Betrüger sind?

Nein. Das heißt, dass die Malware sich mit diesem Banner tarnt, damit Leute wie Du glauben das wäre was legitimes und es für unverdächtig halten.

Deine Screenshots zeigen keine "Security Solution" sondern Malware.

Schließe mich den Vorrednern an.

Nennt sich Virtual App Delivery - VAD.

z.B.: https://cameyo.com/cameyo-cloud/

Signierte & verschlüsselte Mails mittels S/MIME

Dafür brauchts aber Zertifikate für die Anwender

zur Nutzung im Team hiermit einfach und kostenfrei generiert: https://github.com/gunnarhaslinger/SMIME-OpenSSL-CA

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/de/kunst-und-k…ent-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.org/…names_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.