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 ... 22 23 [24] 25 26 ... 375
346
Sítě / Re:Veřejná IPv4 a IPv6 a bezpečnost
« kdy: 29. 10. 2022, 12:57:32 »
Bezpeci ma (minimalne) dva vyznamy. Jeden pocitovy, netechnicky, jako ze kdyz bude za natem tak se mu bude lip spat. V tomto vyznamu NAT bezpeci poskytuje.
Tohle ovšem není „bezpečí“, ale „pocit bezpečí“. A pokud něco neposkytuje bezpečí ale poskytuje to pocit bezpečí, ve skutečnosti to naopak bezpečnost snižuje. Protože dotyčný má pocit, že je v bezpečí, nesnaží se o další zabezpečení, není obezřetný a tím se vystavuje nebezpečí.


Druhak bezpeci v oboru pocitacovych sitich znamena uroven prekazek v pristupu nekam, a NAT jako takovy prekazka je, urcitym druhem zabezpeceni tedy take je. Muzeme se samozrejme bavit o tom jak velkou prekazkou (urovni bezpeci) je, ale rikat ze nat nema nic spolecneho se sitovou bezpecnosti je podle me nespravne, a hranici to s bezpecnostni propagandou.
Chyba ve vaší úvaze je v tom, že předpokládáte, že každá překážka zvyšuje bezpečnost. Jenže to není pravda. Za prvé, aby překážka zvyšovala bezpečnost, musí působit systematicky – ne že útočníka zastaví jen v případě, kdy na ni náhodou narazí. Bankovní lupič může zakopnout o obrubník chodníku před bankou, rozbije si nos a banku nevyloupí. Cizojazyčný bankovní lupič může narazit na vstupní dveře s nápisem táhnout, nepodaří se mu je otevřít (bude tlačit), zazmatkuje a uteče. Můžete mít neoplocenou zahradu a v jednom místě dva metry zapomenutého plotu – může se stát, že se k vám někdo bude chtít v noci dostat, narazí zrovna na ten plot a nevšimne si, že jde obejít. Ale nic z toho není zabezpečení, protože to útočníka zastavilo jenom náhodou.

Za druhé, aby překážka zvyšovala bezpečnost, musí chránit proti nějakému vektoru útoku, proti kterému nechrání jiná věc v obranné sestavě. (Pozor, několik vrstev zabezpečení s tím není v rozporu – každá vrstva chrání jiným způsobem, takže je namířená proti jinému vektoru útoku.) Pokud do trezoru umístíte papírovou krabici, není to bezpečnostní opatření, protože kdo dokázal otevřít trezor, poradí si i s papírovou krabicí.

NAT chrání asi tak stejně, jako kdybyste měl kolem baráku plot, ale kus by ho chyběl – a v tom místě by byl normální průchod, nijak nehlídaný, dalo by se tam projet autem…

347
Software / Re:Mobilny prehliadac a podpora notifikacii
« kdy: 28. 10. 2022, 13:35:46 »
Funguje to na Androidu. Safari to v základním nastavení nepodporuje, a i když se začátkem roku šuškalo o tom, že příští verze už to bude mít pro všechny, stále je to schované pod experimentálními funkcemi, které si musí uživatel ručně zapnout.

Jinak ohledně podpory technologií v prohlížečích je nejlepší se podívat na Can I use, třeba to Push API: https://caniuse.com/push-api

348
O serveru Root.cz / Re:Reklama Barum
« kdy: 28. 10. 2022, 10:57:46 »
Teď se mi objevila stejná reklama (Barum Continental)
Dnes opět stejná reklama (Barum) a tentokrát už byla za obsahem fóra. Na oči teda pořád hrozné, jak je to všude v každé skulině mezi obsahem, ale aspoň už člověk vidí obsah fóra.

349
Bazar / Re:Hledám knížku - Pro Git (Scott Chacon)
« kdy: 28. 10. 2022, 10:26:40 »
Pokud by vám stačila elektronická: https://www.root.cz/knihy/pro-git/ Překvapuje mne, že vyšla papírově, asi to byl hodně nízký náklad.

350
Server / Re:Certifikáty pro vývoj na localhostu
« kdy: 28. 10. 2022, 00:04:44 »
Generuje to řadu problémů, aplikace jsou čímdál složitější, často potřebují artefakty, které jsou na CDN, počítají s nějakou cachováním, někdy si ověřují certifikáty, někam logují, počítají s nějakými timeouty na straně serveru, někdy potřebují databázi
Něco z toho je problém, když ta aplikace má webový frontend vystavený na localhostu? Já mezi vyjmenovanými věcmi nevidím nic, co by záviselo na tom, jestli to běží na http://localhost:8080 nebo na https://pepa.example.com. Také mi stále není jasné, jak cokoli z toho souvisí s přenositelností na jiný počítač.

třeba v případě Wordpressu se rádi instalují podle domény
Tohle je jediný případ, kdy si dovedu představit problém – ovšem při vývoji nějakého pluginu je asi jedno, jak se jmenuje doména, a při konfiguraci konkrétního webu bych to raději dělal na cílovém serveru. Ale uznávám, že v některých případech by se v tomhle případě mohlo hodit nechat přesměrovat si doménu lokálně a nechat si vystavit ten certifikát.

