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 - Miroslav Šilhavý

Stran: 1 ... 49 50 [51] 52 53 ... 206
751
Software / Re:Jak opravit Linux se špatným /etc/fstab
« kdy: 27. 03. 2020, 18:04:26 »
Např. v síťových startech, na kioscích, ... je to žádoucí chování. (...)

(...) to je zlomek zarizeni, ktere navic VZDY admin upravuje tak aby bylo vse omezene, jak pri ootu, tak v nabehlem, takze by navic (k tem hromade) jen udelal zmenu aby blokoval emergency, proc tim ale argumentujes ze je to v poradku pro beznej desktop co vlastni/pouziva/ma_pod_rukama majitel/admin/root?
Já si myslím, že by měl nastávat absolutní zlomek situací, kdy potřebujete takto nouzově opravovat. Naopak by si admini měli nad sebe sami dobrovolně plést bič a zabezpečení hrotit maximálně a nejlépe i implicitně. Oslabit bezpečnost, aby se pohodlně pracovalo, to dovede každý.

proc tim ale argumentujes ze je to v poradku pro beznej desktop co vlastni/pouziva/ma_pod_rukama majitel/admin/root?
Protože distribuce nemůže vědět, jak bude použita. Proto má být zabezpečna raději víc, a ať si to oslabí každý, kdo k takovému závěru dojde.

navic, myslis ze pro kiosek kterej spravujes na dalku je idealni stav aby pri fail datoveho disku byl stopnut boot a neslo se vzdalene pripojit?
Kiosky se většinou mění kus za kus, když jsou daleko, tak přepravní službou. Základem je mít to nastavené tak, aby se to stávalo opravdu výjimečně.

To, co tady razíte, je klasický postup povyšování chyb na standard. V 80 % situacích to vyhovuje, tak to rovnou povýšíme na univerzální pravdu..?

752
Software / Re:Jak opravit Linux se špatným /etc/fstab
« kdy: 27. 03. 2020, 09:49:36 »
Myslet si, že zvyšuji bezpečnost tím, že je žádoucí, aby do emergency režimu nešlo normálně vstoupit ("i za cenu horších nouzových operací")

Např. v síťových startech, na kioscích, ... je to žádoucí chování. Nemáte zařízení fyzicky pod kontrolou, často má už v určitém bodě přístup k síťovým prostředkům a stejně opravu provádíte na dálku. Tam má naprosto smysl jakýkoliv fail stav vyústit v uříznutí přístupů.

753
Software / Re:Jak opravit Linux se špatným /etc/fstab
« kdy: 26. 03. 2020, 15:02:50 »
Prospějeme tím tak, že ostatní init systémy kompletně nezablokují boot když se nepodaří namountovat nějakou položku z fstab. Buď pokračují dál, nebo nabídnou spuštění shellu.

To je asi otázka názoru, co je správné chování, hlavně názoru na bezpečnost. V mnoha situacích chcete mít od boot loaderu až do spuštění systému proces nenarušitelný i za cenu horších nouzových operací. Je na rozhodnutí uživatele, jestli má grub nebo primitivnější loader, je na rozhodnutí uživatele. Je na rozhodnutí uživatele, jestli systemd nastaví, aby ignoroval chyby a pokračoval. Je i na uživateli, jestli root má heslo (a tedy lze jej využít pro emergency), nebo jestli je zablokovaný. Z mého pohledu "bezpečnost ve výchozím stavu" je správný postup.


Jinak tohle chování se dá v systemd emulovat parametry nofail,x-systemd.device-timeout=8 ve fstabu. Z nějakého důvodu není default, ale prý je fstab stejně zastaralý a máme používat mountovací unity…

Mountovací unity dávají smysl, ostatní pak vědí, jestli na nich mohou stavět závislosti.

Základní OS klidně může být ve fstabu, ale když to selže, měl by se bootovací proces zastavit. To se tazateli stalo. Dále má bootloader, kde nic nezmění při provádění; nic mu nebrání (asi) vyměnit. A na konec, jestli správně chápu, má zablokovaného roota - což musel udělat taky vědomě.

754
Hardware / Re:Záruka notebooku na opravovaný díl
« kdy: 25. 03. 2020, 19:59:30 »
Záruku máte na notebook, ne na jednotlivé díly.
Záruka se Vám prodloužila o dny, kdy byl notebook v servisu.

