Zabezpeční dat na serveru pro případ hacknutí

hknmtt

Zabezpeční dat na serveru pro případ hacknutí
« kdy: 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?
« Poslední změna: 14. 09. 2022, 08:04:55 od Petr Krčmář »


Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #1 kdy: 14. 09. 2022, 08:41:01 »
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.
Gréta je nejlepší.

hknmtt

Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #2 kdy: 14. 09. 2022, 09:15:12 »
Hardver/fyzicky aspekt tu neriesim. Ide len o softver.

robin martinez

  • *****
  • 1 138
  • Have you hugged your toilet today?
    • Zobrazit profil
    • Null Storage
    • E-mail
Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #3 kdy: 14. 09. 2022, 09:22:29 »
odpojit server od site
One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man.

I do Linux, Hardware and spaghetti code in PHP, Python and JavaScript

RDa

  • *****
  • 2 465
    • Zobrazit profil
    • E-mail
Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #4 kdy: 14. 09. 2022, 09:35:37 »
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


Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #5 kdy: 14. 09. 2022, 09:44:45 »
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

hknmtt

Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #6 kdy: 14. 09. 2022, 10:26:31 »
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.

hknmtt

Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #7 kdy: 14. 09. 2022, 10:49:04 »
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/...

Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #8 kdy: 14. 09. 2022, 10:50:47 »
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.

Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #9 kdy: 14. 09. 2022, 11:17:31 »
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.

Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #10 kdy: 14. 09. 2022, 14:13:40 »
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)

_Jenda

  • *****
  • 1 550
    • Zobrazit profil
    • https://jenda.hrach.eu/
    • E-mail
Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #11 kdy: 14. 09. 2022, 14:24:26 »
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?

hknmtt

Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #12 kdy: 14. 09. 2022, 16:18:38 »
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.

Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #13 kdy: 14. 09. 2022, 16:33:09 »
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.

Re:Zabezpeční dat na serveru pro případ hacknutí
« Odpověď #14 kdy: 14. 09. 2022, 16:40:12 »
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.)