Zamezíme spamu

24.8.2009 18:23 | Přečteno: 1094× | tutorials | poslední úprava: 24.8.2009 18:38

No, chtěl jsem toto téma nechat až na víkend jako oddychové, ale bude nejspíše vyčerpávající už jako pondělní, vzhledem k faktu, že se to už provalilo.

Ukazuje se, že spam tvoří 95procent všech mailů, že stojí nemalé peníze firem a obzvláště představuje energetickou náročnost většího než velkého města:) asi dvou a půl násobku Prahy. Kdo tedy za spamem stojí? Jsou to především anonymní tvůrci malwaru, které se nikdy nepodaří dopátrat, ale dá se jim zamezit. Já jako uživatel nebo spamer mám na výběr dvě možnosti. Buď si vytvořím svůj vlastní mail server, ze kterého budu odesílat spam a obchodní sdělení, což mi hrozí umístěním se na blacklist a pokutami od úřadů nebo využiji raději botů, což se u spamu obvykle dělá. Já jako BFU, který chytí breberku v ne mých windows, už je totiž delší dobu nepoužívám, budu posílat mail pomocí mail serveru, odešlu tím zároveň spam. Vezmeme-li v potaz, že spam tvoří 95procent všech mailů, dojdeme k závěru, že na každý mail by muselo být potřeba 20spamů, tj. asi určitě více jak 100spamů na jednu naši zprávu, kterou stihneme napsat za 5minut, kvůli které máme klienta zapnutého. Mám-li zavirovanou stanici, jsem v tu konkrétní dobu také identifikovatelný mail severem stálými požadavky o odeslání mailu. Dobře, odešlu-li svůj mail ze spamující stanice, tak během vteřiny mám u serveru požadavek o odeslání dalšího jiného, což už je pochybné, jsem tudíž potencionální spamer. Jak tomu na druhé straně zamezíme? První mail se odešle hned, druhý za 5vteřin, třetí za 20, čtvrtý za minutu a ten váš až zítra. Tím se omezí odeslání stovky dalších. Pokud by zde byla dobrá komunikace mezi mail serverem a uživatelovo klientem o požadavku odeslání více mailů způsobem, že nápor od vás je nepřijatelný krátkou zprávou, donutilo by to uživatele k přejetí systému antivirem nebo jeho reinstalaci. Vše by závislelo na časové frontě, která by se dala vrátit na webovém rozhraní mail serveru a tak dokola. Samozřejmě, že spam je problém zavšivených klientů, o kterých nemá uživatel představu. Málokterý spamer odesílá spam přes webové rozhraní web klienta, protože ten nejspíš nebude zavirovaný a nebude zde tvořit spamy automatika. Když už bych se dostal do problémů se spamováním tak, že by mail serverer odmítal odesílat mé požadavky z pracovní stanice a toto mi dostatečně řekl v krátkém čase, měl bych mít tuhle možnost jako jistotu pro přihlášení se a odeslání rychlého mailu z prohlížeče. Faktem je, že žádná zombie stanice neodešle mail bez potřebného serveru, když jím sama není. I kdyby by byly všechny servery děravý, nemuseli by akceptovat tak rychlé požadavky od konkrétních uživatelů a tohle jim dávat vědět. Tohle zde totiž není pod kontrolou. Ten spamující server by byl buď na blacklistu, což by pak neschopností administrátora bylo záměrem spamovat jiné, nebo by mail server odmítal přijmout větší množství požadavků s časy, jak jsem uvedl a tím by přispěl k snížení procenta spamu. Záleželo by to na volbě nastavení administrátorem. Sám mám možnost takový mail server s více virtuálními uživateli spravovat. Z web klienta těžko nějaký spam odešlu. Riziko, že odešlu já spam je menší než u veřejných poskytovatelů pro uživatele, který svou schránku vystaví kdekoli a používají zavirované stanice, přesto nevidím problém v komunikaci mezi serverem a zavirovaným mail klientem. Říct zde: Ty se snažíš odeslat víc mailů, než jsi schopen poslat, tak ti je odešlu později, zatím si zkontroluj bezpečnost na pc, bude určitě daleko lepší volba než maily zcertifikovat nebo dokonce zpoplatnit. Vidím to jako administrátor serveru, který nemá nic proti normálním mailům a také nic proti obchodním sdělením, které by se dali srovnávat s whitelisty přímo na mail serveru a pro ty by časové omezení neplatilo v závislosti na nastavení serveru, pak by to byl onen identifikovatelný server, který odesílá obchodní sdělení a to se dá snadno odfiltrovat podle hlavičky přímo ve spam filtru. Ona ta filosofie mít všechno pomocí webu je v jednom správná a to v odpovědnosti přístupu na věc. Co vy myslíte?        

Komentáře

[isimsip]

Prostudujte si prosím ještě jednou smtp protokol. Především tu část o serveru a klientu.

[bluemoon]

a vy si zase neco prostudujte o filtrovani, neni zde zadny problem na smtp protokolech, o kterych jsem ani nemluvil.

[sigma]

Pokud chcete komukoliv poslat e-mail, je to nutně otázka SMTP protokolu. Mám svůj e-mail server pro svou doménu, kdokoliv mi může poslat e-mail, ale jedině tak, že se připojí na TCP port 25 mého serveru a pomocí SMTP protokolu mi e-mail předá. Takhle nutně - ze specifikace SMTP - funguje každý veřejný mailserver, a takhle se na něj může připojit jakýkoliv zombie.

