Máte ssh pod kontrolou?

V článku Best practices ssh můžete posoudit, jak moc dobře máte svůj server nastavaný.

4.8.2010 07:56 | vencour | Zajímavý článek

Komentáře

[vencour]

Zajmavé jsou i ty linky Featured Articles.

[Jendа]

One of my client has really outdated php script and an attacker was able to create a new account on the system via a php script.

Řekl bych, že tady to nebude problém toho skriptu, ale spíš admina serveru, že mu klienti můžou vytvářet uživatele…

There is no need to login as root via ssh over a network.

Asi jsem divný, ale SSH dost často používám k administraci serveru a k tomu je root obvykle potřeba…

Ale mnohé jiné rady chválím a děkuji za ně .

[vencour]

V příslušné diskusi taky zazněly podobné postřehy.

[Jendа]

Komu se to nechce číst celé, tak vybírám dvě největší perly:

For this reason I use strong usernames too

Log in as ‘joey’, then sudo … provides audit trail & allows us to know WHO is using root privilege

Nejdřív mě to rozesmálo, ale teď si uvědomuji, že je to spíš k pláči…

[Mrkva]

A TOHLE spravuje nějaký server?!

[Václav "Darm" Novák]

Au...

[Andy]

Ja mam taky roota zakazanyho, ale samozrejme existuje sudoers a sudo su.

[Jiří J.]

A to by mě zajímalo. V podstatě se setkávám se dvěma názory - "login za roota není bezpečný, proto používám sudo" a "je to nesmysl, loguji se rovnou na roota".

