Příspěvky

1

Odkladiště / Re:Zálohování stále se měnících velkých dat

« kdy: 16. 01. 2025, 16:44:58 »

Pokud to je modul, je to pořád součástí té aplikace, ne?

Chceš mít schopnost dělat aktualizace bez výpadků a nasazovat změny průběžně? Prostě zapomeň na to, že do jedné databáze zapisuje více samostatných aplikací. Z cizích databází čti pouze z veřejných schémat, přes api nebo odbírej event log. Jedna databáze = jeden vlastník = jeden zapisovatel a cokoliv jiného řeš replikacemi, migracemi, transformacemi. Samozřejmě to je zjednodušení.

Argumentuješ správně, když více dodavatelů používá stejné schéma a databázi, změny musíš koordinovat napříč dodavateli a nasazovat to najednou. To je pak nepořádek, to nikdy nezautomatizuješ.

Neber to absolutně. Urči si kritickou část systémů, kterou máš pod kontrolou, tam zaveď a vynuť nějaká pravidla, aby se ti žilo lépe. V dalších vrstvách můžeš stavidla uvolnit. Banky mají svůj Core, který udržují takhle náročně a přesně, ono se jim to vyplatí, ale pak mají třeba systém na vykazování práce, což je běžná databáze někde v kubernetu, přistupuje do ní několik dalších aplikací vč. koupených pluginů, udržuje to několik týmů, zálohuje se to celé najednou, aktualizace znamená výpadek a restart, s tím se dá žít, uděláš to mimo pracovní dobu, na konci měsíce z toho uděláš report do účetnictví a ten skončí v Core vrstvě.

Musíš si určit co chceš a co ne. Je na tobě, co pustíš do infrastruktury a jaká pravidla musí co splnit. s NIS2 se nám objeví ve spoustě firem povinnost si zmapovat, který systém je jak důležitý pro chod firmy a jak pro nás je bolestný výpadek, tohle ti přesně udělá ten řez. Pokud bez té aplikace nemůžeš ani otevřít dveře, těžko jí můžeš provozovat stylem, že X aplikací od X dodavatelů zapisuje do stejné databáze a aktualizují si schémata jak se jim zachce. Rozumíš kam s tím mířím?

Pokud někdo chce udělat z např. Pohody (pohoda.cz) kritický systém a řekne mi, že tady má webovou aplikaci, která přímo přistupuje do databáze, další která používá api, má tady několik koupených pluginů a třetí strana to aktualizuje sama každý půl rok. Řeknu mu, že bez rozbití těch integrace a jejich oddělení a normalizování datové vrstvy s tím moc neudělám (viz třeba co vše musel udělat AK system, aby měl pohodu distribuovanou). Pak přesně přichází na řadu diskuze, jestli je levnější to předělat nebo koupit flexibilnější účetní systém.

2

Odkladiště / Re:Zálohování stále se měnících velkých dat

« kdy: 16. 01. 2025, 12:29:55 »

Tak zajima me to prave z architektonickeho hlediska, protoze pripravuji prepsani sveho erp/ucetnictvi (inhouse reseni). At to je cely vlastne primarne insert-only (writeonly, append), a modify se dela jen nad pomocnymi tabulkami pro aktualni stav (primarne z toho duvodu aby to bylo zivy a synchronni ve dvou lokacich). Nejvetsi hruza je ale ze zmen schematu - doposud na te "primitivni" db bylo vse jenom rozsirovano a pridavano, s tim ze to je pak zpetne kompatibilni (tj. nic nezmizi a ani nic nebude jinak), ale pak to casem vytvori neudrzovatelny moloch (asi hodne SAPoidni).

Tak se pidim po tom, jak resit tyhle veci (tj. nejake procesni pristupy, at je schema synchronni s okolnimi "skripty"). Napada me takovej tick-tock pristup, kdy se prvne zmigruje okoli na pouziti obojiho a pak az data. A to jeste bych rad bezvypadkove (treba aukro me neskutecne vytaci hlaskou o odstavce.. tohle v roce 2025 by uz nemelo byt bezne/caste). Z popisu jak hodnotis sektor by me byl blizsi asi pristup vice mensich zmen, ve smyslu mala zmena = mensi sance to podelat, castejsi zmena = stane se z toho rutina, nez ten druhy obcasny s vetsimi upravami.

Udělej mezi tím rozhraní, pohledy, marty, jinou databázi.

Přistup k schématu a databázi jako k vlastnictví. Každé scéma vlastní konkrétní aplikace a nikdo jiný než daná aplikace dané schéma nepoužívá. Pokud potřebuješ data sdílet mezi aplikacemi, exportuj data jako veřejný, stabilní, zaručený interface (ať už formou materializovaných pohledů nebo replikaci do jiné databáze nebo použití nějaké rpc nebo fronty), pak máš prostor, kde můžeš ošetřovat zpětnou kompatilibitu, verzovat či řídit změny bez ohledu na to, jak s schématy zachází její vlastník.