(Kdybyste však opravu platil, tak na opravu je několik měsíců záruka)

755
Software / Re:Jak opravit linux
« kdy: 25. 03. 2020, 10:01:49 »
Jen by mě zajímalo, zda opravdu systemd (nebo obecně bootovací proces linuxu) nemá nějaký mechanismus (například klávesovou zkratku), aby se šlo dostat do boot procesu přímo na tom počítači, když ho spustím, abych nemusel vůbec "přesedlávat" na jiný počítač a  ručně na jiném PC editovat grub.cfg, cmdline.txt, atd. nebo rovnou opravovat?

Grub zeditujete přímo v jeho menu, pomocí klávesy `e` a po zeditování jen spustíte pomocí C-x.
Druhý počítač ani live distro není potřeba.

756
Software / Re:Jak opravit linux
« kdy: 25. 03. 2020, 09:19:37 »
Obvykle by to mělo jít napravit i bez live distra, pouze kernelu poslat parametry:

Kód: [Vybrat]
root=/dev/xxx init=/bin/sh

následně v shellu přemountovat filesystem na read-write a pak už tradá editovat

Kód: [Vybrat]
mount / -o remount,rw

a toto funguje, dokud je v pořádku initrd. Pokud je initrd nakopnutý, obvykle se to dá řešit natažením starší verze (co jsem se setkal, tak distribuce uchovávaly starší jádra a jejich initrd).

757
Sítě / Re:Bezpečnostní úskalí RDP
« kdy: 24. 03. 2020, 09:16:07 »
V tom se naprosto shodneme. Připadá vám to nereálné? Mně ne, tomu se říká odbornost :-)
Kromě toho to taky chce kvalitní technologie.

Nereálné ne, drahé ano. Dražší, než RDG. Lze spočítat.

No mě taky ne, ale připadá mi to nereálné ve scopu původního tazatele, který na takovou systematickou akci při vší úctě není připraven. Natlačili ho do ne zrovna ideálního rohu, odkud se teď snaží operovat.

Taky se mi zdá, a taky zjistil, že je v rohu, proto se ptá. Na něm je, jestli v rohu zvolí špatné řešení (a ponese si za něj odpovědnost), nebo dokáže prosadit rozumné řešení.

uffff.....
1. řešení je hodně pravidel na routeru(izolce IP, porty, etc)
2. řešení je na kliošské stanice nainstalovat Aplikační firewall a tam vytvořit zónu která směruje do VPN, povolit vybrané aplikace a vše ostatní zakázat
3. řešení je na kliošších filtrovat outgoing provoz

ad 1) vyžaduje statické IP => tím pádem se IP stane součástí bezpečnostního řešení => IP nelze 100% zaručit, že se nezmění => bezpečnost jde vniveč; proto je potřeba se dostat z L2 na L7
ad 2 a 3) nikdo Vám nezaručí, že to neselže nebo že si někdo nevytvoří jinou instalaci bez něj => klientský firewall je určitý typ hardeningu, ale ne bezpečnostní řešení pro server

758
Sítě / Re:Bezpečnostní úskalí RDP
« kdy: 23. 03. 2020, 18:42:26 »
Omezení ukládání hesel bych se vyhnul - je to možné třeba přes program rdp.exe obejít. Navíc to bude nutit zaměstnance nechat session otevřenou celý den.

Na to je jednoduchá obrana. RDP se nastaví tak, že po půlhodině nečinnosti vzdálenou plochu odpojí. Dalším připojením se uživatel připojí do stavu, ve kterém byl odpojen.

Na terminálovém serveru se ještě přidává i automatické odhlášení, např. po další hodině. Pak to funguje tak, že odpojení je jakési "varování" před odhlášením. Odhlašováním po určité době se šetří prostředky serveru.

759
Server / Re:Backup serveru
« kdy: 23. 03. 2020, 17:29:15 »
Pokud to má být nová složka pro každou zálohu, proč rsync a ne obyčejné scp?

760
Sítě / Re:Bezpečnostní úskalí RDP
« kdy: 23. 03. 2020, 14:52:42 »
Horší je to s cashflow když jich máte koupit 100, k tomu 100 RDS CAL a OLP Office na terminal. To už je raketa když se to spočte. Spoustu zákazníků to dovede k vědomému porušování licenčních podmínek, které potom horko těžko rovnáme. Přístup na stanici vyjde samozřejmě levněji, akorát se maličko hůř spravuje.

