Re: Spamer abwehre Ideen

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...

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...

>
> > 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.

>
> > 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.

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.

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...

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

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...)

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?

Gruesse
Olaf

-- 
Olaf Hoyer        ohoyer(at)gaff.hhhr.ision.net
Fuerchterliche Erlebniss geben zu raten,
ob der, welcher sie erlebt, nicht etwas Fuerchterliches ist.
(Nietzsche, Jenseits von Gut und Boese)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message