To, jestli jedna aplikace bude celý ERP nebo tam budeš mít jednotlivé služby je na tobě, vždy se při určité velikosti vyplatí to logicky rozdělit.

A pokud jde o řízení změn u konzumentů dat, tak hodně záleží na tom, co konzument dělá. Pokud to je třeba posílač emailů, tak starého omezím pouze na původní verzi schématu a spustím nového nad novým schématem. Stará data doběhnou a nové se začnou posílat jinak.

Nebo udělám nějaký bridge, který bude nové schéma zpětně migrovat do starého, aby původní aplikace plně fungovala beze změn. Tohle je třeba v případě bank častý způsob. Navenek nic není vidět. Až aplikace se upraví, změní se jí link na nové schéma a bude ho konzumovat přímo.

Základem je ale pořád mít nějakou vrstvu, která bude fungovat jako mezičlánek, výstup z té vrstvy je verzovaný interface a o vstup se právě stará majitel schématu a udržuje migrace při změnách. Na začátku třeba začínáš tím, že máš pohledy typu select *, protože nepotřebuješ nic jiného dělat.

Pokud jde o zápis, platí pravidlo výše, pouze jedna aplikace jako vlastník může do schématu zapisovat, ostatní nikoliv, takže na vše mít RPC nebo frontu změn a ty si bude sama aplikace odbavovat, jen ta ví, jaké je správné schéma. Varianta, kdy všichni zapisují do jedné společné databáze, jak je běžně vidět u webových aplikací vede pouze a jen k celkovým odstávkách při aktualizaci.

Pokud jde o bezvýpadkovou aktualizaci a migraci schémat. Buď máš potřebnou obslužnou logiku implementovanou v aplikaci a v jednu dobu zapisuje a čte z dvou různých verzí schémat, což je někdy dost komplikované nebo používáš materializované pohledy a migrace na úrovni databáze, aplikace pak má najednou k dispozici obě verze schémat, nové i staré a může postupně přejít na nové.

Občas se dostaneš do situace, kdy změnu potřebuješ udělat daleko rozsáhlejší, použij verzování route a směruj staré požadavky na starou aplikaci a nové požadavky na novou a v jednu dobu budeš provozovat dvě verze backendu, data z nich sdružovat právě v nějakých martech, veřejných interfaces.

Cest je ale hodně, tohle je jen takové postrčení jak to můžeš řešit. Vše zmíněné zvládne pg, s mariadb nepočítej. Pokud se vzhlédneš v moderních nosql databázích, budeš si to muset nějak implementovat sám.

3

Odkladiště / Re:Zálohování stále se měnících velkých dat

« kdy: 15. 01. 2025, 16:57:07 »

Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců.

A pouziva se to prakticky vse, nebo je to spis dusledek nasazeni nakoupene technologie, ktera byla vytvorena nebo dokonvergovala do univerzalniho reseni, aby zadna zmena schematu v teto casti uz nikdy nebyla potreba (coz rozhodne usnadnuje aktualizace a snizuje moznosti problemu, kdyz jsou vse pouze data a samotna struktura se nemeni).

Nebo je tam i nejaka segmentace dat (sam jsem pouzival ve vykonnem vyhledavaci), to pak pocet klidne narust muze libovolne, a usnadnuje to pak paralelizaci, ono jeden stroj s naivnim schematem databaze bude mit chte nechte sve limity.

ty data jsou normalizovaná a modelovaná, s validací, datovými typy a vše co si přeješ, dělá se i migrace schémat a dat za provozu. Dokud vše bylo věcí mainframů, byly běžné noční odstávky, kde se dělala údržba, validace. Dnes se přechází na 24/7 provoz, často to běží na věcech jako Oracle Exadata a už potkáš u kubernetes v core infrastruktuře (koukám na to trochu nelibě, ale co).

Zpravidla je core výsledkem dodávky jedné společnosti, partnera nebo vlastní in-house vývoj, nebývá to mišmaš všeho, co koupíš, to jsou až ty vrstvy nad tím. Je tam hodně číselníků, třeba třetina. Každá banka to má jiné, když jsme migrovalii data při slučování bank, tak to jsou tisíce člověkodnů jenom na to, abys ty data propojil a spároval, ikdyž na druhé straně logicky musí být hodně podobné.

Ty systémy jsou rozsáhlé, protože i rozsah služeb a funkcí je vysoký. Třeba PSD2, to jsou desítky nových tabulek jen kvůli tomuhle. Změny se dělají pořád a příprava nových věcí se děje denně, nasazování je pak dána jen tím, jak to má banka vnitřně nastavené, některá je schopná změny dělat skoro denně, jiná si to nechá do velkého balíčku jednou za půl roku. Core nemusí být složen fyzicky z jediné databáze, ale častěji to je soustava několika databází a segmentuje se to.

Jsem architekt, do provozních dat tolik nevidím a ani mě nezajímají, zajímá mě jen jak to je postavené, navrhnuté a jak s tím dál. Stejně tak nemohu sdělovat příliš konkrétní data, protože nevím, co je zveřejnitelné a co ne. Zagoogli si, jestli tě to více zajímá, např. z Komerční banky o tom veřejně mluví Frantisek Kubala.

