Fórum Root.cz

Ostatní => Odkladiště => Téma založeno: kvas 30. 03. 2020, 10:50:23

Název: Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: kvas 30. 03. 2020, 10:50:23
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.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: Miroslav Šilhavý 30. 03. 2020, 11:43:09
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.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: rooobertek 30. 03. 2020, 12:30:09
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.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: Miroslav Šilhavý 30. 03. 2020, 12:37:05
...

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á.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: kvas 30. 03. 2020, 12:40:19
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



Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: Miroslav Šilhavý 30. 03. 2020, 12:47:09
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.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: kvas 30. 03. 2020, 13:05:14
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
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: Miroslav Šilhavý 30. 03. 2020, 13:13:21
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.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: kvas 30. 03. 2020, 13:23:08
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.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: SB 30. 03. 2020, 13:23:52
...že odborník už umí svojí diskrecí pokračovat v nastavení.

Tak tohle by možná stálo za vysvětlení.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: Miroslav Šilhavý 30. 03. 2020, 13:24:16
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.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: Miroslav Šilhavý 30. 03. 2020, 13:27:48
...ž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.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: kvas 30. 03. 2020, 13:46:06
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:)
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: kvas 30. 03. 2020, 13:54:13
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......



Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: _Jenda 31. 03. 2020, 13:22:04
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ě.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: Miroslav Šilhavý 31. 03. 2020, 14:19:21
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......

Mám pocit, že si nerozumíme. Navrhované řešení řeší NOVÁ spojení ze serveru do světa. Nevyřeší se tím to, aby se zablokovaly přístupy zvenčí (to se zase řeší jinak, ale to jsme tu nediskutovali). Možná si pletete pojem "odeslat data" (nějaký script aktivně něco odešle) a "odpovědět na požadavek" (což je nejběžnější činnost, co dělá http server).

Každopádně, pokud jde o Tomcata, toho bych nikdy nespouštěl na přímo, ale vždy zřetězený až za reverzní proxy. Jako reverzní proxy může sloužit nginx, haproxy, apache. Na proxy pak můžete nejlépe ovládat kdo smí přistupovat k službě.

(Zbytek naší diskuse výše se týká situace "odeslat data").
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: luvar 01. 04. 2020, 09:10:12
Pre "zabezpečenie" jednej aplikácie sa na linuxe dá použiť aj niečo ako firejail https://firejail.wordpress.com/ Osobne som párkrát použil, ale nepamätám si viac.

Moja osobná skúsenosť so SoapUI, čo ma kus prekvapila, bolo, že daná aplikácia vo free verzii robí pri odoslaní testovacieho http requestu, asi 3 requesty na google analitics... Zistil som to pri nahrávaní traficu cez http proxy korektne nastavené v aplikácii...

nápad: Pri dočasnom poriešení problému je možné požiť aj "ifconfig down eth0" prístup :)

PS: Doterajšie prístupy sa zameriavali na sieťovú bezpečnosť (a imho sú potrebné), ale treba myslieť i na to, že aplikácia vie vygenerovať napríklad aj html súbor, ktorý pri generovaní náhľadu inou aplikáciou môže spraviť traffic...
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: kvas 01. 04. 2020, 12:40:32

Mám pocit, že si nerozumíme. Navrhované řešení řeší NOVÁ spojení ze serveru do světa. Nevyřeší se tím to, aby se zablokovaly přístupy zvenčí (to se zase řeší jinak, ale to jsme tu nediskutovali). Možná si pletete pojem "odeslat data" (nějaký script aktivně něco odešle) a "odpovědět na požadavek" (což je nejběžnější činnost, co dělá http server).

Každopádně, pokud jde o Tomcata, toho bych nikdy nespouštěl na přímo, ale vždy zřetězený až za reverzní proxy. Jako reverzní proxy může sloužit nginx, haproxy, apache. Na proxy pak můžete nejlépe ovládat kdo smí přistupovat k službě.

(Zbytek naší diskuse výše se týká situace "odeslat data").