Osobně používám druhou variantu, přijde mi zbytečné vytvářet nového uživatele jen pro prohlížení logů a update systému (tedy nepotřebuje prakticky nic ukládat v $HOME). Nikdo mi nikdy pořádně nedokázal vysvětlit, v čem spočívá to zabezpečení. I kdyby útočník nějak dokázal zasahovat do mé komunikace se serverem (třeba data injection), dokázal by mi tam "napsat" rm -fr /*, tak je jedno, jestli budu přihlášen na roota nebo na klasického uživatele + sudo. A pokud jde o uživatelské jméno - to se přenáší snad už šifrovaně, ne? Takže útočník nemá (bez prolomení mého klíče) ani páru, na koho se přihlašuju.

Napadá mě jen jedna možná výhoda loginu na normal usera - dvojí heslo. Nebo přihlášení klíčem na server + su/sudo s heslem pro roota. Tak by v případě ocizení klíče / zjištění hesla mohl útočník maximálně smazat obsah $HOME toho normálního uživatele. Ale stojí to za tu námahu? Nebo je v tom něco víc?

[Filip Jirsák]

Výhoda je jediná – pokud se všichni, kdo mají přístup na roota, budou chovat slušně (tj. nebudou měnit logy, instalovat backdoory apod.), máte při využití přihlášení na běžného uživatele a následné su automaticky logované, který ze správců byl kdy přihlášen. To se dá ale asi stejně zařídit logováním toho, jaký klíč byl použit pro přihlášení. Jiné výhody to dvojí přihlášení nemá.

[Jiří J.]

Oukej, přečetl jsem si diskuzi pod tím článkem a víceméně chápu případy, kdy je vhodné použít sudo. Mimo případ s více adminy je to třeba i ten, kdy se na roota přihlašuje admin přes heslo a zároveň na ten stroj má přístup více uživatelů přes ssh. Což jsem si neuvědomil tak rychle, protože "klasický" setup pro mě je server s určitým typem použití, primárně web/databáze/..., tedy už samotný přístup k sshd je limitován port knockingem, případně VPN a nikdo jiný se tam nepřihlašuje. V takovém případě asi dvojí přihlášení nemá moc smyslu.

[Jendа]

kdy se na roota přihlašuje admin přes heslo a zároveň na ten stroj má přístup více uživatelů přes ssh.

Tohle jsem nepochopil…

Jinak je ti jasné, že jakmile dáš někomu sudo na nějaký program, který umožňuje spouštět děti nebo nějak cokoliv upravovat, tak ten člověk už může se systémem dělat úplně cokoliv a ty se nemáš šanci se to dozvědět? Leda tak kdyby se logovalo na nějaký vzdálený server přes rsyslog.

[Jiří J.]

Ten citovaný kousek souvisí s potencionálním ztížením uhádnutí uživatele, který má přístup na roota. Představ si server, kde se na ssh přihlašuje .. 300 lidí. Pochopitelně ne všichni jsou důvěryhodní a prakticky se vzájemně neznají. Skutečný admin si může udělat normální uživatelský účet mezi těmito 300 lidmi a dát jen sobě práva pro sudo. Ostatní si tak můžou libovolně "útočit" na roota, na kterého se stejně nejde normálně přihlásit. (I když - na druhou stranu - root bash shell by byl asi jako child process toho uživatele.) Uváděl jsem to jako příklad k porovnání s "jeden účet, jeden admin" schématem, kde se nemá nikdo jiný vůbec dostat k sshd, natož aby zkoušel nějaká hesla.

Ohledně více adminů přes sudo - pochopitelně, ale v tom není ta pointa. Dělal jsem na jednom (herním) serveru spolu s dalšími lidmi správce systému. Používali jsme společný root account, ale pak někdo přišel s nápadem použít sudo. Mělo to praktické výhody (individuální bash historie, vlastní home), ale i drobnou vadu na kráse (psát po každém loginu "sudo bash"). Nikdo z nás neměl zájem něco mazat nebo se před něčím schovávat, ale pokud by nastal problěm třeba se špatně nakonfigurovaným apache, věděli bychom, za kým jít a nemuseli kvůli tomu obvolávat všech 5 lidí.

[Jendа]

Ostatní si tak můžou libovolně "útočit" na roota, na kterého se stejně nejde normálně přihlásit.

Jak útočit na roota? Jako zkoušet hesla? Už jsem níže napsal, že když bys přidal jméno uživatele k heslu roota, tak tím bezpečnost zvýšíš nesrovnatelně víc.

A navíc proč se nepřihlašovat klíčem.

[pht]

psát po každém loginu "sudo bash"

Můžete použít "sudo -i", ale to není to správné používání. Pointa suda je v tom že uděláte "sudo příkaz", takže v logu budete mít nejen kdo, ale i co.

[Filip Jirsák]

kdy se na roota přihlašuje admin přes heslo a zároveň na ten stroj má přístup více uživatelů přes ssh

To nechápu. Za prvé nechápu, proč se root přihlašuje přes heslo a ne přes klíč, a už vůbec nechápu, jak to souvisí s tím, že se přihlašují přes ssh i další uživatelé. A i ten případ s více adminy je dost sporný, stejnou službu udělá i logování klíče, kterým se root přihlásil.

[pht]

pokud se všichni, kdo mají přístup na roota, budou chovat slušně

V podstatě bych řekl že tato podmínka je nutná pro jakýkoliv přístup na roota

[Jendа]

Nikdo mi nikdy pořádně nedokázal vysvětlit, v čem spočívá to zabezpečení.

Neboj, mně taky ne.

Napadá mě jen jedna možná výhoda loginu na normal usera - dvojí heslo.

Toto (i „strong username“ v citaci výše) je velmi častý blud pocházející od těch, kteří se na to nepodívali z hlediska matematiky střední školy. „Výhoda“ dvojího hesla jako pokus o obranu před brute-force útokem je nesmyslná, zkombinováním těch hesel do jednoho se totiž získá řádově větší ochrana. Například při 2 10znakových heslech je v případě použití každého zvlášť možných 2⋅64^10 = 2,3E18 kombinací, ale při zkombinování za sebou 64^20 = 1,3E36.

Tak by v případě ocizení klíče / zjištění hesla mohl útočník maximálně smazat obsah $HOME toho normálního uživatele.

To je asi jediné možnost, ale nedá se nějak udělat, aby se autentizovalo klíčem i heslem najednou rovnou na roota? Nutno podotknout, že pokud se dostane na uživatele, tak nastaví alias su na nějaký vlastní skript, který uloží heslo.

[Jiří J.]

Viz můj příspěvek výše. Musím uznat, že v praxi existují případy, kdy je sshd využíván více lidmi (případně více "root" uživateli). Pro takové případy je fakt lepší sudo.

[Michal Ludvig]

Nikdo mi nikdy pořádně nedokázal vysvětlit, v čem spočívá to zabezpečení. I kdyby útočník nějak dokázal zasahovat do mé komunikace se serverem (třeba data injection), dokázal by mi tam "napsat" rm -fr /*, tak je jedno, jestli budu přihlášen na roota nebo na klasického uživatele + sudo.

Tak ja ti to teda vysvetlim

Attack ktery nas zajima se jmenuje SSH hijacking — SSH umi v jednom spojeni vytvorit nekolik kanalu, to se pouziva treba pri vzdalenem spousteni X11 aplikaci. Pokud se utocnikovi podari napadnout tvoji workstation a zjisti ze mas otevrene ssh spojeni jako root na nejaky jiny server, tak muze presvedcit tvoje bezici ssh aby oteverelo jeste jeden kanal a v nem na vzdalenem systemu spustilo, treba, /bin/bash. Samozrejme s pravy roota kdyz jsi tam zalogovan jako root. Tak proto neni dobre delat ssh root@somewhere

[Jendа]

Jenže když ti někdo zkompromituje počítač, tak může interagovat i s běžícím ssh, ve kterém běží bash pod rootem, protože ses sunul. Například do toho okna může přes xdotool poslat svůj vlastní příkaz ( nohup nc … /bin/bash 2>&1 > /dev/null &), před který šoupne mezeru, a hned potom vyvolat refresh terminálu, takže si toho nikdo nevšimne. Nebo ti může ukrást soukromý klíč z ~/.ssh. Nebo ti nainstaluje keylogger a odposlechne si heslo.

[Michal Ludvig]

Jde o to ze ssh na roota otevira dalsi pohodlny attack vector. Je to jen jeden z mnoha ale proc utocnikum ulehcovat praci, ze?

[pht]

Koukám, že o ssh panuje spousta mýtů a za chvíli se možní začnou psát i báje a pohádky.

[Filip Jirsák]

Pokud se útočníkovi podaří napadnout mou pracovní stanici, odkud se hlásím někam jinam jako obyčejný uživatel a pak dělám su na roota, přesvědčí mé ssh, aby otevřelo ještě jeden kanál a v něm na vzdáleném systému spustilo třeba /bin/bash, a v něm udělá s heslem odposlechnutým na mé pracovní stanici su. Takže to su nám zase k ničemu nepomohlo. Spíš naopak, opět vytvořilo pocit falešného bezpečí, a skutečné zabezpečení jde stranou.

[Michal Ludvig]

Proč tak příkře? "Přesvědčit SSH aby otevřelo druhý kanál" a "Odposlechnout heslo" jsou dvě úplně odlišné věci, přičemž může ale nemusí být možné je provést obě zároveň. U některých zákazníků používáme one-time-passwords - tam by odposlechnutí hesla bylo k ničemu ale ssh na roota by pořád bylo napadnutelné. Jindy třeba používám authentication agent forwarding - tam se heslo a dokonce ani klíč k tomu ssh procesu vůbec nedostane, ale vlastní spojení je pořád napadnutelné. Hlásit se na neprivilegovaného uživatele jistě není lék na všechny neduhy světa, ale nemáš pravdu že to ničemu nepomůže.

[Filip Jirsák]

Útočník má v moci mé prostředí na stanici, ze které se hlásím na vzdálený systém. Já se přihlásím a udělám su na roota – co útočníkovi brání udělat to samé, nebo rovnou použít mé přihlášení a poslat skrze něj třeba rm -rf /, zatímco mně bude do terminálu vypisovat nějaké neškodné hlášky? Ano, „přesvědčit SSH, aby otevřelo druhý kanál“ je něco jiného, než „mít úplnou kontrolu nad klientským systémem“, ovšem to druhé bude asi ve většině případů mnohem jednodušší – nebo vy znáte nějaký jednoduchý způsob, jak v bezpečném klientském prostředí „přesvědčit SSH, aby otevřelo druhý kanál“?

[Michal Ludvig]

co útočníkovi brání použít mé přihlášení a poslat skrze něj rm -rf / ?

Co mu brani? No neni to tak trivialni udelat - je potreba oblafnout ssh stejne jako u ssh hijackingu. Ovsem pokud mi pod rukama nekdo zacne psat "rm -rf" tak si toho nejspis vsimnu, zatimco kdyz si vyrobi novy kanal a bude si neco kutit ve vlastnim bashi tak si toho nejspis nevsimnu. Byt utocnikem tak co je pro me vyhodnejsi?

Navic kdyz se dostanu do nejakeho systemu a zjistim ze tamodtud jde ssh na root@jinde tak uz mam dvere otevrene - nemusim instalovat keylogger, nemusim cekat az se tam bude logovat priste abych chytil heslo, proste nemusim si komplikovat zivot. Staci vzit ssh-jackor a postoupit o dalsi hop.

Ale to je jedno. Oba dokazeme najit priklady ktere "dokazuji" kazdeho z nas pohled na vec, takze toho nechme. At se kazdy rozhodne sam jestli ssh root@ ano nebo radsi ne. Dobrou.

[Filip Jirsák]

Co mu brani? No neni to tak trivialni udelat - je potreba oblafnout ssh stejne jako u ssh hijackingu. Ovsem pokud mi pod rukama nekdo zacne psat "rm -rf" tak si toho nejspis vsimnu, zatimco kdyz si vyrobi novy kanal a bude si neco kutit ve vlastnim bashi tak si toho nejspis nevsimnu. Byt utocnikem tak co je pro me vyhodnejsi?

Není třeba oblafnout ssh, nemusíte si všimnout žádného psaní – stačí oblafnout třeba terminál, window manager, podstrčit vám jiné ssh atd. atd.

Navic kdyz se dostanu do nejakeho systemu

Co to znamená „dostanu se do nějakého systému“?

zjistim ze tamodtud jde ssh na root@jinde tak uz mam dvere otevrene - nemusim instalovat keylogger, nemusim cekat az se tam bude logovat priste abych chytil heslo, proste nemusim si komplikovat zivot. Staci vzit ssh-jackor a postoupit o dalsi hop.

Není potřeba brát ani ssh-jackor, stačí použít stávající kanál, kde už je uživatel přihlášen na vzdáleného roota.

[Michal Ludvig]

Jasne, ze "stačí oblafnout třeba terminál, window manager, podstrčit jiné ssh atd. atd.". A navic jedna z moznosti je otevrit novy kanal rovnou na vzdaleneho roota. Kdyz ta moznost je proc by ji utocnik nemel nevyuzit? Jednoduche, elegantni, dobre skryte. Kdyz by ssh na vzdaleneho roota nebylo musel by si poradit jinak (treba pokusem o oblafnuti terminalu nebo window manageru) a mozna by mu to nevyslo. IMO ma smysl zavrit dvere i kdyz okno zustava pootevrene.

(Pokud chcete mit posledni slovo tak prosim. Ja uz v mlaceni prazdne slamy v tomto threadu pokracovat nebudu.)

[Filip Jirsák]

Když máte 100 věcí, které útočník může zneužít, a vy jednu odstraníte, nijak jste si nepomohl. Musíte mu znemožnit všech těch 100 způsobů zneužití – a když to uděláte, nemusíte se pak trápit ještě extra ošetřováním toho jednoho způsobu, protože ten už jste ošetřil v rámci celku.

Kdyz by ssh na vzdaleneho roota nebylo musel by si poradit jinak a mozna by mu to nevyslo.

Ano, to je klíčová věta pro opatření typu „přihlášení na roota přes su“. Možná nebude útočník moc schopný a do systému se nenabourá. Ovšem opatření, která jako přepdoklad vyžadují neschopného útočníka, jsou k ničemu.

IMO ma smysl zavrit dvere i kdyz okno zustava pootevrene.

Podle mne má smysl místo toho postavit plot nebo pořídit alarm. Zavírat okno, když jsou otevřené dveře, je jako opatření proti zlodějům k ničemu.

[Jendа]

Pokud to beru podle sebe, tak nabourat do počítače bych se ti nedokázal, ale zneužít ssh na uživatele + su bych uměl. Tudíž bych nepředpokládal, že někdo, kdo se ti umí nabourat do počítače, nebude umět zneužít ssh se su.

A pokud ti vadí, že je ssh vidět v ps, tak si přejmenuj ssh na firefox .

[pht]

Kdyz by ssh na vzdaleneho roota nebylo musel by si poradit jinak (treba pokusem o oblafnuti terminalu nebo window manageru) a mozna by mu to nevyslo.

Nějak nevidím rozdíl v pravděpodobnostech selhání programů ssh-jackor a terminal-jackor.

BTW zrovna tak existuje asi 150 dalších způsobů, např. ptrace na ten ssh proces a vložení vlastních příkazů.

Obecně pokud má někdo pod kontrolou kanál, kterým něco provádíte Vy, tak to může udělat za Vás.

IMO ma smysl zavrit dvere i kdyz okno zustava pootevrene.

A dokud nepředložíte nějaká konkrétní čísla, kde bude poznat kolik peněz takové opatření stojí a kolik ušetří, tak to bude pouze bezpečnostní honimířina (jak to nazývá Linus) a nikoliv kvalifikovaná rada

[Filip Jirsák]

Asi jsem divný, ale SSH dost často používám k administraci serveru a k tomu je root obvykle potřeba…

Ale mnohé jiné rady chválím a děkuji za ně .

No ony jsou to vůbec best practices a worst practices na jedné hromadě, akorát chybí rozlišení, které jsou které

[Michal Kubeček]

Obzvlášť pikantní je, že některé rady jsou vzájemně v konfliktu. V jedné se třeba doporučuje používat silná hesla a v druhé nepoužívat hesla vůbec. V jedné radí odstěhovat sshd na jiný port a v druhé omezit paketovým filtrem přístup na port 22. :-)

[Jiří J.]

Řekl bych, že tady to nebude problém toho skriptu, ale spíš admina serveru, že mu klienti můžou vytvářet uživatele…

No především celý ten odstavec je nesmysl. Pokud byl admin skutečně tak neopatrný, pak asi měl i /tmp primountované bez parametru noexec, případně měl dostupné interpretery perlu/pythonu/vlastně i php. Takže se útočník nemusel zabývat nějakým ssh, mohl si spustit vlastní (třeba telnet) server a AllowUsers by mu v tom nezabránilo. Ostatně i takový C99 má jednoduchou variantu shellu.

[Mrkva]

Ono takový interpreter je na webserveru docela potřeba, pokud tedy nechcete hostovat jen statické HTML stránky :)

[Michal Kubeček]

Mou důvěrou silně otřásla už první rada. Pominu-li, že odinstalování balíčků je naprosto zbytečné, tak kdybych ji zkusil použít ve své distribuci, odinstaluji spolu s SSH démonem i klienta. No a sedmička, to už je takový evergreen, divím se, že rovnou nedoporučili i přestěhování na port 22222.

[Michal Kubeček]

Ach pardon, takže všechno zpátky, přehlédl jsem devítku… :-)

[the neanonymní já]

Mě pobavil už ten první obrázek - SSH Session in Action jako bychom to nikdy předtím neviděli

[Filip Jirsák]

Autor to možná viděl poprvé, některé rady by tomu odpovídaly…