Zaujmal ma pricip backupu, kde sa hodne casto zapisuju do DB data. Neslo mi ani tak o velkost dat, ale velmi caste frekvenciie zapisov

Zálohují a schraňují se transakční logy, tj. záznam o tom, že proběhla nějaká změna v databázi (insert, update, změna schémat). Počet transakcí jen ovlivňuje to, jak je transakční log velký, jsou to append-only soubory. Stav v databázi je pak až materializace právě těch jednotlivých transakcí, hodně zápisu ti nevadí, vždy máš nějaký point in time (transaction id), ty jsou seřazeny v čase.

4

Odkladiště / Re:Zálohování stále se měnících velkých dat

« kdy: 15. 01. 2025, 14:19:16 »

Jde-li konkrétně o banky.

Ono to řešení není tak složité, složité je jen v detailech. Ukázkový příklad, Oracle DB nad replikovaným diskovým polem, replikovaný transakční log, na vstupu se každý požadavek ukládá do auditního logu. Transakce se nejprve uloží do interní fronty a poté se provedou změny v modelu. Vše se striktně spouští v db transakci.

To co tzv. Core (či Core banking system, CBS). Je to databáze a k tomu rozhraní, které se stará o transakce, klienty, účty, účetnictví, číselníky atd. Na Core databázi se zpravidla nikdo z venku (ani aplikace) nepřipojuje, vše se replikuje přes transakční log, který se čte. Core bývá fyzicky, síťově a administračně oddělen od zbytku infrastruktury.

České banky mají Core velký zpravidla několik TB velký, RTO se pohybuje v hodinách. Při obnově se zahodí datová složka, vezme se poslední snapshot/checkpoint a od něho se aplikují jednotlivé transakce z logu (jedna po druhé). To už psali předřečníci.

Naše banky mají zpravidla dvě aktivní lokality, kam se data rovnou replikují. Transakční a auditní logy z core putují na pásky se zpožděním pár desítek minut.

Vedle toho pak nezávislé stojí jiné databáze a datové sklady, které data dále zpracovávají, posílají, zobrazují klientům v bankovnictví, dělají reporty a výstupy do ČNB atd. Aplikací a systémů nad Corem pak může být i několik stovek a to jsou pak systémy, s kterými se potkávají běžní lidé a zaměstnanci. Často ale neobsahují primární data a mohu je obnovit z Core systému. Tam se data zálohují už daleko jednodušejí, snaphosty virtuálů, dumpy dat a vesměs to je věcí týmu, kterému to patří, aby udělal backup and restore implementaci. Obnova se čvičí několikrát ročně a některé banky to mají již plně zautomatizované.

Technicky se ale nedá zabránit všem druhům útoků, důležitou roli hraje dohledový tým a automatizace, která izoluje v případě problémů celé systémy, dohledové centrum funguje nonstop. Díky vysokému tlaku ČNB, jsou naše banky v tomhle hodně progresivní. To už se ale nedá říct o těch systémech nad tím, s kterými se větčina vývojářů a uživatelů setkává.

Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců. K transakcím se ukládají i atributy a metadata, tj. z jakých terminálů transakce vznikla, různé identifikace a seriová čísla, IP adresy, časové známky, podpisy atd. atd.

5

Hardware / Re:Neznáme napájanie USB hubu

« kdy: 10. 01. 2025, 10:59:28 »

Jen bych si k Jirkovi dovolil dodat, že s výjimkou vyloženě průmyslového USB hubu s napájením z 12V rackové "kolejnice" jsem nikdy neviděl hub se zdrojem dávajícím víc než 5,5V. Co se týče proudové zatížitelnosti, i k 7portům jsem viděl přibalené jen max. 2,5A zdroje, tzn výrobce počítá, že se do toho budou strkat akorát flashky nebo kabely do zařízení s vlastním napájením, a že průměrných 500mA/port většina uživatelů ani nebude potřebovat. Asi dvakrát jsem to dokonce viděl napsané v manuálu.
BTW když je k hubu přibalený zdroj, má zpravidla větší hodnotu než ten hub.
BTW2 kolega hardwarář si po zkušenostech s "consumer" huby už radši staví huby sám.
BTW3 kancelářské USB huby, co se tady na maloobchodě prodávají běžně kolem 7 stovek, jsou na alíku za jednotky dolarů včetně poštovného, takže bych v tom fakt žádný napájecí šavlostroj nehledal.

a nechce to kolega stavět nějak trochu i na prodej? Myslím, že bych pár zájemců měl, pro sebe si umím něco slepit, ale nechci to poskytovat lidem v okolí, tak moc svým elektro dovednostem nevěřím. Všechno se napájí z usb a mít někde v zásuvce kvůli tomu 10 spínaných zdrojů není nic, co se mi líbí.

