Neu SPAM durch die Eingabeseite bei den Kundendaten

[IRCnet]

Wir haben das gleiche Problem... der lilFoot Spam protector lite hat die bisher alle abgehalten, aber seit ein paar Tagen kommen genau die gleichen Anmeldungen mit den SPAM URLs und der besonderen Schriftart. Das muss dann ja HTML-Code sein. Vielleicht gibt es eine Möglichkeit HTML-Codes im Adressfeld auszuschließen, dass hat da ja sowieso nichts verloren. Hoffe es gibt eine schnelle Lösung um die Spambots wieder auszusperren.

 

[Greenman]

Hatte gestern noch die Textfelder leicht abgeändert. Hat aber nichts gebracht. Der Spam kommt immer noch in regelmäßigen Abständen.

Es wäre interessant zu wissen, ob die Felder befüllt werden, also ob die überhaupt durch den Spamprotektor gehen.
Hierzu müsste man das aber loggen, damit man sieht, was da für Daten übergeben werden.

Geht aber nur vernünftig, wenn man in der config Datei nen kleines tracking einbaut
Dann sieht man was da so passiert wenn die das Formular absenden

Glaube ja auch das die es schaffen den Spamprotektor zu umgehen. Habe auch den Lilfoot Spamprotector light. Schon lange, und bisher war ruhe. Das Herausfinden der Datenübergabe hört sich sehr schlüssig an. Wie würde denn sowas aussehen/umgesetzt werden.

 

[css-umsetzung]

Wenn ich so etwas mache, erstelle ich immer Tagesabhängige log Dateien, was aufgerufen wird, dann siehst du anhand der IP Adresse, was die betreffende IP alles aufgerufen hat.

In Deinem Fall, wo es eben darum geht das ein Formular vergewaltigt wird, würde ich die unter anderem, die REQUEST Daten, wenn das "betreffende Formular" verwendet wird mit loggen.

Bevor hier jemand Amok läuft
wenn es sich um Registrationsdaten handelt, werden selbstverständlich keine Passwörter oder sicherheitsrelevante Daten gespeichert.
Es geht ja in erster Linie darum zu sehen, was passierte vorher und warum kommen die auf einmal durch.

Ich hatte mal mit Marcel darüber gesprochen, ob es nicht sinn macht, auch zu prüfen, wie schnell das jeweilige Formular ausgefüllt wird, In meinem Formular Manager verwende ich das in dem eingebauten drei Stufen Schutz.
Solche Sachen könnte man dann eben sehen, ob das Sinn macht oder von mir nur eine fixe Idee ist.

 

[lilfoot.software]

Andreas und ich werden uns am WE das Plugin ansehen um einen möglichen Fehler auszumerzen. Ausserdem wird am WE an einer neuen Version für die Plugins (sowohl Full als auch Lite) gearbeitet die weitere Schutzmaßnahmen integrieren soll.

Es ist wirklich ein ewiges Zerren um den Sieg zwischen eigehendem Spam und den Abwehrmaßnahmen. Aktuell scheint da wieder eine größere Runde gelaufen zu sein die den Spammern ein wenig Oberwasser gegeben hat. Aber ich bin dran

 

[css-umsetzung]

Im Zuge dieses Termins, biete ich dem ersten der sich meldet und täglich damit zu kämpfen hat an, ihm ein von mir beschriebenes loggen "kostenlos" einzubauen und zu überwachen.
Es macht aber keinen Sinn, wenn da nur alle drei Tage etwas passiert. Umso schneller Daten zur Verfügung stehen, umso einfacher wird es.

Wenn also Interesse besteht, uns zu unterstützen, bitte per PN melden.

 

[Entenfurz]

Inzwischen sind die SPAM Anmeldungen zum Glück wieder auf 0 gesunken. Entweder die hatten dass nur ein paar Tage vor, oder wir haben nun Glück gehabt.

 

[lilfoot.software]

@Entenfurz Das freut mich zu hören.

Ich habe mich am Wochenende mit Andreas (@css-umsetzung) ausgetauscht. Wir haben die ein oder andere Optimierung besprochen (z.B. die dynamische Benennung der HoneyPots) und haben auch über weitere HoneyPots gesprochen. Im Laufe der Woche wird es Updates für beide Plugins geben die die Ergebnisse des Austauschs mit Andreas enthalten

 

[Bencondito]

Hallo
Das Selbe Problem . Ich hab jetzt Google Captcha ( ausser bei der anmeldung ) und Das LilFOOT SpamProtector Plugin installiert. Dadurch wurde es besser , Aber es kommen immer wieder neue Anmeldungungen. Das LilFOOT SpamProtector Plugin fängt es nicht ab trotz :

