blog.orwen.org osobní názory, postřehy a nápady tak jak sem propadnou klávesnicí

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:

1. po několika dnech chrlení byla IP adresa stále na blacklistu
2. útočnk měl stále práva Apache
3. nefungovala funkce mail() na která, jak se ukázalo byla pro organizaci nezbytná
4. 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.

Jak nemá vypadat datový rozvaděč a co s tím

Když jsme se s Duhou stěhovali do nového sídla, jednou z věcí na kterou jsem se opravdu těšil byl datový rozvaděč. Místo kam vedou všechny síťové kabely od počítačů.
Ve starém sídle nic takového nebylo -- kabely prorůstaly budovou jako plíseň a když jsme si odpojili našich 7 switchů, přišly si stěžovat hned dvě firmy, které na nás byly napíchnuté. Chaos.
A jak vypadal onen datový rozvaděč?

Vpravo nahoře jsou vyvedené do patch panelů síťové zásuvky stanic, vlevo nahoře vykukují rackové aktivní prvky a ta hromada dole je jsou modemy, routery a switche D-link a Zyxel.

Omlouvám se za hroznou kvalitu fotek, považujte to za nástroj security by obscurity konceptu. Protože do hromady vlevo momentálně přispíváme hned čtyřmi zařízeními, rozhodli jsme se dva plně obsazené šesnáctiportové switche nahradit jedním rackovým. Zároveň jsme v tu dobu koupili nové APčko a router, tak z toho vznikla pěkná nadílka.

• router Linksys s podporou 802.1q, VPN s spousty dalšího
• switch Linksys SLM248G
• Wifi router Linksys WRT320N

Příští týden mám zkoušku z předmětu Počítačové sítě II, tak si pořádně pohraju s návrhem sítě. Třeba VLANami se  dají dělat pěkné kusy . Rozhodně plánuji rozjet load balancing, VLANy (alespoň pro VoIP a servery) a nějaký monitoring. Duhu teď čeká růžová a spolehlivá budoucnost.

Za pár dní se tu objeví fotka datového rovaděče v novém, tak doufám, že to bude poznat .

Aktualizace: Tak už je hotovo : Malá zařízemí (tj. modem a router) byla přesunuta na poličku. Dva switche nahradila jejich racková varianta a kabeláž byla sepnuta.