urcite si rozumieme. Ja tu neriesim pripad komunikcie "odpovode na pozadavek z venku". stale sa bavime o desktope a nie serveri, ktory je na internete. tam by samozrejme tomcat nebezal napriamo ale za apachom, kdezto na devel stanici na to nevidim dovod (ak odhliadnem od testovania) z pohladu bezpecnosti. ta "nebezpecna aplikacia" je bindovana iba na localhost, takze z vonku nedostupna.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: oss 01. 04. 2020, 12:50:39
Vo vseobecnosti OSS nie je bezpecnjesie ako proprietarny softver.

Co sa taka webovych aplikacii tak odporucam sa zbavit interpretovanych zrudnosti a CGI skriptov.
Dany server odpoj od siete uplne, do infrastruktury si daj proxy, na ktorej povolis len konkretne endpointy a len vybrane programy (nie pouzivatelov) smeruj na danu proxy.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: Miroslav Šilhavý 01. 04. 2020, 15:36:47
urcite si rozumieme. Ja tu neriesim pripad komunikcie "odpovode na pozadavek z venku". stale sa bavime o desktope a nie serveri, ktory je na internete. tam by samozrejme tomcat nebezal napriamo ale za apachom, kdezto na devel stanici na to nevidim dovod (ak odhliadnem od testovania) z pohladu bezpecnosti. ta "nebezpecna aplikacia" je bindovana iba na localhost, takze z vonku nedostupna.

Na devel stanici bych udělal něco hodně podobného.
1. Firewall output => reject (kvůli timeoutům je to vhodnější než drop)
2. Firewall output user=[můj pracovní účet] => accept (osobně bych preferoval i pro svého usera proxy)
3. Aplikaci povolit přístup ven jen přes (dopřednou) proxy (a toto bych měl i na produkci)
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: kvas 01. 04. 2020, 17:45:04
Na devel stanici bych udělal něco hodně podobného.
1. Firewall output => reject (kvůli timeoutům je to vhodnější než drop)
2. Firewall output user=[můj pracovní účet] => accept (osobně bych preferoval i pro svého usera proxy)
3. Aplikaci povolit přístup ven jen přes (dopřednou) proxy (a toto bych měl i na produkci)

ano, to by asi bolo idealne ale priznam sa, ze takto dokladne to nakonfigurovane nemam. Ja sa vo vacsine pripadov spolieham na to, ze cely "standardny" Ubuntu desktop stack je "jakz-tak" bezpecny.

Ale k otazke zo zaciatku tohoto vlakna: tak trochu som predpokladal, ze to dopadne presne ako to dopadlo. Ani jeden clovek tu nenapisal, ze si preveril aspon jednu OSS aplikaciu a s kludnym svedomim moze spavat:) - jasne, ked je spravne nakonfigurovany firewall, riziko je blizke nule ale minimalne podla tohoto vlakna zistujem, ze pocit bezpecia z OSS (typu "musi to byt bezpecne, ved je to OSS a urcite sa niekto nasiel, kto ten kod overil") je len fatamorgana - aj ked pocet citatelov vlakna asi nebude dostatocna reprezentativna vzorka.

BTW: a co ked je bezpecnostna diera v spominanom firewalle? sme tam, kde sme boli :) - ale to nie je otazka do plena, len take odlahcenie od temy na zaver.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: Miroslav Šilhavý 01. 04. 2020, 18:05:47
Ale k otazke zo zaciatku tohoto vlakna: tak trochu som predpokladal, ze to dopadne presne ako to dopadlo. Ani jeden clovek tu nenapisal, ze si preveril aspon jednu OSS aplikaciu a s kludnym svedomim moze spavat:) - jasne, ked je spravne nakonfigurovany firewall, riziko je blizke nule ale minimalne podla tohoto vlakna zistujem, ze pocit bezpecia z OSS (typu "musi to byt bezpecne, ved je to OSS a urcite sa niekto nasiel, kto ten kod overil") je len fatamorgana - aj ked pocet citatelov vlakna asi nebude dostatocna reprezentativna vzorka.

