Ústavní soud zrušil data retention v ČR

Jak se zdá, neuvěřitelné se stalo realitou. Ústavní soud dnes zrušil povinnost poskytovatelů komunikačních služeb uchovávat až šest měsíců údaje o tom, kdo s kým a jak moc komunikoval. Toto se týká téměř každého uživatele Internetu nebo každého uživatele mobilního telefonu. Příslušné paragrafy zákona o elektronických komunikacích byly do našeho právního řádu včleněny na popud EU (implementace směrnice o data retetnion) a nyní byly shledány protiústavní a zrušeny. Více informací viz web Ústavního soudu. Můj komentář k této věci je krátký, ale výstižný: „Ústavní soude, výborně! Jen tak dál!“.

IPv6 privacy extensions

Skutečnost, že IPv4 adresy akutně docházejí, ponechám stranou. Linux podporuje IPv6 již dlouho, a podporuje i jedno z jeho rozšíření, rozšíření soukromí (privacy extensions). Bohužel většina distribucí jej ve výchozím stavu nezapíná, což má jisté následky na vaše soukromí vůči všem serverům, se kterými váš linuxový systém komunikuje přes IPv6.

Je to dáno tím, že v rámci autokonfigurace IPv6 se k prefixu sítě přidává i MAC adresa vaší síťové karty, a ta se tak stává součástí IPv6 adresy, pod kterou vystupujete. Sledováním této části IPv6 adres může jakýkoliv server, se kterým pravidelně komunikujete, sledovat, odkud odevšad k němu přistupujete. Systémy Windows mají privacy extensions ve výchozím stavu zapnuté, u linuxových distribucí je tomu zatím převážně naopak.

Pro konkrétní síťové rozhraní je možné privacy extensions povolit buď dočasně nebo permanentně. Dočasně to lze provést následujícím příkazem:

sysctl -w net.ip6.conf.interface.use_tempaddr=2

