Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 45 46 [47] 48 49 ... 375
691
Software / Re:Rsync celého disku
« kdy: 19. 02. 2022, 09:43:03 »
Tak moznost by bola
Kód: [Vybrat]
find -mtime
odporucam
Kód: [Vybrat]
find -- help
to ale bude zrejme fungovat na fs ktory si uklada cas zmeny suboru, ako na tom ntfs neviem.
Takže místo aby rsync procházel všechny soubory na disku a zjišťoval, jestli se změnil jejich čas změny, tak by find procházel všechny soubory na disku a zjišťoval, jestli se změnil čas změny… Hm, jak by to asi mohlo pomoci?

Jediný rozdíl je v tom, že rsync to porovnává proti času modifikace souboru na protějším disku, takže ho také musí načíst. Ale pokud není cílový disk pomalejší, než zdrojový, nemělo by to mít na přenos podstatný vliv.

NTFS čas změny souboru ukládá.

Nicméně pokud vím, NTFS ukládá čas změny s nižší přesností, než Linux, což by znamenalo, že i stejné soubory musí rsync porovnat podle obsahu. rsync by měl ve výchozím nastavení porovnávat čas modifikace s přesností na sekundy, ale teoreticky může být někde výchozí nastavení jiné. Některé verze rsync mají přepínač --modify-window, kterým je možné nastavit, jak různé časy modifikace souboru má rsync ještě považovat ze stejné.

692
Software / Re:Rsync celého disku
« kdy: 18. 02. 2022, 19:50:47 »
Není to žádná chyba, rsync takhle pracuje (a nemůže pracovat jinak). Když chcete synchronizovat dva disky, rsync musí projít všechny soubory, zjistit, které jsou na druhé straně starší nebo tam chybí, a ty na druhou stranu přenést. Standardně rsync neprochází obsah všech souborů, jenom ty, kde se liší velikost nebo čas, ale projít všechny soubory na disku musí. OS neposkytuje (ani neukládá) žádné informace o tom, které soubory se změnily od nějaké doby.

693
Server / Re:cloudfare - ochrana emailovej adresy na webe
« kdy: 17. 02. 2022, 19:11:47 »
Nemyslím, že by to poznávali. Nahradí e-maily v HTML kódu a pak je zase JavaScriptem v prohlížeči nahradí zpět. V prohlížeči tedy nic nepoznáte, ale pokud robot stahuje jenom HTML a v něm hledá regulárním výrazem e-mailové adresy, nic nenajde.

694
Zajímavé, na to jsem nepomyslel.
Tyo HTTP-01 a ALPN-01 jsou metody žádosti o certifikát? Já jsem četl, že jsou metody. Přes umístění souboru do .well-known/... a druhá přes umístění záznamu do DNS.
Ano, přesněji jsou to metody pro ověření toho, že jste oprávněným vlastníkem domény (nebo jeho zástupcem). Metody HTTP-01 a ALPN-01 komunikují přímo s cílovým serverem (podle A nebo AAAA DNS záznamů), poslední metoda DNS-01 komunikuje s doménovým serverem, takže s ní je možné certifikát vystavit dřív, než existuje cílový A/AAAA záznam.

Jo a mimochodem je nějaký defaultní čas interval automatického prodlužování LE certifikátu?  Něco jako 15 dní? (Vím že platnost je 90 dní)
Defaultní ne, vždy to záleží na konkrétním klientovi. Typické je obnovovat je každé 1 nebo 2 měsíce.

Na tom serveru nevidím nic divného....
Pokud to byl opravdu přesun na jinou IP adresu (případně jiný server, jiného poskytovatele), už na tom nejspíš nic neuvidíte.

Divné je, že má ping 1ms  :o  Já mám ping na začátek internetu kolem 18ms a spíš tak 30ms doprostřed českého internetu..
V rámci českého internetu není 1 ms neobvyklá.

695
Nejjednodušší vysvětlení je, že se web stěhoval na jinou IP adresu a v DNS to bylo dřív, než došlo k vystavení certifikátu. Což je u certifikátů vystavovaných přes ACME časté, protože vystavení přes HTTP-01 nebo ALPN-01, jak to dělá ve výchozím nastavení většina nástrojů, vyžaduje správný A/AAAA záznam. A co si budeme povídat, je to i nejjednodušší – certifikát vystavený od LE máte během pár vteřin, a u webu typu wordle.cz se nic nestane, když to pár vteřin nebude fungovat.

Případně mohl být nějaký jiný důvod, proč HTTPS server ještě neměl vystaven certifikát na správné jméno. Chyba v prohlížeči či serveru je nepravděpodobná – už by se s tím setkal někdo dřív.

