RelayDB, greylisting

Csillag Tamás

<cstamas@digitus.itk.ppke.hu>

http://digitus.itk.ppke.hu/~cstamas

Előadás áttekintése

Célok

1. Néhány módszer bemutatása
2. Ötleteket adni
3. Javaslat: mit használjunk és mit ne?
4. Spammerek tevékenységének vizsgálata
5. Mások mit csinálnak?
6. Hogy "szokás" ma?

Néhány módszer

módszer    telepítési költség  karbantatás  problémák  hatékonyság
RFC -k          alacsony       minimális    közepes        jó(*)
greylisting     alacsony       alacsony      kevés       közepes
relaydb         közepes        alacsony  kevés/közepes   közepes
DKIM          közepes/magas    alacsony      kevés    egyre jobb(*)
SPF, CallerID   közepes        közepes        sok        alacsony
    

Miért ennyi módszer?
"Do not rely on single solution to stop spam."
             -- Wietse Venema
    

RFC megkövetelése

• Direct-to-MX támadás ellen hatásos
• Zombik ellen (vírus/worm)
• Bot hálózatok ellen
• Kis programok minimális méret/tudás
• Open proxy-k, gépek feltörésével jut a támadó ilyen gépekhez
• RBL: CBL lista

RFC megkövetelése (2.)

• Helo check (pl. localhost, saját név / IP)
• És az érvényesség? Feloldódik-e a helo név?
• Nemrég ez szakmai körökben nagy vihart vitát indított
• Érdemes-e ellenőrizni?
• DNS check (sender domain, host)
• A legtöbb helyen alapfunkció
• Érdemes használni!
• Backscatter - bounce -ok számának csökkentése
• Már az SMTP kapcsolatnál utasítsuk vissza a levelet!

RFC megkövetelése (3.)

Some parts of RFC 821 are simply too absurd to tolerate.
             -- Daniel J. Bernstein
    

RBL

• Fontos a körültekintő kiválasztás
• Több listával kapcsolatban rossz a tapasztalat
• Pl. néha egy-egy internet szolgáltató is felkerül
• CBL: composite black list
• XBL-SBL Spamhaus.org
• NJABL
• Dialup
• Auth?

Greylisting alapötlet

• A levél első fogadásakor feljegyezzük:
• Küldő gép IP cím
• Envelope-from
• Envelope-to
• ...és átmeneti hibával visszautasítjuk a levelet
• RFC-nek megfelelő gépek újraküldik
• Postfix-ben könnyen kezelhető keretrendszer található
• Máshol is van erre eszköz (pl. sendmail milter)

Greylisting (problémák..)

• Nem ugyanaz a gép küldi újra!
• VERP címek rendszeres változása
• Változó küldő IP cím
• Érezhető késleltetés

Relaydb alapötlet by Daniel Hartmeier

Saját feketelista

• A pf (packet filter) írója írta
• OpenBSD-s program
• Minden egyes IP címhez: whitecount, blackcount, timestamp
• A programot portoltam linux alá
• ... később perl-ben a MailScannner frameworkhöz

Relaydb példa

Received: from localhost (localhost [127.0.0.1]) <-- #1 Figyelmen kívül hagyja
        by checked.digitus.itk.ppke.hu (Postfix) with ESMTP id A6DB418000FE
        for <cstamas@digitus.itk.ppke.hu>; Wed, 16 Mar 2005 17:02:05 +0100 (CET)
Received: from manus.itk.ppke.hu (manus.itk.ppke.hu [193.225.109.60]) <-- #2 már ismeri w-count++
        by digitus.itk.ppke.hu (Postfix) with ESMTP id 9289918000FE
        for <cstamas@digitus.itk.ppke.hu>; Wed, 16 Mar 2005 17:02:02 +0100 (CET)
Received: from manus (localhost [127.0.0.1])  <-- #3 Figyelmen kívül hagyja
        by checked.manus.itk.ppke.hu (Postfix) with ESMTP id 80B873550
        for <cstamas@digitus.itk.ppke.hu>; Wed, 16 Mar 2005 17:02:02 +0100 (CET)
X-P0F: 193.225.12.103: FreeBSD [4.6-4.9] 5 hops away, link: ethernet/modem, uptime: 203 hrs <-- #4 Figyelmen kívül hagyja
Received: from nws.iif.hu (nws.iif.hu [193.225.12.103]) <-- #5 új címként megjegyzi w-count=1, nem megy tovább
        by manus.itk.ppke.hu (Postfix) with ESMTP id D1BC4390F
        for <cstamas@itk.ppke.hu>; Wed, 16 Mar 2005 17:01:59 +0100 (CET)
Received: (from nobody@localhost)
        by nws.iif.hu (8.12.6/8.12.5) id j2GG1xC7073175; Wed, 16 Mar 2005 16:01:59 GMT
        (envelope-from nobody)

    

$ cat /tmp/nws.header | relaydb -v -w -f /tmp/relaydb.db
reading mail headers, considering the mail not spam
checking 193.225.109.60
  found, white 32081 -> 32082 black 423
checking next header
checking 193.225.12.103
  not found, inserting new host 193.225.12.103 white 1

I'm not interested in security through obscurity.
I want real security mechanisms, solutions that
work for _everybody_. Yes, that's a lot more
difficult than randomly blowing away "suspicious"
portions of the Internet mail infrastructure, but
it's the Right Thing To Do.
                 -- Daniel J. Bernstein