Portál AbcLinuxu, 25. dubna 2024 02:27
Stavíme poštovní server – 11 (greylisting, MSA)
Články
-
Stavíme poštovní server – 11 (greylisting, MSA)
Greylisting patří mezi opatření kontroverzní, nicméně v praxi velmi účinná. Program Postfix lze snadno spřáhnout s nástrojem pro realizaci této ochranné metody. Následující odstavce ukáží, jak na to. Nebude ale chybět ani představení jedné další záležitosti, která s provozem poštovního serveru a ochranou proti spamu souvisí – rozdělení rolí přebírání pošty od klientů a jejího doručování.
Obsah
Greylisting – ano/ne?
link
Greylisting (též graylisting) je antispamová metoda založená na faktu, že při odesílání spamu se obvykle odesílá jedna zpráva za druhou, aniž by se řešilo selhání doručení. Je prostě jednodušší zkusit to doručit většímu počtu příjemců, než řešit, že některé servery to dočasně odmítnou přijmout a bude nutné opakovat pokus o doručení. Legitimní servery však odmítnutou zprávu zkusí doručit později znovu.
Výhody greylistingu
link
Greylisting znamená, že při příjmu zprávy server zkontroluje ve své databázi, zda zná trojici server-odesílatel-příjemce. Pokud trojici zná, zprávu přijme, jinak ji odmítne, typicky s kódem 450. Od neúspěšného pokusu začíná běžet lhůta (například 2 nebo 5 minut), během které je doručení zprávy se stejnou trojicí odmítáno. Po vypršení této lhůty server zprávu přijme, není-li odmítnuta z jiného důvodu.
Existence lhůty má hlavní smysl v tom, že pokud by se přece jen odesílající server pokusil spam znovu doručit, může se již mezitím objevit na černých listinách a vyhodnocení takové zprávy jako spam je mnohem pravděpodobnější. Greylisting bývá nastaven tak, že po úspěšném přijetí určitého počtu zpráv nebo uplynutí určité doby od prvního úspěšného doručení se trojice přidá do databáze permanentně (zůstane tam do případného ručního odebrání), jinak se po nastavené době tato trojice odstraní a systém se pro ni tedy vrátí do stavu, jako kdyby ji vůbec neznal.
Toto celé funguje v praxi jako velmi účinný filtr, přestože již řadu let můžeme číst o tom, že si s ním spammeři brzy snadno poradí. Zatím si neporadili, resp. se spíše ani nesnažili, protože greylisting stále patří k velmi málo používaným metodám. Velmi výhodné je, že je drtivá většina spamu odmítnuta hned na začátku, před analýzou zprávy, proto se ušetří nemálo systémových prostředků, které by byly potřeba na zpracování hlaviček a těla zprávy.
Nevýhody greylistingu
link
Jak už to v životě bývá, každá věc má své výhody i nevýhody. Greylisting má nevýhod hned několik. Především je vždy problém s tím, že první zpráva s příslušnou trojicí parametrů je zpožděna minimálně o dobu nastavené prodlevy, v praxi samozřejmě o něco více. Někdy také zpráva nemusí být doručena vůbec, protože je odesílající server špatně nastaven (což však odesílatele ani příjemce nezajímá, oni prostě chtějí komunikovat).
Další nevýhodou je, že v některých případech se neodesílá z jednoho serveru (resp. IP adresy), nýbrž z většího počtu, z tzv. poolu. Cílový server proto povolí příjem z jedné adresy, příští pokus ale může být z jiné. Pokud má pool mnoho adres a další pokusy následují s prodlužovanou periodou, může být zpráva doručena až po mnoha hodinách nebo i dnech, případně vůbec.
Problémy greylistingu jsou ale do značné míry řešitelné. Jednak lze greylisting vypnout pro příjemce, kteří si nepřejí ho používat a dávají přednost hladkému doručování, i za cenu většího množství spamu. Dále lze využívat (místo povolování jednotlivých IP adres) povolování příjmu celých bloků adres, je-li povolen příjem z jediné z nich – tím se odstraní většina problémů s pooly, aniž by přitom výrazněji utrpěla účinnost ochrany. Problematické servery lze dát na bílou listinu (whitelist), takže i pro ně jsou zprávy přijímány bez působení greylistingu. A konečně poslední věcí je vhodné nastavení prodlevy. Výchozí hodnota bývá 5 minut, lze ji zkrátit na 2 minuty, což v mnoha případech značně urychlí doručení prvně odmítnuté zprávy (byť to samozřejmě takto rychlé doručení nezaručuje).
Realizace greylistingu
link
Samotný program Postfix neobsahuje funkcionalitu greylistingu. Je proto třeba ji realizovat externě, pomocí vazby na Postfix přes roli „policy service“. Obecně totiž Postfix umožňuje dotazovat se vnější služby na to, jak má se zprávou naložit – a nemusí se jednat jen o greylisting, funkce je zcela obecná. Služba vyhodnotí, zda se má zpráva přijmout, či odmítnout (a když odmítnout, tak jakým způsobem), a oznámí to zpět Postfixu, který se podle toho zachová.
Služeb, kterými lze realizovat greylisting, existuje více. Následující řádky se budou vztahovat k programu Postgrey, nicméně není nutné použít právě tento, k dispozici jsou například programy SQLgrey, tumgreyspf, Greylist Daemon nebo Policyd. Případně si lze napsat vlastní implementaci (není to složité), nicméně vzhledem k aktuální nabídce pravděpodobně není důvod tak činit.
Instalace a konfigurace programu Postgrey
link
Postgrey je program (démon) napsaný v jazyce Perl. Je k dispozici prostřednictvím balíčku ze standardních repozitářů většiny běžných distribucí, případně ho lze získat z webu autora. Po instalaci je potřeba nastavit jeho spouštění, pokud to neproběhlo v rámci instalace balíčku. Standardní metodou je spouštění v rámci runlevelu.
Trochu nepříjemné je, že Postgrey nemá běžný konfigurační soubor. Parametry se dají zadávat jen prostřednictvím příkazové řádky. Některé distribuce, například Debian, to však řeší tím, že se dá vše potřebné nastavit v /etc/default/postgrey, konkrétně v proměnných prostředí POSTGREY_OPTS (základní parametry) a POSTGREY_TEXT (text použitý při odmítnutí zprávy – kvůli případným mezerám nelze nastavovat přes POSTGREY_OPTS).
Co všechno je potřeba nastavit? Především je to komunikační socket. Lze použít internetový nebo lokální (unixový). V prvním případě není třeba řešit práva a dostupnost, je ale nepatrně vyšší režie a k socketu má přístup jakýkoli lokální proces. Tady jsou příklady nastavení:
--unix=/var/run/postgrey/socket
--inet=127.0.0.1:60000
V případě unixového socketu je potřeba, aby měl Postfix právo k němu přistupovat. Protože se pro program Postgrey standardně vytváří uživatel a skupina postgrey, stačí potom, aby bylo pro skupinu postgrey zajištěno právo vstupu do adresáře /var/run/postgrey a aby uživatel postfix byl členem této skupiny. Samotný socket dovoluje přístup každému a nejde to přes parametry příkazové řádky změnit, čili omezení přes adresář je jediné možné. I tak ale nejde o bezpečnostně kritickou věc, proto není třeba se tím příliš trápit. Ostatně u internetového socketu (druhý řádek) má přístup obecně každý z místního stroje.
Lze ale nastavovat i další věci. Například můžeme chtít nastavit dobu prodlevy, změnit dobu odstraňování nevyužívaných záznamů („čištění whitelistu“, odstraňování dočasných položek) nebo délku okna pro první pokus o opakované doručení. Celé i se socketem by to vypadalo takto (v souboru /etc/default/postgrey):
POSTGREY_OPTS="--unix=/var/run/postgrey/socket --delay=120 --max-age=90 --retry-window=4"
Tímto nastavením zajistíme prodlevu 2 minuty, životnost dočasných položek (těch, které nejsou uloženy jako permanentní) 90 dnů a okno pro opakované pokusy 4 dny. Parametrů lze nastavovat mnohem více, všechny najdete v manuálu postgrey(8).
Ve výchozím nastavení Postgrey nepracuje s jednotlivými IP adresami klientů, nýbrž s částmi bez posledního bajtu (čili jde o síťovou masku /24 čili 255.255.255.0). Tím se do značné míry řeší problém s pooly, které bývají typicky rozlišeny jen koncovým bajtem adresy, i když to samozřejmě může přinést větší propustnost pro spam. Pomocí --lookup-by-host lze toto chování vypnout.
Dále existují ještě soubory s whitelisty. Standardně jsou to dvě dvojice. Vždy jeden soubor ve dvojici je distribuční (může se aktualizovat při aktualizaci balíčku) a druhý lokální, administrátorský. Jde o soubory whitelist_clients, resp. whitelist_clients.local (whitelist klientů) a whitelist_recipients, resp. whitelist_recipients.local (whitelist příjemců). V první dvojici jsou obsaženy jmenné nebo IP adresy klientů, ze kterých se mají zprávy přijímat bez použití greylistingu, ve druhé pak adresy příjemců, kteří si nepřejí greylisting nebo u nich není z technických důvodů vhodný.
Klienty lze uvádět jako jednotlivé IP adresy či doménová jména, částečné IP adresy, adresy s maskami (CIDR) nebo pomocí regulárních výrazů. U klientů lze uvádět úplné adresy, domény, uživatelská jména nebo opět regulární výrazy. Tady je malá ukázka souboru whitelist_recipients.local:
admin@
franta@moje.domena
jina.domena
Uvedený soubor vyřadí greylisting (a tedy zajistí okamžitý příjem zpráv) pro uživatele admin v každé obsluhované doméně, pro uživatele s adresou franta@moje.domena a pro celou doménu jina.domena.
Nastavení programu Postfix
link
Aby greylisting fungoval, musí se ještě nastavit program Postfix, aby se u běžícího démona Postgrey dotazoval na příslušné trojice klient-odesílatel-příjemce. To se zajistí přidáním pravidla do sady pro kontrolu příjemce v souboru main.cf:
smtpd_recipient_restrictions =
permit_mynetworks,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
check_recipient_access hash:/etc/postfix/access,
permit_sasl_authenticated,
reject_unauth_destination,
check_policy_service unix:/var/run/postgrey/socket,
permit
Jak vidíte, oproti předchozímu tvaru (z šestého dílu seriálu) přibyl pouze předposlední řádek, kde se jako policy service nastavuje unixový socket programu Postgrey. Toto pořadí zajišťuje, že se greylisting použije až jako poslední rozhodovací kritérium o přijetí zprávy. Nemá totiž smysl, aby se greylisting aktivoval i v případě pokusů o doručení do cizí domény (tedy před reject_unauth_destination) nebo dokonce i pro ověřené klienty (tedy před permit_sasl_authenticated).
Leckoho asi napadne, že pro vyřazení greylistingu pro určité klienty nebo příjemce, případně odesílatele, by šlo s výhodou využít i této konfigurace. Skutečně ano, a to často dokonce ještě výhodněji než při vložení do konfigurace programu Postgrey. Tady je takový námět:
smtpd_recipient_restrictions =
permit_mynetworks,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
check_recipient_access hash:/etc/postfix/access,
permit_sasl_authenticated,
reject_unauth_destination,
check_recipient_access mysql:/etc/postfix/mysql/no-greylisting.cf
check_policy_service unix:/var/run/postgrey/socket,
permit
Přibyl zde řádek těsně před greylistingem. Tento řádek obsahuje ověřování příjemce v databázi MySQL, a to pomocí dotazu nakonfigurovaného v souboru /etc/postfix/mysql/no-greylisting.cf. Podobně by šel použít třeba LDAP nebo nějaká jiná metoda. O vypnutí greylistingu tak může rozhodovat přímo příslušný uživatel (přes nějaké administrační rozhraní); není třeba, aby administrátor kvůli tomu zasahoval ručně do nějakého souboru. Greylisting pak může sloužit opravdu k plné spokojenosti, protože kdo ho nechce používat, může ho snadno vypnout – nebo může být naopak ve výchozím nastavení vypnutý a uživatel si ho při nadměrném přívalu spamu sám zapne.
Message Submission Agent
link
Pod tímto tajemným názvem (zkracovaným jako MSA) se skrývá věc, která formálně existuje už hodně dlouho, nicméně v praxi na ni člověk moc nenarazí. Jde o klasický problém „slepice-vejce“. Protože to nikdo nepoužívá, nikdo to nezavádí. A protože to nikdo nezavádí, nikdo to nepoužívá.
Snad i malé dítě už dnes ví, že SMTP služba běží standardně na portu 25. Na tento port se připojují serverové i klientské programy a jeho prostřednictvím probíhá veškerá e-mailová komunikace. Jenže to má některé nepříjemné důsledky, proto vznikl nápad, že se to rozdělí. Port 25 bude sloužit jen pro doručování pošty (tedy komunikace mezi servery, vystupování jako Mail Transfer Agent), kdežto pro odesílání z klientů se použije port jiný, konkrétně 587. Zabývá se tím RFC 2476, nově také draft RFC 4409.
Právě v čísle portu spočívá onen problém s „nepoužíváním“. V poštovních klientech je jako výchozí port nastaven téměř vždy 25 a změna na 587 mnohdy znamená, že se uživatel musí zanořit do hloubi nastavení poštovního účtu a číslo portu tam změnit. Na druhou stranu, pokud by tam bylo 587, u většiny poskytovatelů by to nyní nefungovalo a uživatel by byl opět nucen trápit se s nastavováním. Je otázkou, do jaké míry je vhodným řešením „automatická konfigurace“ použitá například v programu Mozilla Thunderbird 3.
Výhody separace MSA a MTA
link
Za „normálních“ okolností, tedy tak, jak je většina poštovních serverů nastavena, se tentýž server chová nejen jako Mail Transfer Agent, ale de facto také jako Mail Submission Agent, byť ne se všemi specifiky. To přináší různé problémy, související s ochranou proti spamu a s konfigurací serveru.
Pokud se však role oddělí, situace se zjednoduší. MTA běžící na portu 25 se bude starat jen o vlastní doručování – nebude tedy přijímat jinou poštu, než kterou přímo doručí do místních schránek. Odpadá tím potřeba řešit předávání dál (relaying), protože nic takového se prostě nekoná.
Naopak samostatný MSA nebude obsluhovat žádné schránky, bude se starat jen a pouze o příjem pošty od klientů a její předávání cílovým MTA. Proto bude také vždy vyžadovat autentizaci klientů, čímž se eliminuje nelegitimní přístup (jak od spammerů jako takových, tak i od primitivnějších spambotů na ovládnutých počítačích; chytřejší spamboty samozřejmě mohou v některých případech získat a používat autentizační údaje).
S tím souvisí možnost bezproblémového přístupu na MSA i ze sítí, kde je blokován port 25, jakkoli jde taková blokace proti podstatě Internetu. Dále může MSA řešit některé drobné problémy klientů (například absenci některých hlaviček). Principiální výhodou separace je pak samostatná konfigurace MSA a MTA, bez nutnosti dělat kompromisy a hledat styčné body mezi požadavky jednotlivých rolí. Každá ze služeb se konfiguruje zcela samostatně, změna v MTA většinou nemá žádné dopady na MSA a naopak.
Konfigurace programu Postfix – společný stroj
link
Postfix může být nakonfigurován tak, aby plnil kteroukoli z oddělených rolí (MSA a MTA). Může to fungovat tak, že bude Postfix figurovat v obou rolích, ať již na stejném, nebo na různých strojích. Jiným řešením je použít Postfix jen pro jednu z rolí a na druhou nasadit jiný software. Záleží čistě na volbě správce, jakou cestou se vydá.
Pokud obě role sdílí stejný stroj, nastává problém, jak nakonfigurovat dvě služby odlišně, přestože jsou poskytovány stejným modulem Postfixu. Řešení je dvojí. Buď se použije služba postmulti, která je přímo určena ke spouštění více instancí s různou konfigurací. Služba je ovšem obsažena až ve verzi 2.6, která není k dispozici v repozitářích řady distribucí. Navíc je konfigurace poměrně složitá, takže přesahuje rámec tohoto článku (využití postmulti bude náplní jednoho z pozdějších dílů seriálu).
Druhou možností je předání potřebných parametrů přes příkazovou řádku služby. Toto řešení je velmi jednoduché na konfiguraci a lze ho používat i se staršími verzemi Postfixu, byť není až tak úplně čisté a systematické.
Toto řešení spočívá v tom, že bude základní konfigurace v main.cf připravena pro MTA a v master.cf se přímo u služby submission použijí takové parametry příkazové řádky, aby byla konfigurace přizpůsobena funkci MSA. Soubor main.cf může mít například následující obsah:
myhostname = postak.moje.domena
myorigin = $mydomain
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
virtual_mailbox_base = /var/mail/virtual
virtual_mailbox_domains = ldap:/etc/postfix/ldap/vdomains.cf
virtual_mailbox_maps = ldap:/etc/postfix/ldap/vmailbox.cf
virtual_alias_maps = ldap:/etc/postfix/ldap/virtual.cf
virtual_minimum_uid = 100
virtual_uid_maps = static:100
virtual_gid_maps = static:100
smtpd_client_restrictions = permit
smtpd_sender_restrictions =
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
check_sender_access hash:/etc/postfix/access,
permit
smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
permit_sasl_authenticated,
reject_unauth_destination,
permit
smtpd_helo_required = yes
disable_vrfy_command = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = no
broken_sasl_auth_clients = yes
content_filter = smtp-amavis:[127.0.0.1]:10024
Všimněte si, že se definují parametry SASL, přestože je autentizace vypnutá (smtpd_sasl_auth_enable = no). To je proto, aby se co nejméně parametrů muselo definovat přes příkazovou řádku služby submission. Takto nakonfigurovaný MTA bude přijímat poštu pouze pro místní schránky, což je zajištěno pravidlem reject_unauth_destination v sadě smtpd_recipient_restrictions. Pravidlo permit_sasl_authenticated se neuplatní, protože je autentizace vyřazena z činnosti (nicméně se uplatní po jejím zapnutí – viz dále).
Teď je potřeba nakonfigurovat MSA. Příslušný řádek master.cf, který je potřeba přidat, bude vypadat takto:
submission inet n – – – – smtpd
-o smtpd_sasl_auth_enable=yes
-o virtual_mailbox_domains=
-o content_filter=
První řádek je úplně stejný jako u situace, kdy MSA a MTA běží na samostatných strojích. Aktivuje se jím služba submission pro MSA. Na dalších řádcích jsou již zmiňované parametry příkazové řádky. První říká, že se zapne autentizace SASL (u MTA je zcela logicky vypnutá, nepoužívá se). Další řádek vypíná domény pro virtuální doručování (tím je zajištěno, že se nebude nikam doručovat) a konečně poslední parametr vypne filtr obsahu (zde je zbytečný).
Toto vše je samozřejmě jen velmi jednoduché využití rozdělení rolí MTA a MSA. Lze pokročit ještě dále a například definovat rozdílné politiky šifrování TLS (pokud se používá), rozdílnou přísnost na syntaktickou validitu (u MTA se bude pouze hodnotit filtrem obsahu, kdežto u MSA lze dát striktní pravidla, která zajistí odmítnutí zprávy ještě před převzetím). Lze také pomocí MSA kontrolovat shodu obálkového odesílatele (příkaz MAIL FROM) s povolenými adresami autentizovaného uživatele a/nebo nastavovat identifikaci odesílatele (Sender-ID).
Konfigurace programu Postfix – dva stroje
link
Pokud běží každá ze služeb na vlastním stroji, ať už fyzickém či virtuálním, stačí na daném stroji brát v úvahu jen jeho vlastní roli a na tu druhou se neohlížet. Jako první přijde na řadu MTA, tedy server doručující do schránek.
Soubor master.cf lze ponechat v té podobě, v jaké byl v minulém dílu, čili žádná služba submission, která přibyla v případě společného stroje, zde není. Soubor main.cf lze naopak použít v podobě uvedené výše, byť parametry okolo autentizace (smtpd_sasl_type apod.) jsou zde zbytečné a lze je vynechat.
Dalším krokem je připravit konfigurační soubory pro MSA. V souboru master.cf se smaže/zakomentuje internetová služba smtp, místo ní bude služba submisssion:
#smtp inet n – – – – smtpd
submission inet n – – – – smtpd
Tím se aktivuje služba běžící na portu 587 (submission) namísto původní služby na portu 25 (smtp). Port 25 zůstane uzavřený, nic na něm nepoběží.
Dále se musí zajistit přístup k autentizaci, protože Dovecot běží jinde (tam, kde jsou umístěny schránky, tj. například na MTA). Možnosti jsou v zásadě dvě – buď se spustí samostatná instance programu Dovecot, která bude pracovat se stejnou databází jako instance poskytující přístup k poště (použitelné u databáze MySQL apod. nebo LDAP), anebo se umožní vzdálený přístup pro autentizaci na jediné instanci.
První možnost je jednodušší, spočívá pouze v tom, že se Dovecot nainstaluje na stroj určený pro MSA a nadefinuje se mu speciální konfigurace. Tato konfigurace nebude obsahovat komunikaci pomocí protokolů pro přístup k poště (čili Dovecot nebude naslouchat na příslušných portech ani nepoběží služby, které komunikaci zajišťují), Dovecot bude poskytovat pouze autentizační služby. Konfigurační soubor dovecot.conf bude vypadat například takto:
protocols = none
disable_plaintext_auth = no
auth default {
mechanisms = plain login cram-md5 digest-md5 ntlm
passdb ldap {
args = /etc/dovecot/ldap.conf
}
userdb ldap {
args = /etc/dovecot/ldap.conf
}
user = dovecot-auth
socket listen {
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
Příklad je samozřejmě určen pro řešení s uživateli v adresáři LDAP. Parametr protocols je nastaven na none (žádné protokoly) a ze sekcí zůstala pouze auth default, která konfiguruje autentizaci.
Kdo nechce instalovat Dovecot na MSA, může zvolit metodu druhou, tedy vzdálenou autentizaci. Problém je však v tom, že Dovecot poskytuje autentizační služby pouze přes lokální (unixový) socket, nikoli přes internetový. Jedinou možností je tedy využít programy typu socat, které dokáží tento nedostatek obejít vytvořením internetového spoje mj. mezi lokálními sockety. Netřeba snad dodávat, že komunikace by měla být vždy nastavena jako šifrovaná a náležitě ověřovaná (server i klient), aby nebylo možné se neoprávněně dostat k uživatelským heslům.
SSL/TLS a problematika šifrování
link
Zejména v posledních letech se šifrování komunikace stává vysloveně nutností, protože zvědavé uši mohou číhat kdekoliv. A když už se nešifrují jednotlivé zprávy, je žádoucí šifrovat alespoň komunikace mezi klientem a serverem i mezi jednotlivými servery. Celý příští díl seriálu proto bude zaměřen na záležitosti související se šifrováním poštovní komunikace, a to jak SMTP, tak POP3 a IMAP.
Související články
Další články z této rubriky
Diskuse k tomuto článku
15.1.2010 08:36
bigBRAMBOR | skóre: 37
Re: Stavíme poštovní server – 11 (greylisting, MSA)
15.1.2010 08:52
trekker.dk | skóre: 72
Re: Stavíme poštovní server – 11 (greylisting, MSA)
15.1.2010 09:31
Prokop Mikule | skóre: 9
Re: Stavíme poštovní server – 11 (greylisting, MSA)
15.1.2010 12:53
honza
Re: Stavíme poštovní server – 11 (greylisting, MSA)
20.1.2010 15:11
st. Grumpa | skóre: 12
Jde to i bez greylistingu
6.9.2013 11:53
Denny
Re: Stavíme poštovní server – 11 (greylisting, MSA)
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
15.1.2010 14:19
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
15.1.2010 09:31