Mám tady stařičký odkoupený startech, ale pouze s usb 2 a 700mA na port, jsou ale všechny porty galvanicky oddělené. Cenu nového notebook za nový hub pro usb-3 se mi dávat nechce a tyhle hračky v eshopech ve mě také důvěru nevzbuzují.

6

Odkladiště / Re:Zkušenosti s internetovým bankovnictvím a digitální veličinou

« kdy: 10. 01. 2025, 10:50:52 »

Toje zase jirsákův argument  ad vytržením
A viděl jste snad internetové bankovnictví? Otisk prstu se dá získat ze skleničky a možná se nějaký otisk najde na telefonu samotném, sken obličeje se dá zfalšovat vytištěním na karton
nedá se říct že jedno je bezpečnější než druhé, vždy platí za nějakých okolností (zda nosím  "ten PIN" do  smartphone bankovnictví nebo login údaje do internet.banking vyrytý do zadní stěny telefonu ) nebo zda telefon má primitivní čtečku skenu obličeje která se dá ošálit přilepením vytisklé fotky na obličej nebo že otisk prstu není bezpečnost(ní zvyšující )prvek ale  (bezpečnost) zjednodušující prvek, funguje, pokud zloděj najde telefon kdesi na zemi a nedokáže zjistit otisk prstu

Pozor! Ono se sice mluví o otisku prstu, ale telefony nepoužívají otisk prstu jak známe z daktyloskopie (či televizních detektivek). Snímají se jednotlivé body a u nich se zaznamenává elektrická vodivost (či odpor), to vůbec nekoriguje s papilárami z otisků na skleničce. Telefon má pak v sobě uložený otisk (hash) toho záznamů pro různé dílčí sektory, při přiložení prstu se zjišťuje, jestli většina sektorů odpovídá (hodně zjednodušeně řečeno). Nelze sebrat otisk prstu ze sklenice a použít na odemčení telefonu. Nelze z telefonu vyexportovat otisk prstu a ten dále použít. V počátku to byly jednotky bodů (např. senzory u prvních notebooků), první mobily měly desítky bodů, dnes se zaznamenává stovky či tisíce bodů. Lze ten senzor oblafnout nějakým modelem vodivostní mapy prstu vytištěným na 3D tiskárně, ale nikde jsem nic takového nečetl a ani si nedokážu představit, jak by se získal vzor.

Ty 2D skeny obličejů jsou šílené, otevírání přes fotky je od začátku velice problematické, ne všechny současné telefony umí snímat 3D a ještě ideálně i v jiných vlnových délkách než viditelné světlo. Od otisku se odchází ne kvůli bezpečnosti, ale kvůli tomu, že se to výrobců nehodí do vzhledu, otisk je problematický pro některé lidi a prostředí (pokud mám suchou a popraskanou kůži, nefunguje to, to je problém těch manuálně pracujících a naší starší populace, stejně tak se výrazně mění snímání podle vlhkosti a ne vždy si můžeme utřít prst - proto třeba za deště nebo v hodně suchém prostředí ty otisky fungují na štíru).

7

Distribuce / Re:Zkušenosti s distribucí HexOS

« kdy: 10. 01. 2025, 09:59:11 »

early access a beta, to je asi moc nové. TrueNAS byl roky nad freebsd, nedávno ale začali migrovat na linux s tím jsem už nedělal.

Pokud se ale budou držet v kolejích, TrueNAS byl za mě vžd spolehlivý systém na řešení malých storage, aktualizace bývaly bezproblémové, nutné migrace si skoro nepamatuji a byl to plnohodnotný systém, na který jsi se mohl přes ssh připojit a znal jsi ty nástroje.

8

Odkladiště / Re:Zkušenosti s internetovým bankovnictvím

« kdy: 09. 01. 2025, 16:50:04 »

Vždyť i vzdělaný kolegové z IT oboru běžně odkliknou chybu certifikátu, protože to vidí pořád..

Nevím, mluv za sebe nebo za tvoje "vzdělaný" kolegy.
Já a lidi co znám máme nastaveno vynucovaní https ve všech prohlížečích. Pomocí GPO a v celé firmě, kde se objevím a vidím že to nemají, tak je to jedna z prvních věcí co tam tlačím.
Pokud to hodí chybu, heh nebo pokud stránka jede jenom na http, tak mám v hlavě hned alarm a řeším co se děje.
A řeší se to opravou webu, komunikací proč nemají zapnuté https atd. odklikávání je zakázano.
Pokud se nevyřeší, tak se ten web prostě nepoužívá.

Jasně, každý je superstar a nikdy neporuší pravidla, GPO se používá zpravidla na firemních počítačích, že, to asi není cílovka. Pravidelné testování ve firmách mluví jasně, vždy se někdo nachytá a mohu ti garantovat, že občas udělají chybu i ti, kteří o sobě tvrdí, jak jsou strašně obezřetní. Všichni občas uděláme chybu či něco opomeneme.

Plošné útoky ale necílí na ty, kteří jsou opatrní, ale právě na ty, kteří opatrní nejsou (a je jedno jestli to je kvůli jejich znalostem, vnitřního rozpoložení, manipulaci atd.).

