Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: hknmtt 14. 09. 2022, 07:43:12
-
Zaujimali by ma vase tipy na zabezpecenie dat pre aplikacie dostupne online (ie. webstranky, webservery a podobne) pre pripad hacknutia a prevencie odcudzenia citlivych dat.
Cize akceptujem, ze sa mi niekto dostane na server. Ide teda o to aby taky utocnik nemohol s datami ku ktorym sa dostane nic urobit.
Co mna osobne napada je:
- hashovat v db vsetko chulostive kde je nutne porovnavanie a overovanie dat(email, pristupove hesla..)
- sifrovat v db s AES to, kde je nutne aj citanie dat
- hesla(napriklad pre ten AES, alebo k mejlom, bankovym api,...) poskytnut pri spusteni cez premenne prostredia, ktore sa po spusteni aplikacie zmazu - niekto preferuje subory a do premennej dat cestu, iny zase priame pouzitie premennych
- hesla v pameti riesit cez nejake specialne kniznice, ktore zabrania ich ziskaniu z pamete alebo zo swap suboru
- pouzitie kompilovaneho jazyka aby sa utocnik nedostal k zdrojovym kodom(nie ze binarka nejde reverznut, ale to uz vyzaduje znacne usilie, takze preco nepridat utocnikovi robotu)
- zakaz vsetkych portov, okrem tych ktore pouziva aplikacia
- moznost SSH, bez hesla ale s certifikatom, iba cez terminal webhostignu(tzn lokalne)
- logy zabezpecit asi nepojde, urcite nie aktivne logy, takze tam asi treba prejst aplikaciu a vysledovat potencialne citlive udaje
- pouzitie kontajnerov pre zabranenie zmeny suborov v systeme(i ked do kontajneru sa da dostat, aspon pri reboote akekolvek zmeny zmiznu
Co dalej?
-
Já bych přidal ještě zabezpečení přístupu k serveru pořádným lockem a 2F ověřením totožnosti.
A těšíce se na výživnou debatu si beru popkorn.
-
Hardver/fyzicky aspekt tu neriesim. Ide len o softver.
-
odpojit server od site
-
Co jsi nezminil:
- volba spravne distribuce, ktera aktivne dba na bezpecnost
- provadet aktualizace
- sledovat CVE
Taky je moznost:
- provozovat alternativni instanci (heterogenni cluster), s jinou sadou zranitelnosti
- odlejvat na write-only journal data, takze se ti nikdy neprepisou a muzes urezat kompromitovanej konec
A hlavne:
- trenovat obnovu reseni a dat po prukaku
-
ad1: ak budete ukladat aj mail iba vo forme hashu, ako odoslete uzivatelovi novo vygenerovane heslo v pripade ze ho zabudne?
ad2: databazy mavaju svoje vlastne riesenia ako si sifrovat data interne v tabulkach, pouzival by som to, vlastne na kolene urobene riesenie pomocou AES moze byt sice tiez velmi ucinne, ale vykonovo to moze zabit pracu s databazou
ad3: ako ich chcete dostat do tich premennych, resp suborov pred startom aplikacie?
ad5: dobry bod, skuste este pridat enjaku obfuskaciu, rozne jazyky ako napr .net a java umoznuju lahku dekompilaciu kvoli CLR resp JVM runtimu
ad6: spravne
ad7: pozor aby ste sa nevymkli z vlastneho domu
ad8: ak bude dobre vyrieseny bod 2 a 3, dalo by sa to ukladat v db
ad9: myslite tym mat celu webovku v kontajnery? Pride mi to trochu tazkopadne a limitujuce, nikdy som to nevidel, mozno to ide, ale nebude proste len lepsie vytvorit na vsetko spojene s prevadzkou webu ineho uzivatela/skupinu a adekvatne osetrit jeho prava a kam vlastne moze sahat
-
ad3: ako ich chcete dostat do tich premennych, resp suborov pred startom aplikacie?
bud manualne pred spustenim aplikacie(subor/env). manalne pri spusteni aplikacie si ich aplikacia sama vypyta nez sa spusti. secretom cez kubernetes. jednorazovym tokenom cez nieco ako hashicorp vault... skratka ide o to aby tie udaje boli dostupne pri spusteni ako sucast konfiguracie aplikacie a potom sa zo systemu zmazali a ostlali bezat len v pameti aplikacie.
-
ad2: databazy mavaju svoje vlastne riesenia ako si sifrovat data interne v tabulkach, pouzival by som to, vlastne na kolene urobene riesenie pomocou AES moze byt sice tiez velmi ucinne, ale vykonovo to moze zabit pracu s databazou
Problem mysql/mariadb je ze pouzivaju iba 128bit(16byte) kluce plus nemaju moznost GCM. Co nemusi byt zle, ale zase AES je dnes plne podporovany priamo v CPU takze ci to sifruje aplikacia alebo db je vykonovo irelevantne. A riesit nejaku exoticku pokrocilejsiu db ma zmysel len pre dedikovane sifrovanie.
ad9: myslite tym mat celu webovku v kontajnery? Pride mi to trochu tazkopadne a limitujuce, nikdy som to nevidel, mozno to ide, ale nebude proste len lepsie vytvorit na vsetko spojene s prevadzkou webu ineho uzivatela/skupinu a adekvatne osetrit jeho prava a kam vlastne moze sahat
To je naprosto bezne. Ci ide o kompilovane aplikacie alebo bezne typu php alebo nodejs. Alebo snad dnes niekto este stale riesit webovky cez ftp? Akoze wordpress na 10 korunovom hostingu a podobne asi aj hej ale samozrejme o takych pripadoch sa tu nebavim. Riesim na mieru site aplikacie/weby/...
-
Já bych škrtnul všechny vámi uvedené body a soustředil bych se na to, aby k tomu hacknutí aplikace vůbec nedošlo. Se stejnými náklady to bude mít řádově lepší výsledky. V datech asi budete mít i něco jiného, než login/e-mail a heslo, které můžete zahashovat. A pokud chcete extra řešit bezpečnost přihlašovacích údajů, neřešte vůbec přihlašování sám a místo toho implementujte jen přihlášení přes externí služby (OpenID, Google, Facebook, …). Například řešení zapomenutého hesla je z hlediska bezpečnosti komplikovanější, než ukládání hashe hesla.
-
Na zabezpečení "z venka dovnitř" potřebuješ mít hlavně pořádný firewall, tím nemyslím že musí být drahý, ale který monitoruješ, který je konfigurovatelný a který hlavně umíš nastavit, toto je to nejdůležitější.
A musíš mít čas na sledování a vyhodnocení logů, ev. nějaký honeypot.
Ideál, pro nízké rozpočty, je pfsense.
Na data "uvnitř" je nejlepší ochrana záloha (GFS, 3-2-1, snapshot atd.)
Běžný prvky bezpečnosti jako hesla apod. považuji za samozřejmost a toto vůbec nemá cenu rozebírat.
Myslím si, že nějaká kouzla na úrovni DB a aplikace jsou spíše otázkou bezpečnosti pro napadení "zevnitř", tzn. důvěryhodným a plně autorizovaným uživatelem. A to je otázka spíše procesů, návrhu app. apod.
-
Já bych škrtnul všechny vámi uvedené body a soustředil bych se na to, aby k tomu hacknutí aplikace vůbec nedošlo
Tak tak. Mám totiž neodbytný pocit, že pokud se tam někdo dostane, tak si může dělat co chce a klíčové je ,aby se tam nedostal.
V tom seznamu sev druhé polovině do toho pletou body, které vlastně řeší, aby se tam nikdo nedostal.
Ale i tak myslím že by stálo se zaobírat se čitelností dat, resp. šifrováním (takové to rozšifrování na bootu - na rootu o tom byla série 3článků asi max. rok stará něco jako "plně zabezpečený boot/debian"), . Nejdeo (snad samozřejmé hashování heslel, což mimo jiné není šifrování), ale o prostá data na sarveru (uložené maily na mailserveru, html stránky), která jsou uložená v storage. Aby se je nemohl jednoduše číst kdokoli z hostingové společnosti (tedy nevím jak a zda to jde řešit na web-hostingu, teď jsem myslel vps)
-
Na zabezpečení "z venka dovnitř" potřebuješ mít hlavně pořádný firewall, tím nemyslím že musí být drahý, ale který monitoruješ, který je konfigurovatelný a který hlavně umíš nastavit, toto je to nejdůležitější.
Tím myslíš jako WAF co bude heuristicky chytat pokusy o hacknutí té webové aplikace nebo jak?
-
Já bych škrtnul všechny vámi uvedené body a soustředil bych se na to, aby k tomu hacknutí aplikace vůbec nedošlo
Prave o to ide ze co ked sa tam niekto dostane. Preto riesim sifrovanie a hashovanie dat v db a uchovanie desifrovacich hesiel iba v pameti aplikacie. Cize ked sa tam niekto dostane a vytiahne db alebo logy tak relane s tymi datami nezmoze nic.
-
Myslím, že pokud to hackne trochu šikovně, dostane se i k těm klíčům v paměti a celé šifrování bude k ničemu.
-
Na zabezpečení "z venka dovnitř" potřebuješ mít hlavně pořádný firewall, tím nemyslím že musí být drahý, ale který monitoruješ, který je konfigurovatelný a který hlavně umíš nastavit, toto je to nejdůležitější.
A musíš mít čas na sledování a vyhodnocení logů, ev. nějaký honeypot.
Ideál, pro nízké rozpočty, je pfsense.
Na data "uvnitř" je nejlepší ochrana záloha (GFS, 3-2-1, snapshot atd.)
Běžný prvky bezpečnosti jako hesla apod. považuji za samozřejmost a toto vůbec nemá cenu rozebírat.
Myslím si, že nějaká kouzla na úrovni DB a aplikace jsou spíše otázkou bezpečnosti pro napadení "zevnitř", tzn. důvěryhodným a plně autorizovaným uživatelem. A to je otázka spíše procesů, návrhu app. apod.
Záleží na tom, co myslíte „kouzly na úrovni aplikace“.
Hlavně je potřeba mít bezpečnou aplikaci. Tj. aplikace musí kontrolovat oprávnění, veškeré kontroly provádět na backendu (i když je třeba stejná kontrola v klientovi). Musí pracovat se strukturovanými daty, pokud je to alespoň trochu možné (binding proměnných v SQL dotazech, tam je to bez diskuse; používat DOM pro generování HTML výstupu, pokud to jde); pokud to není možné, tak alespoň používat správné escapování (např. to HTML, když ho nejde generovat ze strukturovaných dat). Používat konstrukce, framework nebo ideálně jazyk, který brání určitým typům chyb (třeba automatickou správu paměti, která brání chybám buffer overflow).
Dobré je mít na to testy, to bych nazval jedenapůltou vrstvou zabezpečení.
Aplikační firewall (např. WAF pro webové aplikace) je až druhá, volitelná vrstva zabezpečení – a rozhodně na ni nelze spoléhat, pokud máte díry ve vrstvě první. Pokud se jedná o web, pak bych asi ještě jako vrstvu 1,9 zařadil pozapínání různých bezpečnostních funkcí prohlížečů pomocí hlaviček. Oproti WAF je extrémně snadné to nastavit a používat; když to jednou nastavíte, je extrémně nízká pravděpodobnost false-positive vyhodnocení (což o WAF rozhodně neplatí) a o případné chybě se tak můžete dozvědět brzy.
Pokud je to one-man show, po té, co budete mít pořádně první krok, už nebudete mít čas ani prostředky řešit druhý krok (aplikační firewall). Řešit ochranu dat v případě, že se útočník už dostane do aplikace, by byl až třetí krok – a rozhodně nemá smysl se tím zabývat před tím, než budete mít vyřešené kroky 1 (včetně 1,5 a 1,9) a 2. Jedinou výjimkou je hashování hesel – to se nedělá kvůli bezpečnosti, ale kvůli PR. Prostě kdyby vám hesla utekla a zjistilo se, že jste je nehashoval, budete mít ostudu. Že je to z hlediska bezpečnosti jedno, protože chyba je v tom, že prohlížeč vůbec uživatelské heslo někomu vydá, to nikoho nezajímá. Zároveň to hashování hesel je triviální udělat, zejména když se nebudete snažit vynalézat kolo. Když použijete nějakou funkci pro hashování hesel (Argon2, Scrypt, PbKDF2 – na cokoli z toho použít už hotovou knihovnu, která bude používat i sůl) a hesla vám uniknou, nikdo vám nic neřekne. (Já bych ukládání hesel řešil jinak, protože když už se to dělá, snažil bych se řešit hlavně tu bezpečnost, ne to dělat jen na efekt – ale nedoporučuju to ostatním, moje doporučení je udělat to na efekt tak, jak je to doporučováno bezpečnostními odborníky.)
-
Prave o to ide ze co ked sa tam niekto dostane. Preto riesim sifrovanie a hashovanie dat v db a uchovanie desifrovacich hesiel iba v pameti aplikacie. Cize ked sa tam niekto dostane a vytiahne db alebo logy tak relane s tymi datami nezmoze nic.
Je otázka, co řešíte. Zda přístup k datům třeba od poskytovatele VPS nebo kdyby se někdo dostal k fyzickému disku. Pak ale neřešte šifrování v aplikaci, ale na úrovni databáze nebo souborového systému.
Nebo řešíte, že vám někdo hackne vaši aplikaci. Pak je zbytečné řešit nějaké šifrování dat na úrovni aplikace nebo databáze, protože ten útočník ovládá vaši aplikaci a může dělat vše, co může dělat ta aplikace – tedy má přístup ke všem datům. (Existují dvě možnosti, jak se tomu bránit, ale ani jedna se běžně nepoužívá a nemá smysl to tu řešit.)
-
Jedinou výjimkou je hashování hesel – to se nedělá kvůli bezpečnosti, ale kvůli PR. Prostě kdyby vám hesla utekla a zjistilo se, že jste je nehashoval, budete mít ostudu.
Kdybyste to nenapsal zrovna vy, myslel bych si, že si tu někdo dělá škodolibou legraci. Výrok, že se hesla hashují kvůli PR, je přinejmenším kandidát na myšlenku roku.
-
Kdybyste to nenapsal zrovna vy, myslel bych si, že si tu někdo dělá škodolibou legraci. Výrok, že se hesla hashují kvůli PR, je přinejmenším kandidát na myšlenku roku.
Heslo se zabezpečuje tak, že ho nikdo jiný kromě mne nesmí znát. Když heslo někomu prozradím, třeba provozovateli serveru, bezpečnost klesla asi tak na jednu promile. Nemám pod kontrolou, co se s tím heslem děje.
Jako provozovatel jsem v situaci, kdy mi někdo prozradil heslo, což je ten největší bezpečnostní problém. Ale OK, uživatel neměl jinou možnost, takže mi to heslo prozradil a já se s tím musím nějak popasovat. Co se může stát při zneužití hesla? Jedna možnost je, že uživatel to samé heslo nikde jinde nepoužívá - takže heslo lze zneužít jenom v té mé službě. To ale jako provozovatel můžu i bez hesla. Nebo uživatel to samé heslo používá i jinde - takže mi dobrovolně odevzdal své heslo k jiným účtům, nejspíš i k e-mailu, a e-mail mi určitě také prozradil. No to jsou ale zásadní bezpečnostní chyby uživatele. Ale když už mi to heslo uživatel posílá, může se s ním dít spousta věcí. Můžu ho spolu s e-mailem záměrně ukládat a pak databázi prodat. Může být v aplikaci chyba, která hesla někam prozradí. Může třeba někdo do kódu aplikace propašovat něco, co posbírá hesla a někam je pošle, může dokonce posbírat jenom nějaká zajímavá hesla, aby se snížila pravděpodobnost odhalení. Nebo také mohou uniknout hesla uložená v databázi.
Všichni se soustředí jenom na ten poslední bod, neřeší všechny ostatní. Neřeší ty bezpečnostní průšvihy, že heslo uživatele opouští prohlížeč (s čímž uživatel nic dělat nemůže) ani že uživatel používá stejné heslo na více místech (s čímž uživatel něco dělat může). Když bude uživatel používat unikátní hesla, bude ho na úniku dat zajímat heslo nejméně, protože jeho heslo v těch datech bude ten nejméně zajímavý údaj.
Ano, trvám na tom, že hashování hesel je jenom PR pro případ, že by hesla unikla. S reálnou bezpečností to nemá nic společného, protože jako uživatel nevíte vůbec nic o tom, jak provozovatel serveru s hesly zachází - a hashování hesel rozhodně nestačí.
-
Jedna možnost je, že uživatel to samé heslo nikde jinde nepoužívá - takže heslo lze zneužít jenom v té mé službě. To ale jako provozovatel můžu i bez hesla.
Můžou nastat situace kdy to pomůže - může vám uniknout stará nekompletní záloha (a útočník si z ní přečte hesla a přihlásí se), útočník může získat nějakou chybou readonly přístup a takhle si hned přečte heslo a přihlásí se, může uniknout image vaší VPS od poskytovatele - a pak neplatí, že si útočník do vaší aplikace mohl přidat kód, který heslo tajně uloží ještě než se zahashuje, a měsíc počkat až posbírá dostatek účtů.
Všichni se soustředí jenom na ten poslední bod, neřeší všechny ostatní.
Já bych ty ostatní rád řešil, ale co mám asi jako dělat? Vyrobit 30 atomových bomb a potom je odpalovat ve velkých městech dokud Mozilla a Google neimplementují kryptograficky správný způsob přihlašování a průmysl na ně nepřejde? Píšete opakovaně "s čímž uživatel nic dělat nemůže", ale copak jako provozovatel Rootu nebo nějakého malého eshopu s tím něco dělat můžu?
-
Můžou nastat situace kdy to pomůže
Ano, můžou. To ale neznamená, že je dobrý nápad to dělat.
Já bych ty ostatní rád řešil, ale co mám asi jako dělat? Vyrobit 30 atomových bomb a potom je odpalovat ve velkých městech dokud Mozilla a Google neimplementují kryptograficky správný způsob přihlašování a průmysl na ně nepřejde? Píšete opakovaně "s čímž uživatel nic dělat nemůže", ale copak jako provozovatel Rootu nebo nějakého malého eshopu s tím něco dělat můžu?
Ani tohle ale není důvod, proč dělat něco jiného. Uživatel s tím každopádně může dělat alespoň to, že nebude používat jedno heslo pro více služeb.
-
Ano, můžou. To ale neznamená, že je dobrý nápad to dělat.
Proč není dobrý nápad to dělat? Přijde mi, že to přináší minimum starostí navíc, a občas to pomůže (byť ne úplně často).
-
Ano, můžou. To ale neznamená, že je dobrý nápad to dělat.
Proč není dobrý nápad to dělat? Přijde mi, že to přináší minimum starostí navíc, a občas to pomůže (byť ne úplně často).
Bylo to myšleno tak, že to, že to někdy může pomoci, není dostatečný důvod, proč to dělat. Někdy může pomoci úplně cokoli.
Jinak je to jak píšete - prakticky ničemu to neškodí (a v případech, kdy to škodí, je toho potřeba docela dost vědět a pak by se dotyčný na tohle neptal v diskusním fóru), implementace je docela jednoduchá, a ten PR efekt v případě úniku hesel je velmi významný. Takže za mne platí to samé, co v jiných oblastech - když moc nevíte, co děláte, je potřeba mít alespoň dobře ošetřené PR. Takže když nevíte, jak zacházet s hesly, zahashujte je jednou z těch třech funkcí, které jsem uváděl výše.