Dotaz: Interaktivní firewall pro odchozí spojení

[lertimir]

Chci se zeptat, jestli máme v linuxu firewall, který je možné interaktivně nastavovat, v tom smyslu, že se mne firewall při pokusu o spojení zeptá, "program ABCD se chce spojit na IP/port. Povolit/zakázat?" Nebo "Na port nnn přichází žádost o spojení z IP/port. Povolit/zakázat? Nebo Accept/reject/drop?"

V době používání windows jsem s výhodou využíval tehdy tuším Kerio, a když se mne pokoušel nějaký program o komunikaci tak jsem to věděl a mohl se rozhodnout o povolení zakázání. V linuxu sice pomoci iptables umím nastavit příchozí (a i odchozí) pravidla, ale nemá to tu interaktivitu. Tedy kromě accept/reject/drop tak nemám nic jako "ask".

---

---

Odpovědi

[marek_hb]

gulf?

[Jendа]

Na Linuxu tohle nejde. (Windows nerozumím, ale čekal bych, že to nebude moc dobře fungovat ani tam)

Netfilter umí filtrovat podle ID uživatele a možná i podle ID procesu a SELinux/AppArmor umí omezovat síť pro proces (resp. grupu) a jeho potomky. Nicméně existuje spousta cest, jak to obejít - ďábelský proces ti může přidat do .bashrc wget nebo netcat, který spojení udělá za něj - a u wgetu spouštěného z Bashe budeš mít spojení určitě povolená. Ďábelský proces může přes firefox-remote otevřít ve Firefoxu stránku - a u Firefoxu budeš mít určitě internetovou komunikaci povolenou. Nebo ti může rovnou nainstalovat do Firefoxu addon, který mu spojení zprostředkuje. A milion dalších věcí.

Izolace aplikací od sebe navzájem je v Linuxu bohužel mizerná, takže není možné izolovat ani síť.

Pokud tě to trápí, mrkni na QubesOS - je to pokus (bohužel zatím pouze pokus, nevím, jak je to momentálně použitelné) o zabezpečení Linuxu.

[lertimir]

Nestudoval jsem to na windows detailně, ale moje představa je taková, že ten windowsí firewall zahákuje IP vrstvu. Tedy když přijde interupt z karty, že má paket pro IP, nebo přijde požadavek z vyššího protokolu na vytvoření IP paketu, tak ty požadavky jdou do firewallu, ten to buď posoudí automaticky, má-li explicitní pravidlo, nebo mi podá informaci, kdo a jaký paket posílá. Pokud je paket povolen, pošle jej dále do zpracování, tedy zavolá skutečnou prováděcí funkci.

V linuxu trochu podobný přístup máme pro tcpwrapper, který odchytí, posoudí a pokud je odsouhlaseno dále předá. Ale děje se to v podstatě na volání procesů. xinetd odchytí přístup na port a spustí příslušný konfigurovaný proces, což je tcpwrapper a ten po odsouhlasení zavolá vlastní server. Nicméně je to balení na úrovni procesů. Alespoň v době před 18 lety, (ještě na SunOS) kdy jsem se tcpwrapper zabýval, platilo, že aby tcpwrapper zabral musí inetd startovat server, pokud server běžel, třeba nějaká aktivita na ftp, další SYN packet šel přímo do serveru, mimo tcpwrapper.

[Jendа]

Tedy když přijde interupt z karty, že má paket pro IP, nebo přijde požadavek z vyššího protokolu na vytvoření IP paketu, tak ty požadavky jdou do firewallu, ten to buď posoudí automaticky, má-li explicitní pravidlo, nebo mi podá informaci, kdo a jaký paket posílá.

No ale k čemu je tohle dobrý?

[petr_p]

Izolovat s dá. Stejně jako izoluješ síť (SELinuxem, jmennými prostory), můžeš izolovat souborové operace a cokoliv jiného. Jenom je to nechutně složité implementovat a otravné používat.

Windows mají s každým procesem asociovány credentials, které proces může použít k získání oprávnění. Něco jako SELinux má domény, ale credentials jsou dynamické.