696
Neskúšal som to, ale za pokus to stojí. Ak to dobre chápem, uvádzajú tam, že užívateľ nezíska vyššie oprávnenia v zmysle, že by mal práva napr. na súbory, ktoré patria administrátorovi, len to deaktivuje UAC (pokiaľ viem, UAC nefunguje ako v linuxe sudo, že by to menilo užívateľa, pod ktorým spúša proces). Prečo by tam inak dávali príkad s regeditom?
Ano, uživatel tím nezíská vyšší oprávnění. Má tedy smysl to používat akorát v případě, kdy uživatel nepotřebuje získávat vyšší oprávnění (protože už potřebná vyšší oprávnění z nějakého důvodu má). Příklad s regeditem je tam proto, protože na něm je hezky vidět, že na své klíče se uživatel stále dostane, ale když se pokusí editovat systémové klíče (Local Machine), nepodaří se mu to, protože nemá dostatečná oprávnění.

697
Malo by to ísť:
http://woshub.com/how-to-disable-uac-for-specific-applications/
To způsobí, že se nezobrazí UAC dialog, ale aplikace nezíská vyšší oprávnění.

698
FYI drtivá většina těch boxů jsou soupravy pro servisáky, co na nich mají nachystaný sady pro servis airgapped zařízení u zákazníků. Technický manuály, postupy, balíky aktualizací (včetně mapových podkladů), instalační image, což s ohledem na objem není reálný udržovat aktuální vzduchem.
Proč tohle nemáte na SSD discích? Očekával bych, že to nebude moc velké a vejde se to i na levné SSD. Předpokládám, že s tím servisáci cestují, takže by určitě bylo lepší, že SSD nemá pohyblivé části – a jistě by ocenili i to, že je to lehčí a menší.

699
Vývoj / Re:BASH - komunikace klient-server
« kdy: 15. 02. 2022, 16:42:07 »
Záleží na tom, jak robustní řešení chcete. Jestli ty příkazy pořád budete spouštět ručně a pohlídáte si konkurenční přístup, nebo jestli to má být součástí nějakého automatizovaného řešení. V tom druhém případě byste musel vyřešit, aby s jednou instancí aplikace v jednu chvíli komunikoval jenom jeden klient – a to podle mne nevyřešíte jen na úrovni rour, musela by tam být nějaká logika, která pozná, kdy byl jeden příkaz dokončen a může být odeslán další příkaz.

Pokud stačí ta první varianta, měly by stačit dvě pojmenované roury vytvořené přes mkfifo. Jednu napojíte na vstup vaší aplikace – co pošlete do roury, objeví se na vstupu aplikace. Druhou napojíte na výstup té aplikace a k té rouře se připojíte, když budete chtít číst výstup té aplikace. Zhruba takhle nějak:

Kód: [Vybrat]
mkfifo app_in
mkfifo app_out
aplikace < app_in > app_out
echo -e 'CONNECT\n' > app_in
cat < app_out
echo -e 'SHOW STATUS\n' > app_in
cat < app_out
Ten výpis výstupu samozřejmě budete vždy muset přerušit, když budete mít pocit, že už se vypsalo všechno.

700
Odkladiště / Re:Zdielanie hesiel v rodine
« kdy: 13. 02. 2022, 16:22:38 »
Zalezi ako sa to konkretne chova, kam to uklada hesla, ako su ulozene.
Hesla jsou uložená v souboru šifrovaná master heslem.

Ked by bolo presne nieco taketo na trhu, nemam s tym v zasade problem, ale chcem, aby tie data boli moje a mal som k nim pristup aj bez extensiony v browseri. Chcem, aby bol ten password manager samostatny a aby to bolo lahko prenositelne a malo to interface na konzolu.

Som same ucho, aka existujuca extensiona a program toto splna.
S výjimkou toho šifrování pomocí GPG splňuje všechno třeba Bitwarden. Je opensource, existuje jako GUI (desktopové i mobilní), CLI i rozšíření do prohlížeče. Hesla jsou uložená offline v šifrovaném souboru. Umožňuje i synchronizaci online, ale tu používat nemusíte. Ten server si i můžete hostovat u sebe a dokonce existuje i alternativní (nezávislá) implementace serveru Vaultwarden, která implementuje některé funkce, které jsou u Bitwarden serveru jen v placených plánech. A kdybyste se pořád bál, že ta aplikace jednoho dne kompletně přestane fungovat, můžete si pomocí CLI cronem hesla třeba jednou denně exportovat a zálohovat.

Ked nad tym tak rozmyslam, tak vy ste vlastne dohnali do extremu fakt, ze si nekontrolujem nejake URL adresy s tym, ze moje navyky su nebezpecne a tak vlastne cele moje riesenie je postavene na vode. To sa mi zda voci mne dost nefer.
To je váš problém, že vám to připadá nefér. Největší nebezpečí, že heslo unikne od vás, je phishing – heslo prozradíte útočníkovi, když si budete myslet, že ho zadáváte na správný web, ale web bude falešný. Vaše řešení proti takovémuto útoku nijak nechrání. Asi jako kdyby zloději nejčastěji vykrádali byty tak, že odemknou zámek bez klíče, a vy byste si ve dveřích nechal obyčejnou fabku, ale zato byste namontoval na okna mříže a zazdil byste komín.

