Příspěvky

256

Server / Re:Ochrana přístupu k webové aplikaci

« kdy: 16. 01. 2023, 15:19:53 »

Jak píšou ostatní, je to pár řádků do konfigurace reverzní proxy. Předkonfigurované tak, že by někdo napsal těch pár řádků konfigurace za vás, to těžko někde najdete. Možná by to šlo udělat třeba přes Cloudflare, ale to stejně budete muset nakonfigurovat a stejně byste musel nakonfigurovat vaše weby tak, aby se k nim dostalo jen Cloudflare – to už je jednodušší rovnou nakonfigurovat tu reverzní proxy chráněnou heslem.

Já mám v oblibě Caddy server, ten se sám postará o HTTPS a výměnu certifikátů, reverzní proxy je možné nakonfigurovat rovnou při startu z příkazové řádky, autentizace jménem a heslem se zapne pár řádky konfigurace a dá se najít příklad konfigurace s reverzní proxy chráněné heslem.

257

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 16. 01. 2023, 14:29:37 »

Přestaň blokovat neveřejné IP adresy (tak jako je neblokuje ani nikdo jiný, kdo má sám IP veřejnou), všechno bude

Právě naopak, ostatní, kteří mají veřejnou IP adresu, běžně adresy z privátních rozsahů blokují. Třeba proto, že je sami používají, a fakt nechtějí, aby jim do privátní sítě lezl někdo z venku.

všechno bude fungovat

To je dost odvážné tvrzení (jako v tom vtipu: „Ten kůň není blbý, on je odvážný!“). Zejména když vám tu několik lidí popsalo, jak to v síti takového ISP často vypadá a že pak žádná úprava na firewallu zákazníka nepomůže, dokud si to nespraví ISP.

258

Sítě / Re:Poplatek za IP adresu

« kdy: 16. 01. 2023, 09:48:01 »

Obecně se IP adresy ISP nepřiřazují po jednotlivých adresách, ale po blocích, které mají třeba tisíce adres. Prakticky všechny IPv4 adresy jsou rozdělené mezi několik regionálních poskytovatelů (přibližně na úrovni kontinentů), což jsou neziskovky, které spravují adresy v dané oblasti. Třeba pro Evropu je to RIPE NCC. ISP jsou členy této organizace, platí příspěvek podle počtu adres, které má. Dříve platilo, že kdo si o nějaký blok IP adres požádal a splnil podmínky, dostal ho. Pak se pravidla postupně zpřísňovaly a dnes už RIPE nemá žádné adresy, které by přidělovalo – maximálně se občas může stát, že se nějaký blok vrátí, pak se přidělí po malých blocích (256 adres) těm, kdo jsou na seznamu podle priority (jestli se nemýlím, mělo by to jít těm, kteří ještě nic nemají).

Nebo-li přidělování volných IPv4 adres, tak, jak fungovalo dříve, už dneska prakticky neexistuje. Takže pokud někdo potřebuje další IPv4 adresy, musí je koupit od někoho, kdo už je má a je ochoten je prodat.

ISP koncovým zákazníkům nenabízejí různé kategorie adres – nevím, podle čeho by se to mělo rozdělit. Ale bývá na výběr stát, ke kterému je blok adres zaregistrovaný – kvůli geolokaci. Jednotlivé bloky IP adres u sebe mají v pomocných databázích uvedené, kdo je vlastní a také kde se ta adresa požívá (v jakém místě) – a ISP vám může dát na výběr z IP adres z různých bloků, kdy každý z těch bloků u sebe bude mít uveden jiný stát.

- vetsinou je to tak, ze zvenku ma hodne/vsichni zakaznici zvenku jedinou IP
- vlastni pevnou verejnou IPv4 chce opravdu jen naprosto minimum klientu

Tohle platí pro ISP, který poskytuje internet domácnostem nebo firmám (pro kanceláře). Tazatel psal ale o VPS, tj. poskytovatelé hostingů, housingů, VPS, cloudů a podobně. Tam naopak platí, že hodně serverů chce veřejnou IP adresu, mnohé i víc. Pokud je to velká infrastruktura, vystačí backendové servery bez veřejných IP adres, ale pokud má zákazník jeden VPS, v drtivé většině případů pro něj chce i veřejnou IP adresu.

259

Vývoj / Re:Maximální délka e-mailové adresy při registraci

« kdy: 15. 01. 2023, 18:40:13 »

hovorit pri emaloch o "standarde" chce naozaj velke gule.

To, že ty standardy neznáte, neznamená, že neexistují.

260

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 15. 01. 2023, 18:38:35 »