Ono být dnes obezřetný začíná být sakra těžké, vždyť mobilní prohlížeče pro jistotu mi schovávají dost efektivně adresu webu, na kterém jsem, různé web view to odstraňují úplně, služby jako paypal, které se buď otevírají v okně bez url nebo v iframe ve mě budí také důvěru. Viděl jsem na Androidu zobrazený captive portál, který věrohodně kopíroval webové stránky české spořitelny, nešlo tak snadno rozeznat, že jsem vlastně jinde, dokonce to mělo i svůj vlastní adresní řádek se správnou url.

Nechci ale obhajovat mobilní aplikace, to také není růžové.

Ja treba na uctech nic nemam a potrebne castky prevadim ze sporicich podle potreby prave pres mobilni bankovnictvy. Ze zporaku se daji posilat penize jen na vlastni ucet cili nemuzou jen tak nekam odletet jednim prikazem pryc 🙂.

Po kapsach nosim par stovek pro pripad nouze coz pokreje jidlo/tankovani a jine potreby kdyz toto selze.

Hrozba jsou ty predschvaleny uvery … ale slysel jsem legendu ze se jich da zbavit nedanim souhlasu pro marketingove kanpane

Podle moji zname co dela v bankovnictvi nejvic chybuji lide co posilaji penize kamsi a poste nic nectou a pak ziskaji subscription nebo sluzby co ani nechteli.

Nebo se kradou cisla pres e-simky jinym uzivatelum, pak se odcizi bankovni aplikace a utocnik ma pristup k uctu tak jako by byl majitel.

Útočník pak můžeš si na tebe vzít úvěr, nulový zůstatek neznamená, že jsi v bezpečí. Některé banky dokocne umí bez problémů jít platbou i do mínusu (nebudu RB jmenovat).

9

Odkladiště / Re:Zkušenosti s internetovým bankovnictvím

« kdy: 09. 01. 2025, 11:54:10 »

Jak přesně ten útočník odposlechne a změní TLS komunikaci mezi serverem a prohlížečem? To už by ten počítač nebo prohlížeč musel být předem napadený, nebo jde jen o to, že neznalý uživatel slepě potvrdí podvrhnutý certifikát, což by mobilní aplikace vůbec nenabízela?

Co jsem viděl, není to vůbec sofistikované. Únos DNS, pokus o přesměrování v http, MiTM pro web banky, uživatel si to odklikne, ona i úspěšnost 2 % může být dost značná. Vždyť i vzdělaný kolegové z IT oboru běžně odkliknou chybu certifikátu, protože to vidí pořád. Captive portál je dobrá cesta, jak dělat MitM, můžeš se maskovat jako stránka, kterou navštěvuje uživatel, uživatelé jsou nepozorní (logicky). O2 a jeho akce s unášením http provozu jen učí lidi, že to je vlastně běžné a přesně u toho můžeme vidět, jak vlastně to je úspěšné, že uživatelé vůbec netuší co se děje a že to je špatně.

Stejně tak se hodně používají pluginy do prohlížeče (asi spíše ve světě, u nás takových útoků jsem viděl minimum), pokud se ti na síť přihlásí někdo, u koho máš pod kontrolou plugin, jsi na dobré cestě.

Na veřejné wifi nechodíš do bankovnictví, protože se nudíš nebo si chceš zvednout náladu svým zůstatkem, ale protože potřebuješ rychle něco vyřešit, v takovém případě jsi ochotný více rizkovat a být nepozorný. Mysli na to, že taková wifi může fungovat týdny, měsíce bez povšimnutí a vůbec není snadné jí odhalit a ještě najít vlastníka.

Ano, mobilní bankovní aplikace používají vlastní cert pinning a validují si, že certifikát ve správné cestě, nedovolní komunikaci (aspoň co jsem zkoušel u velké pětky). V prohlížeči máš dost omezené možnosti jak něco vynutit (HPKP nám umřel), Google is IP adresy a certifikáty pro své služby kvůli tomu schoval přímo do zdrojového kódu prohlížeče, opravdu systémové řešení. Microsoft ve Windows zase pro některé své interní služby ignoruje nastavení VPN, DNS a komunikuje přímo, opět super řešení, když to nenabízí i aplikacím.

10

Odkladiště / Re:Zkušenosti s internetovým bankovnictvím

« kdy: 09. 01. 2025, 11:34:28 »

Praxe, ty útoky se dějí v praxi a funguje docela plošně. Napadený počítač jde ruku v ruce s napadeným telefonem, nebo obráceně, šíří se po stejné síti, která dovolí veškerý provoz. Odchytit sms aplikací na Androidu umí každá druhá aplikace. Kompromitace osobního počítače a telefonu zároveň se ukazuje jako poměrně častá. Bankovní aplikace se může částečně bránit proti MitM.

Tak toto může skutečně napsat KARDINÁLNÍ IMBECIL.

