• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Neue Spam Prävention

Status
Für weitere Antworten geschlossen.

ThomasF

Hacker
In einem Artikel des aktuellen Linux Magazin wird von einer "neuen" Technik im Kampf gegen SPAM geschrieben ...

( Spamschleudern im SMTP-Verkehr durch Wartezeiten und Stottern austricksen )

Es geht dabei unter anderem um "SMTP-Greet-Delay" und "Teergruben-Simulator"

Siehe auch -> http://www.heinlein-support.de/upload/mk3/tweak_your_mta_eggendorfer.pdf

Im Linux Magazin wird der Author allerdings nur bei der Konfiguration von Sendmail konkret :(

Ich suche in diesem Zusammenhang jetzt schon seit 3 Tagen nach Hinweisen für die Konfiguration unter Postfix gesucht, bin aber nicht wirklich fündig geworden.

Ein paar Hilfreiche Optionen für Postfix habe ich dabei zwar neu entdeckt ... aber für das erwähnte "Stottern" habe ich nichts gefunden ... auch keinen SMTP Proxy ...

Ich schau mir gerade noch das Script von Lutz Donnerhacke an ...

http://www.iks-jena.de/mitarb/lutz/usenet/

aber wenn jemand vielleicht schon einen Schritt weiter ist könnten wir hier das Thema vielleicht aufgreifen, oder ???

So long

ThomasF
 

TomcatMJ

Guru
Hm, ich hab zwar den Linux-Magazin Artikel jetzt nicht da, aber deiner Beschreibung nach hört es sich nach einer Art modifiziertem Greylisting an. Wenn wir dazu genug initiale Infos hier zusammenkriegen werde ich den Thread dann auf Wichtig setzen. Vielleicht wirds dann ja auch zu einem entsprechenden Wiki-Artikel kommen?*g*

Bis denne,
Tom
 
OP
ThomasF

ThomasF

Hacker
Hi,

ich denke nicht das es ein modifiziertes Greylisting ist ... bei diesem "Teergruben-Simulator" wird keine Verbindung abgelehnt.

Nach dem Verbindungsaufbau wird die Übertragung "gestottert" ... der Autor im Linux-Magazin sprich von ca. 120 Bytes mit jeweils einer Pause von 0,5 Sekunden.

Dies bewirkt in bis zu 80% der Fälle das ein Spammer von sich aus die Verbindung beendet weil er glaubt in eine Teegrube gefallen zu sein.

Nach diesen 120 Bytes, eine Zahl die auch per Zufall größer oder kleiner ausfallen kann, geht es mit normaler Geschwindigkeit weiter ....

Ich finde die Idee ganz interessant ... auch wir hier zur Zeit mit Greylisting und den smtpd_restrictions ganz gut fahren ...

Aber letzte Woche hatten wir hier einen traurigen Rekord ... pflogsumm meldete 119641 Mails rejected !!! Und 534 Mails die dann zugestellt wurden ... wobei unter diesen 534 natürlich immer noch eine große Anzahl von SPAM - Mails dabei waren ...

Und selbst http://www.greylisting.org/ spricht davon das sich die Spammer an die Technik des Greylistings anpassen ...

Also ... das Wettrüsten geht weiter ;)

So long

ThomasF
 

ceegee

Hacker
Hi,

ich hab den Artikel auch gelesen und auf eine Postfix Konfiguration gewartet. Leider Fehlanzeige. Ich hatte zuletzt ca. 182000 Rejects zu 600 angenommenen Mails. Allerdings bin ich mir nicht sicher ob pflogsumm wegen amavis doppelt zählt.

Gruß Christian
 

stka

Guru
Ich werde heute Abend mal fragen wie das für den Postfix geht, ich telefoniere heute mit jemandem der das BESTIMMT weiß ;-)
 

gameboy

Hacker
ThomasF schrieb:
Nach dem Verbindungsaufbau wird die Übertragung "gestottert" ... der Autor im Linux-Magazin sprich von ca. 120 Bytes mit jeweils einer Pause von 0,5 Sekunden.

Dies bewirkt in bis zu 80% der Fälle das ein Spammer von sich aus die Verbindung beendet weil er glaubt in eine Teegrube gefallen zu sein.
Was ich mich bei solchen Methoden (z.B. auch bei Greylisting) immer frage, ist: Auch wenn das kurzfristig vielleicht eine gewisse Erfolgsquote verspricht, so ist es doch sicherlich nur eine Frage der Zeit, bis die Spammer ihre Tools entsprechend anpassen, oder?

Viele Grüße,
gameboy.
 
OP
ThomasF

ThomasF

Hacker
@gameboy

naja grundsätzlich hast du wohl recht :(

Anderseits hat diese neue Methode den gewissen Charm, etwas anders vorzugehen als die bisherigen Tools.

Ich persönlich glaube das bei steigender Anzahl "echter" Teergruben eine gute Chance besteht eine Weile "Ruhe" zu haben ;)

Ob die Vorgehensweise mit Teergruben Rechner oder Rechenzeit zu "opfern" um es den Spammern schwer zu machen ist eine ganz andere Geschichte *fg*

Und noch ein ganz anderer Punkt, auf den mich ein Arbeitskollege gebracht hat, .... was wäre denn wenn den Spammern entgültig das Handwerk gelegt würde ???
Melden die sich dann auf dem Arbeitsamt ... ??? ... eher unwahrscheinlich
Also suchen die sich andere Betätigungsgebiete ...

IMHO ist aber Email ein sehr wichtiges Kommunikationsmittel ... ich fürchte jedoch auch das ein rumbasteln am SMTP Protokoll immer eine Notlösung bleiben wird.

So long

ThomasF
 
OP
ThomasF

ThomasF

Hacker
So kurzes Update von mir ...

Also habe in dem Zusammenhang habe ich in einer Postfix Group folgendes gefunden :

http://groups.google.com/group/list.postfix.users/browse_frm/thread/a9b45c3cd257ecdf/1108d7e9c5c37fd4?tvc=1&q=stutter#

Anderseits denke ich das z.B ein policy_server für Postfix nicht geeignet ist, eine entsprechende Erweiterung zu implementieren, da dieser ja nur eine Antwort an Postfix zurückliefern kann ... z.B. reject

Eine sleep Anweisung in den Restrictions reicht aber auch nicht aus ...

Ein grundsätzliches "Stottern" im SMTP wäre auch nicht optimal da es ja Restrictions gibt die vorher greifen und schneller sind ( z.B reject_unknown_sender_domain )
Somit fällt der SMTP Proxy der dem Postfix vorgeschaltet ist auch raus ...

Übrig bleiben würde IMHO ein Patch oder eine Erweiterung von Postfix selber, die erst nach der Abarbeitung der Restrictions, also nach einem "permit" greift ... optimal wäre wenn dies nur greifen würde für Sender die nicht über eine Whitelist das permit erhalten haben ...

Das sind ja gleich mehrere Wünsche auf einmal ... das geht doch nun wirklich nicht .... *fg*

Na mal abwarten ...

Apropos .. eine andere Methode die ich bei der Suche entdeckt habe hört sich auch interessant an *fg*

http://nolisting.org/

So long

ThomasF
 

stka

Guru
Im Moment gibt es keine Implementation für dieses Verfahren für den Postfix. Das graylisting funktioniert aber immer noch ausreichend gut.
 
Status
Für weitere Antworten geschlossen.
Oben