Moment, tohle je nějak divné. Zákaznický router ma defaultu ven, dovnitř k zákošovi třeba jen 192.168.1.0/24, a obvykle ta síť providera nebejvá plochá, ale spíš nějaká kombinace OSPF/iBGP (neboli nexthop pro CE router je anténa na střeše, ta má zase jako nexthop nějakej PE na kostele. Aby se to doroutovalo zpátky, vůbec netřeba aby to SNATovalo za internet, stačí cokoli co se dokáže vrátit (i když za veřejku by to bylo lepší, dokážu si představit validní argumenty, proč to někdo dovnitř vlastní sítě neNATuje za veřejku, ale za privátku/nějaký privátní subnet)

Aby DNAT té veřejné IP adresy na privátní fungoval, je potřeba, aby se paket s odpovědí dostal zpět na to NATující zařízení. Protože to musí odpovědní paket „odNATovat“.

BTW to jestli 100.64/10 je privátní nebo CGNAT rozsah je v našem případě irelevantní (a ve skutečnosti můj provider používá kus desítek, jen jsem nechtěl dávat přesnou identifikaci podle které by se poznal když ho tu "pomlouvám"), oboje jsou adresy, které nemají ve veřejném internetu co dělat, ale v případě připojení k síti providera na nich není nic špatného, pokud ofc nedojde ke konfliktu s adresami v LANce (i to se dá řešit, ale nekomplikujme to, tazatel kdyby to uměl řešit by se v první řadě vůbec nemusel ptát.).

Není to jedno. Privátní adresy se nesmějí používat pro komunikaci mezi sítěmi. Naopak 100.64.0.0/16 je blok určený pro sdílení mezi ISP a jeho zákazníky. Takže to nemá zákazník na WAN blokovat a nemůže se stít, že by měl tyto adresy zákazník ve své síti.

Fajn, a co s tím chcete dělat?

Neposílat zákazníkovi pakety se zdrojovou IP adresou z privátních rozsahů.

Jednak je to slovíčkaření (veřejný internet vs. pakety od zákošů s privátními adresy providera chodí z privátního rozsahu providera....)

Není to slovíčkaření. Různé bloky IP adres jsou určené pro různé účely. Když někdo začne adresy používat pro jiné účely, způsobuje to problémy. Je to jako kdyby ISP vzal nějaké veřejné adresy úplně někoho jiného a začal je používat ve své síti, a tvrdil by, že to, že ty adresy mají být globálně unikátní, je jenom takové slovíčkaření.

druhá věc je čistě praktická - buď můžete být pokročilý zákazník, který když je ze strany zákoše neřešitelný problém, tak se domluvíte přímo s technikem, nebo můžete být věrozvěst-puritán, jinými slovy problémista, což stejně k absenci neveřejných adres na WANu nepovede

No a co třeba to udělat tak, aby to fungovalo a zákazník na WAN pakety se zdrojovou adresou z privátních rozsahů nedostával?

Bavíme se o malých ISP, kteří mají jedno nebo několik zařízení, které SNATuje provoz zákazníků do internetu a zároveň DNATuje veřejné adresy těch zákazníků, kteří mají veřejnou IP adresu. Jediné, co je potřeba, je upravit to SNATové pravidlo, které SNATuje provoz zákazníků do internetu, abys SNATovalo i provoz na ty veřejné IP adresy zákazníků. Opravdu je nepřekonatelný problém podmínku toho SNATu rozšířit? Třeba místo odchozího rozhraní dát jako podmínku to, že cílová adresa není z IP rozsahu privátních adres používaných ISP?

261

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 15. 01. 2023, 18:22:13 »

Jediný, kdo nemá představu, jsi ty sám, protože neprovozuješ ani jednu síť (možná tak nějakou houpací na zahradě ano), tak si nevymýšlej, že by někdo pustil do své sítě neveřejné IP ze sítí cizích. Vůbec nevíš, jak sítě fungují a "rady" z Google, kde zjevně čerpáš, jsou ti k ničemu, když tomu celému absolutně nerozumíš.

Až vám dojde, že síť ISP a síť zákazníka jsou dvě různé sítě, mezi kterými nemůže být provoz privátních adres, pochopíte to.

262

Vývoj / Re:Maximální délka e-mailové adresy při registraci

« kdy: 15. 01. 2023, 16:22:25 »

32 znaků je málo, ale na druhou stranu adresu delší než 100 znaků stejně nikdo příčetný jako svoji uživatelskou email adresu používat nebude.

Správci hesel je jedno, jestli vyplňuje 15 znaků nebo 150.

Když je něco dané standardem, není rozumné vymýšlet si vlastní řešení. Asi nedokážete domyslet všechny možnosti, jak se může uživatel chtít registrovat, tak nevymýšlejte, jak ho zbytečně omezit.

263

Vývoj / Re:Maximalna dlzka Emailu pri registracii...

« kdy: 15. 01. 2023, 15:23:15 »

Dejte tam to, co je ve standardu. Proč byste to omezoval? Akorát tím někomu zkomplikujete život. Někteří lidé při registraci používají unikátní e-mail, vytvořený třeba tak, že se za lokální část přidá + a rozlišení daného serveru. Spousta serverů (včetně GMailu) pak část od + dál ignoruje při vyhledávání schránky uživatele, tj. můžete si tak k jedné schránce vytvořit spoustu adres. Třeba takováhle adresa může být dost dlouhá.

Nejlepší je nevymýšlet vlastní validaci na e-mail a použít nějakou už hotovou. Ona validace e-mailové adresy není zrovna jednoduchá a když to budete vyrábět sám, nejspíš na něco zapomenete.

264

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 15. 01. 2023, 09:32:55 »

O tom, že to má lokální provider zprasené by se dalo dlouze diskutovat, dost často (k jednomu takovému providerovi jsem připojený taky) to historicky vypadá tak, že nějak udělá (samozřejmě na privátkách) natovanou síť pro vesnici dvě tři, pak se mu tam objeví zákazník šťoural který chce veřejku, tak mu jí tak nějak dobastlí - v mém případě 1:1 NAT na vstupu na privátku, která na mě reálně kouká z antény. Kvůli těm pár jednotkám zákošů se mu nevyplatí to celé předělávat a u nich zase ví, že nejsou překvapení že prostě občas jim kromě z veřejek přijde něco i z 100.64/16. Jak se říká, za ty prachy to jedno leftid navíc v ipsec.conf člověk přežije ;-)