1) Nejvíce rozšířené útoky jsou bezesporu za pomocí sociálního inženýringu kdy chyba je vždy mezi klávesnicí a židlí. Viz stovky kauz kdy uživatel skočil na špek manipulátorovi přes telefon a nainstaloval si program pro vzdálenou správu.

2) Kompromitace jsou odlišných zařízení v realitě SE prakticky nedá provést a to z technického hlediska protože STEJNÝ PROGRAM na různém operačním systému NEFUNGUJE(program vyvinutý na Windows prostě na Androidu nespustíš) a tudíž když kompromituješ jednoho zařízení na síti běžící např. na Windows tak z něj se ti skoro nepodaří zkompromitovat např. telefon běžící na Androidu nebo jablíčku.

- tato varianta útoku je prakticky i pro nadprůměrně zdatného IT odborníka skoro neproveditelná(příprava je specifická podle cíle a zabere spoustu času s nejistým výsledkem). A představa že něco takového dokážeš "REMOTE" je dneska skoro sci-fi. Není to nemožné ale je to neskutečně obtížné a mohou to dokázat tak odborníci pracující pro nejvýkonější tajné služby (USA, Rusko, Čína, apod..)

- to je milionkrát jednoduší vyvinout trojana(klient-server app) pro Android/Jablíčko/apod.. který poběží na pozadí a bude vše logovat a který ti umožní spustit a ovládat jinou app. Nebo vtrhnout někomu do baráku, zastřelit mu dítě nebo manželku a 9tkou u hlavy ho donutit aby poslal všechny peníze na nějaký pay-pal/kryptoburzu/apod. a vše vyprat přes kryptoburzy..

to si nemůžeš odpustit urážky?

Vždyť dnes prakticky útočník není autorem aplikace, jen si jí pronajme, pronajímají se nejen aplikace (trojany, viry, ransonware, nazývejme to jakkoliv), ale i konkrétní exploitované zařízení. C&C servery, exploity podle typů zařízení v síti, payloadu podle OS, během chvilku se ti to trojan automaticky rozprostřed po řadě různých zařízení a teprve pak zavolá domů, že čeká na příkazy. Tohle je typ útoků, který nejčastěji vidím ve firmách. Někdy tam prostě čeká měsíce na příkazy.

Útočníci dnes nemají velké znalosti, mají plnohodnotnou administraci pro ovládání trojanů, nejsou autoři kódu a ani nemusí být nijak zdatní, SW kupují na trhu.

Polymorfní programy, které spustíš napříč OS existují, ale ona ta aplikace takový být nemusí, prostě si stáhne payload podle detekce. Tak přesně proběhl i útok na ŘSD před pár lety, nákaza z jednoho zařízení a postihla celou infrastruktur s různými technologiemi.

11

Odkladiště / Re:Zkušenosti s internetovým bankovnictvím

« kdy: 09. 01. 2025, 10:36:46 »

Mliko po brade?
Nejhorsi projekt ktery KB mela bylo jejich IE only+ActiveX+dve verze Javy peklo. Odstrasujici pripad nemajici u obdoby.
V mboha firmach byly jen dedikovane pocitace na ten jejich dort pejska a kocicky.

Profibanka má pořád závislost na ActiveX . Hodnotíš jen UI, původní moje banka si peklo s activeX udělala hlavně proto, že si usmysleli, že budou cool a bude vše podepisovat certifikáty i v prohlížeči, jen to prohlížeče prostě neuměli, šlo to nahradit HW, který dělal ty podpisy. Kam to dospělo víme, ale backend byl spolehlivý, funkce fungovaly, frontendu se dalo věřit, odezvy rychlé, vše plně distribuované, backupované, vše s strong consistency, nestalo se ti, že po půlnoci stáhneš prázdný výpis včerejších transakcí, protože to tam ještě nedoteklo. Dnes? Celý frontend je eventual consistency, SPoF v podobě airflow a single elastic clusteru, přes který tečou veškerá data v json/avro, rekonciliace dat jsou na denním pořádku, protože nějaká schema evolution pro frontend je v počátku. Vše lepené a hotfixované, o nějakém promyšleném designu si můžeme nechat jen zdát, zatím.

Muzete mi jako technikovi rici co si predstavujete pod pojmem odposlouchava GSM? Pro zjednoduseni geopolitiky v kontextu CR?
To chce vedet hodne o tom kde se uzivatel nachazi, ze pouziva pouze GSM v nejakych pripadech a spojit si ho v miste s danou sluzbou a uctem.  To nemusi byt vubec trivialni. Znat klice nebo naborit i A5/3 ( u posledni generace). Ty SMSky nelezou zrovna uplne nesifrovane.
Mnohem jednodussi jsou utoky na SS7 kde si pekne poctete bez sifrovani ( pravdepodobne mimo CR).
GSM vas vsak za tri roky uz trapit v CR nejspis nebude.

Mnohem jednodussi je trojan v mobilu nebo gumova hadice.

Zajimave pak mohou byt utoky v roamingu v nejake dire po meteoritu.

