DIGI online servlet docker?

Közösségi kerekasztal

Sziasztok,

 

Van akinek sikerul dockerben futtatni az alabbi csodat? 

https://github.com/szabbenjamin/digionline

Nagyon hasznos lenne docker-ben tudni ezt is:)

( krumplicska | 2020. 07. 22., sze – 19:39 )

A projekt leírásban található módon tudsz segítséget kérni:
 

Tisztelettel megkérlek, ha hibát találtál vagy ha csak nem értesz valamit vegyél fel github-on hibajegyet vagy kérdezz Telegram csatornánkon és segítünk!

( kbalint v | 2020. 07. 22., sze – 21:12 )

https://github.com/szabbenjamin/digionline/blob/master/Dockerfile

ott van bakker kikommentelve minden info a docker image-hez a fájl végén :D környezeti változóban kell megadni a user / pass-t!

# Build docker image:
  # sudo docker build -t digionline https://github.com/szabbenjamin/digionline.git
  # Create and run docker container:
  # sudo docker run -d -p 9999:9999 --restart unless-stopped --env EMAIL=a@b.hu --env PASSWORD=jelszo --name container-digionline digionline
  # Kodi PVR IPTV Simple Client addon
  # TV channel list: http://localhost:9999/channels_IPTV.m3u8
  # TV EPG source: http://localhost:9999/epg.xml

~ubuntu, raspbian, os x~

szívesen várják a PR-ed :)

cserébe oldd meg környezet függetelenül / implementáld arra az n+1 különbözőre amin szükség lesz rá. Add hozzá, hogy valószínűleg ez a cucc a home lan-on fog üzemelni. a one-liner -t le tudják futtatni, ennél többet már egyre kevesebben.. pl már több parancs && -el összefűzött verziója van akinek gondot okoz :)

Bár igazad van, de egyrészt oda, ahol ezt csinálják valószínűleg teljesen mindegy, másrészt meg ott van a docker fileban, hogyan kerül bele*, nyugodtan beteheted olyan secure módon, ahogy neked tetszik.

*Egyébként meglehetősen szarul, igazából semmi értelme belesedelni abba a fileba, lehetne simán eleve így a repoban :)

A sudoval is az van, hogy bár nem szoktuk, de egyébként ha a usered tagja a docker groupnak, azzal adtál egy nopasswd: ALL -t, szóval megint csak ilyen környezetben nagy különbség nincs egy ilyen célkörnyezetben.

" ha a usered tagja a docker groupnak, azzal adtál egy nopasswd: ALL -t, " - docker konténerek maszírozására kapott jogot. És igen, "ötletesen" megcsinált konténerrel gyakorlatilag bármit is csinálhat a konténert futtató gépen.

Nem kell finoman fogalmaznod, 15+ eve igy dolgozom es hasznalok minden szervert, a cegeseken is, ahol AD-autentikacio van, minden uzemelteto elso dolga a root shell, csak erteni kell hozza. Azt nem tudom elkepzelni, hogy valaki azzal kezd egy szerveren, hogy km-hosszu sudoers-t ir, hogy minden biz-basz menjen.

Sot, olyan szervereim is vannak, ahova (kulccsal, nyilvan, meg halozati szegmentalassal es tarsaival, mielott elokerulve) eleve root-kent lepunk be, skandallum.

Attól, hogy így használod, még nagyon nem helyes. A direktben root-ként mész be addig "buli", amíg nem történik olyasmi, ami miatt szőnyeg széle van, és elkezdődhet az egymásra mutogatás, hogy kinek van munka- é sbüntetőjogi felelőssége az adott esemény kapcsán. (Ja, és ha netán az adott szervezetnél a belső szabályzatok tiltják a technikai user közvetlen belépésre történő használatát, akkor egy auditnál kibukó "fizetős észrevétel" elég a munkajogi következményekhez).