[bluemoon]

spamassassin take nekomunikuje primo na smtp portu a lze jej pouzit i pouze pro klienta nebo pro jine porty. jde mi o fitrovaci metodu, kterou by spamassassin, ale i dalsi jiny, mohli aplikovat. nechtel jsem ho sem tahat, myslel jsem, ze vam to predstavivost dovoli hlavne kvuli principu. jde mi o uvedeni mnozstvi, ktere je s jednou mou zpravou na napedeny stanici poslano daleko vice jineho spamu.

[trekker.dk]

A poté "Jak správně dělit text do odstavců v deseti lekcích"

[sigma]

 

 

 Faktem je, že žádná zombie stanice neodešle mail bez potřebného serveru.

A to jako proč? Pokud tedy tím serverem nemyslíte MX server pro cílovou doménu. Naprostá většina spamů nechodí přes regulérní servery z napadených počítačů, ale právě přímo z těch PC na cílové MX servery. SMTP server, který si nastavíte třeba v Outlooku, totiž po příjetí mail odesílá na MX server dané domény - a v této chvíli je v roli SMTP klienta! Z lib. počítače, z kterého lze navázat TCP spojení na port 25 MX serveru (tj. klidně i z PC za NATem), můžete posílat SPAMy. Problém je v tom, že v roli přijímacího serveru není možné rozlišit, která zdrojová adresa patří "normálnímu serveru" a  která "počítači". Nebo chcete-li jinou formulaci, spammer si může pomocí bota nainstalovat ten "SMTP server" na napadený počítač...

na každý mail by muselo být potřeba 20spamů, tj. asi určitě více jak 100spamů na jednu naši zprávu, kterou stihneme napsat za 5minut

Takhle to většinou nefunguje. Napadený počítač se prostě připojuje přímo na cílové MX servery a sype na ně jeden mail za druhým, dokud je ještě čas - tj. dokud se neobjeví na blacklistech.

Obávám se tedy, že navržené řešení není nijak převratné, a v praxi by ho moc použít nešlo. Možná jsem to ale jen nepochopil.

[bluemoon]

prectete si muj prispevek znovu, jde tady vzdy o pozadavky odeslat nebo preposlat mail, ktere uz jsou mimo nase schopnosti. mozna jsem se dobre nevyjadril a server beru jako stanici s otevrenym smtp portem at uz pro prijem nebo jen preposlanim. filtrem na mail portu serveru at uz je tedy jen urcen pro preposilani, by se dalo toto rapidni odesilani zpomalit od konkretniho uzivatele napadene stanice a dat mu to i vedet, ze toto neni prijatelne. neni to urcite nerealne.

[sigma]

 server beru jako stanici s otevrenym smtp portem at uz pro prijem nebo jen preposlanim. filtrem na mail portu serveru at uz je tedy jen urcen pro preposilani, by se dalo toto rapidni odesilani zpomalit od konkretniho uzivatele napadene stanice

Tak to zombie budou dělat tak, že na jeden server pošlou/zkusí poslat třeba 10 mailů (a klidně počkají na poslání každého z nich 5 minut). V tip je v tom, že zombie posílá SPAMy klidně na desítky různých cílových serverů paralelně. A pak abyste mohl sledovat, který PC posílá "moc mailů", musel byste mít nějakou koordinaci mezi těmi servery. A to už se dostáváme k blacklistům.

Normálního uživatele PC ale vůbec nezajímá, že je jeho IP adresa na blacklistu. Už proto, že ji často NATem sdílí s desítkami dalších lidí a nemá šanci to ovlivnit. Normální uživatel, když už neposílá přes webmail, tak používá pro odesílání SMTP server svého ISP/webhostera, kam se připojuje s autentizací jménem/heslam, takže se na blacklisty nekouká.

konkretniho uzivatele napadene stanice

Když já provozuji MX server pro nějakou doménu, tak nemám šanci identifikovat "uživatele stanice". Já mám k dispozici IP adresu (což je většinou nějaký NAT, nebo IP z poolu nějakého ADSL/kabelovky v USA ap.) a pak obálkovou adresu odesílatele, která je stajně podvržená. 

dat mu to i vedet, ze toto neni prijatelne

Dát někomu vědět můžete, když ho umíte identifikovat. Tohle se samozřejmě používá - když jako webhoster dám zákazníkovi možnost používat autentizovaný SMTP server, a zjistím, že se mi přes něj valí desítky mailů za minutu, tak mu zablokuju účet a dám mu vědět. Ale jak už jsem psal - přes autentizované servery se SPAM neposílá, protože správce toho serveru je schopen konkrétního uživatele rychle zablokovat...

 

 

 

[bluemoon]

o to mi jde, aby zombie stanice cekali co nejdele a bylo jim to dano vedet, pak by netvorili zminenych 95procent. slo mi o aplikaci nejakeho zpomalovaciho filtru. nemusi to byt jen zalezitosti serveru ale i klienta. predevsim si vas mail, ktery uz podvrzeny neni vyzvednete u poskytovatele.

[bluemoon]

netvorily

[sigma]

 No, to je správná myšlenka - zpožďovat e-maily ze zombie strojů.