Pokud máte 100 zaměstnanců, obvykle je cash flow takové, že to unese.
Pokud ne, tak lze licence získat přes Office 365 plány E a rozložit si to v čase. Může to být i pro firmu výhodnější, protože pořízení licencí se daňově odpisuje 36 měsíců, zatímco pronájem (O365) jde do daňových nákladů rovnou.

Citace
Navrhoval bych funkční DNS, potom to fakt řešit nemusíte. Přes RDG se dá uživatel tunelovat přímo na stanici (...)

Přesně tak. Ale to jsem jen tak namátkou vybral jednu oblast, která by patrně potřebovala zlepšení.

761
Sítě / Re:Bezpečnostní úskalí RDP
« kdy: 23. 03. 2020, 10:00:23 »
- windows server stojí pár korun, CALy jsou teda o něco horší...

Ony ani CALY nejsou tak drahé, když si vezmete, že pokryjí několik let práce a poměříte je ke mzdě pracovníků.
Jak už jsem psal, myslím si, že IT odborník by měl umět zákazníkovi vysvětlit, že pokud se mění situace a je nový požadavek na práci z domova, že je to čas na změnu v koncepci. Samozřejmě mě hned napadají i vedlejší linie, co z dotazu vyplývají - např. že pokud pan kolega chce z VPN pouštět RDP až na stanice, musí mít stanice statické IP adresy. To je další věc, která se dávno dělá jinak a taky by zasloužila změnu.

762
Distribuce / Re:ZFS a Linux
« kdy: 23. 03. 2020, 09:56:01 »
Za prvé: je velký rozdíl mezi distribucí (souborem mnoha nezávislých programů od různých autorů a kolektivů) a jádrem (jeden softwarový projekt).

Z hlediska práva to tak jednoduché není. Pokud distribuce (preferovaně, volitelně) závislá na ZFS, a ZFS je závislé na kernelu, jsou to v tu chvíli neoddělitelné součásti. Jejich běh dává smysl pouze dohromady. Jestli toto sloučení provedete na úrovni balíku jádra, na úrovni distribuce nebo si ho provede uživatel sám (třeba s pomocí scriptů, které jste nazval očůráváním), je ve skutečnosti jedno. Výsledek je stejný a bazírovat na technickém detailu, co je k čemu přibalené, je jen formalismus.

Citace
Za druhé: to, že Canonical začal cosi distribuovat, ani zdaleka není zárukou, že je to v pořádku a že žádné riziko nehrozí. On to totiž klidně může být výsledek nějaké neveřejné dohody. Nebo může Oracle jen čekat, až bude potenciálních obětí víc. Nebo prostě žalobu teprve připravují. A i kdyby jim to opravdu bylo jedno a rozhodli se "nechat to být", ani to by pořád ještě neznamenalo, že žádný problém neexistuje (a že třeba časem názor nezmění).

Názor se může změnit vždy a každému. Stejně tak se může změnit některému autorovi vydávajícímu pod GPL a začít se soudit s některou z firem, že v rozporu s licencí zahrnuli jeho dílo do jiného produktu. Je však potřeba zvážit rizika.

Citace
Tato vaše interpretace GPL a pojmu "autorské dílo" je dosti unikátní a rozhodně není předmětem většinového konsensu.

Naopak, distrubuce (včetně) komerčních jsou konsensem z praxe, že nové dílo vzniká sloučením děl (i s rozdílnými licencemi) v jeden funkční celek. Naopak říkat "my jenom připravili balíčky, ale neneseme odpovědnost" je přesně stejným očůráváním, o kterém jste psal.

Citace
Citace
Oraclu vůbec nevadí, když se ZFS bude šířit dál jako součást (chcete-li: přívěsek) něčeho dalšího. Oni se nemají k čemu vyjadřovat, co měnit.
A to víte odkud? Máte nějaké právně závazné vyjádření? Nebo je to jen vaše osobní interpretace textu těch licencí?

Nevím co si představujete jako závazné právní vyjádření? Závazným právním dokumentem je licence (CDDL). I kdyby vydali nějaké prohlášení, tak je platné tady a teď, a nijak to nezaručí, že za týden neprohlásí přesný opak.

