Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #6271 > unrolled thread

mailman spam-Abwehr?

Back to article view | Back to de.comm.software.mailserver

Contents

  mailman spam-Abwehr? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2020-08-27 10:31 +0000
    Re: mailman spam-Abwehr? Sven Hartge <sh-208@svenhartge.de> - 2020-08-27 12:45 +0200
      Re: mailman spam-Abwehr? Sven Hartge <sh-208@svenhartge.de> - 2020-08-27 13:00 +0200
        Re: mailman spam-Abwehr? Florian Weimer <fw@deneb.enyo.de> - 2020-08-27 20:50 +0200
          Re: mailman spam-Abwehr? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2020-08-27 22:47 +0000
            Re: mailman spam-Abwehr? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2020-08-27 23:09 +0000
              Re: mailman spam-Abwehr? Sven Hartge <sh-208@svenhartge.de> - 2020-08-28 06:51 +0200
            Re: mailman spam-Abwehr? Matthias Andree <matthias.andree@gmx.de> - 2020-08-28 08:12 +0200
              Re: mailman spam-Abwehr? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2020-08-28 08:46 +0000
            Re: mailman spam-Abwehr? Sven Hartge <sh-208@svenhartge.de> - 2020-08-28 09:53 +0200
        Re: mailman spam-Abwehr? Florian Weimer <fw@deneb.enyo.de> - 2020-08-28 20:13 +0200
          Re: mailman spam-Abwehr? Sven Hartge <sh-208@svenhartge.de> - 2020-08-28 23:07 +0200
      Re: mailman spam-Abwehr? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2020-08-27 23:00 +0000
        Re: mailman spam-Abwehr? Sven Hartge <sh-208@svenhartge.de> - 2020-08-28 06:44 +0200
        Re: mailman spam-Abwehr? Michael Bussmann <nutznetz@mb-net.net> - 2020-08-28 11:24 +0200
    Re: mailman spam-Abwehr? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2020-08-27 23:14 +0000

#6271 — mailman spam-Abwehr?

In letzter Zeit hab ich einen MASSIVEN Anstieg von mailman
fake-Registrierungen, das dazu fuehrt, dass ich deswegen Beschwerden
bekomme ueber die opt-in Bestaetigungs-E-Mails, die vom Empfaenger als
Spam klassifiziert werden ("Ich hab das NIE angefordert!").

So wie das aussieht sind das bots, die die mailman Web-Registrierungsseite
missbrauchen und da fremde E-Mail-Adressen eintragen.
Ein Motiv dafuer kann ich nicht erkennen, denn der opt-in
Bestaetigungstext ist fix und kann vom Spammer nicht modifiziert werden.

80% der Fake-Registrierungen der letzten Tage kamen vom Massenprovider
"Colocation America Corporation", dessen Netze ich erstmal blockiert habe.
Das ist aber nur eine Notloesung, denn die naechste
Spam-Registrierungswelle kommt dann halt von woanders.

Wenn ich in der mailman-Konfiguration die Registrierung aendere auf
"Bestaetigung durch den Listenadmin" geht der in den Fake-Registrierungen
unter. Ausserdem kann der kaum erkennen, was echt und was fake ist.

Wie sieht eure Loesung aus?


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [next] | [standalone]

#6272

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

> In letzter Zeit hab ich einen MASSIVEN Anstieg von mailman
> fake-Registrierungen, das dazu fuehrt, dass ich deswegen Beschwerden
> bekomme ueber die opt-in Bestaetigungs-E-Mails, die vom Empfaenger als
> Spam klassifiziert werden ("Ich hab das NIE angefordert!").

> So wie das aussieht sind das bots, die die mailman
> Web-Registrierungsseite missbrauchen und da fremde E-Mail-Adressen
> eintragen.  Ein Motiv dafuer kann ich nicht erkennen, denn der opt-in
> Bestaetigungstext ist fix und kann vom Spammer nicht modifiziert
> werden.

> 80% der Fake-Registrierungen der letzten Tage kamen vom Massenprovider
> "Colocation America Corporation", dessen Netze ich erstmal blockiert
> habe.  Das ist aber nur eine Notloesung, denn die naechste
> Spam-Registrierungswelle kommt dann halt von woanders.