Co je ale problém, je, jak vést dialog s firewallem, aby dotaz neschválil ďábelský proces. Ve Windows se na to právě používají ony credentials, případně systém odpojí celé GUI a překryje jej svým dotazem (UAC od Vist).

Tohle by šlo udělat X11 klientem, který by grabbnul veškerý vstup (něco jako dělá pinentry), ale jak říká pan Bžatek, X11 je mrtvý, teď se dělá Wayland.

Nakonec udělat interaktivní firewall není těžké. Přes NFQUEUE se nechá prvotní TCP SYN packet poslat do uživatelského prostoru, který přes atributy socketu identifikuje zdrojový proces a přes onen X11 klient se dotáže uživatele.

Mám pocit, že podobná vymoženost se připravovala do Fedory, ale kam se to dostalo, netuším.

[potato]

Jak tedy vypadá řešení, které umožňuje věci jako používat wget a lftp z cronu, a přitom de facto neeliminuje celou funkci takového firewallu?

[Jendа]

Řekl bych, že ACL musí být nastavena tak, aby nikdo kromě uživatele (tj. jeho login shellu) nemohl editovat crontab.

[potato]

Login shell vznikne například spuštěním bash --login. Naopak v žádném z mých dvaceti spuštěných terminálů login shell neběží. Dělám tedy s/login shell/interaktivní shell/.

Je to I tak omezení, byť by mi asi vadilo jen zřídka. Především ale jednak řeší jedinou situaci, kdy se něco spouští automaticky. Co takový scénář ‚portmaster -f a odejdu na oběd‘? Co prostě cokoli, co probíhá typicky unixovým způsobem: správně to nastavím, a pak to funguje samo?

Druhak lze v podobných případech následovat cestičku z drobků a neměnit přímo crontab, ale wrapnout ty skripty z něj spouštěné. To samozřejmě předpokládá sofistikovanějšího útočníka, ale když už by se někdo rozhodl využít zrovna crontab, tak dává smysl přilepit se k něčemu, co uživatel čeká, že se děje.

[Jendа]

Druhak lze v podobných případech následovat cestičku z drobků a neměnit přímo crontab, ale wrapnout ty skripty z něj spouštěné. To samozřejmě předpokládá sofistikovanějšího útočníka, ale když už by se někdo rozhodl využít zrovna crontab, tak dává smysl přilepit se k něčemu, co uživatel čeká, že se děje.

Samozřejmě by to nesmělo mít možnost editovat ani ty skripty z něj spouštěné.

[potato]

Samozřejmě by to nesmělo mít možnost editovat ani ty skripty z něj spouštěné.

To je ale už velmi vážné omezení ve smyslu ‚nic, co uživatel [podle vybrané definice] nedělá interaktivně, nemůže změnit nic, co by mohlo jakkoli nepřímo ovlivnit jinou automatizovanou/naskriptovanou věc‘. Tedy znepoužitelnění systému, pokud ho nemáš akorát na updatovéní statustu na facebooku.

[Jendа]

Já si myslím, že bych takový sandboxing asi používat dokázal. Třeba s tím JHBuildem - řekněme, že si chci zkompilovat gnuradio. Vytvořím si kontext gnuradio a povolím mu pouze přístup k USB SDR zařízení. Myslím, že nijak jinak se zbytkem systému komunikovat nepotřebuje. Pokud pak budu chtít nějakou nahrávku z rádia poslat na analýzu do NSA, provedu přesun toho jednoho souboru mezi kontexty.

Obdobně jinde.

[petr_p]

SELinux umožňuje rozlišit, kdo spouští který program. Takže ve výsledku proces wgetu spuštěný cronem bude mít jinou selinuxovou doménu než wget spuštěný jinak.

Ale na tohle nepotřebuješ ani firewall, protože jinak spuštěnému wgetu se nepodaří ani volání socket(2), protože ho zařízne SELinux.

