Jak jsem bojoval proti spammerům
V článku se ohlížím zpět na počátky ve svém aktuálním zaměstnání. Stručně v něm rekapituluji první cíl, který jsem si dal: dát do pořádku e-maily.
Jako slepý k houslím jsem se loni na podzim dostal do první linie boje proti rozesílačům spamu. Teprve jsem se rozkoukával v nové kanceláři, když si začali zaměstnanci postupně stěžovat, že jim „nechodí maily„. Ukázalo se, že adresátům často končí ve spamovém koši a když už něco dojde, tak se zpožděním. To byl špatný varovný signál, který nastartovál první fázi mé mise v novém zaměstnání.
V dřevěné skříni zatím tiše šuměly servery chrlily do internetu spam. To jsem však jen několik dní tušil a čekal až mi bývalý spráce sítě sdělí root přístupy. Pročpak asi odešel a nic po sobě nenechal?
Z první diagnostiky vyplynulo, že webovému serveru útočník podstrčil jednou z mnoha děr svůj kód, získal práva uživatele Apache a vychvaloval Viagru. Zakázání funkce mail() bylo dílem okamžiku, problémy však dále trvaly a bylo jich ještě víc:
- po několika dnech chrlení byla IP adresa stále na blacklistu
- útočnk měl stále práva Apache
- nefungovala funkce mail() na která, jak se ukázalo byla pro organizaci nezbytná
- e-maily chodily s několikahodinovým zpožděním
Poslední odrážka mě navedla na důkladnou kontrolu mailového serveru, výborný nástroj qshape ukazoval hrozivou frontu, vypadající asi takto:
T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 17237 8 14 16 44 182 4495 11614 863 0 1
aol.com 16908 0 0 0 0 103 4392 11550 863 0 0
hnutiduha.cz 260 8 14 15 33 70 56 63 0 0 1
psp.cz 21 0 0 0 3 0 18 0 0 0 0
Dočasné řešení v podobě krásného košatého příkazu
mailq | tail -n +2 | awk 'BEGIN { RS = "" } / *@aol\.com$/ { print $1 }' | tr -d '*!' | postsuper -d -
poslalo příchozí spamy do /dev/null; koncepční řešení však rozhodně není toto napsat do Cronu. Zde se mi otevřelo velké pole ladění a optimalizace front Postfixu, nějaké úpravy Iptables by jistě taky pomohly. Až teď, s odstupem času, mě napadá, že takové množství mailů se do fronty mohlo dostat z napadeného webserveru šumícího hned vedle; přesunul jsem tedy svou pozornost na něj.
Logický postup velel najít bezpečnostní díru v některé z webových aplikací. Ukázalo se však, že s procházením tisíců PHP a Perlových skriptů, na který si několik let každý programátor-dobrovolník nahrával co chtěl, mi nepomůže ani syslog. Jednalo se o krásnou ukázku nefunkční (=neexistujícící) bezpečnostní politiky. Po důkladném prozkoumání většiny konfiguráků jsem e-mailový server i s IP adresou prohlásil za potápějící se loď a zvolil strategii útěk. Nutno říct, že s těžkým srdcem, které k nově objevenému kousku kyberprostoru ještě ani nestihlo přilnout.
Bod č.1 a 4. jsem koncepčně přes víkend vyřešil poměrně bezbolestnou migrací našeho mailserveru na mailserver Google Apps, to je samostatná kapitola.
PHP funkci mail() do té doby realizovanou vlastním SMTP serverem jsem opět aktivoval, ale nově ji obsluhovala služba ssmtp, která e-maily posílá přes účet na jiném serveru – v našem případě šlo o server Google Apps, tím byl dočasně vyřešen i bod 3. Ukázalo se, že hnát spam z napadaného serveru přes Googlí službu ale není dobrý nápad. Google víc než 1000 mailů denně nepustí; nehledě na to, že organizace v rámci svých pravidelných rozesílek potřebuje občas poslat třeba i 10 000 mailů denně a navíc jim k tomu falšovat adresu odesilatele. Další věc co puritán Google nemá rád.
Zde je na místě otázka, k čemu někdo potřebuje falšovat hlavičky mailů, nebo rozesílat denně 10 000 mailů? To první slouží ke tzv „zprostředkování odeslání e-mailu“: zákazník si prostě přeje, aby e-mail odeslala organizace, ale pod jeho adresou, viz příklad. A hromadné rozesílky se dají jednoduše vysvětlit rozesíláním e-mailového zpravodaje tisícům registrovaných zájemců.
Rozhodl jsem se pro potřeby takových to rozesílek nahradit PHP funkci mail() vlastní implementací, která bude vlastní odesílání zajišťovat tak, že odesílaný e-mail uloží do databáze. Minutový cron na touto databází spouští prioritní frontu a vlastní odeslání realizuje. Budovaný systém má spoustu výhod:
- snadná kontrola aplikací – vím která co odesílá, můžu ji zablokovat
- přiřazení priority odeslání, například při rozesílce rozesílky zpravodaje trvající desítky hodin prioritní forntu „předběhnou“ e-maily tlačící na poslance
- statistiky odeslaných e-mailů
Vymyšleno, implementováno. Funkční. Systémem už k dnešku proteklo 30 000 mailů k plné spokojenosti všech zúčastněných. Tím byl vyřešen i problém 3.
A samotný útočník s právy Apache? Toho nejprve vyhnaly zvýšené restrikce v php.ini. Koncepční řešení proběhlo teprve nedávno kompletní outsourcovanou reinstalací celého webserveru a rozdělením jednotlivých aplikací do „bezpečnostních zón“ pomocí FCGI. Preventivně jsme zavedli FTPS, revidovali veškeré účty programátorů a zavedli pořádnou bezpečnostní politiku.
Comments
3 Responses to “Jak jsem bojoval proti spammerům”
Leave a Reply
-
Detekce Cenzury
Podpora
Aktuálně
- Pres noc za oknem trochu nasnezilo :-) http://t.co/hypSXDr3
- @jochocz proc?
- @adent tohle zrovna docela cool je ;-) (ale jo, meli by si to ujasnit)
Poslední alba
Cau, jen pro info:-):
1) „čekal až mi bývalý spráce sítě sdělí root přístupy“
- Priste nemusis cekat, az ti byvaly admin preda heslo roota. Od toho mame single user mode, ne? Reboot za to vetsinou stoji.
2) „optimalizace front Posixu“
- POSIX je balik ruznych standardu pro Unix API. Ty jsi asi myslel postovni server Postfix:-)
3) „falšovat adresu příjemce“
- To znamena co? Rekl bych, ze pokud zmenis (zfalsujes) adresu prijemce, tak ten pak nic nedostane:-) Nemyslel jsi falsovani adresy odesilatele?
4) „outsourcovanou reinstalací“
- To jste jako najmuli externi firmu, aby vam nainstalovala novou verzi systemu + Apache?
Ahoj,
.
díky za připomínky
1) máš pravdu… ale já jsem byl v té době zavalen jinými úkoly a neměl jsem v podstatě důvod vrtat se v (do té doby funkčních) serverech, navíc to byla dobrá záminka se s bývalým správcem sítě potkat osobně
2,3) ono to tu není nikde vidět, ale psal jsem ten post ve dvě ráno
4) v okamžiku kdy jsou peníze, ale není čas se snažím outsourcovat vše co jen trochu outsourcovat jde… ale tohle fakt nebylo jen o instalci Apache; musely se tam postupně postupně rozjet desítky archaických nedokumentovaných aplikací (třeba jen párování databáze x aplikace, abysme je od sebe mohli izolovat, mně zabralo dva dny)… a externí firma byl Michal
Doufám, že se ukážeš na našem táboře
.
Ahoj, ty dvě ráno leccos vysvětlují:-) A nechat to udělat Michala je taky rozumné, já jsem se fakt bál outsourcingu na profesionální úrovni (což by asi byla neuvěřitelně drahá cesta do pekel:-)
Hm, dost nezávidím práci s rozmotáváním toho bordelu. Co udělat aspoň pro hlavní weby virtuální servery? Aby byly nějak izolované…
Na táboře se bohužel neukážu, a neuvěřitelně mě to mrzí:-( Ještě pořád jsem zavřený v Norsku… Každopádně díky za pozvání, snad to v září nějak doženeme:-)