Máme tu ale základní problém. Každý jeden SMTP server musí tedy nějak detekovat, že nějaká IP adresa je zombie. Jak to udělat? Říkáte, že bychom mohli sledovat počet mailů za určitý čas z každé IP adresy. No jo, ale jak jsem psal, zombie nefungují tak, že by posílaly "hodně mailů na 1 server", oni fungují tak, že posílají "po jednom e-mailu na hodně různých serverů" (to je příklad, může to být třeba 1 mail za 10 minut na každý server).

Takže:

mě, jako provozovateli 1 serveru, z IP adresy a.b.c.d příjde třeba ten 1 mail za 10 minut. Ale už neumím zjistit, že tahle IP adresa ta těch 10 minut poslala po 1 mailu na 1000 jiných serverů. To by musela existovat nějaká centrální databáze. A ona existuje! Jsou to DNS blacklisty, třeba spamhaus.org

Níže jste psal, že si to umíte představit jako filtrování - tj. není to nutně věcí SMTP, ale třeba klienta. Ale pořád narážíme na stejný problém, a to je ten, že zombie posílají maily paralelně na hodně míst, a bez nějaké centralizace to nemáte šanci zjistit... Takže to stejně skončí u nějakých blacklistů - třeba je nebudu používatna blokování, ale jen na zpožďení, nebo na body do SpamAssasinu...

Na druhou stranu můžu říct jedno: na jednom mailserveru pro cca 100 schránek a 3 domény používám jako jedinou ochranu proti spamu požadavek na reverzní záznam k IP + blacklist zen.spamhaus.org - výsledek je tak 1% spamu ve schránce a tak 1 za půl roku problém s někým, kdo má mailserver na ADSL bez reverzu, nebo IP na blacklistu (tj. false-positives). Nejde to tak dělat vždy a všude, ale já jsem s tím spokojený.

[bluemoon]

ja si ale myslim, ze se tady o 5-10 minutach nebavime, obzvlaste ne, pokud spam tvori 95procent. navic takovy bot, ktery se bude snazit neco rozesilat bude logovat i navstivene domeny.

[Stevko]

Zasa strasne napisany clanok. Vie mi niekto zjednodusene povedat, co je vlastne navrhovane?

A ked nejaka zombie posiela maily, tak to nerobi tak, ze si najde MX prijemcov a neposiela to rovno tam (takze kazde spojenie ide viac menej inde)?

A preco sa miesto MX nepouzivaju SRV zaznamy?

[sigma]

 A preco sa miesto MX nepouzivaju SRV zaznamy?

Možná proto, že SRV záznamy přibyly do specifikace DNS až když už mnoho let byly definovány MX záznamy a všechny mailservery na světě v té době uměly používat jen MX? Prostě zpětná kompatibilita. Jinak, čemu by to pomohlo?

[bluemoon]

asi protoze tyto zaznamy jsou tak neucinne pri filtrovani, ze se musi zpoplatnit, nebo jak si to vysvetlujete? nebudu psat lip, dokud tu nebudou vetsi moznosti upravy nez dvema BR pri oddeleni odstavce.

[CEST]

Pokud vim, tak lze v blogu pouzit i P a UL, mozna i OL. Minimalne ta znacka P by byla dobra.

[bluemoon]

kdyz ani tag P nemuze obsahovat atribut align tak je to tezky.ja si uz zkousel menit pisma a jejich zvyrazneni na ukor jine casti, ale nema to smysl, protoze se mi to zda vsecho az moc vyrazny, tucny a hlavne je to velky font. ani nevite, co ja bych dal za patkove pismo, aby se vam to cetlo lepe. mozna ze to budu psat jinam a vzdycky jen upozornim a odkazu a diskutovat tu budu zde.

[Ladicek]

Align? Člověče, tomuhle zápisku ubližuje v první řadě chybějící rozdělení na odstavce! Já ho kvůli tomu například vůbec nečetl, protože se to zkrátka číst nedá.

[bluemoon]

vzdyt uz jsem to rikal, ze odstavce aby byly zretelne viditelne, tak se musi oddelit dvema BR. kdybych odstavec zarovnal do bloku, byl by dalsi daleko citelnejsi. navic zde u tucneho pisma neco zviditelnit pomoci B je zhovadilost. take tomu ublizuje prechod z casti s reklamou do celeho textu. je to prasarna, kterou nemohu zmenit. klidne bych dal reklamu pod perex a zacal psat pod nej blog, nez aby tomu bylo nerovnomerne. zacinam po trech zapiscich uvazovat o tom, zda-li je abclinuxu takove pro-open nebo ne. pokud poradis zpusob, kterym to bude hezky a jeste lepsi, budu rad.

[Ladicek]

Ne. Odstavce se uzavírají do P. P od slova paragraph. BR je break, odřádkování, nikoliv odstavec. Být tebou, nejdřív si přestanu vymýšlet – na ábíčku prostě všechny blogy vypadají stejně a to je klad (určitě nejen pro mne) – a zkusím tu nejjednodušší možnou cestu.

Btw měl jsem taky jednou prohlížeč, kde všechny texty na ábíčku byly tučné, ani nevím, jak jsem toho dosáhl, ale normálně opravdu nejsou, takže B je klidně použitelné. Když teda pominu, že zvýrazňování ztučněním je opravdu zhovadilost, ke zvýrazňování slouží kurzíva (I) a v HTML značka EM, která se typicky kurzívou vykresluje (ale já jsem línej, takže tu používám I).