Das hatten wir auch, wo direkt via automatisierten POST auf die HTTP-API
das Subscribe en-masse ausgelöst wurde. Die Lösung lieferte eine neuere
Mailman2-Version, siehe unten.

> Wenn ich in der mailman-Konfiguration die Registrierung aendere auf
> "Bestaetigung durch den Listenadmin" geht der in den
> Fake-Registrierungen unter. Ausserdem kann der kaum erkennen, was echt
> und was fake ist.

Dagegen kann man dann leider nichts machen.

> Wie sieht eure Loesung aus?

für Mailman2 in mm_cfg.py ab version 2.1.27 (IIRC):

,----
| # Anti-Subscribe-SPAM:
|
| # If the following is set to a non-empty string, this string in
| # combination with the time, list name and the IP address of the
| # requestor is used to create a hidden hash as part of the subscribe
| # form on the listinfo page.  This hash is checked upon form submission
| # and the subscribe fails if it doesn't match.  I.e. the form posted
| # must be first retrieved from the listinfo CGI by the same IP that
| # posts it.  The subscribe also fails if the time the form was retrieved
| # is more than the above FORM_LIFETIME or less than the below
| # SUBSCRIBE_FORM_MIN_TIME before submission.  Important: If you have any
| # static subscribe forms on your web site, setting this option will
| # break them.  With this option set, subscribe forms must be dynamically
| # generated to include the hidden data.  See the code block beginning
| # with "if mm_cfg.SUBSCRIBE_FORM_SECRET:" in Mailman/Cgi/listinfo.py for
| # the details of the hidden data.
|
| SUBSCRIBE_FORM_SECRET = 'das_schreibe_ich_doch_hier_nicht' 
| FORM_LIFETIME = hours(1)
| SUBSCRIBE_FORM_MIN_TIME = seconds(5)
|
| # Installation wide ban list.  This is a list of email addresses and
| # regexp patterns (beginning with ^) which are not allowed to subscribe
| # to any lists in the installation.  This supplements the individual
| # list's ban_list.  For example, to ban xxx@aol.com and any @gmail.com
| # address beginning with yyy, set
|
| GLOBAL_BAN_LIST = ['^.*\+.*@gmail.com'] 
`----

Wenn das nicht reicht, weil wirklich ein Mensch manuell die
Subscribe-Seite aufruft, dann hilft nur die große Keule: 

1) hinter Login gegen Hochschul-LDAP/AD klemmen. Das sperrt natürlich
alle externen Nutzer aus. Nicht optimal.
2) via Firewall auf Campus-Netz eingrenzen. Sperrt auch alle externen
Nutzer aus. Auch nicht toll.
3) Deine Lösung. Bringt den Listen-Admin an den Rand des
Nervenzusammenbruchs.

S!

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#6273

Sven Hartge <sh-208@svenhartge.de> wrote:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

>> 80% der Fake-Registrierungen der letzten Tage kamen vom
>> Massenprovider "Colocation America Corporation", dessen Netze ich
>> erstmal blockiert habe.  Das ist aber nur eine Notloesung, denn die
>> naechste Spam-Registrierungswelle kommt dann halt von woanders.

> Das hatten wir auch, wo direkt via automatisierten POST auf die
> HTTP-API das Subscribe en-masse ausgelöst wurde. Die Lösung lieferte
> eine neuere Mailman2-Version, siehe unten.

Ach ja: Wir haben sämtliche Listen aus der List-Server-Listenübersicht
entfernt, so dass man nicht mehr so einfach von außen wissen kann, was
für Listen es gibt und wie man diese subcribiert.

S!

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#6275

* Sven Hartge:

> Sven Hartge <sh-208@svenhartge.de> wrote:
>> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
>
>>> 80% der Fake-Registrierungen der letzten Tage kamen vom
>>> Massenprovider "Colocation America Corporation", dessen Netze ich
>>> erstmal blockiert habe.  Das ist aber nur eine Notloesung, denn die
>>> naechste Spam-Registrierungswelle kommt dann halt von woanders.
>
>> Das hatten wir auch, wo direkt via automatisierten POST auf die
>> HTTP-API das Subscribe en-masse ausgelöst wurde. Die Lösung lieferte
>> eine neuere Mailman2-Version, siehe unten.
>
> Ach ja: Wir haben sämtliche Listen aus der List-Server-Listenübersicht
> entfernt, so dass man nicht mehr so einfach von außen wissen kann, was
> für Listen es gibt und wie man diese subcribiert.

Ich habe die Templates dahingehend geändert, daß sie den passenden
mailto:-Link enthalten, und /subscribe komplett abgeklemmt.

Email hat den Vorteil, daß man heutzutage die Absenderadresse recht
gut validieren kann, und bei Admin-Email sehe ich auch kein Problem
damit, Header-From == Envelope-From zu erzwingen.

Im Moment reicht es vermutlich sogar as, axios/0.19.2 als User-Agent
zu blockieren.

[toc] | [prev] | [next] | [standalone]

#6276

Prolog: Ich *ZENSIERT* sollte erstmal die followups auf meine eigenen
Artikel lesen, bevor ich weiteres poste :-}
Hab was aehnliches dazu grad in de.comm.software.webserver geschrieben.

Florian Weimer <fw@deneb.enyo.de> wrote:

> > Ach ja: Wir haben sämtliche Listen aus der List-Server-Listenübersicht
> > entfernt, so dass man nicht mehr so einfach von außen wissen kann, was
> > für Listen es gibt und wie man diese subcribiert.

SEUFZ. EIGENTLICH wollte ich das feature erhalten.


> Ich habe die Templates dahingehend geändert, daß sie den passenden
> mailto:-Link enthalten, und /subscribe komplett abgeklemmt.

Klingt gut! Wie/wo macht man das?
Ich hab zwar mailman und apache selber aufgesetzt, aber das ist JAHRE her
und seither kaum noch angefasst. So ist das halt mit guter UNIX-Software:
einmal installiert und laeuft und laeuft und laeuft... :-}


> Email hat den Vorteil, daß man heutzutage die Absenderadresse recht
> gut validieren kann, und bei Admin-Email sehe ich auch kein Problem
> damit, Header-From == Envelope-From zu erzwingen.

Und ich hab da procmail. Damit kenn ich mich aus :-)


> Im Moment reicht es vermutlich sogar as, axios/0.19.2 als User-Agent
> zu blockieren.

User-Agent log ich bisher nicht. Ist wohl ein Fehler.
Wie blockt man bestimmte User-Agents?


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#6278

In de.comm.software.mailserver Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

> > Im Moment reicht es vermutlich sogar as, axios/0.19.2 als User-Agent
> > zu blockieren.
> 
> User-Agent log ich bisher nicht. Ist wohl ein Fehler.

Inzwischen eingeschaltet und prompt erwischt:

155.254.54.150 - - [2020-08-28 01:05:57] "POST /mailman//subscribe/liste-auswahl HTTP/1.1" 200 1697 "-" "axios/0.19.2" "-"

Guter Tipp!

Wie blockt man mit apache bestimmte User-Agents?

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#6281

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> In de.comm.software.mailserver Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

>>> Im Moment reicht es vermutlich sogar as, axios/0.19.2 als User-Agent
>>> zu blockieren.
 
>> User-Agent log ich bisher nicht. Ist wohl ein Fehler.

> Inzwischen eingeschaltet und prompt erwischt:

> 155.254.54.150 - - [2020-08-28 01:05:57] "POST /mailman//subscribe/liste-auswahl HTTP/1.1" 200 1697 "-" "axios/0.19.2" "-"

> Guter Tipp!

> Wie blockt man mit apache bestimmte User-Agents?

Och komm Ulli, du kannst eine Suchmaschine doch bedienen!

Da gibt es mehrere Varianten:

Via mod_rewrite, aber mod_rewrite kostet recht viel CPU:

,----
| RewriteEngine On
| RewriteCond %{HTTP_USER_AGENT} axios [NC,OR]
| RewriteCond %{HTTP_USER_AGENT} badbot [NC,OR]
| RewriteCond %{HTTP_USER_AGENT} badspider [NC]
| RewriteRule . - [R=403,L]
`----