Punkte für Nutzung von Sonderzeichen :
Punkte bei zu vielen Wörtern in den Feldern "Nachname, Vorname, Ort, Straße":
Punkte bei Domain in den Feldern "Nachname, Vorname, Ort, Straße":
Punkte bei Domain in den Feldern "Kommentar, Nachricht":
Verwendung von spamverdächtigen Worten in "Kommentar, Nachricht":
Verwendung von sehr spamverdächtigen Worten in "Kommentar, Nachricht":
Verwendung von E-Mailadresse mit relativem Spam-Risiko:
Verwendung von E-Mailadresse mit hohem Spam-Risiko:

 

[css-umsetzung]

Nein es ist viel schlimmer wie es scheint.

Ich habe bei zwei Shops ein Tracking eingerichtet, da bei den Shops die ganze Zeit nichts passierte war das ein wenig blöd.
Wir haben aber durch das Tracking neue Dinge gesehen, die optimiert werden können.

Gestern habe ich dann so einen "Angriff" über das Tracking kompl. verfolgen können, die Bots werden wie es scheint immer intelligenter und probieren so viele Kombinationen aus, bis Sie eine haben mit der Sie durchkommen.
Nebenbei hat der noch versucht, über verschiedene SQL-Injection-Angriffe alarm zu machen.

Sie gehen jedenfalls definitiv über das Formular, dass ist sicher.

 

[IRCnet]

Bei mir war am 30., 31., 1. und fast den kompletten 2. auch Ruhe, aber seit dem 2. Februar 21 Uhr habe ich jetzt wieder 5 Fakekundenkonten von Bots... Freue mich auf die Anpassunge des Plugins

 

[wawi-dl]

Wir haben selbiges Problem und hoffen auf eine Lösung.

Wir glauben aber, dass die KI Bots dann angelernt werden und auch die neue Hürde schaffen.

 

[lilfoot.software]

Zusätzlich zu den Änderungen die noch im Laufe dieser Woche veröffentlicht werden gibt es bereits weitere Pläne für Erweiterungen. Beide Plugins werden in (sehr) naher Zukunft um eine SPAM-Erkennung per KI erweitert. Die ersten Tests hierzu laufen bereits und sobald es zuverlässig läuft wird das in den Plugins landen. Ich kann allerdings nicht versprechen das es zu 100% kostenlos für beide Plugins bleibt. Aber ich denke da wird sich eine faire Lösung für alle finden lassen die es dann nutzen möchten.

Mit den KI-Funktionen in den SpamProtectoren fängt dann in gewisser Weise "der Krieg der Maschinen" an

 

[Greenman]

Hallo lilfoot.software,
ich freue mich sehr, dass hier recht zügig etwas passiert, um den Spammern das leben zu erschweren.

Ich kann allerdings nicht versprechen das es zu 100% kostenlos für beide Plugins bleibt. Aber ich denke da wird sich eine faire Lösung für alle finden lassen die es dann nutzen möchten.

Man kann ja nicht erwarten, je umfangreicher es wird, dass alles Kostenlos ist. Allerdings freue ich mich auch darüber, wenn es eine faire Lösung gibt .

Vielen Dank an css-umsetzung und an lilfoot.software für die schnelle Reaktion und zu möglichen Lösungen.

 

[frankell]

Mit den KI-Funktionen in den SpamProtectoren fängt dann in gewisser Weise "der Krieg der Maschinen" an

Bei dem wir nur noch Zaungäste sind. Schöne neue Welt...

 

[wawi-dl]

@css-umsetzung Andreas einer der Wenigen, der sich oft für die Communitiy einsetzt, auch oftmals kostenlos für schnelle Hilfe!
Das darf man auch mal erwähnen, ist auch ein großes Lob wert!

@lilfoot.software
Allein die Lite Version hat schon vieles bewirkt und hoffen auf eine Lösung, da es sicher schlimmer statt besser wird, im Krieg der Maschinen.

 

[martinwolf]