Ano, tohle je skoro přesně případ, o kterém jsem psal hned ve svém prvním komentáři. Akorát že 100.64.0.0/16 není privátní rozsah, je to rozsah určený právě pro NAT ISP, takže je to v pořádku. Ale hlavně – aby tohle fungovalo, musí ISP vedle DNATu veřejné IP adresy na vaši privátní také SNATovat adresy svých zákazníků za něco, co nebude zákaznický router považovat za adresu v síti svého WAN rozhraní, ale za něco z internetu, co má poslat zpátky na bránu. Když ISP SNAT neudělá (občas na to některý zapomene), může mít zákazník na firewallu nastavený volný průchod dovnitř i ven a stejně to nebude fungovat. No a když už ISP ten SNAT dělá, stačí, aby nepoužíval adresy z privátního rozsahu. Které se na WAN zákaznického routeru prostě objevovat nesmí, protože tak jsou privátní IP adresy nadefinované – mohou se používat pouze pro komunikaci uvnitř privátní sítě.

265

Hardware / Re:Flash disky chráněné proti zapisu do firmwaru

« kdy: 15. 01. 2023, 00:18:13 »

No jasne, ze su. Predpokladam, ze autor to nemyslel uzivatelsky ppomocou nejakeho file manager ale asi mu islo modifikaciu firmwaru flash disku. Ak mas spravny nastroj, tak to ide. V minulosti som niekolko krat upravoval flashky. Dostal som sa k nastrojom par firiem a clovek vedel carovat s urcitymi druhmi USB flashiek. Vedel robit aj napriklad "cinske" velkobjemove flasky z fyzicky malych flashiek. Alebo slo menit ako USB disk hlasil do systemu.

Ak autorovi ide presne o toto, tak nieco take sme riesili davnejsie v byvalej firme. Riesili sme fiskalny modul do registracnej pokladnice. Ziaden WORM disk na trhu neslo zohnat. Sandisk mal vyvinutu WORM SD kartu pre potreby policie

To přece popisujete dvě různé věci. V prvním odstavci píšete o firmware, v druhém píšete o nemožnosti přepisu dat na úložišti, tedy to, co je normálně dostupné jako souborový systém v operačním systému. Přičemž WORM úložiště by potřebovalo speciální souborový systém (např. UDF), protože běžné souborové systémy přepisují minimálně metadata.

Každopádně všem díky za info, že i flash disky mají přepisovatelný firmware.

266

Hardware / Re:Flash disky chráněné proti zapisu do firmwaru

« kdy: 14. 01. 2023, 22:40:44 »

Ony se prodávají flash disky, které mají nějaký firmware, do kterého se dá zapisovat?

267

Server / Re:Komprimovat či nekomprimovat data pro HTTP

« kdy: 14. 01. 2023, 22:39:22 »

Ne, nezáleží na tom, zda je soubor dynamický nebo statický. Záleží na tom, zda už je komprimovaný nebo není. HTML, CSS, JS komprimované nejsou, ty má smysl komprimovat. Navíc minimálně CSS a JS obvykle jsou statické. HTML také, pokud jde o SPA aplikaci.

