Zelené programování
V polovině února šel do distribuce první letošní číslo společensko ekologického (!) časopisu Sedmá Generace ve kterém spatřil světlo světa i můj článek odhalující zajímavé souvislosti s IT.
Read more
Plním si dětský sen…
- ALIX.2D2 (LX800 / 256 MB / 2 LAN / 2 miniPCI / USB)
- UBNT UB5 miniPCI, Atheros AR5414, 802.11a, 5 GHz
- MaxLink 22 dBi 5 GHz 30 cm
Hrátky s OpenTTD
Dnes jsem konečně dodělal (s výraznými uvozovkami) „umělou inteligenci„ pro klon Transport Tycoon – OpenTTD (ekonomicko logistickou hru). Úkolem programu je v mapě najít elektrárnu, doly na uhlí a nějak zajistit efektivní dopravu materiálu. V podstatě jediné co stojí za řeč je, že se automaticky nadimenzují délky nádraží a počty vagónů podle počáteční produkce uhelných dolů.
Přehled výpadků UIS na Mendelu
Níže vidíte chronologický přehled oficiálně zveřejněných výpadků UIS od doby co odešel původní vývojový tým do té doby, než se zase vrátil.
Viz dřívější článek Jak se připravit na výpadky UIS, který se věnuje nejen příčinám výpadků, ale také radí, jak zmírnit jejich dopady. Seznam jsem průběžně aktualizoval do podzimu 2010.
Read more
Jak se připravit na výpadky UIS
Univerzitní informační systém nasazený na pěti českých a slovenských univerzitách (pod názvy: UIS, AIS a ISIS) má před sebou těžké období a podle mého názoru se nevyhne zásadním výpadkům. V nejhorším případě úplnému zániku.
Aktuálně: viz seznam výpadků UIS.
Dotazníkový průzkum zaměřený na absolventy MENDELU
Nedávno mně došel do schránky mail s předmětem „dotazníkový průzkum zaměřený na absolventy MENDELU„:
from Pavla Štěpánková
to Pavla Štěpánková
date 23 September 2010 16:55
subject dotazníkový průzkum zaměřený na absolventy MENDELU
Vážená kolegyně, vážený kolego,
Obracíme se na Vás s průzkumem zaměřeným na absolventy Mendelovy univerzity v Brně, který je umístěný na http://pruzkum-absolventu-mendelu.cz/ . Rádi bychom získali Vaše názory…
Nahrávky bloudění v horách
Aneb (naše) nejčastější orientační chyby na hřebenech malých hor.
Čím a proč jsem nahrával
Účastníci výpravy (fotil Wheb)
Když jsem se minulý týden vracel s kamarády z Rumunských hor (hory se jmenovaly Lotru, viz fotky), v seznamu „co udělám až přijedu domů“ přibyla jedna položka. Nazvěme ji třeba „koukání na záznam trasy“ (tracklog).
Zaznamenávat naši cestu mně umožnil GPS logger Holux m-241, který jsem si pro tyto příležitosti koupil. Umí přesně to, co po něm chci:
- krmí se tužkovými bateriemi
- umí zobrazit aktuální souřadnice
- ukládá trasu
A především uživatele neochuzujuje o možnost se ztratit (neumí zobrazit mapové podklady ani navigovat na bod nebo vizualizovat trasu). Vzhledem k tomu, že naše mapy neměly po stranách GPS souřadnice, samotná GPSka tak byla téměř „k ničemu“ tj. – nepřišli jsme o možnost zabloudit.
Vzhledem k tomu, že v naší skupině nebyla práce s mapou a buzolou cizí téměř nikomu, nestalo se, že bychom někde opravdu zakufrovali. Ale pár kliček tu bylo a my se teď na ně můžeme v teple domova podívat.
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.
-
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
