SPAM ile savasma konusunda

Can Erkin Acar <[email protected]> Tue, 13 Jan 2004 15:25:51 +0200
Newsgroups gmane.mail.spam.anti-spam.turkish
Message-ID <[email protected]>
Merhaba,

Bu benim listeye ilk mesajim, hem zaten yeni uye oldum :)
Daha once tartismalari arada liste arsivlerinden takip etmekteydim,
ancak, listenin hareketlendigi bu gunlerde biraz da katkida bulunmak istedim.

Bu amacla, SPAM ile ilgili dusuncelerimi/tecrubelerimi ozetleyip bir de
sonunda, cok az uygulandigini ancak cok etkili olacagini dusundugum bir
yontemden bahsedecegim.

SPAM ile savasmak icin pek cok yol oneriliyor. Bu yontemleri aktif ve pasif ve 
hibrid (karisik) olarak uc baslik altinda incelemek mumun:


A. Pasif yontemler:

Bu yontemler gelen mesajlarin spam olup olmadigini anlamak ve eger spam ise
aliciya iletmeden silmek olarak ozetlenebilir. SpamAssasin, bayesian 
filtreler, spam databaseleri uzerinden hash kontrolu bu sinifa girmektedir.

Pasif yontemlerin avantaji, SPAM olup olmama kararini alici tarafindan
verilmesidir. Ozellikle bayesian filtreler bu konuda kullaniciya buyuk
esneklik saglamakta ve e-mail okutucularinin icine kadar entegre
olabilmektedir.

Bu yontemlerin dezavantaji ise, kararin verilebilmesi icin mesajin tamaminin
sunucuya ulasmasi, bu nedenle de disk ve network kaynaklarini isgal etmeye
devam etmesidir.  Kullanicinin INBOX'i SPAM'siz kalir, ancak spam trafiginde
bir azalma olmaz (hatta spammerlar filtreleri asmak icin yeni yeni teknikler
gelistirirler).

Pasif yontemlerde SPAM maliyetini (disk/CPU/bandwidth) gonderenin degil
alan oder.


B. Aktif yontemler:

Bu yontemlerin amaci, SPAM _trafigini_ azaltmaktir. Her gelen SPAM icin
spam'in gonderildigi adreslere ve upstream adreslere sikayet etmek, en
aktif yontemdir ;)  Bu yontemi bir-derece otomatik hale getirmek de
mumkun olsa da sonuc almak genellikle uzun surmekte ve yogun insan gucu
gerektirebilmektedir.  Gelen SPAM mesajlarin rapor edilmesi buyuk
onem tasimaktadir. Asagida ilgi alanim olan daha 'teknolojik' yontemlerden
bahsedecegim.

En cok bilinen ve uygulanan aktif yontem, 'blacklist' tir.  Blacklist
kullanan sunucu, mesajin gonderildigi IP adresine gore mesaji alip almamaya
karar verir. Burada en buyuk sorun, adres listelerinin olusturulmasinda
yatar. Adresi blacklist'e koyma kararini genelde baskalari verir.
Yanlislikla kara listeye alinmis bir adresin sahibini ise kara gunler 
beklemektedir :). Bir takim listeler, (orn spews.org) SPAM gonderen bir
adresin komsu adres bloklarini da listeye alabilmektedir.

Diger bir yontem ISPlerin dinamik adres verdikleri bloklarda disariya
dogrudan e-mail gonderimini (port 25) engellemeleridir. Bu yontem dogru
uygulanirsa oldukca etkili olabilir. Bu tarz bir filtreleme yapildigini
kullanici sozlesmesinde belirtmenin, ve alternatif (authenticated) mail
gonderme olanaklari saglamanin buyuk yarari vardir. Bu yontemi
uygulayan ISP sayisi oldukca azdir.

Yakin zamanda Microsoft'un bir girisimi olarak duyurulan, ancak arkasinda
eskiden beri yapilan akademik calismalarin bulundugu 'Penny Black' projesi
http://research.microsoft.com/research/sv/PennyBlack/
Mail gondermek icin _gondericinin_ odemesi gereken bir 'bedel' den bahseder.
Bu bedel, ilk akla geldigi sekilde microsoft'a gonderilen bir cek olarak
degil, bilgisayar islem gucu olarak odenir :) Tek mesaj icin farkedilmeyecek
kadar kucuk olan bu, 1-2 saniyelik bir kriptografik islem, binlerce SPAM
mail gonderen birisi icin maliyeti oldukca arttirmaktadir. Acik standartlar
kullanildigi zaman uzun vadede yararli olabilecek bu yaklasimin Microsoft
elinde istenilen sonuca ulasacagina dair guvenim dogrusu pek yok.

Mesajin _bedelini_ gondericiye odetme konusunda yapilan farkli bir calisma ise
blacklist kavramini bir derece ileri goturen OpenBSD projesi 'spamd' ile
gerceklesti. Burada amac, karalisteye alinmis bir IP adresinden gelen
baglantilari dusurmek yerine _surundurmek_ olarak ozetlenebilir:

Eger birisi size SPAM gonderiyorsa, baska binlerce kisiye daha gonderecek
demektir. Ben gelen smtp baglantisini hemen reddedip kapatirsam, gonderici
spamini benden sonraki kisilere hic duraksamadan gondermeye devam edecektir.

Eger ben baglantiyi kapatmayip, mumkun oldugu kadar yavaaaaaaas bir sekilde
smtp baglantisini kabul eder, daha sonra karsi tarafa yavaaas yavaaas
'kusura bakma kardesim, su anda mesajini kabul edemiyorum, lutfen daha sonra
  tekrar dene' dersem, o zaman 1) spammer benim icin cok uzun zaman harcamis
olur spam gonderme hizi cok yavaslar. 2) bana gondermeyi tekrar deneyecegi
icin disk alani harcar. Bu sayede spammer ilk kez gonderemedigi SPAM icin cok
daha yuksek bir BEDEL odemeye baslar.

OpenBSD projesi bu amacla cok az sunucu kaynagi harcayarak cok sayida
spammer surunduren 'spamd' yazilimini gelistirmistir.

Bu yaklasim daha once Berk D. Demir tarafindan listede defalarca dile
getirilmis ancak hakettigi ilgiyi toplayamamistir.



C. Hibrid Yaklasim:

Aktif ve pasif yontemler cogu zaman birlikte kullanilmaktadir. Ozellikle
blacklistlerin olusturulmasi sirasinda pasif filtreleme yontemlerinden,
tuzak e-mail adreslerinden ve kullanici rapor ve sikayetlerinden
yararlanilmaktadir.

OpenBSD gelistiricilerinden Daniel Hartmeier,

'Annoying spammers with pf and spamd'
http://www.benzedrine.cx/relaydb.html

makalesinde, kendi white blacklistlerini olusturmak icin bayesian bir filtre
kullanan, relaydb yazilimini ve bu listenin sonuclari ile spamd kullanarak
spam bedelini spammerlara odeten cok guzel bir kurulum tarif etmistir.
Yazimi bu makaleden bir paragrafla bitirmek istiyorum:

    Remember, I'm doing all of this not to reduce the amount of incoming spam.
    That gets detected and filed very reliably, anyway. The sole purpose is to
    hurt the spammers. And I'm thoroughly enjoying watching my spamd log now,
    as I'm perfectly sure that each of those connections comes from a spammer
    who has spammed me before.

    "Spam me once, shame on you. Spam me twice, shame on me." :)


Iyi calismalar

Dr. Can Erkin Acar
Pro-G Bilisim Guvenligi ve Arastirma Ltd. Sti.
http://www.pro-g.com.tr