Typ souboru, délka a podobně neřešíte, to řeší webový server. Vy se o to nestaráte, vy serveru jenom řeknete, jak má ze jména souboru odvodit komprimované jméno souboru. Takže na server nahrajete třeba index.html.gz a serveru řeknete, že když prohlížeč požaduje index.html a podporuje deflate kompresi, má zkusit připojit příponu .gz a pokud takový soubor najde, má počítat s tím, že už je zkomprimovaný pomocí deflate. Když prohlížeč tento typ transportní komprese nepodporuje, server zkomprimovaný soubor na pozadí dekomprimuje a pošle prohlížeči (proto na serveru vůbec nemusí být uložená nekomprimovaná varianta – dekomprese je rychlá, takže když server náhodou potřebuje nekomprimovaný soubor, vyrobí si ho). Případně jeden soubor může být uložen ve více zkomprimovaných variantách, server pak hledá příslušný soubor podle toho, která komprese je nejlepší.

Takže Content-Type se bere podle přípony, stejně jako u nekomprimovaných souborů. Content size se neposílá, posílá se Content-Length a to je délka přenášených dat (tedy komprimovaných), ne souboru. Range reuesty nejsou pro tyto typy souborů potřeba, HTML, CSS, SVG i JS se vždy stahují celé.

268

Server / Re:Komprimovat či nekomprimovat data pro HTTP

« kdy: 14. 01. 2023, 21:22:00 »

Ty mluvíš o za prvé datech typu png, jpeg a mpeg. Ty už jsou uvnitř zkomprimované a je tedy nesmysl je dále komprimovat http kompresí.

Jenom upřesním tohle – komprese používané v těchto formátech jsou starší a ne tak dobré a pokud nemůžete použít modernější datový formát s lepší kompresí, může se vyplatit ty málo zkomprimované soubory zkomprimovat ještě jednou výkonnějším algoritmem pro přenos. Ale jak jsem psal, je potřeba to ověřit v konkrétních případech, zda se to vyplatí.

269

Server / Re:Komprimovat či nekomprimovat data pro HTTP

« kdy: 14. 01. 2023, 13:01:51 »

sobory mozno komprimovat iba v pripade ze ide o archiv urceny na stiahnutie. ak ide o fotky alebo video ktore sa maju prezentovat v prehliadaci, tak komprimovat ich nemozno z toho dovodu, ze potom nemozu fungovat range requesty ani spravny content-length, mime a podobne veci. Proste skomprimovany subor je len blby blob uz. Preto sa vsetko zistuje na servery a komprimuje az na kabli. Ale mozno su nejake techniky ktore mi nie su zname na predkompresiu suborov v tomto kontexte?

Nikoli, komprimují se třeba všechny textové soubory – HTML, CSS, SVG, JavaScript. Archiv určený pro stažení nemá smysl komprimovat, protože už zkomprimovaný je. To samé video, už je zkomprimované. U obrázků záleží na formátů – moderní formáty s vysokou kompresí nedává smysl komprimovat, u PNG nebo JPEG dává smysl kompresi lepším algoritmem vyzkoušet, může to velikost přenášených dat snížit. A u obrázků se range requesty nepoužívají.

Content-Length bude server posílat správně, o to se nemusíte bát. Stejně tak o Content-Type.

Celou dobu je řeč o transportním kódování, tj. je to kódování jenom pro přenos přes síť, prohlížeč si z toho zase vybalí ta původní nekomprimovaná data. A ano, dělá se to tak, že ty soubory jsou uložené na disku už předkomprimované právě pro to transportní kódování (často i zkomprimované více způsoby, aby server mohl odpovídat podle toho, jaké kódování podporuje klient). Takže server nemusí pořád dokola komprimovat to samé, ale použije to, co má už předkomprimované na disku.

270

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 14. 01. 2023, 12:48:20 »

Pokud si tazatel zablokuje přístup z neveřejných IP adres, pak ze všech, tj. i těch z vnitřní sítě ISP, což je samozřejmě špatně a není k tomu vůbec žádný důvod. A popravdě ani neznám nikoho, kdo by něco takového dělal.

Není na tom vůbec nic špatně. Dělá se to proto, aby se do vnitřní sítě nedostal provoz, který tam nemá co dělat a může jít třeba o podvržené pakety.

A že ty si tady z totální neznalosti dané problematiky vytváříš jakési pseudo-teorie co a jak o nějakých sítích, a pak se do toho sám zamotáš, že ti úplně uniká celá debata, už není můj problém.

Totální neznalost problematiky jste tu předvedl akorát vy. Neznáte internetová RFC, klidně byste do své sítě pustil provoz z cizí privátní sítě, nemáte představu, jak může síť malého ISP vypadat.