OpenVPN pro stovky klientů

[Tuxik]

Ne, ne, ne. Nikdy neříkej, že odrbáváš bezpečnost s odůvodněním, že to nikdo nebude hackovat. Jasně, pokud je fyzický přístup, vždycky se najde možnost, jak to prolomit, ale můžeš to dostat až téměř do stavu, kdy to bude buď o nějaké 0day, s čímž toho moc nenaděláš, nebo to může být třeba o vyčítání paměti ze zapnutého zařízení. V tomto případě je nepravděpodobné, že bude někdo s potřebnou technologií mít zájem to hackovat, navíc tomu stejně nezabráníš, maximálně bys musel mít specializovaný HW, ale to je jiná liga. Ano, nemáš na vývoj 20 let, potřebuješ to mít hotový relativně rychle, protože jinak si to můžeš strčit třeba do šuplíku, ale všechno, kde vidíš možnost pro zlepšení si poctivě zapisuj a vracej se k tomu. Ale zase pozor, neznamená to vymýšlet blbosti a různé obfuskace. Security through obscurity není nikdy opravdové zabezpečení, jen zábava pro útočníka navíc. A pořád dokola si opakuj: Když to moc podělám, už si ani neškrtnu a jako bonus k tomu tím můžu zničit životy nevinných lidí. Přece jde jen o prachy a ty jsou vždy až na prvním místě.

[Reklama]

[Darkhunter]

Já nic neodrbávám. To jsem nikde nenapsal. Snažím se řešit bezpečnost pořád.
Ale také musím řešit features, jinak bezpečnost budu řešit do konce života a nikdy to nevydám.
A opravdu nemám peníze na člověka s daleko většíma zkušenostma, než mám já.
Ach jo. Já vás chápu, ale vy asi nechápete mě. Je nás na to pět a já to všechno řídím, dělám marketing, deployment, linux a tunu dalších věcí.
Ostatní pracují na podíl a bohužel jsem nesehnal linux člověka za podíl.
Jinak ještě nic nevydáváme a máme pár hospod na testování. Až po tom, co to měsíc bude v pořádku, to chcem vydat.
Nechci nic podcenit. Nechci, aby někomu něco nefungovalo. Nechci hned zkrachovat. Bezpečnost především.

[koss43]

Něco podobného už jsem v praxi řešil, jednalo se o stovky openvpn zařízení připojených k serveru, udržet v tom pořádek je fuška, a věř mi, je potřeba mít nějaký adresní plán a řešit certifikáty, jinak se v tom ztratíš.

Důležité je mít 1 VPN server s 1 certifikátem, ke kterému je větší množství klientů. V žádném případě nepouštěj 1 openvpns server pro 1 klient, to je dlouhodobě smrt to mít na 1.000 portech s 1.000 spuštěnými servery.

Další věc je generování klientských certifikátů. Důležité je mít 1 CA autoritu, dělá se ta chyba, že se pro každý certifikát generuje nová CA, což trvá dlouho a opět, je to nepřehledné.

Další věc je, že server, kde to generuješ, tak musí mít solidní generátor náhodných čísel, jinak to bude trvat dlouho, zejména pokud je server virtuální mašina (je tam malá HW entropie). Na linux se dají sehnat démoni pro generování entropie třeba ze síťového provozu, více zde - https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Co je ovšem nejdůležitější je přehled. Doporučuji pro generování, instalaci a správu certifikátů používat konfigurační management jako Ansible. Človek si nastaví nějaký yaml soubor, třeba

Kód: [Vybrat]

- clients:
  - name: machine1
    desc: Babišova drůběžářská
    vpn_ip: 10.0.2.5
    install_ip: 192.168.1.1
  - name: machine2
    desc: Kalouskův zámek
    vpn_ip: 10.0.2.6
    install_ip: 192.168.1.1

Pak si uděláš, že zavoláš

Kód: [Vybrat]

ansible-playbook install_cert.yml --limit=machine1 a ono ti to automaticky vygeneruje a nainstaluje certifikát.

Ten playbook pro ansible samozřejmě musíš napsat. Značná výhoda je, že pak můžeš udržovat veškerou konfiguraci v yaml a kdykoliv ji případně změnit.

[Darkhunter]

Jo, o Ansible jsem přemýšlel, ale pak jsem zjistil, že spoustu mých věcí to neřeší a řeší to jen malou část věcí.

[ZAJDAN]

hosi nejsem zadna mega, ale ja to vidim jinak:
pokud háknu jeden box a budu mit certifikat s heslem, dalsi uz nepotrebuju, protoze jeden pristup uz mam, tak naco ty ostatni? Destination bude stale ten jeden stejny server

[Reklama]

[Darkhunter]

Tak to je jasné.
Však i kdyby byl certifikát pro každého klienta jiný, tak také stačí jeden a přístup budeš mít.