" Azt nem tudom elkepzelni, hogy valaki azzal kezd egy szerveren, hogy km-hosszu sudoers-t ir " - Akkor nagyon gyenge a fantáziád, mert bizony van ilyen - a leghosszabb sudoers, amihez szerencsém volt, az valami 120-130 releváns sort tartalmazott, és senkinek nem fájt. Egy korrekten "belőtt" rendszernél nagyon kevés az a speciális dolog, ami "sudo su -"-ért kiált, ha meg ilyen van, akkor azt és csak azt kell ilyen módon végrehajtani. A 15+ év szép hosszú időszak, mondjuk úgy, hogy te már "beleszülettél" a sudo-korszakba: én még bőven előtte kezdtem az ipart, és mégis megszoktam és természetesnek tartom, hogy amit lehet normál user + sudo, azt nem rootként vagy adott technikai userként csináljuk.
 

" Attól, hogy így használod, még nagyon nem helyes. A direktben root-ként mész be addig "buli", amíg nem történik olyasmi, ami miatt szőnyeg széle van, és elkezdődhet az egymásra mutogatás, hogy kinek van munka- é sbüntetőjogi felelőssége az adott esemény kapcsán. (Ja, és ha netán az adott szervezetnél a belső szabályzatok tiltják a technikai user közvetlen belépésre történő használatát, akkor egy auditnál kibukó "fizetős észrevétel" elég a munkajogi következményekhez). "

 

NIncs ilyen problema, oriasi multinal dolgozom, auditalt korulmenyek kozott, speciel az emlitett szerverek is azok. Semmi nem irja elo azt, hogy ne lehetne root-kent belepni, ha az egyebkent nincs kelloen biztonsagos kornyezettel megtamogatva (mind halozati, mind lokalis szempontpol, sshd konfiggal es tarsaival).

" Semmi nem irja elo azt, hogy ne lehetne root-kent belepni " - azért én megkérdeztném a helyedben a CSO-t, hogy helyes-e, hogy root/kisszékhóember párossal jártok be az éles gépekre... Nagyon csodálkoznék rajta, ha elfogadhatónak tartaná/igen-nel felelne. (Ha mégis, akkor meg remélem, hogy eme céggel semmilyen érdemi kapcsolatom nem volt/nincs és nem is lesz, aminek kapcsán az adataimat kezelnék...)

Komolyan, magyarazd mar el, kerlek, hogy mi a problema azzal, ha:

- (eros, modern) kulcsos autentikacioval,

- az authorized_keys file-ban, az sshd konfigban, illetve a tuzfalon is limitalt modon

lep be valaki egy szerverre? Komolyan kerdezem, es mivel mondtam, mi a szakteruletem, nehezen vagyok meggyozheto.

_Soha_ nem irtam 50-100-200 soros sudoers-t, fel sem merult egyik helyen sem. Ha valahova nem is root-kent lepek be (pl. az emlitett AD-autentikacios megoldassal), ahogy jeleztem, en es mindenki mas is azonnal root shell-re valt, es szinten soha nem dolgoztam olyan helyen, ahol ez ne igy lett volna. Alapveto a passwordless sudo is. Egyetlen ellenervet szoktam egy kulsostol erre hallani, hogy "de hat az auditalhatosag igy korulmenyesebb", na az viszont tokeletesen hidegen hagy. Egy oriasi bankrol van szo, auditalnak eleget, nem erdekel. Mondj szakmai erveket, ami igazolja, hogy ezzel barmi gond lenne, merthogy biztonsagi szempontbol semmi, es nem gyerekek dolgoznak nalunk, nem volt meg ra pelda, hogy abbol volt gond, hogy valamelyik kollega root shell-ben dolgozott.

Honnan fogod tudni hiteltérdemlően bizonyítani, hogy az adott tevékenységet, amiért szőnyeg széle van, ki csinálta? Ki használta az adott hozzáférést? Milyen jelszópolicy vonatkozik a ssh-kulcsodra, és az hogyan, milyen módon van kikényszerítve és naplózva? Van-e olyan eleme az azonosításnak (nem a kulcsfájlt tartalmazó gépre történő belépésre gondolok), amit nem elég birtokolni (privát kulcsod)? Hogyan oldjátok meg azt, ha valaki távozik? A publikus kulcsát valamennyi érintett helyről (/root/.ssh/authorized_keys) törlitek, gondolom, de tényleg mindenhonnan?

