Server Tecmint.com připravil pět tipů jak zvýšit zabezpečení vašeho SSH serveru. Doporučují například hlídat brute force útoky a dávat IP adresu na blacklist trvale nebo alespoň po nějaký čas.
Dalším tipem je zamezení přihlášení roota přes SSH. Osobně si myslím, že to je spíše nutnost, protože žádná ochrana dnes není 100% a tato volba minimálně útočníkům ztíží podmínky. V článku naleznete i odkazy na detailní popisy uvedených řešení.
Takže kdybych místo toho heslo na roota vytvořil jako (username+původní_heslo) (znak + je zde concatenate stringů), získám úplně stejnou bezpečnost? Nebo kdybych zakázal přihlašování heslem úplně a používal klíče.
Vase uvaha je postavena pouze na brute-force utoku. Predpokladate, ze bude trvat stejne dlouho rozlousknout jmeno + heslo jako heslo roota ve tvaru jmeno+heslo.
Ma to i jina hlediska. Je docela problem blokovat IP utocnika se spatnym heslem - muze to byt kombinace chyby s lenosti usera a to spatne heslo (nevite jestli se pokazde lisi) dela neco automaticky. To se vetsinou nedava na blacklist, jen zpomaluje.
Kazdopadne kdyz nekdo zkusi par neexistujich jmen, je sparavny cas dat ho na blacklist. To nevznikne chybou usera. easy. :)
Ale to je jen pro priklad, neresi to distribuovany utok. Tech moznosti utoku a obran je hodne. Nikdy se neda branit 100%. Dulezite je ale to tomu velkemu mnozstvi horsich hackeru nezjednodusovat. :)
Dejme tomu, že má někdo uživatelské jméno „pacient“ a heslo „nbusr123“ a pak se přepíná na roota pomocí su a hesla „kalousek456“.
Útočník musí uhodnout jméno (tam nemusí používat bruteforce, ale může ho odvodit) a dvě hesla.
Srovnej to se situací, kdy je povoleno přihlašování roota a jeho heslo je „pacientnbusr123kalousek456“.
Uhodnout toto složené heslo je výrazně složitější než uhodnout postupně jednotlivé jeho složky (když v prvním případě uhodne „nbusr123“, hledá už jen druhou část hesla a nemusí zkoušet tolik kombinací).
Navíc po napadení účtu běžného uživatele může přidat třeba alias pro příkaz su – obalit ho skriptem, který zadané heslo odešle útočníkovi.
Takže nakonec může zákaz přímého přihlášení roota bezpečnost paradoxně snižovat – člověk by si na běžný uživatelský účet musel dávat úplně stejný pozor, jako by to byl účet roota…
P.S. Mnohem důležitější je zákaz hesel a používání klíčů, případně jednorázových hesel.
Ty vole, tak na tohle "zabezpeceni" ssh-serveru koukam jako tele! Tedy abych byl presnej, nejdriv sem se musel prestat valet smichy po podlaze...
Tak teda jdu vymyslet nakej hodne desivej banner. Jenom nevim, jestli si to boti co prolezaji ssh-servery se slovniky taky prectou...
Mne sa zatial najviac pozdava nasledujuca kombinacia:
1) Zakazat prihlasovanie heslom a inymi divnymi sposobmi, ponechat len kluce:
PermitRootLogin no StrictModes yes MaxAuthTries 1 RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no
2) Urcit povolene loginy:
AllowUsers janko jozko ferko
3) Nastavit firewall, aby povolil len urcity pocet nadviazanych spojeni za nejaky casovy usek:
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name sshblacklist --set $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name sshblacklist --update --seconds 120 --hitcount 6 -j DROP $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
Takto zabezpeceny server (a samozrejme aktualizovany) sa podla mojich skusenosti da povazovat za celkom bezpecny, co sa tyka utoku cez SSH.
Problem je, ak clovek chodi hore-dole a stale sa pripaja z inej wifi (samozrejme zo svojho stroja, resp. mobilu). Samozrejme, da sa spravit nejaky port knocking alebo mat urcenych niekolko strojov, ktore budu fungovat ako proxy, ale problem nastava, ak na server pristupuje viac roznych pouzivatelov, ktori su rozlezeni. Prave na tento pripad som pisal tie predchadzajuce body.
Ked tak rozmyslam, tak okrem sukromneho serveru u mna doma nemam ziaden iny server, na ktory by som pristupoval iba ja sam.
Pro ty deb*lky, co tu slintaj sarkastický poznámky k zakázání přihlašování roota:
- umožní to striktnější pravidla banování pro nepovedené pokusy o přihlášení na roota
- nekomplikuje se omezováním adres odkud se může root přihlásit
- 99% pokusů o kompromitaci ssh serverů _je_ na účet roota, cílené útoky jsou jiná úroveň. To je holá realita.
- odolnost proti 0-day exploitům, které obchází autorizační kód
Takže optimálnější zabezpečení je zakázat roota, povolit su jen pro vybraného uživatele a na něj se přihlašovat nejlépe přes certifikát, kterej by se měl v dostatečných intervalech obměňovat. Ale pořád je to jen malá část toho, co spadá pod problém zabezpečení serveru.
Použití nadávek na faktech nic nezmění, jen prozrazují nedostatek sebejistoty jejich autora.
„99% pokusů o kompromitaci ssh serverů _je_ na účet roota“
Zprávička se tvářila jako že je o bezpečnosti, ne o statistických průzkumech.
Chtěl jsem reagovat i na zbytek komentáře, kdyby to nebylo jen další plácání do větru.
Příspěvek na který jste reagoval, měl alespoň nějakou informační hodnotu (byť subjektivní, ale fakta). Naopak Váš příspěvek je "jen další plácání do větru".
Pokud chcete diskutovat, zkuste v případě nesouhlasné reakce inteligentnější oponenturu:
- eliminujte "emoční výlevy" (osobní narážky apod.)
- maximalizujte informační hodnotu (jasné formulace, informace, fakta)
PS: Omlouvám se za Off-Topic.
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.
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.
Pak 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.
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é.
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.
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.
„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.
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.
Ú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ý?
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.
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).
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?
"...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.
