Příspěvky

556

Distribuce / Re:Vygenerování souboru .cap v Kali 2020

« kdy: 29. 09. 2020, 13:42:25 »

a co to vypsalo? Jaký je návratový kód? Jaký přesně příkaz jsi spustil (v tvé ukázce vidím "-bssid", což je špatný přepínač), jaké frekvenci jsi zadal (proč nepoužíváš raději kanály)?

Víš, že airodump-ng nevytváří cap soubory, ale ivs jako výchozí (teda myslím)? Správný formát volíš přes --output-format.

Každopádně je vždy lepší, když si nejprve přečteš manuál, tyhle nástroje jsou většinou pro lidi, kteří ví co dělají.

557

Vývoj / Re:Zabezpečení mikroslužeb pomocí rolí a privilegií

« kdy: 28. 09. 2020, 18:47:35 »

zabezpečení by mělo být nedílnou součástí tvojí logické infrastruktury a nemělo by záležet na implementaci v jednotlivých mikroslužbách.

Osobně bych volil to co se mi již osvětčilo, kerberos (např. kerberos over ssl ala spnego) pro hlídání komunikace mezi jednotlivými službami a řešení primárně autentizace. Pro autorizace kerberos funguje jen částečně (na základně získávání SPN podle rolí), pro detailnější práva bych nasadil něco jako shiro v javě, v jiném prostředí třeba Apache Ranger.

Pak se dostaneš do situace, kdy služba kdykoliv je schopná navázat spojení s jinou mikroservisou, zároveň to implikuje jejích oprávnění.

Cest je ale spousta, tohle je jedna z možností, která se mi osvědčila a mám jí rád.

558

Server / Re:Zabezpečení databáze

« kdy: 27. 09. 2020, 10:46:29 »

databázi opravdu neotevírej ven do internetu a nepřistupuj z ní odjinud než z interních systémů a uzavřeného síťového prostředí (ideálně mít na localhostu u databáze přímo to api). Žádná z mainstream databází nemá dobře vyřešené zabezpečení, tak aby se mohla vystavit ven, to je stejné jako když ty data bude zveřejňovat.

Mít vlastní api (či aplikační rozhranní) u databáze je nutnost, jinak současný svět nefunguje. Jinak podlé tvé odpovědi nevypadá, že na to jdeš dobře a vem si na pomoc i někoho jiného, v případě úniku dat se zodpovědnost může na tebe přenést.

559

Sítě / Re:DNS hosting

« kdy: 27. 09. 2020, 10:41:06 »

Digital Ocean poskytuje nameservery (to asi myslíš tím DNS hostingem) zdarma, používám pro pár testovacích domén, má api, dobře se s tím pracuje a stačí to.

Jinak viz teď gransy, je lepší mít záložní NS u někoho jiného. Vlastní provoz veřejných DNS je problematický právě kvůli útokům a potřebné infrastruktuře.

560

Server / Re:Zabezpečení databáze

« kdy: 26. 09. 2020, 10:05:12 »

K věci: Od klienta k serveru musí být vše šifrované (např. https) a uživatel musí být ověřovaný dvoufaktorově. Nastavit rozumný timeout session. Nasadit nějaké penetrační testování proti běžným chybám jako sql injection apod. Dvoufaktor použít i pro přihlášení do databáze, pokud to databáze umí a připojuje se do ní přímo z pc uživatelů (tím tedy nemyslím webovou aplikaci). Důležité operace opět vázat na ověření. Tím se dostanete na úroveň zabezpečení internet bankingu a víc nebudete myslím potřebovat. Samozřejmě zabezpečit i server proti průniku zvenčí (to však není předmětem dotazu). Pokud na tom záleží, nechat si vše zkontrolovat nezávislou stranou (bezpečnostní audit) a zhodnotit, jaká škody by vznikly v různých scénářích. A na nějaké vlastní šifrování a dešifrování v aplikaci rovnou zapomeňte, to řeší šifrované kanály za vás.

Bokem: Další vrstva navíc v principu nic neřeší, potřebujete kontrolovat rizika a kvalitu, nikoli kvantitu.

PS: Jo a aby si data uživatelé nevykradli vzájemně, tak na to nasadit samozřejmě to row level security (nemám ale zkušenost).

Byl bych opatrný s tvrzením, že nasazení 2FA a https se dostane na úroveň online bankingu, to řeší bezpečnost proti útoků na uživatele, neřeší to ale bezpečnost tvého systému, tam zabezpečení stojí na několika pilířích v podobě procesu pro řízení rizik (vč. držení aktualizační politiky), SIEM jako realtime monitoringu, automatizovaných testů a code stylu (třeba v podobě owasp, spring). Až pod tím jsou běžné věci, které známe jako programátoři

561

Server / Re:Zabezpečení databáze

« kdy: 25. 09. 2020, 20:43:08 »