Pokud bys chtěl řešení čistě firewallové, tak nakonec nepotřebuješ SELinux, protože se můžeš sám podívat, který proces packet odeslat. Co je jeho binárka, kdo je jeho rodič a tak dále.

[potato]

Proto uvádím další příklady typu ‚portmaster -f a odejdu na oběd‘, kdy je proces původně iniciován interaktině uživatelem v jeho session, ale někdy v nedefinovaném budoucnu bude nějaký jeho potomek potřebovat navazovat nějaká spojení.

[potato]

Tohle tedy asi bude dělat stejně jako root, nicméně stačí si substituovat jhbuild, nebo cokoli podobného...

[Jendа]

Tohle by šlo udělat X11 klientem, který by grabbnul veškerý vstup

Pokud ty izolované aplikace provozuješ na jednom X serveru, tak je veškerá izolace úplně k ničemu.

[petr_p]

Kolem roku 2010 se NSA snažila rozšířit X11 o SELinux. Netuším, kam to dotáhla.

[petr_p]

SELINUX, LeopardFlower, AppArmor, Anoubis

[Jendа]

Jak to řeší problémy, které jsou popsané okolo v diskuzi?

[potato]

Stačí si přečíst Known Issuse u Leopard Flower, aby bylo zjevné, že nejen neřeší zde popsané problémy, ale přidává řadu mnohem zásadnějších...

Anoubis vypadá jako věc, která dokáže malou podmnožinu toho, co SELinux.

AppArmor nebudu komentovat, to je na flamewar.

[Petr Šobáň]

Jak už tady řekly k čemu je to dobré?

Prostě prakticky to není k ničemu dobré, prostě program sám od sebe nemá co posílat pakety do internetu a pokud to dělá tak je napaden a jako takový nemá být nainstalován v OS.

V linuxu vlastně netřeba žádný firewall - obzvláště na desktopu.

K čemu je to dobré pokud nějaký program pošle do internetu data tak očekávám odpověď a potřebuji aby to dorazilo a pokud nechci odesílat data tak ten program nebudu spouštět, tak stejně pokud budu chtít přijímat poštu tak si spustím SMTP server a ten bude poslouchat z internetu, a pokud nechci tak ho nespustím a když se bude někdo chtít přípojit na port 25 tak se stejně nepřipojí když tam nic neposlouchá.

Takže iptables v linuxu jsou hlavně o tom když stroj provádí routování aby se zbytečné pakety nedostávaly dál do sítě, abych odřízl různé útočníky aby mě zbytečně neotravovaly třeba ten smtp server.

Jinak když ti vyskočí okno že program smtp chce přistoupit k internetu tak obyčejný user stejně neumí rozhodnout zda je to oprávněná komunikace.

Takže firewall je spíš aby zabránil různým dos útokům a PC ve tvé síti fungovaly dál i když někdo zahltí tvoji linku do internetu a pod...

Prostě znalý uživatel si OS nastaví správně - neznalého žádný firewall nezachrání pokud si ho nastavuje sám.

[lertimir]

Máš pravdu v tom, že v open source světě, je to méně důležité, protože tu kontrolu, co skutečně program dělá mohu udělat v kódu. Ale občas používám i nějaké programy pod wine, připadně i některé closedsource programy pod linux, a tam dost netuším, kdy a kam program komunikuje a rád bych to věděl. Interaktivní firewall mi to pomůže zjistit a rozhodnout se.

[ondro]

Ale občas používám i nějaké programy pod wine, připadně i některé closedsource programy pod linux, a tam dost netuším, kdy a kam program komunikuje a rád bych to věděl. Interaktivní firewall mi to pomůže zjistit a rozhodnout se.

Ale toto nezistis vdaka interaktivnemu firewallu ani na windowse. To je len iluzia. Je kopa technik ako to obchadzat. Ani na windowse sa sofistikovany skodlivy kod nekomunikuje priamo ale vyuziva prostriedky windows a tie firewall pusta bez pytania. Ak chces naozaj vediet,co program robi a posiela, tak jedine logovanim komunikacie a jej naslednym studovanim.

