it-swarm-eu.dev

Jaký je nejbezpečnější způsob, jak získat rootová práva: Sudo, su nebo login?

Chtěl bych mít root účet v bezpečí, i když je můj nevlastní uživatel ohrožen.

Na Ubuntu můžete ve výchozím nastavení používat Sudo pouze z „bezpečnostních důvodů“. Nejsem si však jistý, že je bezpečnější než jen přihlášení pomocí textové konzole. Existuje-li příliš mnoho věcí, které se mohou pokazit, pokud útočník dokáže spustit kód jako můj normální uživatel. Například přidávání aliasů, přidávání věcí do mého PATH, nastavení keyloggerů LD_PRELOAD a X11. Jedinou výhodu, kterou vidím, je časový limit, takže se nikdy nezapomenu odhlásit.

Mám stejné pochybnosti o su, ale nemá ani časový limit. Některé operace (zejména IO přesměrování) jsou přesvědčivější, ale z bezpečnostního hlediska se to zdá být horší.

Přihlášení k textové konzoli se zdá být nejbezpečnější. Protože je spuštěn init, pokud útočník může ovládat PATH nebo LD_PRELOAD, je již root. Události stisknutí kláves nelze zachytit programy běžícími na X. Nevím, zda programy běžící na X mohou zachytit [ctrl] + [alt] + [f1] (a otevřít celé okno, které vypadá jako konzole) nebo je to bezpečné jako [ctrl] + [alt] + [del] ve Windows. Kromě toho jediný problém, který vidím, je nedostatek časového limitu.

Takže mi něco chybí? Proč se kluci Ubuntu rozhodli povolit pouze sudo? Co mohu udělat pro zvýšení bezpečnosti kterékoli z těchto metod?

A co SSH? Tradičně se root nemůže přihlásit přes SSH. Ale s použitím výše uvedené logiky by to nebylo nejbezpečnější:

  • povolit root prostřednictvím SSH
  • přepnout do textového režimu
  • přihlásit se jako root
  • ssh na druhý stroj
  • přihlásit se jako root?
124
stribika

Bezpečnost je vždy o kompromisech. Stejně jako příslovečný server, který je na bezpečném a odpojeném místě, na dně oceánu, root by byl nejbezpečnější , kdyby tam byl nebyl vůbec žádný přístup.

Útoky LD_PRELOAD a PATH, jako jsou ty, které popisujete, předpokládají, že existuje útočník s přístupem k vašemu účtu již, nebo alespoň k vašim dotfiles. Sudo proti tomu vůbec moc nechrání - pokud mají vaše heslo, přece jen, nemusíte se o to pokoušet později ... mohou jednoduše použít Sudo nyní .

Je důležité zvážit, k čemu bylo Sudo původně určeno: delegování specifických příkazů (jako jsou ty, které spravují tiskárny) na „podřízené administrátory“ (snad grad studenty) v laboratoři), aniž byste úplně rozdali kořen. Používání Sudo vše je nejčastějším používáním, které nyní vidím, ale není to nutně problém, který měl program řešit (tedy směšně komplikovaná konfigurace syntaxe souboru).

Ale kořenový adresář Sudo-for-neomezený řeší další bezpečnostní problém: spravovatelnost rootových hesel. V mnoha organizacích bývají tyto předávány jako bonbóny, napsané na tabulích a zůstávají stejné navždy. To ponechává velkou zranitelnost, protože odvolání nebo změna přístupu se stává velkým výrobním číslem. I sledování toho, jaký počítač má, jaké heslo je výzva - natož sledování, kdo , který z nich.

Pamatujte, že většina „počítačové kriminality“ pochází zevnitř. Při popsané situaci s root heslem je těžké zjistit, kdo co udělal - něco, co Sudo s vzdáleným protokolováním řeší docela dobře.

Ve vašem domácím systému si myslím, že je to spíše otázka pohodlí, že si nemusíte pamatovat dvě hesla. Je pravděpodobné, že mnoho lidí je jednoduše nastavilo na stejné - nebo ještě horší, na začátku je na stejné úrovni a poté je nechali synchronizovat a nechali kořenové heslo hnit.

Používání hesel vůbec pro SSH je nebezpečné, protože trojanské ssh démony, které čichají heslem, jsou zavedeny do něčeho podobného, ​​jako je 90% kompromisů v reálném světě. Viděl jsem. Je mnohem lepší používat klíče SSH, a to může být funkční systém pro vzdálený přístup root.

Problémem však je, že jste nyní přešli od správy hesel ke správě klíčů a klíče ssh nejsou opravdu zvládnutelné. Neexistuje žádný způsob, jak omezit kopie, a pokud někdo vytvoří kopii, má všechny pokusy, které chce, aby hrubou silou frázi vynutil. Můžete stanovit, že klíče musí být uloženy na vyměnitelných zařízeních a připojeny pouze v případě potřeby, ale neexistuje žádný způsob, jak to vynutit - a nyní jste zavedli možnost, že se vyměnitelné zařízení ztratí nebo odcizení.

