Bezpečnosť Dockeru, KeePass a OSS obecne

[kvas]

Ahoj, potrebujem izolovat jednu aplikaciu od internetu, ale tak, aby bola dostupna z mojho desktopu/hostu - koli bezpecnosti. Najskor ma napadol VirtualBox ale ten je trochu tazkopadny, potom som uvazoval o Dockeri ale nejako mi nesedi - neva to teraz nie je podstatne. Skor ma napadlo toto: uvazujete nad bezpecnostou OSS aplikacii, ci im je naozaj mozne na 100% verit, napr. ci nejake CMS (wordpress, joomla) alebo iny OSS projekt (KeePass, tomcat, mysql, SVN, git, nejaka wiki a milion dalsich) neposiela vase data(zdrojaky/dokumenty), zakaznicke data(!!!) z produkcie niekam prec do ciny/ruska/whatever?

jasne, je to open source, mozem si to skontrolovat, ked som paranoik, ale robite to niekto alebo slepo verite komunite?

Co sa tyka "serioznych" projektov, ako napr. mysql/postgres/apache/git/svn tak by to "snad" bolo OK, ale co taky NodeJS a jeho milion balickov, tam je dost velka pravdepodobnost, ze si nieco "zavadne" dotiahnem, podobne image pre Docker(tusim sa tam tazili nejake bitcoiny), alebo rozne pluginy pre CMS, tam je tiez vysoka sanca nieco chytit.

Hladam proste nejaky mechanizmus aby aplikacia X nekomunikovala so svetom mimo toho, na co je primarne stavana. Nebojim sa, ze by mi zasifrovala data a potom vydierala, ale aby mi nic neuslo von/prec.

[Reklama]

[Miroslav Šilhavý]

Co se týče OSS, musíte určitě z části věřit. Dobrým vodítkem jsou statistiky CVE společně s nějakou informací o používání. Nejlepší je hodně používaná aplikace s minimem bezpečnostních chyb ve statistikách. Není to samozřejmě záruka, že zrovna zítra se nenajde díra jako hrom, ale něco to vypovídá. Zrovna Joomla a hlavně WordPress dopadají katastrofálně. Navíc u nich jsou ještě další díry v pluginech a motivech, které do CVE základního produktu nespadnou.

Pokud chci postavit aplikaci a rozumně ji zabezpečit, pak:
1. Běží odděleně. Docker nepovažuji za bezpečný. Samostatná VPS je neekonomická. Mám rád FreeBSD jaily, to je takový kompromis mezi těmi dvěma.
2. Oprávnění musejí být segregovaná. Pokud apache / nginx / php-fpm běží pod uživatelem www-data a pod ním běží i další weby, nelze bezpečnost rozumně nastavit. => Spouštím nezávislou instanci webserveru a php, která běží pod oprávněními jednoho nezávislého uživatele.
3. Na firewallu nefiltruji jen provoz dovnitř, ale i provoz ven. Aplikace nemá co komunikovat ven ze serveru, když o tom nevím. (Tím se také značně omezí možnosti šíření (D)DoS a červů.
4. Aby aplikace mohla komunikovat jen tam, kam chci, nastavuji na serveru proxy server. Aplikace má povinnost komunikovat přes proxy, pokud potřebuje spojení směrem ven. Na firewallu mohu filtrovat jen L3, na úrovni IP adres, za kterou mohou být stovky služeb, např. celé cloudy, a ty IP adresy se čas od času mění, takže by bylo potřeba neustále reloadovat firewall. Na proxy serveru nastavím L7 filtr, obvykle na URI služby, kterou chci povolit.
5. Směrem dovnitř komunikaci proháním přes reverzní proxy, na které běží aplikační firewall. ModSecurity + pravidla, např. od Atomicu.
6. PHP má zásadně omezenou paměť (co nejméně, pár nižších megabajtů).
7. PHP script musí mít omezenou dobu běhu (např. 5 sekund). Cokoliv, co běží déle není na webu stejně použitelné (z hlediska UX) a otevírá to dveře útokům.
8. Administrace webů vyžadují vyšší limity (např. na přeškálování obrázků, pro složitější DB operace, upload souborů, ...). Administrace se musí oddělit na jiný virtuální server, běžící v jiné instanci včetně oddělené instance PHP.

Tím vším se posunete ke zvýšené bezpečnosti. Ano, je to v tu chvíli dost náročné na správu, ale jestli hledáte bezpečnost, tak toto je jedna z cest.

[rooobertek]

K tým cms... Ja ich nemám rád. Mám zlé skúsenosti hlavne s wordpressom, a situácia je tam asi takáto
- treba pravidelne aktualizovať
- treba aktualizovať aj všetky pluginy a šablóny
- aktualizáciou sa pravdepodobne niečo z pluginov alebo šablón pokazí
- čím viac pluginov, tým vyšší počet kombinácií, ako môže jeden plugin pokaziť nejaký iný
- aktualizáciou si môžem dotiahnuť nejakú sviňárnu (toto často platilo/platí aj pre add-ons pre Firefox)
- do hotovej šablóny nemôžem zasahovať, inak prídem o možnosť jednoduchých aktualizácií
- je mnoho robotov, ktoré sa špecializujú na veľmi účinné hackovanie wordpressov a akýchkoľvek iných obľúbených cms, často stačí nemať včerajší update
- sú pluginy, ktoré sa snažia toto všetko riešiť nejakou mágiou, ale predsa len sú to ďalšie pluginy...

Ako príklad si vždy spomeniem na jeden web pre malú vinárničku, ktorý som robil na systéme bez open source cms. Fungoval bez problémov, neboli potrebné ani žiadne aktualizácie, žiadny zásah, proste to išlo. Takých 8-10 rokov neskôr prešli na wordpress. Do mesiaca mali deface a dnes majú už len presmerovanie na facebookovú stránku. Ten mesiac som vyčítal iba z archive.org, pravdepodobne to bolo ešte rýchlejšie.

[Miroslav Šilhavý]

...

Velmi přesně popsáno. OSS CMS jsou dobrý nástroj na rychlý launch (potřebuju rychle dostat produkt ven a získat čas na pořádné stránky), nebo naopak na velmi silný vlastní vývoj (vytvořím si vlastní pluginy, šablony, nakoupím si profesionální pluginy s podporou atd.) a vlastní správu.

Reálně ale 99 % zadavatelů volí WordPress a spol. s představou, že je to cesta jak získat dokonalou funkcionalitu za nula korun a bez správy. Tam je každá rada drahá.

[kvas]

nerad by som to stocil k diskusii o CMS a pod. Mne momentalne skor ide o bezpecnost na desktope, resp. chcem zabezpecit len jednu aplikaciu.

najviac ma zaujal bod:

3. Na firewallu nefiltruji jen provoz dovnitř, ale i provoz ven. Aplikace nemá co komunikovat ven ze serveru, když o tom nevím. (Tím se také značně omezí možnosti šíření (D)DoS a červů.


co som googlil, tak by to malo fungovat nasledovne:
1) aplikaciu spustal len pod userom ABC
2) na firewalle zakazat outgoing pre usera ABC
stacia zabezpecit tieto 2 body pre "pocit bezpecia a istoty"? mate link na jednoduchy postup ako to nastavit? zatial som ziadny pre mna rozumny nenasiel.