A rootként "esel be a gépre", és a root userre váltva dolgozol az két, teljesen eltérő scenario. Az első esetben az adminisztrált gépen csak azt lehet tudni, hogy root credential-lel az x.y.z.w címről és az mzperx kulcsot használva jelentkezett be valaki. Hogy ki, azt csak az x.y.z.w gép logjaiból lehet kibogarászni - ha ott nem egy user volt adott időben bejelentkezve, akkor máris többes felelősség adódik.
A legtöbb szerveren mi az, amit kell tudni napi szinten matatni: diszkek mérete, logok rotálása (ezek illendően alkalmazás userrel jönnek ugyebár létre, nem kell hozzá uid=0), alkalmazások újraindítása (ezek "egysoros" sudoers bejegyzések, és app_admin groupnak "odaadhatók". Egy upgrade meg egy új csomag telepítése lehet még uid=0 igényű, de azt megint csak nem muß helyben csinálni, pláne sok gép esetén jobb egy központi managementből "tolni" a csomagokat.

Ja, a passwordless sudo-ra emlékeim szerint nem egy és nem két audit tool "harap"...

Nem erveket mondtal, hanem kerdeseket tettel fel, de ennyit nem fogok mobilrol gepelni. 
A legtobb kerdesedre egyebkent megvan a bevett valasz, boven elegendo legtobbszor, ha mar source ip-re lehet korrelalni, dhcp lease-time is van a vilagon, villamgyorsan azonosithato.

Oldalakat viszont tenyleg nem fogok gepelni, bocs. Ahogy irtam, auditalt a mukodes, nem erzem ugy, hogy barmirol meg kene gyoznom, nem faj ez senkinek meg nalunk sem, rajtad kivul.

Nem kell válasz, illetve a válaszok - ha végiggondolod azokat - adják az érveket. Azt nem tudom, hogy nálatok milyen mélységű és hatékony a külső audit, amerre én jártam eddig, ott sehol nem volt elfogadott a nem nevesített/admin/root user közvetlen használata bejelentkezésre.

vicces olyan vitát olvasni, ahol a felek nem akarják egymást meggyőzni, csak tolják a saját álláspontjukat, hogy márpedig de. engem, mint egy szakmai fórum olvasóját a jogászkodásnál jobban érdekelne egy olyan típusú vita, hogy "ez és ez a konkrét veszélye, mert így és így lehet ezzel visszaélni, ami ide vezethet" kontra "ezt mi így védtük ki és így előzzük meg, ezért nem fordulhat elő" stb.

nem akartok elindulni ebbe az irányba?

Az az egy a "tényleg fáj" kategória. Példának okáért a jelszópolicy ráhúzása az ssh-kulcsra nem lett megválaszolva (mert nem tudsz ilyet - a smartcard jó, de az mint megvalósítás később "jött be" a thrad-be)...
Nekem nem fáj, hogy rootként járnak ki-be a gépekre, csak akkor az _ahonnan_ legyen olyan módon védve és naplózva, ahogy az éles rendszer védve/naplózva kéne, hogy legyen.

"mzperx kulcsot használva" -- itt a válasz.

Ha publikus kulcsot használsz autentikációhoz, a privát kulcsot sosem adod ki a kezed közül és természetesen jelszóval véded, ami plusz biztonság. Ez a jelszó sosem kerül ki a gépedről.

Szemben a régi megoldásokkal (nem SSO): "itt a HR portál / BitBucket / Wiki / stb., domain usernévvel + jelszóval kell bejelentkezni". Ha belépsz, máris valaki hozzájutott a jelszavadhoz.

"Egy security szakembertől el lehet várni, hogy el tudja dönteni."

Hát azért itt feljebb sikerült egy security szakembernek nyilatkozni, hogy nem érdekli az auditálhatóság, és hogy szerinte a rootként bejárkálásnak semmi más hátulütője nincsen, szóval azért csak óvatosan az ilyen kijelentésekkel :) Már csak azért is, mert egyrészt nem fekete-fehér egy csomó kérdés, másrészt meg a security jellemzően rendszer szinten érdekes, és a kedves security szakembernek nem biztos, hogy meg van róla az összes információja, hogy ezt a jelszót (vagy teljes hiányát ugye, mert itt erről van szó) mekkora risknek kell tekinteni.

