Abuse - Vorgang

    Hier auch noch ein weiterer unabhängiger Fall. Ein Kunde hat gerade sein Mailpasswort irrtümlich in ein Fishing / Identitätsdiebstahl Formular eingetragen.
    Nun wir haben schnell reagiert innerhalb von 10 Minuten und es ist nicht zu Spam gekommen und kein Abuse entstanden.
    Ev. war er aber auch auf Identitätsdiebstahl fokussiert.

    Hätte der Scammer nun aber Spam verschickt würde das gesamte Produkt gesperrt werden.
    Das könnte dann auch ein root Server sein mit 50 Projekten.

    Ich glaube, dass die Lösung ein schnelleres und selektives Sperren wäre:
    Spam vom Mailaccount -> smtp ausschalten (anderes Passwort)
    Spam vom Server direkt -> A Record umbiegen

    Zitat von friend_of_root

    Spam vom Mailaccount -> smtp ausschalten (anderes Passwort)

    Geht halt nur bei Webhosting. Wobei man bei vServern aber ausgehend Port 25 sperren könnte.

    Zitat von friend_of_root

    Spam vom Server direkt -> A Record umbiegen

    Und wenn die Domain nicht bei netcup liegt bzw. andere NS verwendet? Außerdem kann man auch ohne A-Record noch immer HTTP-Anfragen absetzen ;)

    Bzw. bringt halt auch nichts, wenn dort bereits fremder Code läuft. Selbst beim Webhosting kann dieser z.B. durch Cronjobs von alleine getriggert werden.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Zitat von KB19

    Geht halt nur bei Webhosting. Wobei man bei vServern aber ausgehend Port 25 sperren könnte.

    Und wenn die Domain nicht bei netcup liegt bzw. andere NS verwendet? Außerdem kann man auch ohne A-Record noch immer HTTP-Anfragen absetzen ;)

    Bzw. bringt halt auch nichts, wenn dort bereits fremder Code läuft. Selbst beim Webhosting kann dieser z.B. durch Cronjobs von alleine getriggert werden.

    Auf Level 2 Routern im Rechenzentrum könnte einiges gehen.

    >Und wenn die Domain nicht bei netcup liegt bzw. andere NS verwendet? Außerdem kann man auch ohne A-Record noch immer HTTP-Anfragen absetzen ;)
    Deine Einwände sind korrekt.

    >Selbst beim Webhosting kann dieser z.B. durch Cronjobs von alleine getriggert werden.
    Du meinst Zugang zum Webhostingpanel und Cronjobs. Das wäre schon extrem.

    Zitat von friend_of_root

    Hätte der Scammer nun aber Spam verschickt würde das gesamte Produkt gesperrt werden.
    Das könnte dann auch ein root Server sein mit 50 Projekten.

    Ich glaube, dass die Lösung ein schnelleres und selektives Sperren wäre:
    Spam vom Mailaccount -> smtp ausschalten (anderes Passwort)
    Spam vom Server direkt -> A Record umbiegen

    Wo liegt das Kundenpostfach bzw der smtp-Server?

    Auf dem Server selbst? Dann wird es nicht gelingen, nur das Passwort zu ändern.

    Gerade bei einem Root-Server ist es natürlich sehr schwierig, selektiv den Postausgang für nur ein Postfach oder einen Kunden zu sperren. Der Server ist weitestgehend eine Blackbox für netcup, da kann man bestenfalls den smtp-Port ausgehend sperren, soweit das die Netzwerk-Infrastuktur überhaupt hergibt. Selbst dann sind aber alle Kundenpostfächer und auch die administrativen tot.

    Wird der Spam über einen netcup-SMTP-Server versendet, dann wäre es möglich, selektiv zu sperren. Das kann dann aber eigentlich nur ein Postfach in einem Webhosting oder einem Reseller-Webhosting sein. Ist es ein Webhosting des Kunden bei netcup, dann wird sowieso dieses Webhosting gesperrt werden und nicht der Server, womit die anderen 49 Kunden nicht betroffen wären.

    Falls du mit "Spam vom Server direkt" z.B. eine gehackte CMS-Installation meinst, den A-Record kann netcup auch nur dann umbiegen, wenn die Nameserver der betroffenen Domain auch bei netcup liegen. Den A-Record der Serverdomain umzubiegen wird wohl nicht viel bringen, da ist dann höchstens das Serverpanel betroffen. Und das geht auch nur, wenn die Serverdomain netcup-Nameserver verwendet. Das ist bei mir z.B. nicht so, da müsste netcup dann schon die Nameserver erst wieder auf die netcup-Server zurücksetzen. Außerdem ist dann die gehackte Website immer noch zu erreichen über den A-Record der Kundendomain.

    Domains, die über einen Netcup Nameserver laufen wären leichter im Abuse Prozess zu automatisieren.
    Beispiel: A-Record umbiegen auf Parkplatz für die jeweilige Domain.

    Webhostingprodukte haben Standardisierung und Trennung zwischen Mail und Web, die ebenfalls Automatisierung erleichtern könnte.
    Beispiel: Nur die Emailadressen sperren, die für Spam benutzt wurden. Nicht das ganze Produkt. Bzw. auch nicht den Maileingang in diesem Zeitraum komplett blockieren.

    Klar, Rootserver sind sicherlich schwieriger zu handhaben.
    Beispiel: Firewall Einträge könnten betreffende Dienste sperren und dem Betreiber Zeit geben das Problem zu beheben. Vielleicht ein 2-stufiger Prozess

    Die Geschwindigkeit der Abwicklung eines solchen Falles ist natürlich ein Hauptthema.
    Wenn der Webmaster sofort verfügbar ist, dann sollte es nicht 10 Nachrichten und 22 Stunden dauern.
    Derartige Fälle vor dem Wochenende würden dann auch mehrere Tage dauern.

    Abuse ist ein wachsendes Thema, weil Hacks und Scams durch AI immer ausgereifter umgesetzt werden und mit höherer Frequenz eingesetzt werden.
    Dabei muss man im Hinterkopf behalten, es ist nicht immer Fahrlässigkeit und ein gehackter Rootaccount. Sondern oft nur Formularspam.

    Zitat von friend_of_root

    Du meinst Zugang zum Webhostingpanel und Cronjobs. Das wäre schon extrem.

    Nein, ein infiziertes Webhosting kann sich selbst Cronjobs für Plesk anlegen! Das hat ein Forenthread in der Vergangenheit deutlich gezeigt. (Link)

    Sprich: Sicherheitslücke (RCE) z.B. in einer PHP-Anwendung über HTTP ausgenutzt und das das Ding legt sich dann über exec() einen Plesk-Cronjob an. Da kannst Du über SSH/FTP alle Dateien auf dem Webspace löschen und der bösartige Code ist trotzdem weiterhin aktiv. Erst durch Löschen des Cronjobs direkt in Plesk wird man sowas los.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    2 Mal editiert, zuletzt von KB19 (21. März 2025 um 13:27)

    Is there already more information from Netcup about the abuse process and if they are planning to change this in the future? If they suddenly shut down one of our servers it will result in permanently loosing customers. Im really worrying about this

    Zitat von KB19

    Nein, ein infiziertes Webhosting kann sich selbst Cronjobs für Plesk anlegen! Das hat ein Forenthread in der Vergangenheit deutlich gezeigt. (Link)

    Sprich: Sicherheitslücke (RCE) z.B. in einer PHP-Anwendung über HTTP ausgenutzt und das das Ding legt sich dann über exec() einen Plesk-Cronjob an. Da kannst Du über SSH/FTP alle Dateien auf dem Webspace löschen und der bösartige Code ist trotzdem weiterhin aktiv. Erst durch Löschen des Cronjobs direkt in Plesk wird man sowas los.

    Sehr interessante Problematik. Wer hätte das gedacht? Wow, wirklich übel wie der Hacker da Plesk austrickst. Danke für den Link.

    Zitat von friend_of_root

    Similar with webhosting, you can access via FTP but you cannot access the settings panel for hosting or mail.

    Also, ich komme in meinem Webhosting-Paket nicht per FTP auf meine space um etwas zu löschen und so wieder das Limit einzuhalten...! Voll dumm! Jetzt muss ich hier wohl bis nach dem Wochenende warten... CalDAV, CardDAV und sonstige syncs im Eimer...

    Ich verstehe nicht, warum man nicht vorher gewarnt wird? Bei mir war es ein gezipptes-Archiv was ich von einem Verzeichnis anlegen wollte und was die ganze Sache zu over-quota führte. Ich hatte es beim Zippen schon bemerkt und konnte den Archiv-Prozess nicht mal stoppen... und der Support ist echt verdammt schlecht geworden!

    Ich finde das ja ehrlich unglaublich schlecht gelöst. Läuft dann gar nichts mehr, also z.B. auch kein Cronjob, den man sonst präventiv zum Aufräumen einrichten könnte? Wenigstens ein minimales Webinterface, in dem man in Selbstbedienung Dateien nur löschen kann, sollte drin sein.

    Dass die Behandlung von Over-Quota mehr als suboptimal ist, habe ich ja schon öfter hier geschrieben. Die derzeitige Behandlung funktionier sehr schlecht, wenn sehr schnell sehr deutliche Überschreitungen des Speicherlimits passieren. Gesperrt wird erst ab 150% soweit ich mich erinnere. Bei 100% sollte eine Warnung per Mail rausgehen. Der genaue Ablauf wurde mal seitens netcup hier im Forum erläutert. Das große Problem dabei ist, dass die Speicherbelegung nur einmal(?) pro Tag geprüft wird. Damit ist natürlich bei einem solchen Kopiervorgang oder auch bei einem schnell vollaufenden Log reichlich Zeit, die 150% zu reissen, bevor die Überschreitung überhaupt bemerkt wird. Das Kind liegt im Brunnen, ohne dass der Kunde eine Chance hat, das noch zu verhindern. Möglichkeiten das zu verbessern gäbe es sicher reichlich.

    Zitat von tab

    Das große Problem dabei ist, dass die Speicherbelegung nur einmal(?) pro Tag geprüft wird. Damit ist natürlich bei einem solchen Kopiervorgang oder auch bei einem schnell vollaufenden Log reichlich Zeit, die 150% zu reissen, bevor die Überschreitung überhaupt bemerkt wird.

    Da bietet es sich an, die Speicherbelegung selbst per cron-Skript zu überwachen und sich eine Nachricht zu schicken, wenn ein Grenzwert überschritten wird.

    Zitat von marklo

    Es würde ja reichen, wenn ich rasch per FTP die - vermutlich nur teilangelegte - Zip-Datei löschen könnte...

    Auf jeden Fall DANKE für die Anteilnahme...

    Darauf wird es auch letztendlich nach Kontakt zum Support hinauslaufen. Bliebe natürlich der Notfall-Support. Ich weiss aber nicht, ob das in so einem Fall kostenpflichtig wäre

    ich bin da auch schon 2mal reingerannt und man hat leider keine Chance selbst Daten zu löschen.

    cih wurde dann auch durch den Support freigeschalten mit der Warnung mich zu beeilen , da ich ansonsten in 30 min,

    wieder gesperrt sein werde. Dies widerspricht dann aber der Aussage von tab über den einmaligen Durchlauf pro Tag.

    Allerdings ist das bei mir ein paar Jahre her und vielleicht nicht mehr aktueller Status

    It's me, only me, pure michi 🦆

    RS: ja:thumbup: VPS: yep:thumbup: ARM: sicher:thumbup: WH: klar :thumbup:

    Domains: auch:thumbup:

    Zitat von andreas.

    Kannst du dich denn auch nicht mehr an Plesk anmelden, um dann über dessen Dateimanager einige Zip-Dateien löschen zu können?

    Nein, leider geht das auch nicht. Ich kann mich da im WCP zwar anmelden, aber das geht nur eine einzige Seite auf, die auf die Sperrung hinweist. Alle Menü-Punkte in der linken Seitenleiste sind nicht anwählbar.

    Was aber komischerweise funktioniert (sollte wohl besser flüstern...), ist, dass ich mit dem Desktop-Client von Nextcloud auf diese zugreifen kann, obwohl die in dem gesperrten Paket liegt... obwohl sich hier rein gar nichts - mit welcher DAV-Methode auch immer - synced, scheint irgendwas bei WebDAV noch möglich...

    Ich bin so froh, dass dieses l a n g e Wochenende endlich vorbei ist... die hatten da bei Netcup auch alle den Brückentag genommen oder so...