jo, a zabudol som poznamenat ze bezim na ubuntu 16.04
dik

[Reklama]

[Miroslav Šilhavý]

co som googlil, tak by to malo fungovat nasledovne:
1) aplikaciu spustal len pod userom ABC
2) na firewalle zakazat outgoing pre usera ABC
stacia zabezpecit tieto 2 body pre "pocit bezpecia a istoty"? mate link na jednoduchy postup ako to nastavit? zatial som ziadny pre mna rozumny nenasiel.

Jednoduchý postup na to nemám, jsou to hodiny práce. Internetové návody toto vůbec neobsahují (ostatně stejně jako jakékoliv opravdu dobré postupy), předpokládá se, že odborník už umí svojí diskrecí pokračovat v nastavení.

Na to, abyste měl spojení od usera ABC, musíte apache/nginx i php-fpm spustit pod tímto userem - tj. ona nezávislá instance, o které píšu.

Asi vhodnější je na serveru zakázat celý outgoing a naopak povolovat jen uživatele a směry, které chcete umožnit. Jedině tak máte (jakš takš) jistotu, že jste neudělal chybu.

[kvas]

Jednoduchý postup na to nemám, jsou to hodiny práce. Internetové návody toto vůbec neobsahují (ostatně stejně jako jakékoliv opravdu dobré postupy), předpokládá se, že odborník už umí svojí diskrecí pokračovat v nastavení.

nie som si 100% isty, ale zda sa, ze toto by mohlo fungovat takto:

1) vytvoril som usera "ferko"
2) nastavil pravidlo do iptables
3) ked zavolam ping, tak to nema dovolene

Kód: [Vybrat]

sudo adduser ferko
sudo iptables -A OUTPUT -o NAZOV_NET_INTERFACE -m owner --uid-owner ferko -j DROP
su ferko -c 'ping google.com'
ping: sendmsg: Operation not permitted

takto by to mohlo fungovat, nie?

zdroj:
https://www.cyberciti.biz/tips/block-outgoing-network-access-for-a-single-user-from-my-server-using-iptables.html

[Miroslav Šilhavý]

Ano, takto by to mohlo fungovat, ale z hlediska bezpečnosti je to tzv. "na vodě". Bezpečný postup je DROP ALL (pro všechny uživatele) a poté jedno po druhém povolovat. Nikdy nevíte, které spojení se skryje pod jiného uživatele. Např. odchozí pošta se skryje pod uživatele MTA (např. postfix).