Pro A5/0-2 to umíš udělat realtime pasivně (A5/2 měla u nás uměle přidaný padding a ponechala 64b klíče), krabička na to stojí miliony a koupíš jí na "trhu" docela běžně. Pro A5/3 kdo ví, nabídky na černém trhu existují, ale víc o tom nevím, Kasumi s 128b klíčem je pořád asi velké sousto. Je to 10 let co se objevili krabičky pro luštění A5/1 v reálném čase s rainbow table, protože utekla sůl, kterou používá. U nás se A5/3 objevila až s UMTS, ještě nedávno se v GSM nepoužívala, vidím masivní používání až s přechodem na open RAN (nemám ale teď v ruce čísla, kdy došlo k přechodu na A5/3 a do jaké míry, útok o kterém jsem mluvil se stal v roce 2018 v síti TMO).

Nebo máš lepší info jak je na tom A5/3 v GSM u našich operátorů? Vím, že to je v open RANu, ten ale není nasazený ještě všude. Ano, v řadě zemí je právě ještě SS7 běžně používaný, tam ty útoky, které jsem popsal jsou dost časté.

Ano, trojan na Adroidu (iOS je proti nim solidně odolný nikoliv ale nepřekonatelný, jen se to asi nevyplácí masivně dělat) je velmi častý způsob jak se obchází zabezpečení, sms nejsou v telefonu nijak rozumně chráněné a až v posledních verzích lze vyžadovat pro aplikace samotné určitou míru ochrany od OS.

12

Hardware / Re:Neznáme napájanie USB hubu

« kdy: 08. 01. 2025, 14:41:17 »

tady tvrdí 5V/2A https://www.tsbohemia.cz/connect-it-ci-541-mighty-switch-usb-hub-se-7-porty_d231009/poradna, použít může třeba takovýhle kabel https://www.suntech.cz/delock-cable-usb-power-dc-3-5-x-1-35-mm-male-90-1-5-m_d420033.html?gQT=0

Je to tam asi hlavně proto, kdyby zdrojový port nestíhal. Osobně bych se tam bál přivést napětí z nějakého DC trafa, aby tam nevznikl nějaký nepěkný potenciál, kdoví jak to mají řešené uvnitř.

13

Odkladiště / Re:Zkušenosti s internetovým bankovnictvím

« kdy: 08. 01. 2025, 13:32:05 »

Všem co tu obhajují mobilní bankovní aplikace. Jste docela odvážní na odborném serveru tvrdit, že používaní bankovníctvi na jednom, opakuji jednom zařízení bezpečnější než kombinace desktopu + ověřovací sms tj dvou koncových zařízení.

Chápu, že se řeší BFU, ale tady bych čekal jinou úroveň. To že se dá SMS ukrást a podvrhnout neřeší to, že útok na jedno zařízení, opakuji  jedno zařízení je snadnější navíc často hromadný než zkoušet účit na dvě konkrétní zařízení, opakuji dvě konkrétní zařízení zárověn abysme získali přístup ke konkrétnímu účtu.

K tazateli, já mám u RB stále ještě ověření přes SMS, možná i proto tam nemám odpad typu bank id, ale i tak mě banka stále nabízí předschválenou půjčku na 700tisíc. Nechtěj zrušit. Takže RB bych se také vyhnul, navíc SMS ověření nebude dle dnešních standartů takže věci jako propojení účtu tam imho nerozjedete. KB+ mám a jsem spokojen až na zmiznuté dobijení twistu.

Trošku se zapomíná i na bezpečnost fyzickou, už tu pár případů bylo ale divím se, že to není častěji. Jdete si v noci po ulici hezky v klidu a jste přepaden, dáte peníze, dáte přístup k bance, pošlete peníze, půjčíte si více, pošlete dále, vše na účet bílého koně. Skoro jako ze scifi, ale reálně proveditelné.

p.s. prosím pana Filipa, nereagujte na mě, vždy jsou to reakce velmi zcestné a bez argumetnů :-)

Praxe, ty útoky se dějí v praxi a funguje docela plošně. Napadený počítač jde ruku v ruce s napadeným telefonem, nebo obráceně, šíří se po stejné síti, která dovolí veškerý provoz. Odchytit sms aplikací na Androidu umí každá druhá aplikace. Kompromitace osobního počítače a telefonu zároveň se ukazuje jako poměrně častá. Bankovní aplikace se může částečně bránit proti MitM.

Používání počítačů opadá, spousta lidí má už jen ten telefon. Realita je taková, že spoustě lidem zůstává pouze ten telefon. Fyzická bezpečnost a donucení útočníka, abys mu potvrdil transakci trvá, ale je asi jedno, jestli tě bude vydírat a donutí jít do banky nebo ti vezme ruku a potvrdí otiskem. Báze je pořád stejná, to se tímhle nemění, je potřeba fyzická přítomnost a k něčemu tě donutit, jestli to je podepsání směnky, zdělení hesla k účtu či potvrzení na tom nic nemění.