prakticky to je dost široké téma bez zkušeností to stejně v nějaké ohledu zmotáš (nic proti), je lepší si ke spolupráci vzít někoho, kdo už něco takového dělá než se ptát na diskuzích.

Pokud jde o databázovou stranu, měl bys zajistit:
- znemožnit select všech údajů z tabulky najednou (jak psal Miroslav Šilhavý select from function je řešením)
- znemožnit iteraci jednotlivých řádků přes primární klíč (takový autoincrement ti dovolí zkoušet postupně všechny hodnoty), takže id generovat z velkého rozsahu a náhodně
- auditovat každý přístup pro čtení/zápis
- oddělit práva pro administraci, pro zápis a pro čtení

Tohle jsou všechno kroky, které vytvoří bariéru v případě, kdy se útočník dostane k tvé webové aplikaci a bude jí moci ovládat.

Připojovat databázi přímo do webých aplikací se již opravdu tolik nedoporučuje dělat z pohledu bezpečnosti. Vhodné je si udělat jednoduchou rest aplikaci, kterou ti základní operace s čtením a zápisem zajistí a webovou aplikaci opřeš o ní.

Šifrování disku je super, šifrování jednotlivých záznamů už tolik ne, stejně musí mít aplikace klíč, TLS/SSL je na to daleko vhodnější pro zabezpečení dat při přenosu.

Chce také myslet na legislativná stránku, práci s takovými údaji musíš zdokumentovat, musíš mít popsané, kdo k nim má přístup, jak se přístup kontroluje a ověřuje, kde jsou auditní logy.

562

Distribuce / Re:Zabezpečený šifrovaný linux pro denní použití

« kdy: 14. 09. 2020, 10:12:14 »

freebsd a jail , openbsd s unveil/pledge je také velice silná hračka. Nebo máš důvod proč chceč zrovna linux? Linux nikdy nebyl moc přeborník v bezpečnosti mezi aplikacemi a sandboxingu, nepořádek mezi balíčky, kernelem a nastavením dělá obrovský prostor to prostě udělat špatně.

Na linuxové stanice/servery rád používáme Alpine/clearOS a virtualizaci v podobě kvm,qemu, kde běží xka a aplikace. Mám za to, že čím je jednoduší distribuce a SW, tím je snažší tu bezpečnost udržet. V práci zase používáme pořád hojně RHEL/CentoOS minimal, ale to je již na můj vkus příliš velké, nesourodé a komplikované na nastavení.

563

Software / Re:Otravné hlášky googlu

« kdy: 03. 09. 2020, 19:02:55 »

nepoužívat Google. Na malých mobilech to dotáhl k dokonalosti a tlačítko na odkliknutí souhlasu se nevešlo na obrazovku, takže ho nelze odkliknout.

Dělají změny poměrně často, takže addblock je potřeba pořád nějak aktualizovat, ale částečné řešení to je.

564

Server / Re:Solidní smtp/imap free mail

« kdy: 02. 09. 2020, 10:26:28 »

předpokládám, že ty CZ emaily jsou z různých eshopů a malých firem, které mají špatně nastavený emailový server. Na Office365 lze dát konkrétní domény do whitelistu a pak se ignoruje výsledek ze spam kontroly, používáme to tak.

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/create-safe-sender-lists-in-office-365?view=o365-worldwide

U emailových poskytovatelů, kteří mají správné kontroly, to dopadne hodně podobně, všichni ti větší skončí stejně. Můžeš zkusit gmail, využívá sdílené filtry, takže řada těch CZ špatně nastavený schránek kolektivně projde spam kontrolou. Na CZ protistrany dobře funguje Seznam Email Profi či jak se jejich služba jmenuje.

565

Studium a uplatnění / Re:Microsoft Praha - aky to je zamestnavatel?

« kdy: 20. 08. 2020, 10:36:48 »