[#]

Tak to je jasné.
Však i kdyby byl certifikát pro každého klienta jiný, tak také stačí jeden a přístup budeš mít.

Tak snad ovpn jede pod uctem nobody, ne? Bavime se o dvou ruznych vecech, hack tech ostatnich krabicek a hack servru, oboje lze i pri kompromitaci jednoho klienta ztizit.

Tazatel si v kazdym pripade zadelava na hodne velkej problem o tom zadna

[Darkhunter]

A jakej problém? V čem problém?
Pokud se dostane do jednoho klienta, tak má přístup do VPNka a může útočit na server, ale ne na ostatní klienty. Je to jen client to server spojení.

[#]

hosi nejsem zadna mega, ale ja to vidim jinak:
pokud háknu jeden box a budu mit certifikat s heslem, dalsi uz nepotrebuju, protoze jeden pristup uz mam, tak naco ty ostatni? Destination bude stale ten jeden stejny server

Tak ale zalezi k cemu ti to bude, pokud se s tim jednim certem/heslem prihlasis rovnou na server nebo dostanes k raw db a tak, je celej design napicu, ze. Predpokladam, ze system je navrzen tak, ze pres ovpn se proste jen posilaji pres naky api udaje do toho trzebniho systemu, pokud ma kazdej klient vetsi pristup tak omg.

[Darkhunter]

Samozřejmě. Nic víc.
Klient nemá přístup na server.
Kažý server a každá aplikace v něm mají unikátní heslo.
Nejhorší, co se může stát, je, že se klient dostane do databáze na klientovi a to taky jen v případě, že už byl aktivován.
Partition s databází je šifrovaná LUKSem a odemyká se serverem po dotazu klienta na server.
Nad touto koncepcí jsem přemýšlel x měsíců, tak snad mi to nezkritizujete.

[#]

Partition s databází je šifrovaná LUKSem a odemyká se serverem po dotazu klienta na server.
Nad touto koncepcí jsem přemýšlel x měsíců, tak snad mi to nezkritizujete.

Tak to trochu popis, jaka db? Co znamena dotaz servru? Kazdej klienta ma vlastni table space? Vlastni credentials?

[Darkhunter]

Každý klient má databázi u sebe v raspberry.
Na serveru je akorát databáze s tím, jaké moduly zakoupil a kdy vyprší a dalšími identifikátory klienta.
U klienta mám skript, který se zavolá po nahození ovpn spojení.
Jedná se o get na api serveru.
Server z toho získá IP adresu a podle ní udělá dotaz do vlastní databáze.
Poté se přes ssh připojí na klienta a zjistí si, zda-li shoulasí sériové číslo, ip adresa, licence a pár dalších věcí.
Pokud všechno dopadlo správně, tak se otevře zašifrovaná partition a spustí se webové služby na raspberry.

[pruh]

Samozřejmě. Nic víc.
Klient nemá přístup na server.
Kažý server a každá aplikace v něm mají unikátní heslo.
Nejhorší, co se může stát, je, že se klient dostane do databáze na klientovi a to taky jen v případě, že už byl aktivován.
Partition s databází je šifrovaná LUKSem a odemyká se serverem po dotazu klienta na server.
Nad touto koncepcí jsem přemýšlel x měsíců, tak snad mi to nezkritizujete.

Hele me se to celkem libi, jestli chces napis mi mailah, muzem probrat nejaky veci co mas/chces. Mas na to 24h - 5kxesx+owud7pntmmr0@pokemail.net

[Tuxik]

Má to jednu obří mouchu. Není při zapnutí net, není Luks, není EET a hospodskej může maximálně vypisovat paragony a generovat v hlavě náhodný dlouhý Bureškódy, který bude poté opět opisovat do kasy, aby je odeslal. Nebo máš nějak zprovozněnou offline část aplikace s provizorní DB pro offline účtenky?

[Darkhunter]

Samozřejmě to funguje offline.
Internet to potřebuje jen po zapnutí.
Poté je LUKS otevřený a zamkne se to zase až po restartu.
Samozřejmě pokud dojde ke kolizi a internet spadne a oni při tom budou restartovat raspberry, tak to fungovat nebude do připojení internetu, ale ta pravděpodobnost je fakt minimální a v manuálu je to zdůrazněno.
Poté co se obnoví internet, se pomocí cronu odešlou účtenky do EET.(Máme implementovaný buffer, který skladuje FIK kódy pro možný výpadek internetu.)
A také nabízíme možnost 4G modemu jako záložního zdroje internetu.
Pořád máme oproti ostatním řešením tu výhodu, že když nejde u jejich řešení internet, tak jim nefunguje nic, protože mají všechno v cloudu, ale my máme databázi u nich v restauraci.
Samozřejmě nejsme jediní, kdo to tak má, ale většina je v cloudu.