Via Require/SetEnvIf:

,----
| SetEnvIf User-Agent "axios" bad_user
|
| <Location />
|        <RequireAll>
|        Require all granted
|        Require not env bad_user
|        </RequireAll>
| </Directory>
`----

S!

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#6282

FUp2 gesetzt

Am 28.08.20 um 00:47 schrieb Ulli Horlacher:
> Prolog: Ich *ZENSIERT* sollte erstmal die followups auf meine eigenen
> Artikel lesen, bevor ich weiteres poste :-}
> Hab was aehnliches dazu grad in de.comm.software.webserver geschrieben.
> 
> Florian Weimer <fw@deneb.enyo.de> wrote:
> 
>>> Ach ja: Wir haben sämtliche Listen aus der List-Server-Listenübersicht
>>> entfernt, so dass man nicht mehr so einfach von außen wissen kann, was
>>> für Listen es gibt und wie man diese subcribiert.
> 
> SEUFZ. EIGENTLICH wollte ich das feature erhalten.
> 
> 
>> Ich habe die Templates dahingehend geändert, daß sie den passenden
>> mailto:-Link enthalten, und /subscribe komplett abgeklemmt.
> 
> Klingt gut! Wie/wo macht man das?

In einem templates/-Verzeichnis.

ACHTUNG: wenn Du direkt auf den templates fummelst und nicht durchs
Webinterface - die gehen in ein *separates* Verzeichnis, damit sie beim
Update erhalten bleiben, siehe auch Utils.py und hier:

<https://wiki.list.org/DOC/4.48%20How%20can%20I%20change%20the%20HTML%20or%20.txt%20templates%20used%20by%20my%20mailing%20lists%3F>

> Ich hab zwar mailman und apache selber aufgesetzt, aber das ist JAHRE her
> und seither kaum noch angefasst. So ist das halt mit guter UNIX-Software:
> einmal installiert und laeuft und laeuft und laeuft... :-}

Leichtsinn, fahrlässig.  Pflege nötig, wenn die nicht von Deinem
kommerziellen Distributor geleistet wird.
Schau mal, wie viele Security fixes in letzter Zeit noch herauskamen:

<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/1859/NEWS#L8>

>> Email hat den Vorteil, daß man heutzutage die Absenderadresse recht
>> gut validieren kann, und bei Admin-Email sehe ich auch kein Problem
>> damit, Header-From == Envelope-From zu erzwingen.
> 
> Und ich hab da procmail. Damit kenn ich mich aus :-)

Verbuggte, ca. 20 Jahre ungepflegte und seit jeher fehlkonzeptionierte
Museumssoftware, in der Du das error handling selbst schreiben musst, um
scheinzufälliges Verhalten zu vermeiden?

Schau Dir mal maildrop an...

[toc] | [prev] | [next] | [standalone]

#6284

In de.comm.software.mailserver Matthias Andree <matthias.andree@gmx.de> wrote:

> > Ich hab zwar mailman und apache selber aufgesetzt, aber das ist JAHRE her
> > und seither kaum noch angefasst. So ist das halt mit guter UNIX-Software:
> > einmal installiert und laeuft und laeuft und laeuft... :-}
> 
> Leichtsinn, fahrlässig.  Pflege nötig, wenn die nicht von Deinem
> kommerziellen Distributor geleistet wird.

Letzteres ist der Fall. Deshalb muss ICH mich nicht drum kuemmern.
Security Updates werden automatisch eingespielt.


> > Und ich hab da procmail. Damit kenn ich mich aus :-)
> 
> Verbuggte, ca. 20 Jahre ungepflegte und seit jeher fehlkonzeptionierte
> Museumssoftware, in der Du das error handling selbst schreiben musst, um
> scheinzufälliges Verhalten zu vermeiden?

Bisher funktioniert es gut. Um die Design-Schwaechen komm ich mit
Workarounds zurecht.


> Schau Dir mal maildrop an...

Sieht gut aus. Kommt auf meine Muss_ich_mir_mal_anschauen-Liste

Das Problem: Ich hab mehrere 1000 Zeilen procmail Code, historisch
gewachsen ueber 25 Jahre. Das konvertiere ich nicht so schnell :-}


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#6283

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

>>> Ach ja: Wir haben sämtliche Listen aus der List-Server-Listenübersicht
>>> entfernt, so dass man nicht mehr so einfach von außen wissen kann, was
>>> für Listen es gibt und wie man diese subcribiert.

> SEUFZ. EIGENTLICH wollte ich das feature erhalten.

Das ist aber DER Einstiegspunkt für die Deppen:

lists.thm.de:443 193.110.203.153 - - [18/Aug/2020:05:53:36 +0200] "GET /mailman/listinfo HTTP/1.1" 200 10004 "-" "axios/0.19.2" TLSv1.3 TLS_AES_256_GCM_SHA384
listserv.fh-giessen.de:443 193.110.203.153 - - [18/Aug/2020:06:10:03 +0200] "GET /mailman/listinfo HTTP/1.1" 200 10086 "-" "axios/0.19.2" TLSv1.3 TLS_AES_256_GCM_SHA384

Das wäre dann auch hier der Anfang vom Angriff gewesen. Da dort aber
keine Listen aufgeführt werden, war es dann direkt wieder.

S!

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#6286

* Sven Hartge:

> Ach ja: Wir haben sämtliche Listen aus der List-Server-Listenübersicht
> entfernt, so dass man nicht mehr so einfach von außen wissen kann, was
> für Listen es gibt und wie man diese subcribiert.

Das bringt unmittelbar wohl nichts. Die /subscribe-POST-Requests
werden wohl inzwischen blind gemacht, d.h. für die Wirksamkeit braucht
man eine Zeitmaschine.

[toc] | [prev] | [next] | [standalone]

#6287

Florian Weimer <fw@deneb.enyo.de> wrote:
> * Sven Hartge:

>> Ach ja: Wir haben sämtliche Listen aus der
>> List-Server-Listenübersicht entfernt, so dass man nicht mehr so
>> einfach von außen wissen kann, was für Listen es gibt und wie man
>> diese subcribiert.

> Das bringt unmittelbar wohl nichts. Die /subscribe-POST-Requests
> werden wohl inzwischen blind gemacht, d.h. für die Wirksamkeit braucht
> man eine Zeitmaschine.

Natürlich.

Aber zumindest für neue Kampagnen neuer Depper nützt es etwas, weil die
nix mehr abgreifen können, siehe mein anderes Post dazu, wo ich den
Zugriff auf die leere Listen-Liste im Log gefunden habe aber dann nichts
mehr weiter nach kam.

Ich habe den Bot dennoch auf die Blockliste mit aufgenommen. (Bis die
Deppen irgendwann einen echten Browser User-Agent liefern. Dann muss
eben eine größere Keule her.)

S!

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#6277

Sven Hartge <sh-208@svenhartge.de> wrote:

> > 80% der Fake-Registrierungen der letzten Tage kamen vom Massenprovider
> > "Colocation America Corporation", dessen Netze ich erstmal blockiert
> > habe.  Das ist aber nur eine Notloesung, denn die naechste
> > Spam-Registrierungswelle kommt dann halt von woanders.
> 
> Das hatten wir auch, wo direkt via automatisierten POST auf die HTTP-API
> das Subscribe en-masse ausgelöst wurde.

Auch von "Colocation America Corporation"?
Ich hab im apache log gefunden (Auszug):

185.163.211.169 - - [2020-08-27 20:53:29] "POST /mailman//subscribe/s-hpv HTTP/1.1" 200 1633
216.155.42.144 - - [2020-08-27 21:23:20] "POST /mailman//subscribe/de-hpv HTTP/1.1" 200 1641
185.210.76.98 - - [2020-08-27 21:38:06] "POST /mailman//subscribe/de-hpv HTTP/1.1" 200 1641
216.155.27.75 - - [2020-08-27 21:41:58] "POST /mailman//subscribe/liste-stuttgart HTTP/1.1" 200 1713
216.155.42.9 - - [2020-08-27 22:09:16] "POST /mailman//subscribe/de-hpv HTTP/1.1" 200 1641

Das // in der URI deutet auf (schlecht programmiertes) Script hin.


> > Wenn ich in der mailman-Konfiguration die Registrierung aendere auf
> > "Bestaetigung durch den Listenadmin" geht der in den
> > Fake-Registrierungen unter. Ausserdem kann der kaum erkennen, was echt
> > und was fake ist.
> 
> Dagegen kann man dann leider nichts machen.

Ausser man klemmt die Webregistrierung ganz ab. Das hab ich allerdings
noch nicht herausgefunden, wie.


> > Wie sieht eure Loesung aus?
> 
> für Mailman2 in mm_cfg.py ab version 2.1.27 (IIRC):

SEUFZ. Ich hab noch 2.1.26 und muss aus diversen Gruenden (vorerst) dabei
bleiben.

> | # Anti-Subscribe-SPAM:

> | GLOBAL_BAN_LIST = ['^.*\+.*@gmail.com'] 

Wie befuerchtet: gibts bei mailman 2.1.26 im mm_cfg.py nicht :-(


> 1) hinter Login gegen Hochschul-LDAP/AD klemmen. Das sperrt natürlich
> alle externen Nutzer aus. Nicht optimal.
> 2) via Firewall auf Campus-Netz eingrenzen. Sperrt auch alle externen
> Nutzer aus. Auch nicht toll.

Geht nicht.
Ich hab Listenteilnehmer weltweit.


> 3) Deine Lösung. Bringt den Listen-Admin an den Rand des
> Nervenzusammenbruchs.

4) Abklemmen des Web subscribe features. Da such ich noch eine Loesung...
   Das muesste doch via apache.conf gehen?


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#6280

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> Sven Hartge <sh-208@svenhartge.de> wrote:

>> > 80% der Fake-Registrierungen der letzten Tage kamen vom Massenprovider
>> > "Colocation America Corporation", dessen Netze ich erstmal blockiert
>> > habe.  Das ist aber nur eine Notloesung, denn die naechste
>> > Spam-Registrierungswelle kommt dann halt von woanders.
>> 
>> Das hatten wir auch, wo direkt via automatisierten POST auf die HTTP-API
>> das Subscribe en-masse ausgelöst wurde.

> Auch von "Colocation America Corporation"?
> Ich hab im apache log gefunden (Auszug):

> 185.163.211.169 - - [2020-08-27 20:53:29] "POST /mailman//subscribe/s-hpv HTTP/1.1" 200 1633
> 216.155.42.144 - - [2020-08-27 21:23:20] "POST /mailman//subscribe/de-hpv HTTP/1.1" 200 1641
> 185.210.76.98 - - [2020-08-27 21:38:06] "POST /mailman//subscribe/de-hpv HTTP/1.1" 200 1641
> 216.155.27.75 - - [2020-08-27 21:41:58] "POST /mailman//subscribe/liste-stuttgart HTTP/1.1" 200 1713
> 216.155.42.9 - - [2020-08-27 22:09:16] "POST /mailman//subscribe/de-hpv HTTP/1.1" 200 1641

> Das // in der URI deutet auf (schlecht programmiertes) Script hin.

Da kann ich nicht mehr zu sagen, von wo genau das kam, weil das ~2 Jahre
her ist.

>>> Wie sieht eure Loesung aus?
 
>> für Mailman2 in mm_cfg.py ab version 2.1.27 (IIRC):

> SEUFZ. Ich hab noch 2.1.26 und muss aus diversen Gruenden (vorerst) dabei
> bleiben.

>> | # Anti-Subscribe-SPAM:

>> | GLOBAL_BAN_LIST = ['^.*\+.*@gmail.com'] 

> Wie befuerchtet: gibts bei mailman 2.1.26 im mm_cfg.py nicht :-(

Hast du einmal in die Defaults.py geschaut, ob es dort definiert ist und
nur noch nicht in die mm_cfg.py übernommen wurde? Ich bin mir bei der
Version nicht 100%ig sicher.

S!

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#6285

Moin,

On 2020-08-27, Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

> 4) Abklemmen des Web subscribe features. Da such ich noch eine Loesung...
>    Das muesste doch via apache.conf gehen?

Ich war in den letzten Tagen auch betroffen.  Als schnelle Lösung (unter 
Verlust des Web-Subscribes) in der Datei des Listen-vhosts:

| [...]
| ScriptAlias /admin /usr/lib/cgi-bin/mailman/admin
| ScriptAlias /admindb /usr/lib/cgi-bin/mailman/admindb
| Redirect gone /mailman/subscribe
| [...]
| ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/
| [...]

Bis die Tage,
MB

-- 
Michael Bussmann <bus@mb-net.net>

[toc] | [prev] | [next] | [standalone]

#6279

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

> So wie das aussieht sind das bots, die die mailman Web-Registrierungsseite
> missbrauchen und da fremde E-Mail-Adressen eintragen.
> Ein Motiv dafuer kann ich nicht erkennen, denn der opt-in
> Bestaetigungstext ist fix und kann vom Spammer nicht modifiziert werden.

Hat dazu noch jemand eine Idee?
Nicht, dass das bei der Spam-Abwehr helfen wuerde, aber mich
interessierts einfach, was die Spammer sich davon versprechen?

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.mailserver

csiph-web