"A jelszó policy nem sokat ér, ha mindenkinek van egy alapjelszava, és változtatáskor csak 1-1 számot módosít benne, vagy ugyanazt a jelszót több helyen használja."

Ebben egyébként igazad van, (bár a minimális változtatásokra már vannak módszerek, szoktak is megrökönyödni rajta itt is), az elég feat volt, amikor az MS hozott ajánlást arra, hogy a kretén jelszópolicyk nagy része inkább káros, az egyetlen hasznos elem kb a hossza (meg az egyedisége, de az ugye good luck), és hogy legyen 2FA, azóta végre van mire mutogatni, mikor valaki a 128 hosszú, legalább 12 speciális és három kínai karakter 2 hetente változtatva jellegű agyrémekkel jön.

> mzperx kulcsot használva jelentkezett be valaki

Ha mzperx kulcsával lépett be valaki, akkor mzperx-é a felelősség, a kulcs ugyanis csak neki van meg. Vannak előírások, hogy milyen biztonsági gyakorlatot kell követni, de a rendszer biztonsága végsősoron ugyanúgy az emberen múlik mintha jelszó policy lenne, lásd azokat az eseteket amikor az aktuális jelszavát postit-tel ragasztja a monitorra vagy otthagyja a gépét screen lock nélkül az asztalnál nyilvános helyen esetleg kiadja az első gyüttment phising emailre. A munkakör tőle elválaszthatatlan felelősséggel jár és pont.

> publikus kulcsát valamennyi érintett helyről (/root/.ssh/authorized_keys) törlitek, gondolom, de tényleg mindenhonnan

Nálunk jellemzően az SCM menedzseli a helyi juzereket, így kb ugyanakkora biztonsággal vonja meg a hozzáférést authorized_keys alapon mintha unix accountot lockolna. Központi beléptetésnél ez tényleg lehet gond, ez egy valid érv, a gyakorlati áthidalásával nincs tapasztalatom.

"kulcs ugyanis csak neki van meg" - de ezt bizonyítanod is kell, nem csak feltesszük, hogy csak ő birtokolja.

"otthagyja a gépét screen lock nélkül" - ami persze 1-2 perc múlva automatikusan zárolódik. A felelősséget nem vitatom, hogy a munkakörrel jár, de amikor vita van arról, hogy valójában ki használta az adott accountot, akor azért elég kínos tud lenni, ha kiderül (_ha_ egyáltalánkiderül), hogy ugyan a kulcs a Pistáé, de a Jóska gépéről ment be vele Géza, mert... (Volt ilyen esettanulmány a kezemben - na azóta pláne nem komálom a csak kulcsos auth megoldást - legyen jelszó, legyen nevesítve a logban, hogy ki lépett be, és ki kért és kapott emelt szintű jogosultságot, és azzal milyen tevékenységet végzett.

Ha van központosított user management, az jó - de a root authorized_keys fájlja/információja nem biztos, hogy jó, ha onnan "érkezik". Szerintem. De mindenki úgy kezeli a saját hozzáféréseit, ahogy azt az adott cég/szervezet szabályai előírják: ha kockázatartányosan elfogadható az, hogy ssh root@szamlavezetorendszer -i szamlavezetokulcsom.rsa, akkor tegyék úgy - én viszont ebben az esetben szerintem joggal remélem azt, hogy ilyen pénzintézettel nemlesz ügyfélként kapcsolatom soha, mert - engedtessék meg - de nem tarom megfelelőnek a biztonsági előírásaikat. (Ez is egy ok volt, hogy anno a cikibankot otthagytam, mint ügyfél: netbankban a kis- és nagybetűken nem különböztették meg, és ezt írásba is adták, és meg is cukrozták a taknyot, merthogy az ssl milyen biztonságot ad...)

> "kulcs ugyanis csak neki van meg" - de ezt bizonyítanod is kell, nem csak feltesszük, hogy csak ő birtokolja.

Jelszó esetén hogy bizonyítod hogy csak ő tudta? Mi akadályozza meg, hogy megossza? A kulcs lehet egy smartcard-on is, kvázi lemásolhatatlanul, ellentétben a jelszóval ami mindenképp megosztható. Szóval ez épp a jelszó ellen érv.

Nem írta, hogy smartcard-on van a kulcs... Ja,a  jelszó csak az ő tudtával osztható meg (keylogger és hasonlók kivételével), egy fájlt meg -ha csak nincs audit trail a fájlrendszer-műveletekről, hát hogy is mondjam csak... Nem biztos, hogy olyan nehéz észrevétlenül elvinni egy gépről.

Nálunk egyetlen friss security auditon sem akadt még fenn az ssh root login mindenkinek egyedi kulccsal, távoli loggolással, letiltott jelszavas authentikációval. Ellenben pl az, hogy minden fejlesztő tud sudozni egy project userre (pl. www-data) már volt gond.

Utoljára akkoriban rugóztak ezen, amikor a pingelhető szerver is kritikus biztonsági hibának számított. :)

