Příspěvky

796

Vývoj / Re:Bezpečná session v PHP

« kdy: 17. 03. 2020, 09:44:23 »

Alternativou k PHP sessions je JWT - Json Web Tokens (https://en.wikipedia.org/wiki/JSON_Web_Token). Výhodou je, že si data nese prohlížeč a nejsou uložena na serveru. Díky tomu můžete postavit víc serveru a mezi nimi přepínat / balancovat provoz. U klasické PHP session musíte řešit, aby do ní viděly všechny servery, u JWT nikoliv.

To je omyl. JWT i cookies mohou nést data i pouhý identifikátor session, v tom se nijak neliší.

Ano, přesně tak, to se nevylučuje. Systém, který v session / JWT přenáší jen identifikátor (např. uživatele), je podle mě nejlepší. Vzniká tím nejméně problémů v aplikaci. Zejména když se mění struktura dat, která ukládáme v session. Já jsem zmiňoval třeba nákupní košík - tam se může v čase struktura rozšiřovat (např. o pole dostupnosti, akční ceně, ...). Pak je potřeba v aplikaci zavést verzování struktury, nebo se spoléhat checky v aplikaci (aby chybějící pole v session doplnila). To už je rovnou jednodušší to ukládat ve struktuře do databáze.

Sessions (i JWT) jsou v praxi nadužívané i na data, na která se to nehodí.

797

Server / Re:Backup serveru

« kdy: 17. 03. 2020, 09:29:54 »

Líbil by se mi totiž formát zálohy v image, aby se záloha dala dobře přenášet a pracovat s ní v případě obnovení atd. Na ten Borg určitě kouknu

Ve skutečnosti je s images více práce, než s tradičním backupem. Nejdřív musíte zajistit, abyste měl na vzdáleném úložišti několik záloh. Pokud používáte images, tak buďto potřebujete Nkrát tolik místa, nebo využít inkrementální obrazy. Pokud použijete inkrementální obrazy, stejně musíte mít pro plný obraz místo aspoň třikrát. Takže nároky na prostor jsou veliké. Pak nastává samotný přenos zálohy zpět. Jsou to obvykle velká data; ne vždy je jde natáhnout rovnou, takže se většinou nejdřív přenášejí zpět do hlavní site a pak se s nimi pracuje lokálně => další nároky na prostor. Musíte řešit problémy s přenosem. Ano, i u velkého souboru se dá přenos navazovat, ale poté byste měl na obou koncích udělat nějaký checksum, abyste ověřil, že napojováním nedošlo k chybě => čas.

Pokud image, tak je dobrý na lokální zálohy (level 1). Tam bych se ovšem nepatlal s nějakým DD nebo ZFS nebo Btrfs, ale zvirtualizoval bych to a zálohu bych řešil pomocí Veeam Backup (Acronis to taky umí). To jsou poměrně vyladěné systémy, zálohují i obnovují rychle a nenesete riziko, že něco špatně vymyslíte.

Pro běžné zálohy je tradiční zálohování lepší. Já zmiňoval Borg Backup, ale existuje víc řešení. Výhodou je, že jeho repozitář je na úrovni souborů a díky kompresi a deduplikaci je schopný s minimem prostoru udržet i desítky záloh zpětně a ze všech zrekonstruovat plný stav. Přikládám ukázku z produkce. Archiv obsahuje 54 TB zálohovaných dat, ale na úložišti to po kompresi a deduplikaci zabírá 320 GB. Počet záloh, ke kterým se můžu vrátit: 2370. Doba zálohování serveru: 6 minut i s přenosem po internetu (přenáší jen to, co se nenajde v repozitáři).

Kód: [Vybrat]

Time (start): Tue, 2020-03-17 04:17:26
Time (end):   Tue, 2020-03-17 04:23:30
Duration: 6 minutes 4.24 seconds
Number of files: 689993
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:               40.66 GB             16.54 GB             92.25 MB
All archives:               53.62 TB             24.56 TB            320.41 GB

                       Unique chunks         Total chunks
Chunk index:                 5563693           1272684448
------------------------------------------------------------------------------

798

Vývoj / Re:Bezpečná session v PHP

« kdy: 17. 03. 2020, 09:16:12 »

PHP sessions se dají používat zcela bezpečně, jen musíte vědět, která data se do ní hodí a jak s nimi pracovat. To není na rozepsání do diskuse. Spousta internetových rad je nedobrých, nedomyšlených.

Alternativou k PHP sessions je JWT - Json Web Tokens (https://en.wikipedia.org/wiki/JSON_Web_Token). Výhodou je, že si data nese prohlížeč a nejsou uložena na serveru. Díky tomu můžete postavit víc serveru a mezi nimi přepínat / balancovat provoz. U klasické PHP session musíte řešit, aby do ní viděly všechny servery, u JWT nikoliv.

Ať už PHP session nebo JWT, v obou případech je nejčastější začátečnickou chybou ukládání příliš mnoho dat do session a málo do úložiště aplikace (databáze). Do session by mělo přijít co nejméně dat, jen ta, která se vztahují k dané relaci. Ostatní se mají ukládat aplikačně. Příkladem je např. košík na eshopu - ten nemá v session co dělat, protože potřebujete pravidelně ověřovat dostupnost zboží, změny cen a potřebujete, aby byl stejný košík vidět po přihlášení z různých počítačů. Do session naopak patří informace o tom, kdo je přihlášený (id / hash uživatele) nebo např. informace o naposledy navštívených produktech (kvůli navigaci zpět).

Doporučil bych vzít framework, který toto řeší. Z mojí zkušenosti, vyhnul bych se Nette (nedodělané, nestálý vývoj, špadná dokumentace), z těch větších mi přijde dobré Symfony. Učitě bych to neprogramoval sám. Sice o Vašich chybách nebude nikdo cizí vědět, ale uděláte spoustu i začátečnických chby. I vlastní framework budete muset neustále vyvíjet a upravovat - a zkušenost praví, že je jednodušší počítat s pravidelnými updaty cizího frameworku, než neustále měnit něco svého. S obojím je hodně práce, dnes už nic nefunguje tak, že jednou uděláte a pak na to roky nemusíte sáhnout.

799

Server / Re:Backup serveru

« kdy: 16. 03. 2020, 15:51:15 »

... borgbackup, sypu to na remote sshfs.

Já bych doporučil cpát to na remote server přímo přes SSH. Má to obrovskou výhodu proti sshfs. Nikdo nemůže na vzdáleném konci smazat nebo poškodit repozitář - zatímco na sshfs stačí jen smazat / přepsat soubory v připojeném adresáři. Do authorized keys se přidá omezení, aby šel spustit pouze borg a pouze v append režimu. Při kompromitaci zálohovaného serveru nikdo se zálohami neudělá vůbec nic. Prune se pak pouští z jiného místa - tím se oprávnění segregují (chráněný server může jen přidávat, jiný může provádět výmaz starých záloh) a tak se diverzifikuje riziko úmyslného poškození záloh.

800

Server / Re:Backup serveru

« kdy: 15. 03. 2020, 22:32:36 »

Podívejte se na Borg backup. Je jednoduchý, přesto výkonný, umí šifrovat, komprimovat i deduplikovat.
dd bych nedoporučoval, rsync jednu zálohu udělá, ale neudělá repozitář s historií záloh (natož deduplikaci).

801

Sítě / Re:Omezení přístupu na web z IPv6 adres

« kdy: 13. 03. 2020, 15:29:50 »

Když už máš potřebu tuhle zbytečnost dělat, blokuj vždycky prefixy /64.

To bych nedělal, nedá se spolehnout na to, že za /64 je jen jeden účastník.
Znám spousty přípojek i připojených serverů, které jsou v jednom /64 prefixu a každý má svoji vlastní IP z něj.

Jediným řešením je zabezpečení aplikace samotné a pak zmiňovaný WAF.

802

Sítě / Re:Omezení přístupu na web z IPv6 adres

« kdy: 13. 03. 2020, 14:40:44 »

S IPv6 musíte počítat s tím, že každý má (může mít) prakticky neomezené množství IP adres k dispozici. Blokování na základě IPv4 byla vždy zoufalá praktika (u IPv4 přináší false positives díky účastnickým NATŮM). Na IPv6 je problém opačný.

Doporučuji kompletně opustit přemýšlení, že blokace IP adresy je nějaký nástroj bezpečnosti. Bezpečnost se tvoří jinak.

803

Server / Re:RAID nad NVMe SSD

« kdy: 12. 03. 2020, 13:00:21 »

U AMD nevím, ale u Intelu je to horší řešení, než RAID v rámci OS / LVM / FS. Obojí žere CPU a další prostředky, jenže u toho pseudo-hw RAIDU s tím ještě málo co uděláte. Ani servery to nepodporují nijak moc ochodně, VMWare taky ne.

Doporučuji buďto používat opravdový RAID řadič, nebo RAID v rámci OS. Tomuto se vyhnout obloukem.

804

Hardware / Re:Server občas přestane komunikovat

« kdy: 09. 03. 2020, 16:58:58 »

@scientific: Podle mě je levnější koupit laciný server (třeba Supermicro), ušetříte si spoustu starostí. Desktop opravdu není server.

805

Hardware / Re:Server občas přestane komunikovat

« kdy: 09. 03. 2020, 14:46:39 »

Todle bych řekl vypadá na HW errror. Obzlášť, jestli je to home PC používanej 24/7, tak se mohlo stát, že něco odešlo.
Takže klasika - memtest, vizuální prohlídka kondenzátorů na desce....
Další, co jsi nepsal, je, zdali na ten "rozbitej" server funguje SSH. Pokud funguje, tak prozkoumat pomocí SSH. Pokud nefunguje, tak to, že by byl systém ještě ve "funkčním" stavu a reagoval na magické klávesy je poměrně malá.

Kondenzátory vizuálně projít, naprostý souhlas. Jakmile bude některý fouknutý nebo vyteklý, desku poslat do háje. Nemusí to být ale jen kondenzátory. Může to být třeba i jen zdrojem. Blbé je, že bude trvat dlouho na to přijít.

V biosu zkontrolovat, jestli jsou vypnuté C-states.

Ideálně nainstalovat úplně čistý OS a nechat zahořet. Vzhledem k tomu, že se to projevuje až po týdnech, tak to bude trvat dlouho a velká jistota nebude.

Vzhledem k tomu, že se nejedná o serverovou desku, vykašlal bych se na to. Možnosti diagnostiky jsou omezené, budete to řešit týdny a na konci stejně přijdete na to, že koupíte nový hardware.

806

Windows a jiné systémy / Re:Windows 10 jako webový server

« kdy: 07. 03. 2020, 00:51:02 »

V Evropě je přeprodej licencí legální. Nebo tohle už neplatí?
https://curia.europa.eu/jcms/upload/docs/application/pdf/2012-07/cp120094cs.pdf

Stejně jako každý judikát, i tento platí pro obdobné případy. Ale přečtěte si, jaké otázky soud řešil a uvidíte, že většinu z nich nelze při běžném přeprodeji splnit. Už jen např. prokázání řetězce licenční smlouvy (zakončené notářským zápisem!) nebo i silné prokázání nevyužívání software. Takže na tento rozsudek se nedá dobře spoléhat. Dál je považovaný v některých částech za překonaný novějšími předpisy i judikáty, takže z tohoto rozsudku můžete převzít jen některé právní věty. Zejména část o nosiči software je od té doby překonaná značně - a právě o tuto část se rozsudek hodně opírá.

807

Sítě / Re:Softwarová firma bez kabelového ethernetu

« kdy: 06. 03. 2020, 21:42:32 »

Hmm, jak se tohle stane? Měl jsem za to, že APčko, ke kterému nikdo není připojený, vysílá jednou za 100ms (nebo déle) krátký beacon, jinak se nijak neprojevuje.
...
A jak se to řeší na wifi? Samostatná SSID? Jinak se dá použít drátové 802.1x a když se autentizuješ, tak to ten port hodí do správné VLAN.
...
WPA2-Enterprise se striktním ověřováním certifikátů je děravé?

Myslím, že pro 100 uživatelů je toto všechno ještě příliš drahé na WiFi. Dobře. Zavedete 802.1X, k němu Radius napojený na nějakou userbase. Ta bude dost pravděpodobně Microsoft AD, ale není to nutně podmínka. Vytvoříte interní CA, každému uživateli vytvoříte jeho uživatelský certifikát. Pak začnete řešit jak do každého desktopu, tabletu, mobilu protlačíte certifikát CA + uživatelský certifikát pro ověření. Pravděpodobně zjistíte, že pro prvotní nastavení je nejjednodušší přihlášení po ethernetu a distribuce certifikátů přes Group Policy. Tento špás budete muset opakovat co chvíli, protože uživatelé si mění a přeinstalovávají zařízení, nebo budete muset zavést firemní politiku schválených a předinstalovaných zařízení (úplně vymýtit BYOD). Na konci získáte teoretických pár set megabitů sdílených mezi více uživateli. Nesymetrických. Pod stolem a za rohem s kolísavými výsledky.

Toto všechno když si sečtu, tak je ethernet daleko vhodnější řešení. Koupíte stroje. Připíchnete do sítě. Pomocí 802.1X, aniž byste cokoliv instaloval, získáte omezený přístup. Ten umožní síťovou instalaci (PXE). Pěti kliky nainstalujete celý OS, vydistribuujete i certifikáty. Pokud nepožadujete na ethernetu 802.1X, pak nemusíte ani netinstall řešit. Prostě fungujete.

WiFi zde může doporučit buďto ten, kdo si uvědomuje složitost proti ethernetu a přijímá ji, nebo jen ten, který si vůbec neumí domyslet, co vše je potřeba pro srovnatelný běh, nebo ten, kdo si představuje, že firemní síť je jen Gmail + Git. Finančně to vyhraje ethernet, i v budovách, které mají 1,2 m tlusté zdi a kde je potřeba zajistit i vyjádření statika a jádrové vrtání v nosných prvcích.

808

Bazar / Re:Prodám 10 jádrový i7-6950X se základní deskou a 32GB RAM

« kdy: 06. 03. 2020, 21:27:51 »

ano, zato cipsety pro Intel jsou ;-)
https://www.abclinuxu.cz/zpravicky/neopravitelna-chyba-v-cipovych-sadach-od-intelu

Mě to třeba nechává ledově klidným. Předpokládám, že podobné chyby mají všechny čipsety. Ostatně izraelské firmy umějí dekódovat i apple produkty a dost pravděpodobně využívají podobné slabiny. Všechny chyby Intelu jsou vážné, ale po nějakém čase je zafixují. V mezičase se necítím ohrožený, protože zneužitelné jsou jen ve velmi specifických situacích. Mitigace chyb u sebe všude vypínám, zpomalují a reálný přínos pro mě je nulový.

809

Windows a jiné systémy / Re:Windows 10 jako webový server

« kdy: 06. 03. 2020, 21:24:34 »

Legální windows server licence opravdu nestojí pár stovek a to ani pro pár lidí...
/.../
Jinak pokud máte přeprodanou licence např. z Aukra, tak to dle podmínek Microsoftu není legální licence

Windows licence stojí prd proti ceně práce lidí, zcela zanedbatelná položka. Z pohledu zaměstnance je to "darda", za kterou by mohlo být víc užitečných věcí, ale z pohledu zaměstnavatele jýt le to kapka v moři. Zaměstnavatelé s tím dělají štráchy spíš z principu.

Přeprodaná licence může být legální. Je jeden případ, který se dostal před ESD, kdy prodávající velmi přesvědčivě dokázal vyargumentovat důvody prodeje. Je pravdou, že nabídky na aukru a spol. mají úplně odlišné rysy, ale čistě teoreticky to lze udělat i legálně.

810

Sítě / Re:Softwarová firma bez kabelového ethernetu

« kdy: 06. 03. 2020, 11:25:47 »

Byly zde zmíněny některé nápady.  Všechny nápady na wifi se opírají o to, že musí být profesionální (ne nějaké Ubnt nebo Mikrotik) a kvalitní adaptér v počítači. Také vidím poměrně shodu na tom, že je potřeba ošetřit pásmo - např. vynutit vypnutí Windows Update - ale kdy se tedy budou firemní počítače aktualizovat? Jak si poradit s P2P klienty? Jak řešit legitimní přenosy dat (např. z firemního serveru nebo jen Exchange/IMAP synchronizace?). Jak se zajistí, zejména v nehomohennním prostředí jakost nastavení i vybavení. To všechno jsou problémy, které pro 100 PC znamenají víc práce, víc učení se "jak to dělat" i víc peněz (např. enterprise laptopy) než natahat ethernet. O tom jsem naprosto přesvědčený.

Jiná situace by byla, kdyby bylo z nějakého důvodu nutné fungovat bez drátu. Kiosky, volně rozestavený nábytek v prostoru, který zasíťovat nejde a design je vyšší priorita než funkčnost atd. atd.

U ethernetu máme jasně dané kategorie (dnes 6A nebo 7), víme, že utáhnou až 10 Gbps a je jen na switchi a serveru, jestli udělají úzké hrdlo. Dnes může stačit pár Mpps propustnost, když nebude stačit, za tři, pět let lze nahradit silnějším aktivním prvkem a kabeláž to utáhne. WiFi standardy se vyvíjejí stejně, jako ethernet, jenže v případě WiFi to znamená vyměnit úplně vše (u WiFi standardů je nepříjemné, že mix starých a nových standardů de facto degraduje síť na ten nižší standard, protože stará zařízení zaberou "ve vzduchu" delší čas podle staré normy).

Ať už si z toho odnese kdokoliv jakékoliv poznatky, WiFi pro trvalou práci zůstává značně kontroverzní. Na tazateli je posoudit, jestli dá přednost dopředu známé pakárně s instalací strukturované kabeláže, nebo jestli upřednostní ladění WiFi a ethernet si nechá jen jako zálohu, kdyby to nefungovalo.