[Zdeněk Štěpánek]

A zkouseli jste si nekdy napsat tohle? Od urcite doby nemozne, nekdo nad tim asi premejslel kolenem. Misto toho se tam musi uplne idiotsky nasekat kupa <br>.

<p>zdravim</p>
<p>Kratky uvodnik blogu</p>
<break>
<p>Text blogu...</p>

Zdenek

[Ladicek]

Vím, že před časem přibyly nějaké dost drakonické restrikce co se perexu týče, ale jelikož mi přijde rozumné mít perex právě jednoodstavcový a vždycky to tak dělám, moc jsem to neřešil.

[CEST]

Musim priznat, ze se mi ten text cte trosku spatne, takze si nejsem jistej, jestli jsem to navrhovany reseni spravne pochopil, ale pripada mi to podobny jako graylisting.

Mam ale dojem, ze u nekterych klientu se da nastavit, jak casto maji emaily odesilat a kontrolovat. Takze muzu napsat nekolik emailu (treba kdyz jsem offline), nechat je ulozeny ve fronte a pak je poslat, kdyz se prepnu do online. V tom pripade muzu vygenerovat spoustu normalnich emailu, ktere ale bude mail server zbytecne zpozdovat, protoze bude spatne predpokladat, ze to jsou spamy.

Pokud nejake limity, tak treba na max. pocet odeslanych email za nejaky casovy usek, ale aby sam mail server pri prijmu emailu odmitnul email prevzit. Ne ho prijmout a zdrzet.

Dale je problem, jak mail server pozna, co presne je ten tvuj email v poradku a co jsou ty spamy? Ono by se totiz zrejme stalo, ze by se na mail server nasypalo X spamu pred tvym emailem, takze by se poslalo prvnich par spamu a zbytek by se posilal az za dlouho a na tvuj email by se dostalo mozna v pristi petiletce. To bys asi nechtel, co?

IMHO je nejjednodussim resenim podepisovani. Pri podepsani emailu musi uzivatel zadat svoje heslo ke klici, na coz by melo obvykle vyskocit nejaky okynko. Spamy by zrejme spambot nepodepisoval a pokud uz by chtel, musel by vyhazovat spoustu okynek na podepisovani a to by se uzivatel dovtipil, ze je neco spatne. Navic pri pouziti externiho tokenu by byla, ze uzivatel token zastrcil jen pri odesilani posty a jinak by ho nemel, takze spambot by ani nemel cim podepisovat. A pokud by uzivatel z lenosti psat heslo pouzival nejakej agent a spambot by ho dokazal vyuzivat a nechaval by si tak podepisovat spamy, tak by se hned rychle prislo na toho cloveka, ktery spamuje. Dalo by se mu napsat na email, ze ma zavirovanej pocitac a pokud si pocitac neodviruje, preda se to policii a ta to s nim pak bude resit jako umyslne spamovani. Proste vsechno by slo jednodusejc.

Ted me napadlo, ze by se mohlo hromadne rozesilani jednoho spamu na stovku adres ztizit jeste sifrovanim pro prijemce - spammer by tohle zrejme nezvladal - musel by mit nejdriv verejny klice prijemcu a to by mohlo byt obtiznejsi sehnat.

[bluemoon]

hmm, tak by bot pouzil i keyloger a zanedlouho by byl zase ucinny. stejne tak jako jsou znamky tak i tady je boj na nejakou dobu neucinny. tady se jedna o filtry, nejde mi o to jim zamezit uplne, ale shodit je na nejakych alespon 50procent.

[bluemoon]

tohle melo byt urcene prispevku vyse. jeste jednou podotykam, ze se o smtp portu nebavim. filtrovaci zarizeni nemusi byt jen na portu 25, ale i prevazne ve spamfitlru nebo i primo v mail klientu. server beru jako stanici schopnou tento mail prijmout na otevrenem portu pro mail a dorucit uzivateli, at uz je to podvrh.

[CEST]

No pozor. Pokud by byl cert na nejakym ext. tokenu, pripadne klic na USB disku a uzivatel by ho zastrkoval pouze pri odesilani, tak by to byl dalsi stupen bezpecnosti. Navic, pokud se nepletu, tokeny (a mozna i nejaky ty pgp nebo aplikace pro certifikaty) maji vlastni aplikace na zadavani hesel (napr. gnupg vyuzi pinentry, do kteryho by se asi heslo ze stdinu nacpat nedalo), takze sice by spammer mohl heslo lognout, ale bez tokenu (cert) by mu byl na houby. Ikdyby se mu povedlo nejak na pozadi spam podepsat a odeslat, prijemci spamu by hned mohli bombardovat konkretni osobu, aby si vycistila pocitac a pro zajisteni spoluprace by se dal do zakonu zapracovat nejakej (treba pro prvnich par incidentu pouze nizkej) trest, po opakovanych incidentech pak vyssi trest. Pripadne by se mohl osobne ten certifikat zrusit, pripadne by sama osoba mohla pozadat o renew, pokud by mela sama pozdezreni na zcizeni klice a/nebo hesla.