[lertimir]

Už jsem tak nějakou dobu nepracoval, ale vždy jsem to nastavoval tak, aby ani windowsy přímo neměly povoleny odchozí obecnou komunikaci. Tedy pokud ten komerční firewall skutečně visel na HW. Standardně se mi stávalo, že otázky byly přímo, že systém chce někam komunikovat (třeba na Novelské servery), než jsem povolil vše, co bylo třeba.

Ale díky, je zřejmé, že komunikaci zevnitř se v linuxovém firewallu moc neřeší, a jistě je to i tím, že na widlích se mnohem častěji provádí nepotvrzený podezřelý kód a ty komerční firewally to musí nějak řešit.

[Jendа]

Ale občas používám i nějaké programy pod wine, připadně i některé closedsource programy pod linux, a tam dost netuším, kdy a kam program komunikuje a rád bych to věděl. Interaktivní firewall mi to pomůže zjistit a rozhodnout se.

Ne, nepomůže. Pokud jsi nainstaloval nedůvěryhodný program, mohl si tento třeba někam zkopírovat SUIDnutý wget nebo rovnou nahrát rootkit do kernelu (pokud při instalaci měl roota) a ty prostě nemáš jak to zjistit.

[lertimir]

Tomu rozumím. Nemyslel jsem to, jako ochranu proti přímo útočnému softu. U něj, pokud ho spustím, mi nepomůže nic. Nicméně mnohé komerční programy nedělají přímo útoky do systému, ale spíše "bonzují". Chtějí si pokecat se svojí firmou, mnohdy tuhle činnost i lehce zmíní v dokumentaci, ale nijak moc to nezdůrazňují a tím sbírají data. Tak proti takovémuto chování jsem se chtěl případně firewalem chránit. Ty programy nedělají nějaké divočiny jako SUID programy nebo rootkity, jen navazují spojení pod sebou. Jenže normálně to uživatel neví, ony se připojí a odešlou, co chtějí. A já alespoň chtěl vědět, že to dělají, nebo připadně navíc, jim to zatrhnul.

[vlastik]

Osobně mám účet vyhrazený pouze pro Wine a v IPTABLES zakázanou síťovou komunikaci. Podobně to mám u Steamu, Skype a dalších closed-source, ale většinou s povolenou sítí, jen nechci aby mi lezli do mého domovského adresáře. Není to asi tak mocné jako SELinux, ale mnohem pohodlnější :).

[j]

Jen tak pro zajimavost, co od toho cekas? Protoze i v tech widlich pokud das jednou "povolit", tak uz se te podruhy nezepta. A uplne stejne jako je tu popisovano, tak zcela bezne ve widlich pouzivaj aplikace IE, presto ze ty ho trebas nepouzivas, ale appky ho pouzivaji - defakto jakakoli, ktera ti zobrazuje neco z netu. Takze se ti zadny hlaseni ani neobjevi, protoze na ten net leze IE.

Hlaska se ti objevi az v situaci, kdy si konkretni appka rekne o otevreni koneksny.

[lertimir]

Ale já jsem i ve vidlích nedal v podstatě nikdy povolit, pokud jsem nevěděl, že to potřebuji. I při instalacích jsem šel přes třeba 50 jednorázových povolení. A ten IE byl samozřejmě generálně zakázán zcela. I když něco zavolalo IE přímo s oknem, IE najel, ukázal URL, stěžoval si, že se nikam nepřipojí, a já pokud chtěl tak jsem copy/paste sejmul URL a otevřel v jiném prohlížeči.

Slibuji od toho mít přehled, pokud nějaká aplikace chce komunikovat ven. Z diskuse zde mám dojem, že v podstatě jediné funkční řešení je SElinux (možná i AppArmor, ale ten zatím neznám natolik, abych to věděl) s tím, že nové aplikaci prostě na začátku veškerou komunikaci zakážu a studiem SElinuxového logu postupně povolím, co mít musí.

[petr_p]

Podívejte na program sandbox, který je dodáván se SELinuxem (příklad).