Místo slova interface zapište rozhraní, u kterého chcete privacy extensions nastavit (např. eth0. Chcete-li toto nastavení uložit permanentně, tzn. aby přežilo restart, zapište výše zmíněnou řádku do /etc/sysctl.conf, samozřejmě bez úvodního sysctl -w.

Je samozřejmě možné toto nastavit globálně pro všechna rozhraní. V takovém případě se nejprve ujistěte, že načtete ipv6 modul ještě před tímto nastavením (většinou je třeba tento modul explicitně zařadit pro zavedení při startu, ještě před aplikací nastavení ze sysctl.conf). Poté zapište do /etc/sysctl.conf následující dvě řádky:

net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.default.use_tempaddr=2

V mém případě toto nastavení bohužel nefungovalo, i když by mělo. Nezbylo mi tedy než do /etc/sysctl.conf přidat specifikaci pro všechna síťová rozhraní, takto:

net.ipv6.conf.eth0.use_tempaddr=2
net.ipv6.conf.wlan0.use_tempaddr=2

Kritická zranitelnost v jádře Linuxu

A máme tu další díru v jádře velkou jako vrata, umožňuje získat rootovská práva neprivilegovaným uživatelům. Naštěstí tato zranitelnost postihuje jen systémy s určitým nastavením a příslušnou hrozbu lze zvrátit změnou parametru mmap_min_addr na nenulovou hodnotu.

Správcům serverů doporučuji provést rychlou kontrolu:

sysctl vm.mmap_min_addr

Pokud tento příkaz vrátí nenulovou hodnotu, pak na vás příslušné exploity nezafungují. Pokud vrátí nulu, zvyšte hodnotu ručně:

sysctl -w vm.mmap_min_addr="4096"

A následně zapište příslušné nastavení do konfiguráků, aby restart tuto hodnotu nevrátil zpět na nulu. Dlužno dodat, že některé programy mohou mít s tímto nastavením problémy (standardní serverový software však nejspíše žádný problém mít nebude – s výjimkou starší verze Qemu, který nepůjde spustit jinak než jako root). U desktopů může být problém s aplikacemi typu Dosbox (opět bez roota nepůjde spustit).

P.S. Z data publikace příspěvku nic neusuzujte – je chybné.

Zdroje:

Bezpečnost: O můj počítač nikdo nestojí. Ale ne. Stojí.

V souladu s mým předchozím zápiskem
o bezpečnosti jsem se rozhodl vyvrátit jeden z nejrozšířenějších mýtů, které o
bezpečnosti osobních počítačů panují, a sice, že pokud v nich nejsou citlivá
data, nemají o ně útočníci zájem. Aneb „Já tam nic důležitýho nemám, tak nikdo
nemá důvod se mi do počítače nabourat“. To je, bohužel, zcela mylná představa.

Celý příspěvek

Bezpečnost dat: jsme pštrosi

To, že počítače stále více pronikají do našich životů a ukládají stále více dat, která se nás týkají, snad nemusím připomínat. Píšeme e-maily, „okamžité zprávy“, tvoříme dokumenty, pořizujeme různá multimediální data (fotografie a videa), někteří z nás uchovávají i jiná citlivá data (třeba zdrojové kódy nějakého komerčního proprietárního softwaru).

Celý příspěvek

Celní prohlídky elektronických zařzízení

Zdá se, že některé země nyní aplikují právní normy, které umožňují celníkům bez jakéhokoliv důvodu prohledávat data (a pořizovat jejich kopie) na elektronických zařízeních a nosičích. To zahrnuje typicky laptopy, paměťová média, ale i mobilní telefony, PDA a další zařízení. Běžnou praxí jsou tyto prohlídky kromě zemí jako Čína i v Anglii či ve Spojených státech, v Kanadě, Austrálii a patrně i jinde.

V rámci odůvodnění se argumentuje většinou bojem proti terorismu či bojem proti pedofilům, čili obvyklými argumenty používanými k ospravedlňování různých svobodu omezujících či soukromí narušujících opatření, které jsou během poslední doby zaváděna. Z právního hlediska se argumentuje paralelou s hmotným světem – celník má přece právo prohledávat zavazadla, tak proč ne i data na elektronických zařízeních?

Inu, problémem je, že na rozdíl od hmotného světa neplatí pro informace žádná bariéra při přechodu hranic. Skutečně není problém utajovaná data zašifrovat, umístit na nějaký server, důkladně a bezpečně data ze zařízení vymazat, přejít hranice, připojit se na Internet, data zkopírovat zpět na zařízení a dešifrovat. Ve chvíli, kdy se tyto kontroly stávají de facto praxí a obecně se o nich ví, postrádají celkem logicky kýženého účinku – ti, proti kterým je toto opatření oficiálně namířeno, jej budou obcházet. Čili, smysl takového opatření je v tomto směru prakticky nulový.

Stejně jako v případě mnoha omezení svobod a soukromí obyvatel či cestujících, která se poslední dobou zavádí, neexistují žádná oficiální pravidla a procedury, které by tento zásah zaštiťovaly. Tedy konkrétně v těchto případech nebývá jasně definováno, jak má celník při prohlídce postupovat, co smí, co naopak nesmí, co má dělat v případě, že narazí na zašifrovaná data, za jakých okolností a jakým způsobem má právo pořizovat kopie, kdo a jak smí k těmto kopiím přistupovat, jak je to z hlediska bezpečnosti zajištěno, kde se budou skladovat, a samozřejmě, kdo bude odpovědný za případný únik dat.

Účinek je vzhledem k inteligenci obyvatel hluchý – terorista ani pedofil nebudou kompromitující materiály nechávat na laptopech, se kterými přecházejí hranice, když vědí, že mohou být podrobeni kontrole. Naopak samotné prohlídky otevírají řadu problémů pro ty z nás, co žádnou trestnou činnost neprovádějí.

Obchodní zástupce může mít na svém laptopu důležitá firemní data, ke kterým se nesmí dostat konkurence. Přirozeně má dotyčný data šifrována, ale při prohlídce může být nucen vydat dešifrovací klíče (někde dokonce pod hrozbou trestu odnětí svobody). Pro celníka, kterého nikdo nekontroluje a který nemusí dodržovat žádné postupy či předpisy a de facto nemá ani odpovědnost za data, která prověřuje či kopíruje, mohou být taková data snadno a dobře zpeněžitelná. Samozřejmě ke smůle dané firmy.

Stejně tak třeba vývojář může mít na svém laptopu zdrojové kódy vyvíjeného softwaru, obyčejný uživatel může mít na svém laptopu uloženy aktivační kódy ke komerčnímu softwaru, přístupová hesla k placeným službám, bankovní aplikace či certifikáty a jiná podobná data. Administrátor může mít na svém laptopu SSH klíče pro vzdálený přístup k unixovým serverům, popřípadě jiná podobně zneužitelná data. V neposlední řadě si dokážu představit i čistě osobní záležitosti jako lechtivé fotografie (či dokonce videa) patrnera/partnerky, milostnou či klasickou osobní korespondenci.

První věcí je, že k takovým prohlídkám by vůbec nemělo docházet – jsou vážným (a bezdůvodným) narušením našeho soukromí. Druhou věcí je, že když už se dané prohlídky provádějí, činí z nich absence jasných pravidel, kompetencí, zodpovědností a kontroly kontrolorů chaos, ve kterém může celník prakticky vše, a vy nemáte možnost mu v tom zabránit. Chce si zkopírovat vámi vyvíjený software? Nebo fotografie vaší partnerky či partnera? Kdo mu v tom zabrání? Nebo kdo zajistí, že bude náležitě potrestán, když svou pravomoc zneužije? A jak? Víme velmi dobře, že zkopírování elektronické informace není zjistitelné ani prokazatelné (tedy dokud se nerozšíří kvantové počítače) – škody z úniku dat jsou ovšem reálné. Fotografie se objeví někde na Internetu na webech s „amatérskými fotografiemi“, obchodní informace u konkurence, vyvíjený software vydá někdo jiný a vás obviní z plagiátorství… a nikdo nebude hnán k zodpovědnosti.

Dalším problém je, že kontroloři nemívají dostatek znalostí a schopností, a tak si dokážu živě představit s tím spojené problémy (laptop vám bude zadržen, protože používáte Linux/BSD, se kterým celník neumí, apod.), včetně velmi snadného zavlečení virů či jiného malwaru (ne každý používá Linux či BSD…) na prověřovaný laptop z infikované flashky. Nehledě na možnost úmyslného zavlečení nějakého malwaru na dané zařízení.

Co říci závěrem? Z mého pohledu se jedná o naprosto zbytečné opatření, které zdržuje, vážně narušuje soukromí a působí problémy zejména spořádaným občanům, zatímco teroristy, pedofily, vrahy (či kým se ještě pro jeho zavedení argumentovalo) nezastaví, nezpomalí, ani jim moc nezkomplikuje život. Z hlediska implementace postrádají prohlídky jasná pravidla a opatření, která by popisovala a zajišťovala jejich průběh, korektnost a bezpečnost.

Zdá se, že se poslední dobou roztrhl pytel s podobnými polotovary, které ve jménu boje proti terorismu a dětské pornografii jen omezují naše svobody a soukromí, zatímco pachatele těchto zvěrstev ponechávají v klidu. Inu, cesta do pekla je dlážděna dobrými úmysly.

Triviální chyba

Když nakonfigurujete nějaký server (resp. konkrétní službu, která na serveru běží), a ona nefunguje, pak je jasné, kde hledat chybu. Zkontrolovat firewall, podívat se do logů, spustit příslušnou službu v ladícím režimu a zjistit, kde je problém, atd.

Horší je, když se dostanete do situace, kdy daná služba někdy funguje a někdy ne. Přitom v logu neobjevíte nic, co by naznačovalo jakýkoliv problém v rámci dané služby. Firewall jako zdroj problému vyloučíte, protože předpokládáte, že při problému s firewallem by služba dostupná nebyla v žádném případě.

Nebudu vás napínat. Podívejte se na rozdíl mezi těmito dvěma pravidly (rozdíl je zvýrazněn):

1. iptables -I INPUT -p tcp --sport 40000:50000 -j ACCEPT
2. iptables -I INPUT -p tcp --dport 40000:50000 -j ACCEPT

Jediné písmenko, které zásadně mění význam. Druhý zápis je správný, první způsobuje onen nepříjemný „někdy to funguje a někdy ne“ problém. Proč? Toto pravidlo má fungovat tak, že povolí příchozí spojení od klienta na příslušné cílové porty na serveru. To zajistí onen druhý, správný zápis. V prvním, chybném zápise se povolí jakékoliv příchozí spojení, pokud přichází z daného rozsahu portů klienta. Tím se také otevírá poměrně nepříjemná trhlina ve firewallu – jakýkoliv požadavek o spojení s jakoukoliv službou na serveru bude přijat, pokud přichází z definovaného rozsahu portů klienta (zdrojový port klienta se obvykle vybírá náhodně, proto to někdy bude fungovat a někdy ne).

I mistr tesař se utne. I administrátor, který problematiku firewallů dokonale ovládá, se může splést. Únava, chvilkové pominutí smyslů, nepřemýšlení, odvedení pozornosti jinam či dokonce obyčejný překlep (písmena s a d jsou nebezpečně blízko u sebe) způsobí podobný problém. Podstatné je se z podobné situace poučit:

Za prvé, bezpečnost serveru by neměla být definována firewallem – služby by měly být nakonfigurovány tak, aby se k nim žádný neoprávněný uživatel nedostal bez ohledu na to, jestli je firewall zapnutý, vypnutý, dobře nastavený nebo chybně nastavený. Firewall by měl být vždy pouze dodatečnou ochrannou vrstvou, nikoliv tou hlavní. Problém popsaný v tomto článku je jasným příkladem.

Za druhé, pokud eliminujete všechny rozumné příčiny daného problému, zkuste se podívat i do těch oblastí, kde si myslíte, že by chyba neměla být, a proto jste je doposud ignorovali. Neuškodí se „vrátit ke kořenům“ a znovu všechno prověřit od začátku, a to důkladně.

Za třetí, nepanikařte, i když zjistíte, že jste udělali ohromnou chybu či způsobili vážný problém. Nejprve se uklidněte, a teprve pak přistupte k řešení problémové situace. Panika má tendenci prohlubovat škody a způsobovat další katastrofy.

Za čtvrté, provádějte průběžné bezpečnostní audity. Zejména po zásazích do konfigurace služeb či firewallu.

Smysl port knockingu a zabezpečení SSH

Z technologického hlediska je port knocking systém, který monitoruje síťový provoz, a pokud obdrží určitou sekvenci paketů (odtud název – „klepání na porty“), provede nějakou předdefinovanou akci. Nejčastěji se používá k otevření přístupu k nějaké službě přes restriktivní firewall.

Příklad. Mám službu SSH, která běží na standardním portu. Firewall je nastaven tak, že ve výchozím stavu nepropouští provoz směřovaný ze sítě na SSH. Port knocking démon však monitoruje síťový provoz, a pokud zachytí určitou sekvenci paketů na různé porty, provede příkaz, který port SSH otevře pro počítač, který sekvenci vyslal.

Implementací port knockingu a jeho modifikací je více, já se zaměřím na tu klasickou, tj. tu nejběžnější (bez šifrování), která se dá odposlechnout a použít útočníkem. Ano, pokud se jedná o předem definovanou sekvenci paketů, není pro útočníka problém síťovou komunikaci odposlechnout a sekvenci zopakovat. Proto je port knocking často považován za security by obscurity.

Přesto jsem port knocking nasadil na svůj (domácí) server. Proč? Na severu jsem zaregistroval řadu pokusů o průnik přes službu SSH, naslouchající na standardním portu (22). To není nic neobvyklého, existují automatizované nástroje (nebo se jedná o červy a jinou havěť), které skenují určitý rozsah IP adres, hledají běžící služby a zkouší k nim získat přístup pomocí nějakého seznamu nejběžnějších uživatelských jmen a hesel. Takové útoky jsou běžné a relativně málo nebezpečné (pokud máte adekvátně zabezpečený server a nepoužíváte slabá hesla).

Problémem je, že poslední dobou útoky poměrně zesílily, dokonce na mne začal útočit i nějaký botnet (mnoho různých počítačů, které byly kompromitovány a octly se pod kontrolou útočníka). Logy se samozřejmě těmito pokusy zaplnily a já začal dostávat desítky e-mailů o tom, že ta či ona IP adresa byla zablokována (viz nástroje fail2ban či denyhosts).

Tyto útoky nejsou samy o sobě moc nebezpečné, ale zaplňují logy, chudák admin (tj. já) pak tráví o to více času jejich čtením a zvyšuje se riziko, že mezi řadou těchto méně nebezpečných útoků přehlédne něco nebezpečnějšího. Tyto automatizované útoky tedy není zcela od věci odfiltrovat. Těch možností je více:

  • zakázat přihlášení heslem a použít přihlášení klíčem (návod, dobrý tip)
  • přesunout SSH port výše
  • omezit přístup k SSH jen na konkrétní vnější IP adresy
  • ssh-faker a podobné nástroje
  • port knocking

Všechno to jsou více či méně metody, které lze označit za „security by obscurity“. Přesto, pro tento účel jsou více než vhodné. Automatizované útoky jsou většinou velmi jednoduché a hloupé, hledají SSH na standardním portu, a když se na něj nepřipojí (nebo dojde k chybě), jdou „o dům dál“. Samozřejmě, zkušenějšího útočníka tyto metody nijak nezastaví, dokonce ho ani moc nezpomalí. Spoléhat tedy čistě na tyto metody, to by opravdu spadalo do kategorie „security by obscurity“ a plnilo admina falešným pocitem bezpečí. Pokud však berete jako admin na vědomí, že tyto metody slouží pouze k odfiltrování těch nejhloupějších a nejběžnějších útoků, a věnujete o to větší pozornost všemu dalšímu, co se na serveru šustne, pak je vše v pořádku.

Pokud se vrátíme k port knockingu, platí pro něj samozřejmě to, co jsem uvedl v předchozím odstavci. Spoléhat se na něj jako na hlavní zabezpečovací systém by byla osudová chyba. Pokud však admin nebere port knocking jako zabezpečení, ale pouze metodu k odfiltrování automatizovaných útoků, aby zbytečně neplnily logy, je všechno v pořádku. Dokonce více než v pořádku. Pak totiž admin ví, že má jakýkoliv další útok na SSH brát velice vážně (neboť útočník, který se dostal přes port knocking, už velmi pravděpodobně nebude robot, ale živý (a znalý) člověk s úmyslem se na server probourat).

Jak už jsem uvedl, samotný port knocking má řadu implementací a některé už za bezpečné (nebo bezpečnější) považovat lze. Kupříkladu, i takový knockd, port knocking démon, který je součástí řady linuxových distribucí, je schopen používat jednorázové sekvence portů (tj. něco jako jednorázová hesla).

Debian, pam, ssh a jednorázová hesla

Jednorázová hesla jsou dobrou volbou, pokud se chcete přihlašovat k nějakému serveru, třeba přes SSH, ale z nezabezpečeného terminálu. Tedy kupříkladu z internetové kavárny, školního či pracovního počítače. Na těchto počítačích je vhodné předpokládat přítomnost keyloggerů, tedy šmírovacích programů, které zaznamenávají stisky kláves, popřípadě si i fotografují obrazovku.

V Debianu jdou jednorázová hesla nastavit velmi jednoduše. Nejprve nainstalujeme OPIE server a klienta, spolu s příslušným modulem pro pam:

apt-get install libpam-opie opie-server opie-client

Následně upravíme konfiguraci SSH démona /etc/ssh/sshd_config tak, že povolíme následující:

ChallengeResponseAuthentication yes

Pak ještě upravíme příslušný konfigurační soubor pamu /etc/pam.d/ssh, kde nahradíme řádku:

@include common-auth

následujícím:

auth    sufficient      pam_unix.so
auth    sufficient      pam_opie.so
auth    required        pam_deny.so

Restartujeme SSH démona a inicializujeme OPIE:

opiepasswd -c

Pokud si (v případě připojení přes SSH) bude program stěžovat, že nejsme připojeni přes zabezpečený terminál, donutíme ho:

opiepasswd -cf

Budeme muset zadat heslo. Toto heslo budeme používat vždy, když budeme chtít vygenerovat jednorázová hesla. Zkusíme se přihlásit, necháme heslo prázdné a dostaneme výzvu:

Password:
otp-md5 499 ro5619 ext, Response:

Příslušné údaje využijeme k vygenerování hesla (to lze provést kdekoliv, nejlépe však někde na zabezpečeném stroji):

opiekey 499 ro5619

Zadáme stejné heslo, které jsme využili pro inicializaci OPIE. Obdržíme jednorázové heslo ve tvaru:

WART LAIR RICH MIN NERO JILT

Toto heslo pak můžeme použít k přihlášení z nezabezpečeného terminálu. Najednou můžeme vygenerovat více hesel (třeba 10):

opiekey 499 ro5619 -n 10

První z těchto údajů je číslo hesla. Jakmile jednorázové heslo odpovídající tomuto číslu zadáme, již ho nebude možné použít k přihlášení a budeme požádáni o zadání hesla s číslem o jedno nižším:

Password:
otp-md5 498 ro5619 ext, Response:

Jednorázová hesla jsou vhodná všude tam, kde víme, že se budeme k serveru přihlašovat z nezabezpečeného počítače. Jednorázová hesla však nejsou jedinou možností, jak podobnou situaci zvládat. Jinou možnost představují SSH klíče, pokud možno chráněné heslem. Heslo bez klíče je útočníkovi k ničemu, stejně jako klíč bez hesla.

Pomocí pamu lze kombinovat více metod autorizace. Je třeba možné nakonfigurovat pam tak, aby vyžadoval jak jednorázové, tak běžné heslo (v případě, že se někdo mých jednorázových hesel zmocní, bez hesla, které nosím v hlavě, mu pak budou k ničemu). Neoficiální (resp. v repositářích Debianu neobsažené) metody pak zahrnují i ověřování pomocí SMS či čehokoliv dalšího, pro co by si uživatel napsal pam modul.

Bezpečnost chrootu

Chroot je mechanismus unixových systémů, s jehož pomocí je možné mj. uzavřít nějaký program ve „vězení“, ze kterého není úniku. Tedy přesněji, ze kterého by nemělo být úniku. Funguje tak, že zamění nějaký existující adresář za kořenový adresář v rámci daného programu (a jeho případných potomků). Jakákoliv činnost, kterou pak program provádí, provádí pouze v příslušném adresáři, ze kterého se nemůže dostat. Teoreticky. Bohužel, realita je taková, že to jde.

V této diskusi naleznete pěkný malý Céčkový zdroják, pomocí něhož se z chrootu snadno dostanete. Tato technika je podrobně popsána zde. A toto není ani zdaleka jediný způsob. Další jsou popsány třeba zde spolu s metodami zabezpečení chrootu.

Bezpečnostní problém představuje zejména taková konfigurace, kde má útočník šanci získat v chrootu oprávnění roota. Pak není problém chroot opustit nebo jinak škodit, zejména přístupem k /proc nebo /dev. To, že do chrootu neumístíte příslušné soubory ještě neznamená, že si je útočník nebude schopen vytvořit, viz mknod.

Proto je třeba zajistit následující:

  • program v chrootu by měl běžet pouze s uživatelskými oprávněními
  • chroot by měl obsahovat jen to nejnutnější; cokoliv, co příslušný program v chrootu nepotřebuje, by tam nemělo být
  • maximum souborů a adresářů v chrootu by mělo mít taková oprávnění, aby je nešlo modifikovat (nebo v adresářích něco vytvářet)
  • pozor na symbolické linky a hardlinky

Více viz odkazy výše. Podstatně zvýšené zabezpečení chrootu představuje grsecurity či jiné patche zaměřené na bezpečnost či „posílení“ chrootu.