Ze stejného důvodu musíte spustit i nginx/apache a php-fpm pod userem ferko, protože jinak se to skryje (nejčastěji) pod uživatele www-data.

[kvas]

Ano, takto by to mohlo fungovat, ale z hlediska bezpečnosti je to tzv. "na vodě". Bezpečný postup je DROP ALL (pro všechny uživatele) a poté jedno po druhém povolovat. Nikdy nevíte, které spojení se skryje pod jiného uživatele. Např. odchozí pošta se skryje pod uživatele MTA (např. postfix).

Ze stejného důvodu musíte spustit i nginx/apache a php-fpm pod userem ferko, protože jinak se to skryje (nejčastěji) pod uživatele www-data.

Rozumiem. Ale teraz mi ide o zabezpecenie len jednej aplikacie na desktope takze totoby asi mohlo stacit. samozrejme, keby to bolo  nejake php CMStak by bolo potrebne mat pod ferkom spusteny  apache/nginx + php.

[SB]

...že odborník už umí svojí diskrecí pokračovat v nastavení.

Tak tohle by možná stálo za vysvětlení.

[Miroslav Šilhavý]

Rozumiem. Ale teraz mi ide o zabezpecenie len jednej aplikacie na desktope takze totoby asi mohlo stacit. samozrejme, keby to bolo  nejake php CMStak by bolo potrebne mat pod ferkom spusteny  apache/nginx + php.

Ale na destkopu je to to samé. Běží vám PHP pod uživatelem www-data a tím pádem to pravidlo se nevyhodnotí a projde to.

[Miroslav Šilhavý]

...že odborník už umí svojí diskrecí pokračovat v nastavení.

Tak tohle by možná stálo za vysvětlení.

Howto obvykle ukáží jak se řeší nějaká modelová situace. Např. jak zahodit packet, jak zjistit nevalidní TCP flagy, jak filtrovat podle uživatele. Jiné howto ukáže, jak nastavit PHP-FPM pooly pod různými uživateli. Jiné howto ukáže, jak nastavit proxy server. Jiné howto napoví, jak přes proxy server nastavit aktualizace systému. Další howto ukáže L7 filtrování na proxy serveru.

Profesionál se od laika liší tím, že umí nejprve specifikovat, co vlastně chce a v druhém kroku umí uvážit a syntetizovat poznatky z různých oblastí v jeden funkční celek.

Kvas se zeptal poměrně jednoduše na oblast, která je řešitelná velmi namáhavě a liší se situace od situace. Proto na to nejsou žádná howtos.

[kvas]

Ale na destkopu je to to samé. Běží vám PHP pod uživatelem www-data a tím pádem to pravidlo se nevyhodnotí a projde to.

suhlasim, ved to ani nerozporujem v mojej odpovedi:)

[kvas]

Kvas se zeptal poměrně jednoduše na oblast, která je řešitelná velmi namáhavě a liší se situace od situace. Proto na to nejsou žádná howtos.

aby sme sa nepohybovali v celom spektre moznosti uvadzam teda konkretny vymysleny priklad, ktory "akoze" potrebujem vyriesit:

1) povedzme ze neverim, ze je Tomcat (ktory bezi u mna na lokale/devel stanici) bezpecny.
2) vytvorim uzivatela ferko a nastavim iptables tak ako popisujem hore
3) ked spustim tomcat resp. catalina.sh (tusim tak sa ten script vola, nechce sa mi to hladat/overovat) pod userom ferko, tak mozem s tomcatom komunikovat z localhostu ale Tomcat ziadnu moju java classu neposle do sveta.

suhlas? za tomcat si mozno dosadit mysqld/svnserve/keepassx/python whatever......

[_Jenda]

Kód: [Vybrat]

sudo adduser ferko
sudo iptables -A OUTPUT -o NAZOV_NET_INTERFACE -m owner --uid-owner ferko -j DROP
su ferko -c 'ping google.com'
ping: sendmsg: Operation not permitted


Ano, přesně tak. Ještě doporučuji tam cestou přidat '-j LOG --log-prefix "OUT packet " --log-uid' a pak koukat do syslogu/dmesg. Jednu dobu jsem to takhle provozoval a dozvěděl jsem se o spouště aplikací že komunikují, i když by to člověk nečekal: https://brmlab.cz/user/jenda/et Vrcholem je stardict posílající v defaultním nastavení obsah schránky do Číny a ty Gnome věci posílající fyzické a emailové adresy kontaktů.

suhlas? za tomcat si mozno dosadit mysqld/svnserve/keepassx/python whatever......

Ano, pomůže to v naprosté většině případů. Nicméně pozor třeba na ty maily a obdobné způsoby leakování informací a na špatně nastavená práva na souborovém systému. A u grafických aplikací je další problém: aplikace na jednom X serveru si můžou posílat události (například lze panelu poslat Win+R nebo podobnou zkratku na spuštění příkazu), dělat screenshoty a podobně.