Fórum Root.cz
Hlavní témata => Server => Téma založeno: Darkhunter 14. 12. 2016, 23:11:30
-
Ahoj,
potřeboval bych radu ohledně VPNky. Klienti ode mě dostávají raspberry a já potřebuju mít k nim přístup, takže je připojuju na svůj openvpn server.
Zatím to mám tak, že umožňuju multiple connect z jednoho certiifkátu.
Mohl bych pro každého klienta vygenerovat nový, ale zabere mi to čas a vpnka se musí reloadovat že?
Klienti nemají na linux přístup. Samozřejmě se to dá nějak hacknout, ale nemyslím si, že je tam bezpečností riziko.
Asi bych ale potřeboval, aby klientovi občas expiroval ceritifkát.
Jaké je pro mě asi nejlepší řešení?
-
Zatím to mám tak, že umožňuju multiple connect z jednoho certiifkátu.
To je špatné, protože 1) nejde neposlušného klienta revokovat, 2) nejde přes client-config-directory nastavit pevná IP adresa klientovi, takže se ti budou špatně na první pohled rozlišovat.
Mohl bych pro každého klienta vygenerovat nový, ale zabere mi to čas
Na mém 4 roky starém notebooku trvá vystavení certifikátu 6 milisekund.
a vpnka se musí reloadovat že?
Podle mě ne. VPNka ví jaké CA věřit a klient jí poskytne certifikát podepsaný touto CA. VPNka ho nikdy předtím nemusela vidět a prostě jen ověří, že je podepsaný (+ případně musí zkontrolovat revokaci, tam už se to možná bez reloadu neobejde).
-
a vpnka se musí reloadovat že?
Podle mě ne. VPNka ví jaké CA věřit a klient jí poskytne certifikát podepsaný touto CA. VPNka ho nikdy předtím nemusela vidět a prostě jen ověří, že je podepsaný (+ případně musí zkontrolovat revokaci, tam už se to možná bez reloadu neobejde).
Ani pri revokácii sa nemusí VPNka zakaždým reloadovať. V konfiguračnom súbore je nastavená len cesta na CRL, pri revokovaní certifikátu treba akurát vygenerovať nový CRL súbor a ten nakopírovať do príslušnej cesty (konfigurácia VPN sa pritom nemení, teda nie je dôvod reloadovať). Server kontroluje pri každom pokuse klienta o pripojenie, či je daný certifikát revokovaný, alebo nie.
-
Zcela bez urážky, zdá se ti vhodné, aby někdo s takovými (ne)znalostmi o použité technologii řešil takový problém v produkci pro reálné zákazníky a navíc v takovém množství? Pokud se nepletu, je to zase nějaká EET supr čupr krabičkárna. Jsi připravenej za svoje stovky zákazníků platit Bábišce pokuty, až ti to někdo škaredě rozbije?
-
A není pro takovéto účely lepší autentizace jménem/heslem? Každý klient může mít svůj login, je to krásně přehledné (víte z logu, kdo je kdo, s jakou IP adresou) a pod kontrolou (nezaplatí? zablokuj, zaplatí? odblokuj).
-
A není pro takovéto účely lepší autentizace jménem/heslem? Každý klient může mít svůj login, je to krásně přehledné (víte z logu, kdo je kdo, s jakou IP adresou) a pod kontrolou (nezaplatí? zablokuj, zaplatí? odblokuj).
Takto bych to resil i já. neni potreba tolik certifikatu, staci jeden a dalsi overeni jmeno-heslo
-
Super, tak to funguje s two phase autorizací.
Jinak Tuxik nemyslím si, ež se v tom nevyznám. Pár let jsem dělal sysadmina. Jen se ptám na názory ostatních, jak by to vyřešili. Myslím, že k tomu to fórum tady slouží. BTW Babišce nic platit nebudu. Takhle to nefunguje. Zákazník si je zodpovědný sám za to, jaký přístroj na to pořídil. My se to snažíme vylazovat. Zatím to ještě ani neprodáváme.
-
A ještě jedna věc. Dal jsem si ifconfig-pool-persist a v ipp.txt má teď připojený klient jinou IP, než kterou skutečně má. Možná je to tím, že se mu změnilo common name.
-
Kolego, nic ve zlém, ale kurva přečti si dokumentaci než začneš nějakej produkt nabízet lidem. Dost neuvěřitelný, tohle. :-(
-
Tak ještě jsem neviděl nikoho číst celou openvpn dokumentaci a to jsem dělal ve firmách, které nabízely full solutions pro servery.
Kdybych měl číst celou dokumentaci ke každé library nebo každému programu, který pro svůj produkt používám, tak bych na to potřeboval tak sto životů....
-
Super, tak to funguje s two phase autorizací.
Jinak Tuxik nemyslím si, ež se v tom nevyznám. Pár let jsem dělal sysadmina. Jen se ptám na názory ostatních, jak by to vyřešili. Myslím, že k tomu to fórum tady slouží. BTW Babišce nic platit nebudu. Takhle to nefunguje. Zákazník si je zodpovědný sám za to, jaký přístroj na to pořídil. My se to snažíme vylazovat. Zatím to ještě ani neprodáváme.
Já neřekl, že nerozumíš ničemu, ale je jasné, že s openvpn moc zkušeností nemáš. A ano, zákazník si za to odpovídá sám, ale jde o pokuty až půl mega, takže počítej s tím, že když bude mít někdo kvůli tvému řešení problémy, pravděpodobně to skončí u soudu a líbit se ti to nebude. I kdyby jsi to ustál bez placení, s tímto podnikáním můžeš skončit. Nechci ti to úplně vymlouvat, jenom by možná nebylo od věci si k tomu něco nastudovat vlastníma silama, čímž se člověk většinou nejvíc naučí. Trošku z toho vyznívá "nejde o moje prachy, tak to kašlu a nějak to splácám". Já vím, Bábiška si to vymyslela blbě a finální specifikace byly celkem pozdě, takže to tak nějak museli splácat všichni, ale někteří nabízí i pojištění proti ztrátám, které by jejich řešení mohlo způsobit. Nevím, jak jsi zavedená firma a nechci to hodnotit, ale je mi až smutno, kolik nových firem vzniklo jen kvůli EET. Mimochodem, těch dotazů na bezpečnost (někdy i nesmyslných) už jsi tu měl víc, takže to není jen o neznalosti OVPN, ale spíš o neznalosti základních bezpečnostních principů. Takže nechci tě odradit, ale zamysli se pořádně, nejen, že i když si to nepřipouštíš, tak jde pravděpodobně i o tvoje peníze, ale hlavně jde o tvoji pověst a tu budeš případně získávat zpátky špatně. Na tvém místě bych trochu víc studoval a trochu míň se ptal a asi bych si být tebou najmul časem někoho na nějaký alespoň vzebrubný audit.
-
My jsme nevznikli kvůli EET. S kamarády jsme dělali na něčem, co usnadní chod hospod/obchodů atd už dávno předtím, tak nás prosím nehaž do stejného pytle.
Samozřejmě v tomhle máš pravdu a já se snažím zjistit co nejvíc to jde.
Přečetl jsem si spoustu věcí a vím, jak se vyvarovat tomu, aby zákazníkům systém nefungoval.
Strávil jsem na tom několik měsíců a snažil jsem se to vyřešit co nejlépe.
Ono s prací se toho ale moc nestíhá.
Audit stoprocentně si chci udělat, ale stojí kolem sto tisíc korun a ty bohužel teď nemám, ale chci na něj dát první peníze, co vyděláme.
-
Říkám, že nechci posuzovat, jak jsi, nebo nejsi zavedená firma a pokud už v oboru něco děláš, rozumím i tomu, že chceš přidat i EET, protože to k tomu prostě patří. Jinak teda jedna praktická rada... jestli jsi tou two phase autorizací myslel, že mají všichni stejný cert a k tomu jména a hesla, tak se na to vykašli. Certifikát vygeneruješ skriptem za pár vteřin i s přihlašovacími údaji a zvládne to i poučená studenta sluníčkářství na brigádě, která by to prodávala někde ve stánku na náměstí. Pokud budou mít všichni jeden cert a různá jména a hesla, tak to není two phase, protože stačí hacknout jednu krabičku (což jsi sám uznal, že nevylučuješ) a když už si někdo ten jeden certifikát vytáhne, pro všechny ostatní účty už stačí "jen hádat jméno a heslo".
-
Samozřejmě. To je jasné. Ale pochybuji, že by to někdo chtěl hackovat. A když už, tak je tam spoustu dalších zranitelných věcí...
Jakmile má zákazník krabičku u sebe, tak pokud se vyzná, tak se tam dostane v jakémkoliv případě.
Já se to snažím zabezpečit, aby se tam nedostalo těch 99,5% lidí.
-
Samozřejmě. To je jasné. Ale pochybuji, že by to někdo chtěl hackovat. A když už, tak je tam spoustu dalších zranitelných věcí...
Moc často sem nepřispívám, ale když vidím tvoje odpovědi nedá mi to.
Bez urážky, ale pokud tvrdíš, že v tom dělaš několik let tak o tom víš pořád kulový. S tímto přístupem do toho nechoď a argument že pochybuješ :) si snad děláš srandu?
Jak jsi sám zmínil je to nerizikovejší místo a podle toho se zařiď a nepochybuj.
-
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ě.
-
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.
-
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
- 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áš 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.
-
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í.
-
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 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 :)
-
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.
-
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. :D
-
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. :D
Tak to trochu popis, jaka db? Co znamena dotaz servru? Kazdej klienta ma vlastni table space? Vlastni credentials?
-
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.
-
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. :D
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
-
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?
-
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.
-
To je dobrý, že to je zdůrazněný v manuálu. Eště bys jim k tomu měl dodávat ceduli "Z technických důvodů zavřeno". ::) ;D
-
Jen se nenech od zdejších lopat odradit. Umí akorát kecat o tom, jak by se to mělo, ale nikdo z nich nic nedělá 8)
Jen tak dál!
-
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.
Ta pravděpodobnost je bohužel výrazně vyšší, než si myslíš. Stačí zakolísání napětí, všechno ti popadá a obzvláště adaptéry od levných routerů to bohužel až příliš často nedávají a odcházejí. 4G modem je samozřejmě částečně řešení, ale stejně nic moc. Ale tak ve výsledku proč ne. Stejně tak může odejít ta malina nebo její zdroj a stejně nemá nic. Ještě bych možná umožnil doplnit instalaci i USBčkovým wifiovátkem. Sdílení netu přes wifi umí skoro každej chytrej foun a i když někdo nemá na to tarif, jeho zprovoznění je otázkou jednoho telefonátu operátorovi. Asi pořád lepší, než zavírat hospodu a navíc wifi čurapajdl do USB stojí asi 150Kč, což je výrazně míň, než 4G modem.
-
Jen se nenech od zdejších lopat odradit. Umí akorát kecat o tom, jak by se to mělo, ale nikdo z nich nic nedělá 8)
Jen tak dál!
Ano, to byla rozhodně nejkonstruktivnější rada celého tématu.
Javamen to právě vysvětlil, doporučuji lock, již není co dodat.
-
On za něčím jde a dává do toho všechno. Vy akorát kecáte, jak to dělat správně a sami stejně nic neumíte. Trochu pochopení.
Máš tu hromadu blbců, kteří se ptají na úplné píčoviny a nikdo jim nic neřekne. Ale tohle je asi zajímavé, protože ohrožuje lopaťáckou pohodičku a něco dělá.
-
Ta pravděpodobnost je bohužel výrazně vyšší, než si myslíš. Stačí zakolísání napětí, všechno ti popadá a obzvláště adaptéry od levných routerů to bohužel až příliš často nedávají a odcházejí.
On nemusí ani odejít adaptér. Stačí, když ta malina bootuje rychlejc než router a naběhne taky hovno. (Nevím, jak tam má řešený timeouty.) Nicméně teda principiálně mít zařízení, ze kterýho nedostanu data, když dodavatel nefunguje nebo když mu prdne v kouli nebo když mu to někdo hackne a klíče smaže, tak to je teda zákazníkův sen. Zlatej zrecyklovanej Kellnerův tablet s Androidem.
-
On za něčím jde a dává do toho všechno. Vy akorát kecáte, jak to dělat správně a sami stejně nic neumíte. Trochu pochopení.
Máš tu hromadu blbců, kteří se ptají na úplné píčoviny a nikdo jim nic neřekne. Ale tohle je asi zajímavé, protože ohrožuje lopaťáckou pohodičku a něco dělá.
Dovol mi připomenout, že sem přišel pro radu, kterou dostal a evidentně ho zajímají názory ostatních. Ale nebudu kazit další vlákno nesmyslnou debatou s javadebilem, který nechápe ani jednoduché věty. Jestli chceš dokázat, že něco umíš, tak mu něco konstruktivního navrhni. Případně dokaž, že něco umíš. A to o vlákno vedle, kde jsi zatím ukázal jen to, že jsi ani javu, ani nic jinýho z IT neviděl ani z rychlíku. Tím s tebou zde končím.
-
Ale nebudu kazit další vlákno nesmyslnou debatou s javadebilem, který nechápe ani jednoduché věty. Jestli chceš dokázat, že něco umíš, tak mu něco konstruktivního navrhni. Případně dokaž, že něco umíš.
To je stejnej dement jako zabanovaná "semestrálka", mám občas podezření, že to snad je von.
-
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.
Dle toho co pises usuzuji ze planujes uchovavat data pouze v rpi na sd karte a neplanujes zadne pravidelne zalohovani dat. Tohle je dle me velmi blby napad, protoze sd karty jsou znamy svoji "spolehlivosti". Ber v uvahu ze planujes uchovavat zaznamy o EET na stovkach klientu, nedivil bych se kdybys nekolikrat do roka resil, ze se karta sesypala a zakaznik prisel o data(sifrovani zachranu dat neusnadni). Ja bych doporucil, aby vsechny dulezita data byly ulozeny na serveru, na rpi drzet data maximalne vygenerovane v offline rezimu, ktere se po pripojeni odeslou na server.
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.
Kdyz ukradnu rpi, pripojim si modul k netu a server pote rozsifruje lokalni db. Ano muzes povolit pripojeni jen z urcitych ip, ale stejne v hospody/restartace... maji wifi pro navstevniky + beztak budou mit stejnou IP jak pulka mesta (slava NATU). Dalsi moznost je zablokovat ukradeny modul na serveru, coz by pomohlo pouze v pripade ze zlodej se bude snazit stahnout data pote co zakaznik nahlasi kradez. Pokud ziskam fyzicky pristup k modulu(nebo se na nej pripojim treba pres ssh) tak je ti sifrovani db k nicemu.
Dobra vec na sifrovani je ze si tam muzes dat nalepku ze pouzis sifrovani, ktere hrubou silou prolomis za xxx let. Pokud to chces stejne sifrovat vygeneruj klic treba z id hw, na bezpecnosti to neubere a rpi bude fungovat i bez pocatecni komunikace se serverem v offline modu.
Nabyvam dojmu ze neplanujes sifrovat z duvodu bezpecnosti, ale abys mohl snadneji vymahat penize za licenci. Nezaplatil -> nerozsifruji.
Co se tyce vpn, doporucil bych udelat dve.
Default - sem se budou pripojovat vsechny nove nahrane rpi, vsechny moduly budou mit spolecny certifikat.
Product - sem se budou pripojovat vsechny rpi prirazene k zakazniku, kazdy ma vlastni certifikat.
Umozni ti to mit jeden image pro nahravani modulu. Evidenci modulu uz stejne provadis v nejake aplikaci, tak k tomu staci pripojit nejaky skript co vygeneruje certifikaty, nahraje je na modul.
-
Když tak sleduji, jak se každý sere do pokladen (naprogramovat kasu zvládne každá lopata i javamen), ale ostrý provoz jim nic neříká, už se těším, jak uživatelé po čase zapláčí ... (8 let jsem programoval kasy pro zahraniční firmu - info pro rejpaly)
-
Takže znova.
Děkuju Javamanovi za podporu.
Tuxik se snaží poradit a já mu za to děkuju.
Data nejsou jen na raspberry. Člověk si může připlatit za replikacia a každodenní zálohu databáze.
A nevím, kde je rozdíl oproti Kellnerovo tabletu. Taky jim na serverech může rupnout v kouli a zákazníci nemají pak nic z jejich dat. Myslím, že se mě snažíš jen hejtovat. Buď trochu konstruktivnější Lol Phirae.
stan:
Jak se pak dostaneš do ukradeného raspberry?
Pokud vezmeš sd kartu a chrootneš jí, tak jí server neautorizuje a neunlockne db partition, protože tam nebudou všechna data z rpi, která k autoirzaci potřebuješ jako seriová čísla hardwaru a tak.
Šifrování je tam samozřejmě z obou důvodů. Mám kamaráda, co právě dělal pro storyous a říkal, že lidé pak licence ochcávali i po vypršení, proto tam ten lock taky je.
Nobody: Ano, přiznávám, že s pokladnami nejsem ostřílený matador a přiznávám, že se provozu bojím. Proto ale taky testuji v pěti hospodách ostrý provoz měsíc před tím, než to vydám.
A pokladny jsem ani dělat nechtěl, ale Babi.sh nařídil, že musí být eet, tkaže náš systém nemá šanci uspět, když každý bude mít pokladnu. Náš systém byl dělaný hlavně pro uzávěrku a automatizaci skladu...
A ano jsem mladý a skoro bez zkušeností, co se snaží prorazit mezi firmama s miliardovýma investicema a chápu, že to vypadá nedůvěryhodně, ale náš tým na tom pracuje každý den vesměs 16 hodin, takže jakékoliv urážky nevnímám, protože narozdíl od člověka, co mě uráží, vím, že se snažím aspoň něco dělat.
-
Jak se pak dostaneš do ukradeného raspberry?
Pokud vezmeš sd kartu a chrootneš jí, tak jí server neautorizuje a neunlockne db partition, protože tam nebudou všechna data z rpi, která k autoirzaci potřebuješ jako seriová čísla hardwaru a tak.
Nabízím za 50 kKč standardní pentest nebo za 100 kKč extended pentest (evil SD karta měnící po bootu sektory, modifikace zavaděče aby tajně povolil JTAG, pokus o coldboot). jenda (a) hrach.eu, PGP F0192F8E6527282E. Platba jen při úspěšném prostřelení!
-
Doporučuju používat SD kartu jen na bootování. Jak se na ní bude něco pravidelně zapisovat, tak většinou dřív nebo pozdějc chcípne a to většinou tak, že totálně (nejde z ní ani číst).
Taky děláme pro zákazníky řešení postavené na RPi. První půlrok čistě s SD kartou. Pak se začaly množit problémy s mrtvýma kartama. Takže se přešlo na řešení se třema úložištěma a to jede už přes 3 roky bez jediné reklamace.
Celej systém je kompletně na USB disku. Na SD je pouze /boot kde je jádru předaný parametr, který říká že root je na /dev/ten_disk. Třetí médium je fleška, na kterou se pro jistotu denně zálohuje db. Důležitý je vést napájení toho disku samostatným přívodem, protože USB RPička to neutáhne.
-
Co jste pouzivali za SD karty a kolik jste meli iops?
btw. ovpn pod uzivatelem nobody je to samy jako pod uzivatelem whatever, nobody je "default", jenze kdyz by sis pod nim pustil jeste apache tak se dostanes nejen k souborum co vlastni ovpn, ale i k tem co patri apachi nebo necemu jinymu.
Ja si myslim, ze tam chlapec nebude potrebovat ani hesla a budou stacit certifikaty pro jednotlivy klienty s tim ze max revokne. client-to-client se vypne a defakto ani nepotrebuje routovat celej trafic pres server (neposkytuje vpn branu). Kdyz by nekdo ukradnul cert, tak pokud bude zarizeni na siti, tak bude kolidovat, coz se projevi a nekde to zacne rvat.
-
chalani, dovolte postreh zo slovenska kde miernejsia verzia EET uz nejaky rok funguje (neni online, namiesto toho mame fiskalnu pamat). servisujeme riesenie kde je pouzita SD karta pre zaznam zurnalu (textovy format, vsetky bloky + nejaka binarka), z asi 150 pokladni raz do mesiaca odide SDkarta tak, ze data nejdu vycitat, obcas idu vycitat aspon data, obcas je poskodeny zurnal z jedneho dna.
o spolahlivosti SD kariet som si nemyslel vela, ale co sa skutocne deje cloveka prekvapi. a v prvom rade ma problem podnikatel. takze za mna SD karta ani na docasne zalohy, a uz vonkoncom nie nic komplikovanejsie ako textovy format citatelny "volnym okom" ziadne binarky ziadne bloby nedajboze databazy.
-
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.
Hele jak můžeš buffovat FIK? Ten ti přece vygeneruje FÚ nebo to funguje jinak než sem si celou dobu myslel? A když je výpadek internetu tak bys měl tisknout PKP a po výpadku odeslat. Takže pokud výpadek není delší jak 48h tak by to neměl být problem.
Nemyslím to jako hejt ale jako dotaz...
-
Nemůžeš. Máš pravdu. Já měl na EET externistu, protože SOAP je pro mě totální shit a když jsem si četl naposled EET specifikace, tak tam bylo něco takového jako že si předem můžeš stáhnout zásobu těch kódů, které pak tiskneš na účtenku a pošleš to na MF do 48 hodin.
-
také bych důrazně varoval před SD kartami u rpi, provozujeme v jednom projektu 200 ks rpi, z počátku každý týden (po asi 4 měsících) začala umírat jedna sd karta, po několika iteracích jsme skončili u SLC karet s ECC za 80 USD kus, vyrábí je třeba innodisk nebo apacer.
Přitom průměrný zápis byl 750b/s a zapisovali jsme každých 5s, ty běžné foťákové prostě tohle nezvládají.
-
V našem případě se zapisuje pravidelně každých 15 minut. Zapisovaných dat je průměrně 10kB.
Přešlo se na ty externí USB disky. Třeba na alze 250GB za 999,- Kč plus rozdvojovací USB kabel kvůli přívodu napájení k disku.
Toto řešení má sice výhodu nižší ceny a velkého místa na disku, ale je pravda, že to není tak elegantní jako vaše řešení se SLC kartami. Asi je také vyzkouším. Díky za tip.
-
Díky moc za info. Už to řeším. Ale přemýšlím, že klasické flash disky asi nevydrží o moc déle než SD karty?
-
Fíha, tak za 4GB chtějí už přes 3k Kč...To už je moc...Takže spíš usb disk nebo flashka...
-
Něco jako tohle: http://www.k24.cz/product/171527/Mach_Xtreme_ES_SLC_8GB_USB_3_0_140_MB_s_60_MB_s.html + sd karta v ro módu.