Vlákno názorů k článku
Pět tipů jak zabezpečit svůj SSH server
od Heron - Je neuvěřitelné, jak tuhý mají tyhle mýty kořínek.
Nesmysl...
-
Je neuvěřitelné, jak tuhý mají tyhle mýty kořínek.
Nesmysl první, blokování tzv. brute force (Denyhost a Fail2Ban):
Vzhledem k existenci překladu adres a jeho masivního zneužití pro připojení stovek domácností za jednu IP, tak touto metodou dosáhnete akorát tak toho, že se na svůj server nepřihlásíte, jelikož někdo z vaší (ze sítě, odkud se tam chcete přihlásit) sítě vám tam dělal "útok". Toto se stává zcela běžně.
Disable root login:
Nemá žádný bezpečnostní význam. Bezpečnost není založena na tom, že někdo něco neví (security by obscurity). Toho konkrétního uživatele si útočník stejně najde.
Banner: LOL
Jiný port: Opět, security by obscurity, bezpečnost se tím nezvýší (solidní free port scan vám to najde na jakémkoliv portu). Navíc si tím brutálně zkomplikujete práci a efektivně odstavíte různé skripty, co přes ssh něco někde spouštějí.
Všechny tyhle metody zajistí akorát falešný pocit sucha a bezpečí. Nic víc. "Ochrání" pouze proti slovníkovým útokům nebo proti brute force útokům na slabé heslo. Nic z toho by se nemělo používat. Jinými slovy zabrání to pouze tomu, na co by ten server měl být odolný by default.
Jediným skutečným řešením je použití buď dobrého hesla (dobré heslo je od 80bit entropie výše, což je při použití rozumné množiny stisknutelných znaků cca 16 znaků dlouhé heslo).
A úplně nejlepším řešením je samozřejmně nepoužívat přihlašování heslem, ale používat RSA klíče. To je také jedinná možná metoda, jak se přihlásit automaticky (klient ssh záměrně nepodporuje zadávání hesla na příkazové řádce) na vzdálený server (vhodné pro nějaký skript).
--
Poznámka pod čarou. Problém těchto intuitivních metod je v tom, že lidé neumí počítat a přeceňují jejich váhu a navíc si tím zkomplikují samotnou chtěnou legální práci.
Například změna portu znamená přidání max. 65536 pokusů. Ale pozor, není to 2^16 (počet portů) * 2^80 (16 znakové heslo) jak si mnozí myslí, ale součet (2^16+2^80 -- plyvnutí do moře). Stejně tak je to s tím rootem / uživatelem a su na roota. Pokud by měli oba stejně kvalitní heslo, tak: 2^80 + 2^80 = 2*2^80 = 2^81. DALEKO větší efekt má přidání pár znaků k heslu. 20 znakové heslo je cca 2^103. Přidáním 4 znaků jste najednou o 20 bitů jinde.
Takže, nekomplikujte si život používáním kravin, které stejně nefungují, místo toho udělejte pro bezpečnost daleko více lepším generováním hesel, nebo úplně nejlépe, používejte klíče.
-
Jenda (neregistrovaný)
Já bych si rejpnul
„Disable root login: Nemá žádný bezpečnostní význam.“
Jak už někdo podotkl, v nedávné historii byla minimálně jedna díra (faktorizovatelné klíče z Debianu), kde by neznalost uživatelského jména útočníkem pomohla.
„Bezpečnost není založena na tom, že někdo něco neví“
Moje bezpečnost je založena na tom, že nikdo neví moje heslo a dvě prvočísla mého klíče.
-
Filip JirsákStříbrný podporovatelPak je ale potřeba napsat to správně, ne jen zlomek toho, co je potřeba udělat. Tedy: „Vytvořit účty s bezpečnými názvy (např. 20 znaků, kombinace malých a velkých písmen, číslic a symbolů), na všechny ostatní účty zakázat přihlašování, zabezpečit, aby se jména těchto bezpečných účtů nikde neprozradila (např. v e-mailu, v chybových hláškách apod.).“ Přeju hodně štěstí při realizaci.
-
Jenda (neregistrovaný)
Zjistit jméno uživatelského účtu na vzdáleném serveru, ze kterého se dělá jenom su/sudo, podle mě není zas tak triviální. Určitě to ochrání před masovým útokem typu „objevil jsem díru v debianím openssl, spočítal jsem si všech 65535 klíčů a teď scannuju Internet a přidávám si stroje do botnetu“.
Aby bylo jasno, nejsem zastáncem zakazování přihlašování roota - jen si myslím, že tvrdit, že to nepřidá vůbec žádnou bezpečnost navíc, je nesmyslné.
-
Franta <xkucf03/> (neregistrovaný)
Souhlas… ale určitě se najdou lepší řešení – mnohem bezpečnější a zároveň tě nepřipraví o přímé přihlašování na roota.
Např. zřetězit SSH a SSL/TLS. Buď jako VPN nebo jednoduchý šifrovaný tunel, přes který se dostaneš k SSH portu. Pro úspěšný útok by se pak musela objevit ve stejnou chvíli chyba ve dvou různých knihovnách.
-
Filip JirsákStříbrný podporovatel
Pokud se zakáže jen přihlášení na roota, útočník nemusí zjistit jméno toho účtu, který používá správce – může použít kterýkoli jiný účet v systému, třeba bin, daemon, ftp, apache… A i kdyby útočník potřeboval ten správcův účet, je spousta možností, kudy jeho název může uniknout – pochybuju o tom, že by někdo dokázal všechny ty možnosti zkontrolovat, problém by byl dát vůbec jen ten seznam dohromady. Třeba Ident, SMTP VRFY/EXPN, domovské stránky http://server/~user…
Ano, proti jednomu konkrétnímu typu útoku to přidat bezpečnost může. Jenže stejně tak si lze představit různé typy útoků, kdy zákaz přihlašování na roota bezpečnost naopak sníží. A myslím, že tyhle typy útoků jsou mnohem pravděpodobnější, takže ve výsledku to pravděpodobnost úspěšného útoku spíš zvyšuje.
-
Jenda (neregistrovaný)
„může použít kterýkoli jiný účet v systému, třeba bin, daemon, ftp, apache“
Není náhodou podmínkou exploitnutí zmíněné díry v debianím openssl to, že uživatel, na kterého se chcete přihlásit, má možnost přihlásit se klíčem? A váš uživatel bin má authorized_key?
„A i kdyby útočník potřeboval ten správcův účet, je spousta možností, kudy jeho název může uniknout – pochybuju o tom, že by někdo dokázal všechny ty možnosti zkontrolovat, problém by byl dát vůbec jen ten seznam dohromady. Třeba Ident, SMTP VRFY/EXPN, domovské stránky http://server/~user…“
Ještě jednou - robot s databází klíčů z Debianu skenující Internet a snažící se zalogovat nebude nejspíš bruteforcovat jména na lokálním SMTP (doufaje, že se pro mail užívají unixové účty) nebo googlit, jestli uživatel nemá zrovna v domovském adresáři web.
Jinak myslím si, že kdybych neměl na svých serverech uživatele podle jejich běžně známých přezdívek, tak by to nebylo ani u cíleného útoku tak snadné zjistit.
„Ano, proti jednomu konkrétnímu typu útoku to přidat bezpečnost může.“
A o to mi právě šlo - souhlasím, že jde o politováníhodnou chybu, ke které dochází maximálně 3x za deset let a že Katóda Olomóc už dodává kvalitnější elektronky. Ale právě v tomto jednom případě to ochránilo server před totálním vyownováním.
„Jenže stejně tak si lze představit různé typy útoků, kdy zákaz přihlašování na roota bezpečnost naopak sníží.“
Přiznám se, že si žádný takový nedokážu představit.
-
Filip JirsákStříbrný podporovatel
Pokud jde opravdu jen o obranu před robotem, který chce co nejrychleji posbírat co nejvíce root účtů (a je „líný“ i hádat jiná uživatelská jména), bude nejlepší obrana přechod na IPv6, protože tím se prohledávaný prostor zvětší mnohem víc, než používáním jiného jména o pár znacích :-)
su/sudo jsou další nástroje, ve kterých může být chyba; při jejich použití se musí heslo roota zadávat z klávesnice, musí se přenášet přes (myslíme si, že šifrované) spojení. Takže je třeba riziko, že su nebude nic ověřovat a rovnou přepne na roota, přičemž povolením přihlašování na roota a zákazem su se tohle riziko eliminuje. Uznávám, že je to nepravděpodobná konstrukce, ale to byla před dvěma lety i představa, že by generované klíče byly slabší než tříznakové heslo.
-
Filip JirsákStříbrný podporovatel
Útočník může mít na cílovém stroji legální účet. A i kdyby neměl -- když se mi podaří proti průniku zabezpečit všechny uživatelské účty, proč stejně nezabezpečím i ten rootovský?
-
Filip JirsákStříbrný podporovatel
Pokud někdo zabezpečuje server způsobem popsaným v původním článku, odolnost proti útoku z prolomeného účtu neroota (ze kterého běžně správce dělá su na roota) bude prakticky nulová. Dokonce by to šlo asi snadno dělat i robotem - třeba na ten neroot účet podstrčit falešné su a dát ho na začátek cesty by mohl dobře zvládat i robot.
Jinak já nepopírám, že za určité konstelace může zákaz přímého přihlášení na roota zmenšit pravděpodobnost úspěšného útoku. Ale když takový způsob zabezpečení chci použít, měl bych právě ty souvislosti vědět, měl bych vědět, proti čemu mne to chrání a jaká musím udělat další opatření, měl bych mít vyřešené všechny problémy, které bezpečnost ohrožují více.
Pokud je to zabezpečení jen náhodný výstřel (jako v tom článku) ve stylu "mně to kompiluje život, tak to určitě musí být bezpečné, a o žádném zvýšení rizika nevím, protože jsem o tom nepřemýšlel", je to především příznak toho, že dotyčný správce toho o zabezpečení moc netuší. To je myslím to nejpodstatnější -- a jestli tím konkrétním nastavením bezpečnost trochu zvýšil, trochu snížil nebo nijak neovlivnil, to už je vlastně nepodstatný detail.
-
Franta <xkucf03/> (neregistrovaný)
Ad „Přiznám se, že si žádný takový nedokážu představit.“
Pokud by ti útočník napadl účet běžného uživatele na serveru, získá při tvém příštím přihlášení i roota (stačí třeba alias na su, který odchytne heslo).
BTW: co místo zakázání roota jen přejmenovat uživatele s UID = 0? Pokud zákaz roota pomáhá jako ochrana před některými útoky, tohle by fungovalo taky a zároveň bys nepřišel o možnost např. kopírovat soubory jako root, spouštět ze vzdálených strojů správcovské příkazy a taky by to bylo bezpečnější v případě, že by došlo ke kompromitaci účtu běžného uživatele (na roota bys nechodil přes su/sudo).
-
Filip JirsákStříbrný podporovatel
Na přejmenování uživatele root bych asi neměl odvahu. Bůhví, kde všude to jméno bude zadrátováno... Něco jiného by bylo vytvoření přezdívky - dalšího uživatele s uid=0. Ale to by se pak stejně muselo zakázat přihlášení uživatele jménem root v SSH. Mimochodem, čím se vlastně PermitRootLogin řídí? Jménem uživatele, nebo uid?
-
heh (neregistrovaný)
"...Tyto útoky nejsou samy o sobě moc nebezpečné, ale zaplňují logy, chudák admin (tj. já) pak tráví o to více času jejich čtením a zvyšuje se riziko, že mezi řadou těchto méně nebezpečných útoků přehlédne něco nebezpečnějšího. Tyto automatizované útoky tedy není zcela od věci odfiltrovat..."
-
Kdyz jsem se díval do logu neúspěšných pokusů o přihlášení, tak většina jich byla se známými loginy (root, apache apod.). Na jiné loginy tolik pokusů nebylo, ale i tak se jim podařilo slovníkem získat můj login. Udělali pár stovek pokusů a i když bylo heslo poměrně nelmi velmi slabé, tak ho nenašli.