Fata morgana :). Moje zjištění v této oblasti je, že existuje víc typů příznivců OSS. Jedni mají na OSS střízlivý náhled. Chápou jeho výhody a vidí i nevýhody. Ti dost často sahají i ke komerčním produktům, protože si spočítají, že někde se vyplatí víc. Pak jsou druzí, kteří v komerčním SW vidí zkázu lidstva a raději budou vždy podporovat OSS před ním. Takový přístup je taky v pořádku, jen někdy mi vadí, že mám pocit, že to platí někdo jiný - např. zaměstnavatel. A třetí skupina jsou laikové, či začátečníci, kteří se čistě pocitově přikloní k OSS - neb jeho ideje vypadají v magazínech vzletně. Do toho se přidávají další dva fenomény: zkratkovité rozhodnutí "je to zdarma" = "je to levnější" a taky to, že o komerčním SW se tolik nepíše (není proč o něm psát a nebudí takové kontroverze).

Moje zkušenost je, že když spočítáte TCO u komečního SW a u OSS, tak velmi často vyjde líp komerční SW. Výjimek není mnoho, ale existují. Např. Apache web server, Nginx, Tomcat, některé distribuce Linuxu a FreeBSD, které jsou už tak masově používané, že jejich správa a zabezpečení je reálná relativně levně. (Najde se jich samozřejmě víc, to jen pro příklad).

Docker je kapitola sama pro sebe. Je to koncept, který od počátku popřel po dekády budovaný bezpečnostní koncept. Distribuce intenzivně řeší bezpečnost, (zmíněné) projekty taky. A pak přijde nějaký jouda, zabalí to do kontejneru a masy to začnou používat v produkci. Když přijde na otázku bezpečnosti, tak se většinou neřeší, protože se zjistí, že veškerá výhoda Dockeru je fuč, pokud se má udržovat aktuální a bezpečný.

A děravý firewall? :) Nojo, to se samozřejmě děje, dokonce některé "díry" jsou by design, např. při použití NATU a aplikačních helperů. Vysvětlujte ale lidem, že (jeden) firewall != bezpečnostní řešení.
Název: Re:Bezpečnosť Dockeru, KeePass a OSS obecne
Přispěvatel: oss 02. 04. 2020, 07:54:46
Na devel stanici bych udělal něco hodně podobného.
1. Firewall output => reject (kvůli timeoutům je to vhodnější než drop)
2. Firewall output user=[můj pracovní účet] => accept (osobně bych preferoval i pro svého usera proxy)
3. Aplikaci povolit přístup ven jen přes (dopřednou) proxy (a toto bych měl i na produkci)

ano, to by asi bolo idealne ale priznam sa, ze takto dokladne to nakonfigurovane nemam. Ja sa vo vacsine pripadov spolieham na to, ze cely "standardny" Ubuntu desktop stack je "jakz-tak" bezpecny.

Ale k otazke zo zaciatku tohoto vlakna: tak trochu som predpokladal, ze to dopadne presne ako to dopadlo. Ani jeden clovek tu nenapisal, ze si preveril aspon jednu OSS aplikaciu a s kludnym svedomim moze spavat:) - jasne, ked je spravne nakonfigurovany firewall, riziko je blizke nule ale minimalne podla tohoto vlakna zistujem, ze pocit bezpecia z OSS (typu "musi to byt bezpecne, ved je to OSS a urcite sa niekto nasiel, kto ten kod overil") je len fatamorgana - aj ked pocet citatelov vlakna asi nebude dostatocna reprezentativna vzorka.

BTW: a co ked je bezpecnostna diera v spominanom firewalle? sme tam, kde sme boli :) - ale to nie je otazka do plena, len take odlahcenie od temy na zaver.

Samozrejme, ze bezpecnost OSS takmer nik neriesi, kazdy sa spolieha na to, ze to uz vyriesil niekto iny. Predsa je to otvorene.