To teda rozhodne nejsem. Protoze i kdyby si zjistil muj login vcetne hesla, tak bez toho telefonu co na nej prijde ta sms je mu to uplne k prdu.

Bohužel, počítač rád všechny ty loginy ponechává v paměti (než se zadané heslo smaže z operační paměti, může to trvat dost dlouho). Jak píšu výše, když máš napadené jedno zařízení, není zase taková výjimka, kdy máš napadené i druhé, poznat to nemusí jít snadno.

Jsou tady případy, kdy tohle útočník naprosto odbourá. Stačí když má pod kontrolou nějakou wifi (např. někde jí nechá zdarma otevřenou, v centru, u letiště) a stejně tak odposlouchává GSM. Pak stačí jen čekat až někdo bude chtít si z účtu poslat peníze, najednou má oba kanály. Tyhle útoky se zaznamenaly i u nás v ČR, docela časté jsou třeba v JAR a na spoustě míst. Mobilní aplikace tenhle typ útoku efektivně eliminuje.

U sms je také zásadní problém v tom, že musíš sám kontrolovat, že obsah transakce, kterou potvrzuješ odpovídá tomu, co jsi zadal na webu. Opět jsou tady zdokumentované útoky, kdy plugin v prohlížeči měnil obsah příkazu, který jsi z prohlížeče poslal, ty jsi to potvrdil přes sms, ale peníze v jiné výši šly na jiné číslo účtu. Opět se dělo i u nás. Aplikace ti potřebné údaje k ověření poskytne přehledněji než spousty čísel v sms, které přirozeně přehlížíme. Krom toho u mobilní aplikace nelze tak snadno manipulovat s obsahem a tím co se posílá, tomu aktivně mobilní OS brání, což desktopový OS nedělá naprosto vůbec a neexistuje tam žádný chráněný režim.

14

Software / Re:Změny v datových zprávách (zfo soubory)

« kdy: 08. 01. 2025, 13:12:02 »

Tak zmenil se rok, treba soudruhum neco nekde preteklo, vubec bych se nedivil.

nech si tyhle nesmysly.

Testoval jsem to i na zprávách z prosince 2024, takže to si úplně nemyslím. Zpráva, která nám prochází je z 10/2024.

V rámci nějakých náhodných zoufalých pokusů jsem také zkoušel měnit lokální čas, ale také bez úspěchu.

Od nového roku přešli z RSA-PKCS#1 na RSA-PSS (RFC 8017). Openssl smime neumí RSA-PSS a nejspíš to ani nebude nikdy umět, použíj na to openssl cms.

15

Odkladiště / Re:Zkušenosti s internetovým bankovnictvím

« kdy: 07. 01. 2025, 23:27:32 »

Mobilní bankovnictví je řádově bezpečnější, ...

Za tohle tvrzeni by se melo zavirat ... na dozivoti.

Je to totiz presne naopak, bankovnicvi v mobilu neni zabezpeceno naprosto nijak. Kdokoli ten mobil zcizi(nebo hackne), ma zcela neomezeny a nicim nezajisteny pristup.

Fakt by mě zajímalo, kolik budou mít ty speciální HW autentikátory,...

Ve firemnim sektoru urcite znacny. Ony totiz jestli firmy typicky o neco nestoji, tak je to to, ze se jim jejich ucetni prihlasuji k firemnim uctum soukromym mobilem. Zdravime KB a CSOB ... (mozna nekdo dalsi potvrdi i dalsi pripady)

A pokud bys to nahodou nepochopil, tyhle ustavy(choromyslnych) nechapou(nedokazou to, protoze jejich celkove IQ je -∞) ze soukroma osoba je nekdo jiny nez zamestnanec, a to ze se nekdo prijlasuje mobilem k soukromemu uctu neznamena, ze by mu melo byt dovoleno se stejne prihlasit k dalsim uctum na ktere ma dispozicni prava.

BTW: Ad SMS jednak neni pravda ze by to bylo nesifrovane, ale ta sifra je davno prolomena. Existovaly casy, kdy se bezne pouzival SIM Toolkit ... jenze to se zase nikda nanaucil pouzivat droid.

já ti nevím.

Když ti někdo hekne nebo ukradne počítač, jsi na tom stejně. Posuzovat míru bezpečnosti tak, že si rovnou skočíš do stavu, že bezpečnost je prolomena je vtipné. Netuším, jak můžeš tvrdit, že bankovnictví v mobilu není zabezpečeno nijak.

K těm sms, v 2G/3G legacy sítích se sms přenáší v nešifrovaně, pouze se kóduje. V LTE se k posílání sms používá buď IMS (tam je šifrování neúčinné) nebo diameter (tam není). V 5G se také používá IMS, ale již to je nedílnou součástí a není potřeba to dodělávat jako plugin, stačí znát imsi a sms si přečteš, když se hodně snažíš. VoLTE je asi pro sms nejbezpečnější cesta.

Drtivá většina sms se v ČR přenese nešifrovaně v 2G síti (3G síť už skoro není), ČTÚ nařizuje provoz 2G sítě do roku 2028.