Jenze si myslim, ze podle toho tvyho navrhu by v tej dlouhej cekaci dobe skoncilo spousta legitimniho emailu a mail servery by musely hodne dlouho drzet ty emaily na disku a navic, stejne by se ty spamy poslaly - nejak jsi tam nedomyslel reseni, jak by klient mohl serveru rict "jasne, mel jsem tam nejaky spambota a posilal jsem spamy, takze vymaz vsechny zpravy, co jsem poslal". Lepsi reseni by uz bylo, kdyby server opravdu rovnou pri SMTP komunikaci odpovedel nejakou temporary error - too many Emails sent. Bylo by treba nastaveny, ze klient muze poslat 2 Emaily za minutu s moznosti poslat treba 10 najednou, ale kdyz bude chtit poslat vic najednou, tak se pristup zablokuje na 15 minut a teprve pak bude moct znovu posilat (je to ala iptables limit/limit-burst). Tak by treba klient odeslal 10 spamu, ale kdyz by pak chtel uzivatel neco poslat, tak by mu to hlasilo tuhle chybu a tak by zjistil, ze je neco spatne. Ale nevim, jestli by s tim neco udelal. Vetsina uzivatelu leze na webrozhrani, takze by jim to bylo uplne u zadku, ze to spambotovi dovoli poslat 10 mailu za 15 minut. Navic jeden mail muze byt treba 50 mail adres.

[bluemoon]

to je taky pravda: pouzit radeji spravce hesel at uz v systemu nebo nekde jinde na flashce. jenomze reknete to tem tupcum, ne kazdy je tak uvedomely. myslim si, ze je upozornit nekde na zacatku, klidne by to mohlo byt uz v samotnem klientovi, ze podle paketu a hlavicek odesilaji 100 zprav za minutu neni normalni a neni to zas takovy programatorsky problem upozornit uzivatele, aby si zkontroloval system. jsem zarazen ze takovou vec zadna bezpecnostni ochrana neuvedla. ja jsem puvodne myslel neco na spamassassinu, ale jak uz nekdo uvedl, dalo by se to i resit pres iptables.

[Vašek Lorenc]

Ale uvedla.. je to spíš neznalostí trhu, než neschopností dodavatelů. Některé NAC (Network Admission Control) systémy umí kontrolovat i podezřelé procesy, přičemž tohle chování je přesně jedno z nich..

A mít heslo na flash kartě nebo na disku je stejně k prdu, když není zřejmé, který program je vlastně schopen číst paměť počítače a tahat z toho cokoliv si zamane.. třeba i PIN k čipovce.

[bluemoon]

rad se tomu priucim. popiste vice jak tyto systemy jsou schopny informovat uzivatele mensi site za natem, ze odesila spam. jak mu v tom zabrani. myslim ze neni spatna myslenka v tom zpomalit sireni spamu na primarni urovni a zaroven mu dat vedet, ze ho odesila a at radeji pouzije nezavirovaneho web klienta a da si dohromady system co se tyce bezpecnost. do jake miry tyto systemy zamezi spamu by mne zajimalo a hlavne, proc kdyz jsou na trhu, tak i tak je spam 95procent? dekuji za vecny prispevek.
co se tyce spravce hesel, vzdycky jsem daval prednost klientum, kteri s tim nemeli problem pracovat, ale jak uz jsem uvedl vyse, nekteri to nebudou tak delat, pak je problem

[Vašek Lorenc]

 To o klientech jsem nepochopil, tak na to nemůžu asi správně reagovat.. Prostě jde o to, že napadený počítač obvykle je kompletně pod kontrolou viru/útočníka, takže je jedno, co se používá na správu hesel -- jakmile se jednou heslo objeví v paměti, je možné ho z ní získat.

Ad software -- Cisco něco takového dodává, tuším, že ne zdarma. Myslím, že i další hráči na trhu (Intel, Microsoft), ale neb jsou to programy vázané na Windows, tak je prakticky nepoužívám. Nicméně -- děje se to tak, že kdesi vespod mají zadefinovanou politiku, jak se chová "běžný" proces a v případě, že se netrefí do stanovených mantinelů (vytvořené procesy, počty navázaných spojení, atd.), upozorní nejspíš jednak uživatele systému (což je stejně naprd, umí-li virus odklepnout požadované hlášení za uživatele) a pošle to "výš", tedy firemnímu správci sítě. Tyhle technologie jsou obecně stavěné spíš tak, aby byly součástí několika dalších úrovní ochran -- IDS, IPS, firewallů..

A že je tolik SPAMu? Inu, ve světě, kde si lidi netahají ani základní aktualizace na Windows, protože je mají kradená.. ;)

[bluemoon]

no a myslite, ze by nebylo dobre mit neco i pod linuxem? obzvlaste, kdyz uz servery s nat a o mail serverech ani namluve bezi na linuxu? zkusim se dopatrat do pristiho clanku.

[Vašek Lorenc]

Jistě zajímavý dotaz, ale rozhodně ne na správném místě ;)

SELinux a podobné projekty by v podstatě mohly umět monitorovat nevhodné chování procesu. Je možné, že na to už nějaký projekt existuje.. už jsem to pár let nesledoval.

[bluemoon]