Zaroven nemam rad, ak zavisim na jednom konkretnom rieseni ktore je online a som vydany napospas nejakej firme ktora tu za 5 rokov nemusi byt, hacknu ju, stane sa to platene atd atd. Jednoducho musim zavisiet na nejakej externej a sukromnej entite.
To se pořád akorát bráníte něčemu, co pová snikdo nechce. Existují i offline password manažery, ostatně vy jeden jednoduchý používáte. A i drtivá většina password manažerů, které umí komunikovat online, použvá online jenom k synchronizaci hesel – takže i kdybynějaká firma vypnula servery, hesla na zařízení mi pořád zůstanou. A pořád je můžu vyexportovat do CSV a přenést jinam.

Kdezto ked mam raz Git repozitar a zasifrovane to je s GPG tak to je nepriestrelne a zelezobetonove riesenie.
Ne, není to neprůstřelené a železobetonové řešení. Namontoval jste si na okna mříže, ale zdolědji chodí dveřmi.

Ten program, pass, ani nemusi uz existovat, pretoze budem schopny rozsifrovat nejaky zasifrovany subor s mojim klucom aj cisto z konzoly bez nejakeho dalsieho programu.
Ne, k rozšifrování pořád budete potřebovat GPG – to je ten program, na kterém jste závislý.

701
Odkladiště / Re:Zdielanie hesiel v rodine
« kdy: 13. 02. 2022, 14:05:02 »
Mozno otvorim, ale potom by som tam musel zadavat heslo atd bez toho, aby som si vsimol, ze to je podvrh.
Právě že to závisí jenom na tom, že si všimnete. Což není moc pravděpodobné, když podvrh neočekáváte.

Ale nie je to pre mna dovod, preco by som to mal pouzivat, pretoze mam nejake navyky atd. Viem, ze to moze zniet dost alibisticky :)
Pokud máte své nebezpečné návyky, je to vaše věc. Ale něco jiného je doporučovat ostatním, aby si také vybudovali takový nebezpečný návyk.

Ak by bol ten pass spraveny tak, ze by mal svoju extension do browsera a cital to z lokalneho git repozitara, to by bolo asi najviac nepriestrelne riesenie. Bohuzial nic take neexistuje zatial (sa mi zda) a som ochotny to, ze to nekontroluje ci sa ta URL zhoduje, strpiet.
Existují jiní správci hesel, kteří fungují v offline režimu a rozšíření do prohlížeče mají. Ale to zase bdue proti vašim návykům…

702
Odkladiště / Re:Zdielanie hesiel v rodine
« kdy: 13. 02. 2022, 13:42:09 »
minimalna sanca na phishing v tomto pripade, fakt si na to pockam ...
Minimální pravděpodobnost útoku, ovšem v případě útoku vysoká pravděpodobnost, že bude úspěšný. Pokud jde o bezpečnost, nemám rád, když se násobí nízká pravděpodobnost vysokou, protože to může dopadnout všelijak. Dávám přednost tomu, když se násobí dvě nízké pravděpodobnosti.

ja si nepamatam, kedy mi prisiel e-mail, ktory sa tvaril podozrivo a zaroven este som na neho klikol, asi nikdy.
Vy tenhle argument myslíte vážně, že? Tohle ale nedokazuje vůbec nic. Lidé, kteří podlehli phishingu, vám bude tvrdit to samé – že si ničeho podezřeléhlo nevšimli.

ak by mi napriklad prisiel e-mail od CSOB ze mame pre vas produkt xyz atd, tak to ani necitam. Nezaujimaju ma tie ich "nove produkty" atd atd.
Fajn, takže některé e-maily nečtete. Ale jiné e-maily nejspíš čtete, a když vám takový e-mail pošle útočník, otevřete ho.

703
Odkladiště / Re:Zdielanie hesiel v rodine
« kdy: 13. 02. 2022, 11:40:45 »
Je to mozne. Ide o to riziko ako je velke, na ake stranky chodite atd. Ak mate ku kazdej stranke ine heslo a 2FA a vseobecne si davate pozor, tak si myslim, ze uz ste vo vseobecnosti dost safe.