Aus meiner Sicht muss JTL das direkt im Core schon abfangen, dass hier die Eingabe einer URL erst garnicht zulässig ist, Ausnahme bildet natürlich das Feld "www". Falls wer eine Lösung vorab haben will, ist ab v5.4.0 nutzbar. In der includes/src/Customer/Registration/RegistrationForm.php die folgenden Funktionen wie unten angegeben anpassen:

    private function validateBaseData(): void
    {
        // Regulärer Ausdruck für die Erkennung von URLs (http, https, ftp oder www.)
        $urlPattern = '#(https?://|www\.)#i';//CUSTOM
        foreach (['nachname', 'strasse', 'hausnummer', 'plz', 'ort', 'land', 'email'] as $dataKey) {
            $this->data[$dataKey] = isset($this->data[$dataKey]) ? \trim($this->data[$dataKey]) : null;
            if (!isset($this->data[$dataKey]) || !$this->data[$dataKey]) {
                $this->errors[$dataKey] = 1;
            }
            // 2. Prüfung: Enthält das Feld eine URL? (Neu hinzugefügt) //CUSTOM
            elseif (\preg_match($urlPattern, $this->data[$dataKey])) {
                $this->errors[$dataKey] = 3; // Eigener Fehlercode für "Keine URLs erlaubt"
            }
        }
        if (
            $this->config['kunden']['kundenregistrierung_pruefen_name'] === 'Y'
            && \preg_match('#\d+#', $this->data['nachname'])
        ) {
            $this->errors['nachname'] = 2;
        }
    }

    private function validateOptionalData(): void
    {
        // Regulärer Ausdruck für die Erkennung von URLs (http, https, ftp oder www.)
        $urlPattern = '#(https?://|www\.)#i';//CUSTOM
        $conf = [
            'kundenregistrierung_abfragen_anrede'       => 'anrede',
            'kundenregistrierung_pflicht_vorname'       => 'vorname',
            'kundenregistrierung_abfragen_firma'        => 'firma',
            'kundenregistrierung_abfragen_firmazusatz'  => 'firmazusatz',
            'kundenregistrierung_abfragen_titel'        => 'titel',
            'kundenregistrierung_abfragen_adresszusatz' => 'adresszusatz',
            //CUSTOM 'kundenregistrierung_abfragen_www'          => 'www',
            'kundenregistrierung_abfragen_bundesland'   => 'bundesland',
            'kundenregistrierung_abfragen_geburtstag'   => 'geburtstag',
            'kundenregistrierung_abfragen_fax'          => 'fax',
            'kundenregistrierung_abfragen_tel'          => 'tel',
            'kundenregistrierung_abfragen_mobil'        => 'mobil'
        ];
        foreach ($conf as $confKey => $dataKey) {
            if ($this->config['kunden'][$confKey] !== 'Y') {
                continue;
            }
            $this->data[$dataKey] = isset($this->data[$dataKey]) ? \trim($this->data[$dataKey]) : null;
            if (!isset($this->data[$dataKey]) || !$this->data[$dataKey]) {
                $this->errors[$dataKey] = 1;
            }
            // 2. Prüfung: Enthält das Feld eine URL? (Neu hinzugefügt) //CUSTOM
            elseif (\preg_match($urlPattern, $this->data[$dataKey])) {
                $this->errors[$dataKey] = 3; // Eigener Fehlercode für "Keine URLs erlaubt"
            }
        }
    }

Disclaimer: Verwendung auf eigenes Risiko da keine offizielle Freigabe von JTL erfolgt ist. Weiter ist diese Anpassung nicht updatesicher, darum vor dem Einspielen eine Sicherungskopie der Originaldateien anfertigen.

 

[Entenfurz]

Hallo
Bei uns hat der SPAM nun leider auch wieder massiv zugenommen.
Es wäre ja nun schon auch eine Überlegung, ob man nicht einfach im Admin Backend ein Feld hätte, bei dem man bestimmte Wörter bei allen Feldern der Kundendaten sperren könnte.
Würde man das Wort Blogspot einfach sperren können, wäre dass schon eine kurzfristige Lösung. Auch ist mir unverständlich, warum JTL diese Variante mit HTML Daten bei den Adress- und Namensfeldern überhaupt ermöglicht...

 

[css-umsetzung]

Das hilft dir eventuell bei der Registration.
Nachdem ich die Logs gesehen habe, habe ich gesehen, was der Spamprotector alles abhält, von daher ist die Registrierung nur ein kleiner Baustein, der gerade auffällt.

Im Core würde ich von hause aus schon nichts ändern, das hätte ich wenn, dann über die config Datei gemacht, ist für mich aber Sinnlos, da dort auch alles andere stehen könnte und teilweise steht.

Tatsache ist, das wie ich schon häufiger schrieb, das ein ewiges hinterherrennen von Keywörtern ist, daher muss man hier verschiedene Wege gehen.

Die Logs die ich erstellt habe, waren wie ich auch schon schrieb, recht aufschlussreich.

Es ist führt am Spamprotector also eigentlich, kein Weg dran vorbei wenn man Opfer eines oder mehrerer Bots ist.

 

[MKis84]

Bei uns hat folgendes kurzfristig geholfen und seit da an haben wir keine Spamanmeldungen mehr:

URL des Registrationsformulars von /Registrieren auf irgend eine beliebige andere URL ändern. Es scheint als grast der Bot einfach alle Shops auf /Registrieren ab und füllt die Formulare aus.

Die Spamanmeldungen kamen immer über folgende IP rein: 80.71.157.31. -> evtl sperren oder gleich ganzer IP Bereich sperren.