no zatimco jsem se koukal, tak novell takove reseni ma primo pomoci nac. ve win existuje dokonce reseni od meho kritizovaneho symantecu ani ne za 90korun, coz by se vyplatilo daleko vice nez maily zpoplatnovat. pritom toto reseni odstrihne uzivatele od pristupu k smtp uplne, zatimco ja jsem navrhoval jeho zpomaleni. aplikace reseni se tak stava spise subjektivnim hodnocenim ucinosti. jinak pokud by bylo neco snadno upravitelneho pro spravce site a zaroven klikajiciho uzivatele, bylo by to dobre zverejnit.

[bluemoon]

uprimne pokud tu bude placena volba a volba posilat dva maily za minutu, tak co si asi vyberete? vic jak 10mailu za minutu pri svem plnem vedomi to budou nejspis obchodni sdeleni a ty jak je znamo nemusi nic podvrhovat. kolikrat mi chodi letaky z obchodu, od kterych jsem si neco koupil, primo z jejich serveru. daval jsem je jako moznost pro administratora si toto nastavit jako whitelist bez moznosti zpozdeni. kdyz je nechci zobrazovat, dam si je do spamu a konec, o tom jsem uz mluvil.

[Kvakor]

Jak už se tu v několika předchozích reakcích správně uvedlo, většina zombifikovaných PC mailserver poskytovatele vůbec nepoužívá a komunikuje s cílovým mailserverem (s tím z MX záznamu) přímo. Z toho důvodu by bylo nutné analyzovat provoz odcházející na port 25, což by bylo hlavně u vělkýchy sítí dost složité a náročné (např. musely by se uschovávat informace o každém odesláném mailu po určitou dobu).

Někteří poskytovatelé, hlavně ti, co nepřidělují veřejné adresy, to řeší zablokováním portu 25 pro odchozí provoz a povolují odesílání pošty jen přes jejich mailserver. Je to sice porušení síťové neutrality, ale pokud poskytovatel umožní svým zákazníkům obejít toto omezení (např. můj poskytovatel zruší blokování, pokud si pořídíte veřejnou IP), je to podle mně mnohem menší zlo, než nechat zombifikované stroje posílat spamy.

U sítí za NATem dokonce nevidím rozumný důvod, proč by měl být por 25 průchozí, protože dle RFC 821 by měl mít SMTP server veřejnou a resolvovatelnou adresu, což u NATu neplatí, navíc jeden spamující stroj může "zablacklistovat" všechny ostatní, co s ním sdíli adresu.

[Stevko]

Blokuje to aj aspon jeden poskytovatel, ktory prideluje verejne IP adresy (kolej.mff.cuni.cz).

[eoj]

Miluji reseni od lidi, kteri nechapou problem.

[bluemoon]

a v cem je to nepochopeni? ja jako spravce mail serveru spis vidim nepochopeni ve smyslu zpoplatneni mailu. zaroven take nevim, jak moc bych se tim nepochopenim mel nadradit nad spravce yahoo mailu, kteri spravuji daleko vice schranek. mas dostatecny prostor argumentovat.

[Robert Krátký]

Odstavce, prosím.

[bluemoon]

podle ceho si predstavujes odstavec? ja podle tagu BR a ten tam rozhodne je.

[Heron]

V České typografii se odstavce sází odsazením prvního řádku, západní typografie (jak která) vkládá mezi odstavce mezeru. Obávám se, že ani jedno tvůj text neobsahuje.

Pro odstavce je v HTML už od prvního standardu vyhrazen párový tag <p>. Nepárový tag <br> značí nový řádek v odstavci.

[deda.jabko]

odstavec neni jen zalomeni radku!

[bluemoon]

ja nevim jak vy, ale spam se pres poskytovatele schranky a jeho vlastniho web klienta neda posilat, pokud je dobre zabezpecen. hraje v tom roli casova narocnost.jedine to jde pres deravy system samotneho uzivatele, kde bychom mohli aplikovat filtr uz primarne bud u nej v klientu nebo na serveru s natem nebo primo ve vasi schrance a dat to tomu uzivateli take vedet. uvazuji-li spravne, tak zombie station by jsme mohli odriznout, upozornit ji, ze je zombie bez vetsich problemu s tim, kde by filtr byl aplikovan, zamezit ji casovym posunem v odesilani a zaroven donutit uzivatele pouzit web klienta. Odhaduji snizeni alespon z 95procent na max. 50.

[Jendа]

jedine to jde pres deravy system samotneho uzivatele, kde bychom mohli aplikovat filtr uz primarne bud u nej v klientu

Jak v klientu, proboha? Většina spamovacích červů vůbec žádné klienty neřeší. Prostě si stáhne seznam adres, začne je načítat a vždycky se připojí na cílový mailserver na port 25, nasype tam čtyřicet tabletek Viagry a odpojí se.

na serveru s natem

Nejen s NATem. Třeba UPC, pokud vím, tlačí veškerou odchozí komunikaci s dport 25 transparentním Spamassasinem a když tam chodí moc mailů s vysokým skóre, tak to prostě zatrhne.

nebo primo ve vasi schrance

Jako ve schránce oběti? Co to?

Omlouvám se, pokud jsou mé reakce mimo, ale nějak vám nerozumím :-P (velká písmena na začátku vět, diakritika v komentářích, proboha, odstavce se dělají pomocí tagu p).

[sigma]

 aplikovat filtr ... primo ve vasi schrance