Citace
Pokud Sun zvolil licenci, která šíření i pod GPL2 neumožňuje, a Sun ani Oracle na tom dodnes nic nezměnili, pak prostě o to, aby ZFS v Linuxu být mohl, nestojí. Já to jen respektuji a nesnažím se vymýšlet krkolomné myšlenkové konstrukce k tomu, abych ho tam mít mohl. Stejně tak to respektují maintaineři linuxových filesystémů.

Ano, když si postavíte premisu, že je to nutná podmínka, pak můžete k takovému závěru dojít.

Přečtete si však CDDL. Je to licence, která uvolňuje dílo pro jakékoliv užití, dokonce i bez podmínky šířit dál zdrojové kódy. Pokud existuje výkladová nejasnost, musí se hledat řešení v kontextu tohoto účelu. Oracle se v praxi vzdal požitků z díla a uvolnil ho. I kdyby část týkající se ZFS nebyla souběžně licencovaná pod GPL, zůstane ten kód volný dál, dokonce i volnější než zbytek Linuxu. V každý časový okamžik od nyní může kdokoliv kód ZFS vzít a znovu ho přiložit k jakémukoliv dílu. Oracle nemá jakoukoliv možnost svoji licenci odvolat.

O co v tomto případě jde, je práce programátorů, kteří budou dál pracovat na spojení ZFS s Linuxem. Ty práce se totiž prolínají - někdy je potřeba změnit něco v jádru ve prospěch ZFS, jindy je potřeba změnit něco v ZFS ve prospěch Linuxu. Jejich práce by se musela (administrativně) rozlišit, jestli se jedná o odvozené dílo od Linuxu (a tudíž smí spadnout pod GPL), nebo jestli se jedná o dílo odvozené od ZFS (a tudíž musí spadnout pod CDDL). To je jediná praktická komplikace. Pochopitelně, programátoři by si pak vybrali, jestli budou věnovat své úsilí části GPL-Linuxu, nebo jestli věnují úsilí části ZFS a přijmou, že jejich práce nebude GPL, ale CDDL.

Citace
Reality check: btrfs je od SLE11-SP3 (červenec 2013) plně podporovaný a používaný enterprise zákazníky.

Reality check: už pár let platí, že výrazná většina vývojářů btrfs jsou zaměstnanci SUSE nebo Facebooku. Pro žádnou z těchto firem není SOHO těžištěm jejich zájmu.

Ano, když to napíšete jen jako "fakta", vypadá to dobře.

V praxi: SuSE doporučuje Btrfs jen pro root partition, nikoliv na data. Raid 1 a 10 poměrně dobře. Raid 6 ne. Btrfs má dost špatný výkon při OLTP. Btrfs ztratilo data už pěkné řádce uživatelů.

763
Sítě / Re:Bezpečnostní úskalí RDP
« kdy: 22. 03. 2020, 23:57:21 »
RD Gateway není aktuální, nemají Windows Server.

Ptal jste se na bezpečné řešení. Možná toto je právě doba, kdy by měl klient zvážit pořízení WS. Zcela správně totiž identifikujete to, že při četnějším využívání RDP ve VPN rostou rizika. Pochopitelně, žádný klient nevydá peníze, když existuje srovnatelné řešení levněji. Na vás by mohlo být právě umět vysvětlit, v čem se řešení liší.

Při výběru VPN si dejte pozor, aby nezvyšovala výrazně latenci. PPtP není bezpečné. OpenVPN je tragedie (nejen) na výkon. L2TP je fajn, pokud ani na jedné straně (ani po cestě) není NAT. Pokud jsou oba konce na MS technologiích, zaměřil bych se na SSTP.

764
Distribuce / Re:ZFS a Linux
« kdy: 22. 03. 2020, 23:51:46 »
(...) Uživatel si sice může tyhle udělat ledacos, ale rozhodně nemůže výsledek takového sloučení dál šířit jako jedno dílo, protože snad nikdo si nedovolí popírat, že by takové dílo bylo odvozeným dílem. (...) No a triky spočívající v tom, že budu jako distribuovat jen zdrojáky a nechám uživatele, ať si to jako přeloží sám (skriptem, který mu poskytnu), to je klasická ukázka toho, co se v lidové češtině označuje výrazem "ochcat předpis".