Nejvyšší zabezpečení bude dosaženo prostřednictvím jednorázových klíčů nebo kryptografických tokenů založených na čase/počítadle. To lze provést v softwaru, ale hardware odolný proti neoprávněné manipulaci je ještě lepší. Ve světě s otevřeným zdrojovým kódem existuje WiKiD , YubiKey nebo LinOTP a samozřejmě existuje také proprietární těžká váha RSA SecurID . Pokud se nacházíte v organizaci střední až velké velikosti, nebo dokonce malé organizace zaměřené na zabezpečení, vřele doporučuji prozkoumat jeden z těchto přístupů pro administrativní přístup.

Pravděpodobně je to přece jen doma, kde opravdu nemáte problémy se správou - pokud budete dodržovat rozumné bezpečnostní postupy.

105
mattdm

Toto je velmi složitá otázka. mattdmjiž pokrylo mnoho bodů .

Mezi su a Sudo, když uvažujete o jednom uživateli, su je o něco bezpečnější v tom, že útočník, který našel vaše heslo, nemůže okamžitě získat oprávnění root. Stačí však, aby útočník našel lokální kořenovou díru (relativně neobvyklou) nebo nainstaloval trojan a počkal, až spustíte su.

Sudo má výhody i přes přihlášení konzoly, pokud existuje více uživatelů. Například, pokud je systém nakonfigurován se vzdálenými protokoly proti neoprávněné manipulaci, můžete vždy zjistit, kdo naposledy spustil Sudo (nebo jehož účet byl ohrožen), ale nevíte, kdo zadal root heslo na konzoli.

Mám podezření, že rozhodnutí Ubuntu bylo částečně v zájmu jednoduchosti (pamatovat si pouze jedno heslo) a částečně v zájmu bezpečnosti a snadnosti distribuce pověření na sdílených strojích (obchodních nebo rodinných).