OK, tak mi naznačte, jak já ve své schránce z příchozích zpráv poznám, že za určitou IP adresou je zombie? Jde o to, že ve své schránce (nebo i na MX serveru) nemám možnost potenciální zombie identifikovat jinak, než IP adresou.

 dat to tomu uzivateli take vedet

Když znám jen tu IP adresu, jak to uživateli dám vědět? Můžu se podívat do RIPE, kdo IP blok alokovaný - tam najdu ISP, např. O2 a dokonce i s e-mailem abuse@iol.cz nebo tak nějak. Myslíte, že k něčemu bude když jim budu psát, ať uživatel informují? Myslíte, že je to možné při počtu jejich klientů, aby se tímhle zabývali? Velká část SMAPu chodí z Asie - je reálné jim nějak dávat vědět?

aplikovat filtr ... na serveru s natem

Jistě, ISP by mohli nasadit na svých routerech (nejen na NATu) nějaký NAC (Network Admission Control), ale proč by to dělali? Náklady by byly nemalé a navíc v síti každého ISP mohu klidně provozovat svůj mailserver, takže by ISP musel evidovat IP adresy, u kterých NAC nebude tak přísný.

Umím si tu představit jedno "jednodušší" řešení, které by hodně omezilo SPAM: kdyby každý ISP poskytující služby "obyčejným" uživatelům jako výchozí politiku blokoval odchozí spojení na port 25 (mnozí to tak už dělají, nejčastěji když je uživatel stejně za NATem), povolení by bylo prostě na požádání, pokud bych chtěl provozovat SMTP server. Aby ovšem fungoval e-mail klient (např. Thunderbird) "normálním uživatelům", museli by používat buď SMTP server ISP (ideálně s autentizací), nebo jiné SMTP servery (gmail, jiný mailhoster) na portu 587 (submission, viz. http://www.ietf.org/rfc/rfc2476.txt), kde je vynucená autentizace. Ale: musela by k tomu přistoupit většina ISP, má do mnoho problémů, nevidím to v blízké budoucnosti reálně.

 

 

[Jendа]

Ehm, reagujete na mě?

Umím si tu představit jedno "jednodušší" řešení, které by hodně omezilo SPAM: kdyby každý ISP poskytující služby "obyčejným" uživatelům jako výchozí politiku blokoval odchozí spojení na port 25 (mnozí to tak už dělají, nejčastěji když je uživatel stejně za NATem), povolení by bylo prostě na požádání, pokud bych chtěl provozovat SMTP server.

+1

Aby ovšem fungoval e-mail klient (např. Thunderbird) "normálním uživatelům", museli by používat buď SMTP server ISP (ideálně s autentizací), nebo jiné SMTP servery (gmail, jiný mailhoster) na portu 587 (submission, viz. http://www.ietf.org/rfc/rfc2476.txt), kde je vynucená autentizace.

"Normální uživatelé" už asi tak sedm let minimálně vůbec netuší o nějakých e-mailových klientech. Drtivá většina používá webmail.

[sigma]

 Omlouvám se, nějak jsem to popletl. Měla to být reakce na autora blogu.

"Normální uživatelé" už asi tak sedm let minimálně vůbec netuší o nějakých e-mailových klientech. Drtivá většina používá webmail.

To jsem si taky nedávno myslel, ale tak úplně pravda to není. Hlavně v malých firmách, kde mají třeba 1 nebo 2 počítače stále vede Outlook. A to ze dvou důvodů:

1) historicky mají e-mailovou adresu na @volny.cz @tiscali.cz a nechtějí ji měnit - nemají ze svého pohledu důvod měnit, nebo jim to ani nikdo neporadí. Tady jim webmail nenabídnou, a když už ano, tak s ubohým rozhraním a nebo se 100MB kapacitou. Další možnost je, že mají třeba už 8 let vlastní doménu, někdo jim kdysi nastavil ten Outlook (a při reinstalaci Windows jim ho někdo jiný nastavil vždy znovu stejně), a oni to prostě berou, že to takhle funguje.

2) chodí jim hodně e-mailů s velkými přílohami, a nechtějí je mazat a přílohy ukládat jinam. Má to něco do sebe, ale nepřesvědčíte je, že to lze dělat jinak. Jde klidně o 3-4 GB/rok. G-mail vám tohle nabídne, ale ten vešel ve známost až za poslední roky.

3) Navíc: na takových místech se často o počítače "nikdo" nestará, resp. nikdo neví, jak je všechno nastaveno. Oni jen ví, že už 6 let jim chozí pošta do Outlooku... a když se to rozbije tak to nějaký "obdorník" obvykle slepí zase dohromady.

Mnohokrát jsem byl svědkem toho, jak někdo brečel nad tím, že se rozsypal jeho 12GB velký .PST soubor outlooku, kde měl všechny e-maily...

Ale samozřejmě "domácí" uživatelé, kteří pošlou tak 1 e-mail za týden a příchozí maily hned mažou, tak ti už ani neznají nic jiného než webmail.

[Jendа]

No jo, asi mám nedostatečné zkušenosti s malými firmičkami. Díky za poučení.

Ale samozřejmě "domácí" uživatelé, kteří pošlou tak 1 e-mail za týden a příchozí maily hned mažou, tak ti už ani neznají nic jiného než webmail.