Jinak teda jediný praktičtější případ, který mne napadl, je použití API, kde není localhost povolený pro CORS. Ale to se dá řešit buď povolením nebo proxy.

351
Server / Re:Certifikáty pro vývoj na localhostu
« kdy: 27. 10. 2022, 19:09:37 »
není lepší prostě na localhostu nedělat vývoj? Ono to je pak vždy těžko přenositelné, máš vše na jednom počítači, nemůžeš dát jednoduše přístup někomu jinému atd.
Čemu přesně říkáte „vývoj na localhostu“? Já tak říkám tomu, že si stáhnu zdrojáky z git repository, pustím npm install a pak npm dev (nebo něco podobného), ladím to v prohlížeči, edituju v IDE, a když jsou změny hotové, comitnu a pushnu je do git repository. Když chce vyvíjet někdo jiný, udělá to samé na svém počítači. Není to těžko přenositelné, stačí git clone a npm install (ano, je potřeba mít dostatečně novou verzi gitu a dostatečně novou verzi node). Není vše na jednom počítači, je to na počítačích všech vývojářů, ve všech git repository na serverech atd. Rozpracovanou verzi na lokálním počítači nechci zpřístupňovat nikomu jinému. Teprve dokončené verze z toho samého repository nasadím na server, kde je to teprve přístupné dalším, ale to už není vývoj na localhostu.

352
Server / Re:Certifikáty pro vývoj na localhostu
« kdy: 27. 10. 2022, 16:53:47 »
V drtivé většině případů neřeším, protože http://localhost spadá do Secure contexts, takže se k němu prohlížeče chovají, jako kdyby to bylo načtené přes HTTPS. Pokud potřebuju opravdu otestovat HTTPS, mám na 127.0.0.1 a ::1 nasměrovanou doménu ve stylu localhost.example.com a pro ni mám vystavený certifikát od LE. Ale vlastně ho teď nemám ani obnovený, používám to tak málo kdy, že jsem ani neřešil automatizaci a obnovím ho jednou za uherský rok, když to potřebuju.

353
Myslím tím, že z hlediska bezpečnosti je jedno, zda ISP NAT používá nebo nepoužívá. To, že se k vám nedostane jednoduše útočník z druhého konce světa neznamená, že stejný útočník není s vámi ve stejné síti za NATem. Nebo že nesedí v síti hned před NATem, odkud se za NAT dostane také. Takže když budete plánovat obranu, musíte počítat s tím, že útočník je ve stejné síti.

Je to jako kdybyste vytrénoval psa, že nepustí na zahradu nikoho, kdo má modrou bundu. Určitě pak nepřestanete zamykat – protože víte, že pes pustí kohokoli, kdo modrou bundu nemá.

A jestli NATem myslíš jen tu část A -jMASQ bez části BÉ -ctstate INVALID-DROP/ESTABLISHED-ACCEPT.
NATem myslím NAT a ne firewall. Tedy jen A a ne B. Když to v iptables není v tabulce nat (nebo případně mangle), není to NAT.

355
Já sibling chápu tak, že je to sousední element na stejné úrovni zanoření, tedy sourozenec(už ten název to přeci říká).
Ano, ale není to jen jeden sourozenec, jsou to všichni následující sourozenci. Teprve dalšími pravidly určíte, které z těch sourozenců chcete. To, co je v XPath následováno dvěma tečkami, je specifikace tzv. osy – je to množina uzlů v XML nějakým pravidlem odvozená od aktuálního prvku. A teprve z té množiny se pomocí dalších podmínek vybírají konkrétní prvky. To, co běžně používáte (hledání podle názvu elementu) je ve skutečnosti osa child::, akorát XPath umožňuje v takovém případě specifikaci osy vynechat. Podobně umožňuje vynechat osu attribute::. Všechny osy jsou popsané např. v dokumentaci Saxonu: Axis Steps.

356
Neporozuměl jsem, co přesně chcete porovnávat, hledat nebo testovat. Ale:

Podmínky (v hranatých závorkách) se vyhodnocují vždy vzhledem k aktuálnímu uzlu. Takže

Kód: [Vybrat]
/ResultSets/ResultSet/Row[following-sibling::Status]

hledá od elementu Row sourozence typu Status, a takoví v tom XML určitě nejsou – Row má jako sourozence zase jen Row.

following-sibling neznamená „sourozenci“ a už vůbec ne „nejbližší sourozenec“, ale znamená to, že to, co je za dvojtečkou, se bude hledat na ose následujících sourozenců. Takže když jste na elementu Row, following-sibling::Row najde všechny následující elementy Row, které mají stejného rodiče. following-sibling::* najde všechny následující elementy (bez ohledu na typ), které mají stejného rodiče. following-sibling::*[1] najde nejbližší následující element, který má stejného rodiče. Atd.