Linux nemá zabezpečený klíč pozornosti ani jiné zabezpečené uživatelské rozhraní pro autentizaci. Pokud vím, ani OpenBSD žádné nemá. Pokud se obáváte přístupu root, můžete úplně zakázat root přístup z běžícího systému: pokud chcete být root, musíte do příkazového řádku bootloaderu něco napsat. To samozřejmě není vhodné pro všechny případy použití. (* BSD's securelevel funguje takto: při vysoké úrovni zabezpečení existují věci, které nemůžete udělat bez restartování systému, jako je snížení úrovně zabezpečení nebo přímý přístup k připojeným nezpracovaným zařízením.)

Omezení způsobů, jak se člověk může stát rootem, není vždy zisk pro bezpečnost. Pamatujte na třetího člena bezpečnostní triáda : důvěrnost , integrita , dostupnost . Zamknutí ze systému vám může zabránit v reakci na incident.

Návrháři zabezpečené distribuce OpenWall GNU/*/Linux také vyjádřili kritické názory na su (za účelem root) a Sudo. Možná vás bude zajímat čtení tohoto vlákna:

... bohužel su i Sudo jsou jemně, ale zásadně chybné.

Kromě diskuse o nedostatcích su a dalších věcech se Solar Designer zaměřuje také na jeden konkrétní důvod k použití su:

Ano, bývalo běžnou sysadminovou moudrostí spíše než "root" než přihlášení jako root. Ti nemnoho, kdo, když by byli požádáni, mohli skutečně přijít s platným důvodem pro tuto preferenci, by odkazovali na lepší odpovědnost dosaženou tímto přístupem. Ano, je to opravdu dobrý důvod pro tento přístup. Ale je to také jediný. ...(Přečtěte si více)

Ve svém distro mají „ve výchozí instalaci se úplně zbavili kořenových programů SUID“ (tj. Včetně su; k tomu nevyužívají schopností):

U serverů si myslím, že lidé musí znovu zvážit a ve většině případů zakázat vyvolávání su a Sudo uživateli. Ze starého "přihlášení jako root bez root" neexistuje žádné další zabezpečení, pak su nebo Sudo do root "sysadmin" moudrosti ", ve srovnání s přihlášením jako root a přímo jako root (dvě oddělené relace). Naopak tento přístup je z hlediska bezpečnosti jediný správný:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(Pro odpovědnost více sysadminů musí systém podporovat více účtů s oprávněním root, stejně jako Owl.)

(U stolních počítačů s X je to složitější.)

Také se absolutně musíte vypořádat ...

BTW, měli nahradit sulogin s msulogin , aby umožnili nastavení s více kořenovými účty: msulogin umožňuje jednomu zadat také uživatelské jméno při přechodu do režimu pro jednoho uživatele (a zachovat „odpovědnost“) (tato informace pochází z tato diskuse v ruštině ).

Zdá se, že předpokládáte, že použití Sudo vždy zachovává proměnné prostředí, ale není tomu tak vždy. Zde je výňatek ze sudoské stránky:

Existují dva odlišné způsoby řešení proměnných prostředí. Ve výchozím nastavení je volba sudvů env_reset povolena. To způsobí, že příkazy budou prováděny v minimálním prostředí obsahujícím TERM, PATH, HOME, Shell, LOGNAME, USER a USERNAME kromě proměnných z vyvolávacího procesu povoleného volbami sudvostů env_check a env_keep. Účinně existuje whitelist pro proměnné prostředí.

Pokud je však v sudoers zakázána možnost env_reset, z proměnného, ​​které není explicitně odepřeno volbami env_check a env_delete, jsou z vyvolávajícího procesu zděděny. V tomto případě se env_check a env_delete chovají jako blacklist. Vzhledem k tomu, že není možné zakázat všechny potenciálně nebezpečné proměnné prostředí, doporučuje se používat výchozí chování env_reset.

Ve všech případech jsou proměnné prostředí s hodnotou začínající na () odstraněny, protože by mohly být interpretovány jako bash funkce. Seznam proměnných prostředí, které Sudo povoluje nebo zakazuje, je obsažen ve výstupu Sudo -V při spuštění jako root.

Takže když env_reset je povoleno (výchozí), útočník nemůže přepsat vaše PATH nebo jiné proměnné prostředí (pokud je výslovně nepřidáte do seznamu povolených proměnných, který by měl být zachován).

4
Cedric

Nejbezpečnějším přístupem je přihlášení pomocí ssh pomocí (alespoň) 2048 dlouhého klíče (s deaktivací přihlášení pomocí hesla), pomocí kterého je klíč uložen pomocí fyzického zařízení.

4
Šimon Tóth

Chci jen přidat něco trochu mimo téma. (u tématu jedna zaškrtněte '/ bin/su -' zde dále)

Myslím, že výše uvedené „zabezpečení“ by mělo být také spojeno se skutečnými údaji, které chceme zabezpečit.

Pokud to chceme zajistit, mělo by to být jiné: my_data, my_company_data, my_company_network.

Obvykle, když mluvím o bezpečnosti, mluvím také o „zabezpečení dat“ a zálohování. Můžeme také přidat systémy odolné vůči chybám a podobně.

Vzhledem k tomu si myslím, že bezpečnost jako celek je rovnováhou mezi použitelností, „bezpečností dat“ a požadovaným úsilím o zavedení bezpečného systému.

Cílem Ubuntu byl a většinou stále je konečný uživatel: Výchozí je sudo.

Fedora je bezplatná verze RedHat, která je zase více orientována na servery: Sudo bývalo deaktivováno.

Pro další distribuce nemám žádné přímé informace.

Používám právě teď, většinou Fedoru. A jako starý uživatel jsem nikdy nenapsal „su“. Ale mohu napsat "/ bin/su -" ve velmi krátké době, i když nejsem přesně pisatel. Proměnná PATH .. by neměla být problém (zadám cestu). Také „-“ (mínus) by v zásadě mělo odstranit mé proměnné prostředí uživatele a načíst pouze ty kořenové. tj. vyhnout se některým dalším možným problémům. Pravděpodobně také LS_PRELOAD.

Zbytek myslím, že @ mattdm byl docela přesný.

Ale nechme to dát do správného pole. Předpokládejme, že skriptovací inteligentní sada získá přístup k mým datům. Co si sakra myslíš, že s tím udělá? - Publikovat moje obrázky? můj? - Snažím se zjistit jméno mé přítelkyně a říct jí, že navštěvuji porno stránky?

Na obrázku jednoho uživatele jsou dvě nejhorší situace: - Dítě smaže všechna moje data: pro zábavu nebo omylem - Dítě používá můj počítač k dalšímu útoku na jinou entitu. Nebo podobné cíle.

Pro první případ, který jsem zmínil výše, bylo lepší vynaložit úsilí na zálohování než na zabezpečení sítě. Jo, jste zachráněni. Myslím, že selhání hardwaru není tak odlišné.

Druhý případ je jemnější. O těchto činnostech však existují signály. V každém případě můžete udělat to možné, ale já bych svůj domácí počítač nenakonfiguroval tak, aby byl chráněn před teroristickými útoky!

Přeskočím další scénáře.

na zdraví F

3
user5520

Pokud existuje obava, že kompromitovaný uživatelský účet lze použít k vyčesání hesla použitého pro Sudo nebo su, použijte jednorázový přístupový kód pro Sudo a su.

Můžete vynutit použití klíčů pro vzdálené uživatele, ale to nemusí projít shromážděním za účelem dodržování předpisů. Může být efektivnější nastavit bránu SSH, která vyžaduje dvoufaktorové ověření, a odtud povolit použití klíče. Zde je dokument o takovém nastavení: Zabezpečte nasazení SSH pomocí dvoufaktorové autentizace WiKID .

2
nowen

Můžete se také podívat na privacyIDEA , což vám nejen poskytuje možnost používat OTP pro přihlášení k počítači (nebo pro provádění su/Sudo), ale také může provádět OTP offline.

Kromě toho je schopen spravovat vaše SSH klíče. Tj. Pokud máte mnoho počítačů a několik uživatelů root, jsou všechny klíče SSH uloženy centrálně. Je tedy snadné „zrušit“/smazat klíč SSH, pokud již nelze důvěřovat.

Samozřejmě existují organizační úkoly a pracovní postupy, které zabezpečují systém.

0
cornelinux