Tak taky ti obvykle mají zavirovaná Windows (ve firmách bývají obvykle spravována alespoň trochu odpovědnou osobou). Na narušování síťové neutrality jsem dost citlivý, ale mít ve smlouvě s ISP škrtátko "povolit odchozí port 25, pokud nevíte, co to znamená, nechte nezaškrtnuté" by mi vůbec nevadilo.

[Kvako]

Mnohokrát jsem byl svědkem toho, jak někdo brečel nad tím, že se rozsypal jeho 12GB velký .PST soubor outlooku, kde měl všechny e-maily...

A Outlook Express (a.k.a. "Malý Utlouk") navíc ani nezvládá .PTS nad 2GB - je sice ochoten je vytvořit, ale už je neotevře. Microsoft dokonce musel dát v dispozici udělátor, kterým to jde "opravit", i když na webu jdou podobných programů sehnat tucty, více viz To repair a 2GB Personal Folders or Offline Folders file.

Já osobně jsem to řešeil už dvakrát - poprvé jsem onomu neštastníkovy převedl poštu do normálního Outlooku (i když měl MSO, tak ho do té doby nikdy nepoužil), u druhého (který neměl MSO) jsem nainstaloval Thunderbird a poštu do něj naimportoval.

[Luk]

i když měl MSO, tak ho do té doby nikdy nepoužil

To dělá hodně lidí. "Velký" Outlook jim připadá příliš složitý.

u druhého (který neměl MSO) jsem nainstaloval Thunderbird a poštu do něj naimportoval

Tohle jsem také udělal řadě lidí, ale z jiného důvodu. Prostě se jim OE nějak "rozbil" a přestal fungovat. Většinou nešel ani spustit. Přechod na Thundebird bylo logické řešení.

[Ondrej 'SanTiago' Zajicek]

> Umím si tu představit jedno "jednodušší" řešení, které by hodně omezilo SPAM: kdyby každý ISP poskytující služby "obyčejným" uživatelům jako výchozí politiku blokoval odchozí spojení na port 25 (mnozí to tak už dělají, nejčastěji když je uživatel stejně za NATem),

Jenze to je nehorazny zasah do sitove neutrality. ISP proste nema co blokovat pakety na zaklade udaju urcenych pro prijemce (a tim cislo portu je).

[Eregon]

Taky mi to připadá jako nepřijatelná buzerace ze strany ISP. Na druhou stranu je to to jediné, co dokáže odesílání spamu z určité sítě zablokovat dost spolehlivě.

Trošku jsem nad tím přemýšlel a snažil se vymyslet kompromis, který by neomezoval koncového uživatele. Uvažoval jsem nad whitelistováním, ale to je v konečném důsledku nesmyslné.

Dovedlo mě to ale k myšlence SMTP proxy serveru, na který by se nějak transparentně nasměrovala veškerá komunikace s cílovým portem 25. Tenhle proxy server by měl za úkol zabránit SMTP komunikaci bez přihlášení k cílovému serveru (tzn. pokud klient nepošle auth, komunikace bude ukončena, všechno ostatní by zůstalo na tom, jak si klient rozumí s cílovým serverem).

Potřeby běžných koncových uživatelů by to mělo řešit v klidu - aspoň teda mám za to, že dnes už nikdo soudný neposkytuje svým uživatelům SMTP, ke kterému není třeba se přihlašovat a zároveň by bylo dostupné z Internetu.

Je to ale ještě invazivnější řešení, než blokování cílového portu 25. Pokud by někdo chtěl mít doma vlastní mailserver, byl by v háji, proto by taková "ochrana" přípojky musela být volitelná - s tím, že rozesílači spamu by byli nekompromisně odpojováni.

Nicméně možnost odpojování je bez toho proxy úplně stejná, jako s ním, a přísný přístup k nezodpovědným uživatelům je podle mě lepší, než se namáhat, aby se dalo říct, že se vlastně nic neděje.

Takže jsem vlastně nevymyslel nic

[Luk]

pokud klient nepošle auth, komunikace bude ukončena, všechno ostatní by zůstalo na tom, jak si klient rozumí s cílovým serverem

To ovšem vylučuje použití TLS, které je už dnes docela žádoucí. Čili buď by se to muselo po STARTTLS pustit (čili spammer s TLS by měl zelenou), nebo by se TLS obecně zakázalo, což je hovadina. Klientské certifikáty nepoužívá skoro nikdo (a při autentizaci je to stejně zbytečné), takže na ně můžeme při posuzování s klidem zapomenout.

dnes už nikdo soudný neposkytuje svým uživatelům SMTP, ke kterému není třeba se přihlašovat a zároveň by bylo dostupné z Internetu

To neposkytuje (kdysi to AFAIK dělal např. Seznam), protože by se velice rychle dostal do blacklistů jako open relay. Nehledě na to, že by ho příval spamu zatížil natolik, že by to sám brzy vyhodnotil jako neúnosné.

[Eregon]

Já nad tím přemýšlel zatím jen v hrubě principielní rovině bez zabíhání do technických detailů.

A už v téhle rovině se celý přístup ukázal jako nesmyslný. Resp. zbytečně složitý na to, že může fungovat jen jako obezlička pro líné a neschopné jedince.

Technických problémů by se pak asi našlo i víc - něco by se řešit dalo, něco ne. Ale proč to řešit, když samotný princip je k ničemu, žejo