+1, ugyanez nalunk is. Ahogy mondtam, a korabbiakra nezve, bankban dolgozom, igy pl MNB es tobb kulonbozo konyvvizsgaloi audit is 1-3 evente van, jol beallitott egyeb parameterek eseten semmi gond ezzel. 
 

Illetve jeleztem azt is, hogy a kerdesek csak technikai szempontbol erdekelnek, audit miatt kicsit sem, mar a fenti miatt is.

Igen, en tisztaban vagyok vele. Megis, miutan leirtam, hogy auditalt szerverekrol beszelunk, _de_ azzal kapcsolatban, amirol szo van, egyedul technikai szempontok erdekelnek csak, audit-megfelelesiek kicsit sem, megis majdhogynem kizarolag audit-szempontu kerdeseket tettel fel, amiket semmilyen tekintetben nem ereztem relevansnak. 

En leirom, hogy hogyan csinalom. Igazabol az igeny akkor merult fel,

amikor rajtam kivul meg egy ember is be akart lepni a szerverre, hogy ott tenylegesen dolgozhasson.

 

1. gepre csak ssh kulccsal lehet belepni (tehat ssh-n keresztul felh+jelszoval nem)

2. aki belep ssh-n keresztul, az automatan kap sudo jogot (kulcsos whitelist), a felhasznalonak nem kell jelszot beutni.

3. a felhasznalok nem tudnak lokalisan jelszoval belepni, nem is ismerik a jelszavukat.

4. ssh-n root login letiltva

 

Egyeduli hatulutoje, hogyha *egyszerre* vagyunk ketten belepve a szerverre, akkor aki masodjara lepett be, annak a

sudo kulcsos azonositas nem mukodik, azaz nem tud sudo parancsokat vegrehajtani. Ennek egyebkent egy pozitiv

hozomanya, hogy egyertelmu, hogy mikor ki sudo-zhatott.

 

Savazhattok.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( winben | 2020. 07. 27., h – 13:21 )

Bakker, annyit beszél már mindenki a dockerről, hogy a végén már tényleg rá fogok fanyalodni, hogy nekiüljek és utánanézzek mi az. :D

Btw igen, emiatt írtam azt, hogy boldogan elfogadok pull request-et ha valaki tud egy szép megoldást. Meg igen, azóta beláttam, hogy ritka tróger megoldás volt a ts fájlba rakni a config-ot, de ha most változtatok akkor százával fognak jönni a panaszok, hogy #ménemjó.

Paraméterbe rakni jelszót meg... hát... régebben tudta a nyomi digionline rendszer, hogy legalább md5 jelszavakat küldtem fel, most, mióta refaktorálták szigorúan plaintext-ben várja, szóval vannak helyzetek, amikor nem érdemes 123-nál bonyolultabb jelszót beállítani, tehát az olyan, mint jelszó szinte csak szimbolikus.

Na, ez itt az. :(