Právě to vnímám. Ona se podle mě nedá přesně stanovit hranice, kde končí jádro, kde začíná modul, čím se liší modul od programu atd. Linuxákům jsou tyto pojmy "jasné", ale nejedná se o přirozené dělení, pouze o dlouho budovaný zvyk. Když se odprostíte od tohoto zažitého dělení, tak z přirozeného pohledu (z pohledu laika) se stále jedná o programové vybavení, díky kterému funguje hardware, který si koupil. To by byla asi první překážka u případného soudu.

Modul pro Linux smí být i non-GPL. Zde začíná poměrně nepochopitelný postoj maintainerů, kteří si situaci vychutnávají a pro užití v non-GPL modulech exportují jen část funkcí. Zaslepeně, ale řekněme, když pomineme první problém výše, mají na to právo. Tento postoj by se dal chápat např. z bezpečnostních důvodů - ale to není ten případ.

Dále, takový modul, když využije to, co co je mu nabízeno, smí být non-GPL. Smí se externě distribuovat, smí být kompilovaný společně (resp. proti) Linuxu, smí být využívaný. Pokud však tato teze platí, pak nemůže existovat ani právní problém. Pokud smí zdrojové kódy i binárky šířit jedna distribuce, nemůže existovat ani překážka k tomu, aby takový kód byl součástí Linuxu rovnou. Stejně jako distribuce explicitně označuje Linux jako GPL, a ZFS jako CDDL, stejné rozdělení by nemuselo být až v distribuci, ale rovnou v Linuxu.

Citace
Jak jsem vysvětli výše (a už několikrát v minulosti), přelicencování Linuxu je možné jen v čistě teoretické rovině, praktická proveditelnost by byla víceméně nulová, i kdyby zájem byl.

Viz výše. Společná distribuce GPL Linuxu a non-GPL jiných součástí by nemusela vyžadovat přelicencování ani na jedné straně.

Citace
Oracle je v úplně jiné situaci, protože jako firma je to jedna entita, která drží veškerá potřebná práva.

Oraclu vůbec nevadí, když se ZFS bude šířit dál jako součást (chcete-li: přívěsek) něčeho dalšího. Oni se nemají k čemu vyjadřovat, co měnit.

Citace
A tohle všechno platilo dávno před tím, než Sun zveřejnil zdrojáky ZFS pod CDDL.

To by si ovšem Linux nesměl myslet, že je pupek světa a že všichni jsou tu od toho, aby se dávali na "správnou víru". Než aby se hledalo technické a administrativní řešení a vyhovělo se licencím, vedou se žabomyší spory a poměřují se pindíky. Je dost možné, že v příštích deseti letech bude ZFS překonán, ale zatím je o míle vepředu. Jediný konkurent, Btrfs, nedosahuje produkční jakosti pro enterprise. Ne všechny podniky, ale zatím většina dává přednost ZFS, pročež Btrfs chybí v této oblasti jak vendoři, tak i zkušenosti z praxe. Pokud se něco nezmění, tak Btrfs bude čím dál víc konvergovat k vlastnostem žádaným v SOHO a enterprise segment nebude mít ještě dlouho jinou volbu, než ZFS.


765
Sítě / Re:Bezpečnostní úskalí RDP
« kdy: 22. 03. 2020, 11:05:48 »
Normální administrátor umí omezit VPN přístup jen na prostředky, které uživatel potřebuje k práci (tj. třeba jen ten RDP server/port 3389).


Znalý administrátor by nepokládal dotaz, jaký byl položen. VPN mají taky své slabniny + existentní riziko miskonfigurace. U RDP (RDS) máte k dispozici aspoň rychlé aktualizace.

Pokud se chcete bavit o bezpečném řešení, tak je to extra VPN pro RDS, chráněná certifikátem a tokenem a to samé pro přihlášení na RDP.

Jde o to, že v praxi to vypádává jinak. Starý server, mnohdy už mimo životní cyklus, k tomu VPN na MS Serveru (2008R2 apod.) nebo nějakém Mikrotiku a oboustranně povolený NAT-T. To Vám přijde bezpečnější, než jeden podporovaný a aktualizovaný produkt?

Stran: 1 ... 49 50 [51] 52 53 ... 206