Re: Thread in freebsd-stable und Anti-Spam

From: Bernd Walter <ticso(at)cicely9.cicely.de>
Date: Mon, 28 Apr 2003 12:28:06 +0200

On Mon, Apr 28, 2003 at 11:51:51AM +0159, Karsten W. Rohrbach wrote:
> Oliver Fromme(olli(at)secnetix.de)@2003.04.27 19:24:20 +0000:
> > keinen guten Grund daf?r hat, sondern /usr/sbin/sendmail
> > o.?. aufrufen. Das ist n?mlich daf?r da. Ein Programm,
> > das versucht, selbst STMP zu machen, handelt sich eine Men-
> > ge ?rger ein (und eine Menge M?glichkeiten, es falsch zu
> > machen). Beispielsweise mu? es ein eigenes lokales Queuing
> > implementieren, und zwar korrekt und sicher, was keineswegs
> > trivial ist. Dem w?rde ich eher nicht ?ber den Weg trauen.
>
> Ahem, warum sollte ein SMTP Client nun Queueing implementieren? Gerade
> auf einem Client will man doch meist (durch interaktive Frontends), dass
> ein Fehler auch angezeigt werden kann, und zwar dann wenn er passiert.
> Applikationsserver sendet Notification an einen Redakteur, dass ein
> Dokument freigegeben werden soll. SMTP-Server nicht verfuegbar: Fehler.
> Queueing an dieser Stelle wuerde das Debugging und den generellen Umgang
> mit dem System schon ziemlich bervig machen.

Ich hätte Probleme, wenn ich eine Mail neu schreiben müßt, nur weil der
SMTP Server nicht ereichbar war.

> > > Wenn ein Spammer Mails ueber ein offenes Relay "explodiert", dann
> > > verursacht ein vermeintliches Relay sicherlich weniger Bandbreite, da
> > > die Zilliarden ausgehender Mails ausbleiben... mal so auf der
> > > Schiefertafel ueberschlagen ;-)
> >
> > Wohl kaum ... Das wird der Spammer n?mlich ziemlich rasch
> > merken, und dann woanders sein Gl?ck versuchen. So ganz
> > dumm sind die Spammer n?mlich (leider) nicht.
>
> Trotzdem verursacht dann das vermeintliche Relay weniger Traffic als das
> offene ;-) Nein, mir ist klar was Du meinst und Aepfel und Birnen...

Aber wohl immer noch wesentlich mehr, als dem Nutzen gegenüber steht.

> Die Idee, die mir dabei kommt ist folgende:
> - Spammer haben ein gewisses Profil der Relaynutzung

Das glaube ich nicht.
Ich habe die unterschiedlichsten Ansätze gesehen.
Und du darfst nicht vergessen, daß sich Spammer keineswegs auf SMTP
reduzieren.
Man denke an webmail, socks, ...
Es gibt allerdings auch Varianten, die noch nicht genutzt werden.
SMTPS Probes habe ich z.B noch nie gesehen.

> - Spammer haben bestimmt Profile des Ausfindigmachens offener Relays

Das glaube ich ebenso wenig wie beim vorigen Punkt.

> - Wir haben jetzt den Honeypot Ansatz bis zum Erbrechen diskutiert

Eigendlich nicht.
Die Konsequenzen fehlen daraus Filter Regeln zu bauen.
Aber das machen ja bereits anderes.
Problem dabei ist allerdings, das du selbst zuverlässige Honeypot
Ergebnisse von Hand durchsehen muß, um nicht die Relayserver von
Providern zu filtern.
Und gerade die Fälle machen echt Arbeit.

Einen witzigen Fall hatte ich mit MSN.
Die Mail kam von einem *.msn.com Rechner und ich habe das dann an
abuse(at)msn.com weitergeleitet.
Von denen kam dann eine Mail, daß die Nachricht nicht von MSN kommen
würde, da der Absender nicht @msn.com wäre.
Darauf habe ich denen geantwortet, daß das Reversemapping msn.com sei
und auch vom Forwardmapping gedeckt wird.
Zudem wäre ja auch die IP auf Microsoft registriert.
Was soll ich sagen - die Antwort ist Microsoft Intern mit too many Hops
auf einem Exchange gebounced worden...
Den Bounce habe ich dann an postmaster(at)microsoft.com und noch direkt an
abuse(at)msn.com geschickt - postmaster@ war ohne Reaktion...

> - Wenn alle beteiligten Honeypots, denen man vertrauen kann, ihre
> Verbindungsinformationen in eine Zentrale Mimik einkippen, kann man
> flaechendeckend sehen, wer wann mit welcher Streuung Relays finden
> will (und evtl. benutzt)

Und was hilft dir das?
Meine Kiste sind relayfest - warum sollte ich also wissen wollen von
wo relays gesucht werden?
Ich brauche da nichts mehr extra filtern.

> - Daraus -> ACL, RBL, Remote Firewall Config, Yadda yadda...

Und die Kisten die wirklich relayen sind falsch konfiguriert, da wirst
du auch nichts mit den Informationen ereichen.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-chat" in the body of the message
Received on Mon 28 Apr 2003 - 12:28:24 CEST

search this site