357
Sítě / Re:Veřejná IPv4 a IPv6 a bezpečnost
« kdy: 21. 10. 2022, 13:20:11 »
Tak asi budou scénáře, kdy NAT* pomůže. Ale je tu příliš scénářů, kdy NAT nepomůže (vizte moje příspěvky výše), takže bych se na to nespoléhal. Navíc se opíráte o bezpečnost routeru. Jak dlouho váš výrobce vydává bezpečnostní aktualizace? Pokud to výrobce vůbec dělá, instalujete je?
Tak ono lze vymyslet scénář, že pomůže, že má router červenou barvu. To ale ještě neznamená, že něco takového budu reálně řešit, protože ten scénář je extrémně nepravděpodobný.

*) IIRC při čistém NAT bez firewallu stačí routeru poslat zvenku packet na vnitřní IP adresu, a jsem za NATem. Základní firewall tomu může zabránit.
Hlavně se celou dobu bavíme o NATu u ISP. To znamená, že jste za NATem ve stejné síti s dalšími zákazníky ISP, možná se všemi. Abyste od nich byl oddělen, potřebujete konfiguraci routování nebo firewall – to, že jste s nimi společně za NATem vám nijak nepomůže. A jste si jist, že některý z těch zákazníků není sám útočníkem, a hlavně že žádné ze zařízení ostatních zákazníků není ovládané útočníkem?

358
Sítě / Re:Veřejná IPv4 a IPv6 a bezpečnost
« kdy: 20. 10. 2022, 19:51:19 »
Problém je, že zjevně nemáte tušení, jak často se stane, že někdo nainstaluje a spustí něco, co sice někde poslouchá (nebo obecně provádí nějaké kejkle se systémem), ale chtěné to není.
Ale mám.

Takže tuhle situaci: "firewall tam nebude ale poběží tam služba, která ale chtěná není" jste tak nějak taktně opominul protože se vám to nehodí. Čili jako obvykle.
Ne, situaci jsem neopominul. Této situace jsem si vědom – ale zároveň vím, že tu situaci firewall nezachrání.

To byl omyl nebo to bylo úmyslně a je to tedy poněkud laciná, ovšem ve vašem případě, pane Jirsáku, poměrně obvyklá demagogie?
Co kdybyste si odpustil ty invektivy? Vaše osobní problémy tu nikoho nezajímají.

Vaší moc ne. Jenomže Franta uživatel není vy. Franta uživatel má neskutečnou schopnost udělat si v systému naprostý bordel a obvykle o tom navíc často ani nevědět. Co je tazatal pochopitelně nevím, ale proto musím předpokládat to horší.
Což ovšem NAT nijak nevyřeší. Protože ten bordel v systému bude komunikovat zevnitř sítě ven, tedy NATem projde jako po másle. A jako bonus bude ještě komunikovat s ostatními zařízeními v lokální síti, o kterých vy si myslíte, že jsou „schovaná“ za NATem.

360
Sítě / Re:Veřejná IPv4 a IPv6 a bezpečnost
« kdy: 20. 10. 2022, 18:39:13 »
To není úplně pravda. Když třeba na Arch Linuxu bez jakékoliv konfigurace spustíte třeba UFW, bude odmítat veškerý nechtěný příchozí provoz. Což je v jeho případě to, co chce, nic víc k tomu vědět nepotřebuje a poslouží mu docela dobře.
Zatímco když tam ten firewall nebude a nepoběží tam žádná služba, bude to odmítat veškerý nechtěný příchozí provoz. A když tam nějakou službu nainstaluje a spustí, bude to zase odmítat veškerý nechtěný příchozí provoz – protože ta služba bude chtěný provoz. C.B.D.

[quote author=Martin Poljak link=topic=26803.msg378121#msg378121
Ani to není úplně pravda. Odstíní ho od různého primitivního automatizovaného botnetového provozu na různé frekventované porty.
[/quote]
Což ovšem nijak nezvyšuje bezpečnost.

Atokonto mě fascinují rady zdejších guru vyprávějících jak vlastně nepotřebuje nic, že je úplně v pohodě, když coby sysadminovský analfabet (vzhledem k tomu, že je běžný uživatel) má vystavovat veřejnou IP adresu bez toho, aby byl schopen či ochoten kontrolovat co kde poslouchá a v jaké verzi a nenainstalovat ani ten blbej firewall, co všechny porty prostě zavře což je v daném případě to nejlepší, co lze udělat.

Fakt se lidi proberte, tohle nejsou síťaři jako vy.
Ale ono opravdu není potřeba nic a je to úplně v pohodě. Naštěstí, takže se do internetu mohou připojit i lidé, kteří nejsou síťaři.

Dříve bych se bál nechat do internetu vystavené bez nějaké další ochrany Windows, ale ani to už není u 10 a 11 problém. U Linuxu a macOS to nebyl problém nikdy.

Daleko lepší rada je „neinstalujte/neaktivujte nic, o čem alespoň rámcově netušíte, co negativního to může způsobit“. Víte, co negativního může způsobit firewall? Ne — tak ho neaktivujte.

Stran: 1 ... 22 23 [24] 25 26 ... 375