Beiträge von gunnarh

    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.


    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.google.com/safe-browsing/…tcup.co.in%2Fde

    pasted-from-clipboard.png

    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!

    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.

    Ja, als ich schrieb "Falls der Webserver nicht ohnehin schon so vorkonfiguriert ist, dass er dann impressum.php ausliefert ..." meinte ich Optionen wie MultiViews. Wer so etwas bereits aktiviert hat braucht meinen RewriteRule-Vorschlag also eventuell gar nicht. Persönlich habe ich gerne mehr Kontrolle darüber wie Apache das genau macht und verwende daher bevorzugt RewriteRules. Aber manche Leute stehen mit Regular Expressions und insbesondere Apache RewriteRules auf Kriegsfuß, denen ist vielleicht MultiViews lieber.

    Man verlinkt weder .html noch .php Dateien.

    Links setzt man stets auf technologie-neutrale URLs. Wenn die Datei also impressum.php heißt dann nur "impressum".

    Falls der Webserver nicht ohnehin schon so vorkonfiguriert ist, dass er dann impressum.php ausliefert hilft folgende generische Rewrite-Rule in der .htaccess-Datei oder vHost Konfiguration:

    Apache Configuration
    RewriteEngine on 
    AddType application/x-httpd-php .php
    RewriteCond %{REQUEST_FILENAME} !-d 
    RewriteCond %{REQUEST_FILENAME}\.php -f 
    RewriteRule ^(.*)$ $1.php [NC,L]

    Nein, aber Du kannst Dir ein kleines Verwaltungs-Panel mit den von Dir gewünschten Funktionen über die von NetCup bereitgestellte API selbst programmieren und dies dann authentifiziert Deinem Kunden bereitstellen. Vielleicht gibt es hier im Forum ja jemanden der soetwas schon umgesetzt hat und seinen Source teilen möchte.

    Andere Frage: Wie erstellst Du denn derzeit Dein Backup?

    Was würdest Du denn tun, wenn Dein Server heute unerwartet "crasht" (z.B. defektes Host-System, Disk-Image beschädigt, nicht mehr zu retten).

    Dann müsstest du ja aus Deinem Backup auch irgendwie Bare-Metal-restoren?

    Ich sichere z.B. mit VEEAM auf einen bei einem anderen Anbieter liegenden CIFS-Storage.

    Restore funktioniert durch Einlegen des VEEAM.iso Image und mount des CIFS-Storage + entsprechender Wartezeit. Letzteres teste ich ab und an mal in einer VM zuhause.

    Ich teile die Enttäuschung darüber, wie Netcup das mit den SnapShots löst. Also das Erstellen eines Snapshots nur dann zulässt, wenn <50% des Disk-Image-Files aus Sicht des Hypervisors belegt sind.

    Mir ist schon klar, dass ein CopyOnWrite-basierter Snapshot dazu führen KANN, dass im Worst-Case tatsächlich doppelt so viel Speicher benötigt wird wie aktuell belegt ist.

    ABER: Dieser Worst-Case würde ja nur eintreten, wenn man nach Erzeugen des SnapShots tatsächlich alle vorhandenen/belegten Blöcke verändert.

    Meist möchte man einen Snapshot anlegen, weil man für ein paar Stunden ein "Sicherheitsnetz" möchte (z.b. OS-Update). Oder weil man wie von Dir hier skizziert ein Image exportieren möchte. In diesen Fällen ändern sich aber keine 100% der Blöcke sondern nur wenige Prozent.

    Auch ich würde NetCup daher ersuchen hier eine bessere Lösung zu finden.

    Vorschlag:

    * Es müssen 15% (nicht wie bisher 50%) des Speichers frei sein

    * Wenn nach Erstellung des Snapshot die Belegung insgesamt (VHD + Snapshot) sich der Gesamtkapaziät nähert soll eine Warnung erfolgen.

    * Von mir aus kann - wenn die Gesamtkapazität erreicht ist - auch der Snapshot automatisch aufgelöst oder der Server nach entsprechender Vorwarnung gestoppt werden.

    => Wäre jedenfalls alles besser als der aktuelle eher unbrauchbare Status-Quo.

    Netcup bietet doch gar keine "Hoster-Firewall" (was auch immer das sein soll?).

    Wenn Du "Host-Firewall" meintest solltest Du noch einmal einen Moment inne halten und darüber nachdenken, wie Du einen root davon abhalten möchtest die einfach zu deaktivieren.

    Nur zwecks Dokumentation.... das von mir hier vor fast zwei Jahren beschriebene Problem vom Oktober 2020 ist weiterhin in identischer Form vorhanden.

    Wurde also in den letzten zwei Jahren leider NICHT gelöst.

    Ich habe abermals ein Support-Ticket eingebracht, bislang keine Antwort - rechne auch mit keiner da ich inzwischen einen Workaround gefunden habe.

    Da ich diese Woche abermals 2x meine GLUE-Records der .at Domain anpassen musste (Übersiedelung auf neue Server) konnte ich folgenden Workaround "erarbeiten" und als funktionstüchtig validieren. So entgeht man diesem Bug:

    Vorbereitung: Nachschauen wann die NIC.at Reload-Zeiten sind, sich einen Zeitpunkt suchen zu dem kein Reload stattfindet (Die Reloads finden zu festgelegten Zeiten zur vollen Stunde statt, wenn man den Vorgang also um xx:20 durchführt dann hat man jedenfalls 40 Minuten Zeit bis zum nächsten potentiellen Reload der .at Zonen). Derzeit findet der Reload laut nic.at zu folgenden Zeiten statt: Unsere Reload-Zeiten sind um 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) [Anmerkung: Jetzt im Sommer ist es getesteter Weise MESZ und nicht MEZ, oder einfacher ausgedrückt: Zeitzone Vienna].

    Weiters Vorbereitung: Wer DNSSEC benutzt notiert sich vor dem Umschalten die hierfür nötigen Parameter, damit man diese nicht erst nach dem Zurückschalten auf eigene Nameserver dann erst mühsam neu recherchieren werden müssen. Die DNSSEC-Parameter lassen sich nach dem Zurückschalten auf eigene Nameserver erst nach dem Speichern wieder eingeben.

    1. Im CCP bei der .at Domain von eigenen Nameservern auf die Netcup Nameserver umschalten und speichern (man muss dazu nichts befüllen, einfach umschalten und ohne zu befüllen auf speichern drücken reicht aus).

    2. Whois der eigenen .at Domain prüfen - nun sind die Netcup-Nameserver eingetragen, technisch wirksam würde das erst zum nächsten nic.at Reload-Zeitpunkt

    3. Nun wieder auf eigene Nameserver im CCP umstellen und die Daten vollständig neu eintippen, speichern

    3b. Optional: Falls DNSSEC benutzt wird, nun auch diese Daten eingeben und speichern (ist erst nach Speichern der eigenen Namserver-Namen + GlueRecords möglich)

    4. Whois prüfen ... voila - sofort übernommen. Die eigenen Nameserver mit den nun hinterlegten GLUE-Records scheinen im WHOIS auf.

    5. Abwarten bis zum nic.at Reload, dann werden die glue-Records in die .at Zone übernommen.

    seltsame Probleme ...

    (-2 points) Your "from" domain does not match your DKIM "from" domain or does not have DKIM signing.

    (-1 points) The DKIM signature is not from the author's or envelope-from domain.

    (ist doch logisch, wenn man f. alle Domains das selbe verwendet ...)

    Warum verwendest du für alle Domains "das selbe"?

    Wenn du OpenDKIM einsetzt ist "SigningTable" und "KeyTable" das Stichwort dies zu lösen. Selbst wenn du für alle das gleiche Schlüsselpaar verwendest, die Config hierfür sollte schon "pro Domain" erfolgen. Kann man für alle Postfix "local-host-names" (das können in einem Multi-Domain-Setup ja auch sehr viele sein) freilich auch automatisiert generieren.