ja bych v microsoftu klidne delal, ale jedine s linuxem/*bsd :-D

s Linuxem se tam ale pracuje relativně dost , dokonce si mě párkrát najali na výběrko právě kvůli linuxu a databázím.

566

Studium a uplatnění / Re:Kolik % marži mají firmy při bodyshopingu?

« kdy: 19. 08. 2020, 15:52:26 »

...

Obvykle si to jednotlivci nezavádějí tak striktně, spíš zjednoduší postupy. Mimochodem, proto se často živnostníkům nedaří  z živnosti vybudovat firmu a třeba pracovat ve dvou, ve třech. Tam pak ty náklady vyskočí a původní zdánlivě vysoké příjmy se rozplynou v režii. Osobně souhlasím s tím, že i živnostník by měl stanovovat cenu s ohledem na rizika, aspoň částečnou zastupitelnost a na růst.

Ono to s sebou nese i další projevy. Např. zákazníci body shopu jsou nespokojení, když musí s každým kontraktorem řešit pracovní záležitosti separé. Zákazníci pak tlačí na kontraktora, aby jim poskytoval služby ve stejné úrovni, jako ti velcí (zastupitelnost, rezervy, splatnosti, ...) - a v tu chvíli už není prostor vysvětlovat, že "za mě platíte méně". Nižší cena v hlavách zákazníků není spojena s přijetím toho, že služby jsou horší.

Vysoké sazby na MD platí snad jen korporáty a ty právě vyžadují ty postupy, u bank musí být každý dodavatel schválen a projít prověrkou, při práci s důvěrnými daty je potřeba osvědčení NBÚ pro práci/vznik důvěrných dat (tu získat jako živnostník stojí také nemalé úsilí, viz seznam https://www.nbu.cz/cs/informacni-centrum/seznamy/936-seznam-podnikatelu-s-vydanym-potvrzenimosvedcenim-podnikatele/). Tohle vše ten prostředník zastřešuje.

A ano, s jednotlivci se nikdo moc nechce bavit. Agentura dodá 100 lidí na klíč, je to mnohem jednodušší než si samostatně získávat 100 po jednom, to je obrovská agenda. Lze to u konkrétních případů dělat, ale obecně nikoliv. Z toho pak vzniká ta ochota těch velkých firem za hotové a dodané lidi platit tak vysoké sazby na MD, pro ně to je pořád výhodnější než si ty lidi zaměstnávat samostatně.

U např. českých bank je rozhodující i pojištění, běžně se pracuje na systémech, při kterých chybou mohou vznikat škody v desítkách milionů, jednotlivec si většinou není schopný takové pojištění zaplatit nebo vyjednat, zatímco velká agentura to bez problémů pokryje. Jako OSVČ je velice těžké si nějaké pojištění na IT sjednat za rozumné peníze.

567

Studium a uplatnění / Re:Kolik % marži mají firmy při bodyshopingu?

« kdy: 19. 08. 2020, 10:29:11 »

V jedné z větších outsourcingových agentůr v IT v ČR je průměr na 40 % (náklady na zaměstnance vůči fakturaci u klienta). Senioři kolikrát dostanou skoro to, co se fakturuje, junioři to živí a generují zisk skupiny.

Náklady na provoz a rizika jsou dost vysoká, korporáty mají smluvní pokuty za spousty drobností, faktury proplácejí i s půl ročním zpožděním, certifikace (ISO 9000, NBÚ, externí audit vychází na miliony ročně). Nutnost dodržet určitou IT bezpečnost znamená mít vlastní IT oddělení a drahé SW na kontrolu provozu, nic levného. Zajistit stálé zakázky také není snadné a nějaké prostoje jdou na náklady firmy.

Nelze porovnávat svůj příjem (plat nebo fakturaci) proti fakturaci odběrateli, je potřeba k tomu započíst i náklady, které bych měl pokud bych to dělal na sebe. Pak to nevychází tak výhodně.

568

Studium a uplatnění / Re:Průměrný plat java kontraktora v Praze

« kdy: 13. 08. 2020, 11:52:37 »

Po 3 letech praxe mi připadá dost šílené si říkat o 7k/MD.

Je to šílené, ale ty ceny takové opravdu jsou. Jako ještě je „3 roky praxe“ a „3 roky praxe“ (ve skutečnosti má tazatel 5 let, že jo, protože počítače asi nejsou jenom Java, a před tím třeba dělal nějaké hobby projekty nebo školu), bavíme se opravdu o schopných lidech.

Setkávám se s takovými lidma uvnitř bank, někteří nejsou vůbec špatní, ale celkový dojem je příšerný. 3 roky či 5 let je strašně krátká doba i pokud bude celá pracovní doba věnovaná studiu, pokud se u toho musí dělat i nějaká práce, je to na zkušenosti málo. Jen pokud vemu Spring a Javu, to jsou tisíce stránek dokumentace k prostudování.

OK System, Oracle, IBM, MSD a podobní doteď platí takovéhle peníze i v ČR, ale to není programování, to je lepení podle zadání. Zkusil bych se podívat na nabídky pro tyhle....

569

Studium a uplatnění / Re:Průměrný plat java kontraktora v Praze

« kdy: 13. 08. 2020, 09:55:55 »

Po 3 letech praxe mi připadá dost šílené si říkat o 7k/MD. To programuji od 90. let. V posledních měsících se ty částky snižují a i banky začínají platit méně.

570

Server / Re:Hosting pre vlastnu CDN siet

« kdy: 11. 08. 2020, 16:49:08 »

CDN se nebuduje pro malý provoz, ale pro značný provoz. Pokud mám malý provoz, stačí mi jeden hosting, pokud potřebuji stabilní latence celosvětově, pořídím si více malých hostingů v dané lokalitě, pokud potřebuji celosvětovou dostupnost pro hodně dat, pořídím si CDN. Říkat hostingům napříč kontinenty CDN je už hutná inflace terminologie, viz i popis CDN na wiki.

K dotazu, mrkni na digitalocean.com, vultr.com, Azure, AWS, Google Cloud, OVH a další globální poskytovatele.