Je to naozaj siroka tema. Ale napr. ze phishing e-maily. Ked mi to nehodi rovno do spamu a pride mi nejaky email od xyz o abc tak ja uz na prvy pohlad rozoznam ze to je nejaky spam a automaticky to mazem, ani to neotvaram. Ani ma to nepokusa vidiet, co v tom emaily je. Na phishing sa chyti vela "amaterov", ako starsi ludia atd ktori nemaju cit pre taketo veci a klikaju hore dore. Samozrejme, ze to nie je len ich domena a obetou sa stanu aj "uvedomeli pouzivatelia pc" ale ja tam vidim vyraznu korelaciu.
Když to shrnu, víte jen o primitivních phishingových útocích na vaši osobu, takže to vlastně moc neřešíte. Takže je jen otázka času, kdy nějaký lepší phishingový útok na vás bude úspěšný. Nejspíš bude stačit, když e-mail bude správně česky a povede na rozumně vypadající stránku.

704
Odkladiště / Re:Zdielanie hesiel v rodine
« kdy: 13. 02. 2022, 10:53:42 »
Filip Jirsak, uz som to tu raz pisal, preco to prehliadate a stale si idete tu svoju basnicku dookola. Ano pasword manazerovy neunikne zmena domeny, ale to je tak vsetko pred cim to chrani. Nic ine.
Password manažery ještě výrazně přispívají k tomu, abyste měl unikátní a dostatečně silná hesla. Přičemž tyhle třo věci jsou dnes největší rizika – že budete mít stejné heslo něke jinde, že bude heslo slabé, a že z vás útočník heslo vyláká trikem. Všecho ostatní jsou proti tomuhle zanedbatelná rizika. Takže ano, správci hesel vás chrání „jenom“ před těmi největšími hrozbami.

Řešení s kopírováním nebo opisováním hesel vás možná chrání před něčím nedůležitým, ale ochrana před skutečnými hrozbami tam chybí.

Pasword manazer mi ale nevie zarucit ze moje hesla ulozene na ich serveroch su fakt chranene pred zneuzitim, ja nemam cestu ako zistit aky softver im bezi na servery a komu vsetkemu predavaju data o mne.
Zaručit to dokáže hrozně jednoduše – tak, že server ta hesla vůbec nezná a znát nemůže, protože se šifrují už na klientovi. A pokud se tolik bojíte online správců hesel, existuje i mnoho offline řešení.

Dalej cross-site scriptin. Staci mat otvorenu nakazenu stranku na inom tabe a utocnik si precita vsetky data z ostatnych tabov, to znamena ze vie ukradnut aj session cookies a teda vykonavat akcie za vas pekne v pozadi bez nutnosti vizualneho otvorenia noveho tabu. A podobne chutovecky, s ktorymi hackery prichadzaju.
To je nesmysl, vůbec netušíte, o čem píšete. Navíc to nijak nesouvisí se správci hesel – session cookie je pořád stejná, bez ohledu na to, zda heslo vyplnil správce hesel nebo jestli jste heslo opisoval s papírku.

Este by som doplnil, ze to heslo v podstate ani vobec kopirovat nemusite, ak mate heslo napr. ako 4mS45o%sdxaZy!d^s tak nie je problem si ho len s pass zobrazit v konzole a proste ho tam rucne opisat a odmietnut aby si to browser pamatal (take to vyskakovacie okno, kde povolite, aby vam to tam uz potom vyplnalo automaticky, takze to nedrzi ani browser). Mozete namietnut, ze to je predsa neprakticke, ale to je mi v mojom pripade tiez jedno :)
Ano, je to nepraktické. Ale hlavně jste se chytil té nejméně podstatné věci. Útok, se kterým se dnes setkáte nejčastěji, je phishing. Proti tomu vás žádné opisování nebo kopírování hesel nechrání.

705
Odkladiště / Re:Zdielanie hesiel v rodine
« kdy: 13. 02. 2022, 09:52:04 »
mozete to rozvinut? uprimne ma to zaujima. To akoze ked mam Linuxovy clipboard a skopirujem si heslo (ctrl+c / ctrl + v) do weboveho formulara, tak to je bezpecnostne riziko?
Ano. Největší bezpečnostní riziko je to, že to heslo vložíte do špatného formuláře. Pokud na vás zaútočí phishing a vy si toho nevšimnete, sám vložíte heslo do stránky připravené útočníkem. Rozšíření v prohlížeči se to nestane, protože to porovnává doménové jméno a „nepřehlédne“ přesmyčku nebo prostě jen jinou doménu. No a pak jsou tu ještě ty méně důležité možnosti – heslo je ve schránce a zůstane v ní i po vložení, takže ho můžete vložit jinam (jak na webu, tak mimo něj), a aplikace běžící v počítači si mohou kdykoli obsah schránky přečíst (což už by vyžadovalo kód útočníka spuštěný na vašem zařízení – ale pokud rozšifrováváte celý soubor s hesly, pak by v takovém případě jedno heslo ve schránce bylo nezajímavé, protože ten kód by měl přístup ke všem heslům).

Stran: 1 ... 45 46 [47] 48 49 ... 375