Re: Spamer abwehre Ideen

On Tue, Feb 24, 2004 at 08:06:52PM +0100, Olaf Hoyer wrote:
> On Tue, 24 Feb 2004, Bernd Walter wrote:
>
> > > Wir hatten gestern einen Kunden, welcher sich nen Virus einholte und uns mal so husch husch 90000 mails auf einen relay liess. Spam total, mit generierten email adresse und alle an aol :-)
> >
> > Ja und?
> > 90000 ist doch gar nichts.
>
> Moin!
>
> Naja, kommt auf die mail selber an und natuerlich auf die Maschine, die
> dahintersteht...

Sicher, aber ein ISP sollte eine Maschine haben die darüber lacht.

> Wenn die mail klein ist, hat die Kiste natuerlich einiges im queuing zu
> tun, bei den von typischen Viren generierten mails, wo ja noch einiges
> an binary attachment (meist so bis 150kbyte) dranhaengt, ist das auch
> mitunter ein Problem des Spools, da soviel Plattenplatz zu haben, wenn
> die Software jede mail recht spontan einzeln handelt.
> Qmail ist recht fix, hat aber ein mehrstufiges Verarbeitungskonzept, was
> ich nicht unbedingt als ressourcenschonend bezeichnen moechte...

Mit Sendmail ist das bei richtiger Konfiguration Kleinkram.

> >
> > > Nun, bin ich mir am ueberlegen, was ich für
> > > moeglichkeiten auf einem relay server häaette.
> > > Wir relayen für unsere IP netze und machen mx20
> > > für unsere domains, bzw. Mailbackup und senden
> > > die sobald mx10 wieder up ist, weiter.
> >
> > Jetzt wird es widersprüchlich.
> > Ist der Rechner nun Kundenrelay oder 2.-MX?
>
> Bei vielen (kleineren und auch manchmal mittelgrossen) Providern macht
> der physikalische Server sowohl Kundenrelay ausgehend als auch
> secondary MX.

Der Punkt ist, das Kunderelay normalerweise rausgeht und auch schnell
raus soll, während 2.MX mit Sicherheit noch eine Weile in der Queue
bleiben wird.
Wenigstens eine 2. Systemumgebung macht Sinn - wenn auch auf dem
gleichen Rechner.

> > > Nun, spamassasin brinngts nicht so, da wir die
> > > msg scannen und der empfänger wahrscheinlich
> > > auch nochmals... Eine Idee währe die connections
> > > zu checken und wenn sagen wir 50 connections von
> > > einem user offen sind, dessen ip zu sperren oder
> > > zu limitieren. Oder z.B. die gesendeten emails
> > > zu zaehlen und bei einem max, den zu killen.
> >
> > Warum sollte ein Kunde 50 Connect aufmachen, wenn er doch alle
> > 90000 auf einen Connect verschicken kann?
> > Dafür gibt es das RESET Komande beim ESMTP.
> > Mal abgesehen davon kann der Kunde ja auch einen legitimen Grund haben
> > 90000 Mails zu versenden.
> > Und wo ist das Problem ausgehende Mails zu filtern?
> > Entweder Ihr macht das oder Ihr akzeptiert die 90000 Mails.
>
> Genau das filtern ist denke ich die Intention des OP, die Frage ist hier
> eben, auf welchem Wege man dieses in einem derartigen Szenario
> bewerkstelligt.

Mit purer Maschinenleistung - ein guter Filter braucht das einfach :(

> Die Frage ist auch, wie man legitimen Usern (die meist faul sind, und
> deren Massenmailersoftware selten was von SMTP-Auth gehoert hat) einen
> ungestoerten Zugang zum Mailserver bietet, und gleichzeitig von Viren
> befallene Rechner am absetzen von Muell hindert. Frage ist dabei dann
> auch automatisch die Funktionsweise der SMTP-engine eines Wurmes, ob
> diese fuer jede Mail einen eigenen connect macht, oder ob die mails in
> einen Server reingeworfen werden, und innerhalb der Session dann mehrere
> RCPT TO: gesetzt werden. Hiervon muss ja gemaess rfc mind. 100 rcpt to:
> pro mail drin sein, kann natuerlich auch sein, dass in neueren rfcs
> dieses evtl. anders gehandhabt wird.

Ich Zweifelsfalls binded sich der Virus ans Windows Mail System und
logged sich mit den Outlook hinterlegten Daten ganz legitim beim Relay
ein.

> Man kann natuerlich sagen, dass wenn von einer IP mehrere simultane
> connects kommen, dass dieses suspekt ist, und dann diese blocken, am
> Mailserver oder an einer Firewall, da duerfte aber auch in begrenztem
> Masse eine Teergrube helfen...

Bei Endkundenzugängen ist das durchaus machbar und es wird auch von
einigen ISPs gemacht, aber eine Lösung ist das letzlich nicht, da auf
Dauer die Viren einfach nur aufrüsten werden.

> Legitime Kunden senden ja meist innerhalb einer session, sofern deren
> Mailersoftware nicht komplett murksig ist, oder alt/schlecht gewartet...

Derartige Software kommt aber leider immer mal wieder vor.

> Als Provider hat man haeufig auch in den AGB stehen, dass groessere
> Massenmailings vorher anzukuendigen sind, damit auch sichergestellt
> werden kann, dass die infrastruktur dieses a) aushaelt und b) kein
> falscher Alarm irgendwo losgeht, wenn ploetzlich das mailrelay so einige
> mails in der queue liegen hat (nagios hat da ein recht nettes plugin
> fuer...)

Sicherlich eine gute Massnahme.

> Auf welche Weise wuerdest Du in einem derartigen Szenario filtern?
> Du erwaehntest mal etwas von einem groesseren Mailersystem, welches Du
> aufgesetzt hast, da sind doch sicherlich auch Mechanismen drin, die
> Muellmail in irgendeiner Form begegnen?

Die Problematik gab es damals noch nicht in der Form - da hat gab es
noch die Devise sowas durch zu lassen.
Inzwischen nehmen große Provider wie AOL ja nicht mal mehr von externen
Systemen mehr als eine Handvoll Mails an und drosseln dann runter.
Wenn man also, wie in diesem Fall, eine Virenflut nach AOL hat, dann
wird auch der Legitime Verkehr zu denen behindert :(
So wälzt man als großer Provider Probleme ab...
Derzeit filtere ich auf einem zwischenliegenden Rechnerpool und tagge
Mails.
Mit den Tags können dann die Outbound Rechner bestimmen was damit
zu geschehen hat.
Mails die auffällig sind werden zwischengelagert und durch eine
Kundenzuordnung wird dieser Benachrichtigt und kann die dann freigeben
oder canceln.
Reingehende werden getagged und der Kunde kann die in einen extra
Folder einsortieren lassen oder wie auch immer behandeln.
Einfacher wäre es natürlich den Kunden Windows zu verbieten :)

-- 
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-questions" in the body of the message