Hrátky s ssh (diskuse)

[bambas]

No ja jen ze je asi lepsi, pokud mam verejnou IP, misto portu 22 pouzivat nejaky vyssi, treba 22000, apod. Ale to je jen muj nazor, noflame pls.

[Michal Kubeček]

Pokud si opravdu myslíte, že je to lepší, tak zkuste napsat proč. Jinak to jiný význam než flamebait nemá.

[prOm3TheuS]

Taky se nechci hádat, ale svoji výhodu to má. Port 22 je většinou neustále otvírán a zavírán otravnými roboty, kteří zkouší jednoduché kombinace jmen a hesel. Tím se zbytečně plní logy a zatěžuje démon.

[Michal Kubeček]

Pořád nevidím, v čem je ten problém. Pokud nemáte slabá hesla (nebo ještě lépe nemáte vůbec povolenou autentizaci heslem), nemusíte se jich bát, pokud máte, tak máte vážný problém bez ohledu na port. Jestli vám překážejí zápisy v logu, tak si to logování vypněte nebo si ho oddělte do samostatného souboru.

[Zdenek]

Videl bych tu jistou vyhodu v rychlejsi kontrole tech logu, pripadne snizeni moznosti prehlednuti skutecneho problemu.

[Grunt]

Tak, tak. Já se nejdříve snažil čistit ty logy, pak jsem se pokoušel blokovat přístup z těch adres co se o to pokoušeli (většinou Čína nebo tak), pak jsem povolil přístup jen z dopředu známých adres (ale to znemožňuje náhodné nečekané připojení z neznámého místa – a jak na sviňu vždy když je to nejvíc potřeba) a nakonec jsem skončil na portu 987.

[Hrabosh]

Já zatím používám Fail-to-ban.

[Josef Kufner]

Příloha:

• log-auth-week.png (2619 bytů)

Pak je ještě možnost omezit ssh na spojení přes VPN. Případně zablokovat rozsahy IP adres, ze kterých jsou útoky nejčastěji. Povolování tady není příliš praktické, protože se pak občas sám nepřipojíš.

Btw, už nějakou dobu mám v MRTG hozenou velikost /var/log/auth.log a pár dalších. Krásně jsou na tom jednotlivé útoky vidět. (viz příloha)

[Jendа]

Pak je ještě možnost omezit ssh na spojení přes VPN.

To bych se bál, že umře VPN a co pak s tím. SSH démon se mi zdá přecijen robustnější než SSH + VPN.

[Kvakor]

SSH přes OpenVPN má smysl jen tehdy, když je onen stroj, ke kterému se přistupuje, za NATem, nad kterým není kontrola (tj. není možné přesměrovaty port) a/nebo onen stroj dostává adresu dynamicky přes DHCP. V jiných případech je to zbytečné zesložitění, dokonce se odvažuju tvrdit, že SSH je to poslední, co má smysl cpát skrz OpenVPN tunel.

[Jendа]

SSH přes OpenVPN má smysl jen tehdy, když je onen stroj, ke kterému se přistupuje, za NATem, nad kterým není kontrola (tj. není možné přesměrovaty port) a/nebo onen stroj dostává adresu dynamicky přes DHCP.

To už radši SSH tunel nebo Teredo tunel, v případě měnící se adresy pak skript v cronu, který bude po každé změně adresu někam práskat (buď někam na HTTP nebo nejlépe dyndns).

[moira]

Pravděpodobnost, že umře VPN je stejná jako že umře SSH. Tím neříkám, že SSH nad VPN není zbytečné.

[Michal Kubeček]

SSH přes VPN používám tam, kde mám VPN tak jako tak a nemá smysl kvůli vzdálenému přihlášení extra zprovozňovat telnet nebo rsh jen proto, abych náhodou nešifroval a neautentizoval dvakrát.

[Jendа]

Ale v tomto případě ti pro problém stačí, aby umřelo jenom jedno z toho.

Jinak co jsem tak viděl v Debianu, SSH je při updatu vždycky úzkostlivě ošetřeno (dokonce mi kdysi nějaký skript z balíčku s aktualizacemi důležitých síťových nástrojů nabízel, že spustí kopii starého SSH na jiném portu), s VPN nemám tolik zkušeností, ale přijde mi ten software takový komplexnější (čti: víc věcí se může rozbít).

[Michal Kubeček]

Nemusíte vypínat logování úplně, stačí nelogovat ta hlášení, která vás nezajímají.

[sidik]

Kromě robotů to většinou znamená i konečnou pro scriptkiddies, co si někde přečtou článek "jak se nabourat do serveru", který začíná větou "připojte se na port 22" nebo si stáhnou přiložený tool, který je psán na port 22 a oni nejsou schopní ho upravit tak, aby buď otestoval všechny nebo mířil jinam.

Není to ani tak o bezpečnosti, jako spíš ulehčení práce - default je 22, tak se všechno stáčí na něj. Vzpomínám si, jak mi takhle během pár dní narostl log na 3GB, protože nějaké trdlo v místní síti zkusilo na můj počítač snad všechna možná zaklínadla (ne, do té doby jsem SSH nijak nenastavoval - na domácím PC, kam se připojuji z práce jsem neviděl důvod). Pak jsem si hrál s iptables a v rámci zkoušení jsem dal SSH jinam a 22 nastavil na DROP. A byl klid :)

[Michal Kubeček]

Kromě robotů to většinou znamená i konečnou pro scriptkiddies

Sice mi není moc jasné, jaký je podle vás rozdíl mezi "roboty" a "script kiddies" (podle mne je robot ten skript a kiddie ten, kdo ho spustil, takže ve výsledku prašť jak uhoď), ale spíš by mne zajímalo, o jakou "konečnou" se podle vás jedná. To, aby se vám nedostali na počítač - a to je IMHO to podstatné - pomocí obskurního portu nezajistíte a naopak, použijete-li správné prostředky, abyste to zajistil, mají "konečnou" i na defaultním portu.

Vzpomínám si, jak mi takhle během pár dní narostl log na 3GB

Máte-li problém se zbytečnými zápisy do logu, pak řešte ten problém, tj. zbytečné zápisy do logu.

[sidik]

Rozdíl mezi robotem a scriptkiddies je velký. Robot může běžet někde v nějakém botnetu a neustále kontrolovat různé stroje (ze seznamu, z rozsahů zemí...) a hledat kde by se chytil. Scriptkiddie je děcko, které si někde na netu stáhlo script nebo přečetlo návod a zkouší co s tím kde natropí. Tou konečnou mám na mysli, že to přestanou zkoušet. Pro děcko to znamená konečnou především proto, že nemá páru o tom, co vlastně dělá, takže nemá znalosti na nějaké zkoušení jiných portů. A někteří roboti si vedou logy o strojích, které neodpovídají, aby s nimi v budoucnu neztráceli čas...

[Michal Kubeček]

Takže v tom vlastně žádný podstatný rozdíl není… Aby nedošlo k nedorozumění, za podstatné považuji to, jestli se mi někdo dostane na počítač, ne to, jestli mám nějaké hlášky v logu, že se o to někdo snažil (kterých se navíc lze snadno zbavit, aniž bych kvůli tomu stěhoval sshd na obskurní port).

[Josef Kufner]

Ono se těch hlášek nezbavíš, protože jsou stejné jako ty od skutečných útoků. Ale když přestěhuješ sshd na jiný port, tak ho robot přehlédne a hlášky zmizí, takže skutečný útok se mezi nimi neztratí.

V podstatě to takto může bezpečnost zlepšit, ale je to spíš o pohodlí než o něčem jiném.

[Jendа]

Ono se těch hlášek nezbavíš, protože jsou stejné jako ty od skutečných útoků.

Bavíme se o hlášce oznamující odmítnutí přihlášení kvůli špatnému heslu?

[Josef Kufner]

Přesně tak, protože je sakra rozdíl mezi tím, když neco zkouší jen tak náhodně co ho napadne, nebo jde po konkrétních existujících účtech.

[Jendа]

Trápí nás vůbec útok hrubou silou přes síť? Pokud heslo není vyloženě primitivní, útočník nemá nejmenší šanci.

Jinak snad na všech unixech je existující účet root.

[Chytrex]

ten však jde jednou direktivou v configu zakázat přes SSH

[Jendа]

A k čemu je jeho zakázání dobré? (docela hezké je zakázání přihlašování roota heslem a povolení jenom klíčem - PermitRootLogin WithoutPassword (ano, ten název je děsivý :))

[Chytrex]

eliminuješ tím přihlášení na jediný 100% jistý účet na tom daném stroji.

[Jendа]

A k čemu by mi ta eliminace jako byla? A eliminuju tím i vlastní přihlášení, bez kterého se často neobejdu (a su/sudo není řešením, například záloha systémových adresářů, ke kterým může jenom root, se tak provést nedá).

[Josef Kufner]

Ale dá. Právě k tomu to sudo je dobré.

[Jendа]

Jako že jde pomocí suda rsyncnout/rdiff-backupnout /etc ze vzdáleného stroje? To jsem nevěděl. Nicméně pořád to neodpovídá na otázku, k čemu je to vlastně dobré, když se můžu přihlásit rovnou jako root.

[Chytrex]

Právě to sudo pomáhá, tím že nepotřebuješ ukazovat funkční rootlogin na ssh.. Přeci jen login který není ve slovníku a není běžný systémový nejde tak lehce odhalit. root je všude.. Povolený rootlogin přes ssh mi příjde jako obří blikající šipka s nápisem "TUDY" a mířící k sejfu.. A to že na té cestě jsou miny a žiletkový drát nehraje roli.:) Pořád je to slabé místo.. Pořád to někomu zjednoduším.. A pokud je navíc u rootloginu povoleno heslo.. Tak to se dá bruteforcem uhádnout.. Ano je to na dlouho.. ale i tady může zafungovat náhoda.

[Jendа]

Takže vlastně jediný argument je, že se to přes nějaký další účet hůř bruteforcuje. Takže teď si vezmi kalkulačku a spočítej si, jaký přínos má tvé uživatelské jméno složené z několika malých znaků, a jaký přínos by mělo prodloužení hesla roota o pár znaků z a-zA-Z0-9, nebo ještě lépe zakázání přihlašování heslem a používání 4Kib RSA klíčů.

[pavlix]

eliminuješ tím přihlášení na jediný 100% jistý účet na tom daném stroji.

Není to z hlediska bezpečnosti ekvivalentní připlácnutí mého běžného loginu do rootovského hesla a ponechání možnosti přihlásit roota zvenčí?

Zákaz přihlášení heslem mi přijde daleko užitečnější.

[Josef Kufner]

Netrápí, ale někoho tu trápily zabordelené logy ve kterých se pak lehčeji přehlédne něco, co by nás už trápit mohlo.

[Jendа]

Tak co třeba nelogovat pokusy o přihlášení, které neuspěly kvůli špatnému heslu?

[Josef Kufner]

Viz výše.

[Jendа]

Jak moc výše?

[Michal Kubeček]

Buď mi pokusy uhodnout heslo vadí a pak bych to měl řešit (nejlépe tak, že přihlášení heslem zakážu úplně) nebo mi nevadí a pak je řešit nemusím. Jestli ty pokusy provádí robot běžící na nějaké zombii, script kiddie nebo někdo kdo si na to napsal vlastní skript, v tom vůbec nehraje roli. Takže mne buď zajímá, kdo se mi pokouší přihlásit na server, a pak mne nutně musejí zajímat všechny takové pokusy, nebo mne to nezajímá, a pak mne nezajímá žádný.

[Michal Kubeček]

Skutečných útoků???

[Jakub Lucký]

No jasně... ti roboti přece nejsou žádní útočníci, to je jen takové logging decoration </bohapustá ironie>

[Heron]

No nevím. Logy například apache, nedej bože maillogy, se plní mnohokrát rychleji a také nikdo neřeší změnu portu z 80 na 12345 proto "aby to nezatěžovalo démon a neplnily se logy". To mi prostě nepřijde jako důvod, natož dobrý.

Pokud tu službu chci provozovat, měla by být nastavená a zabezpečená co nejlépe. Změnou portu toho nijak nedosáhnu, pouze si zkomplikuji připojení.

[qiRzT]

Nechci obhajovat ten důvod (a ani změnu portu), ale u apache a mailserveru se tak nějak očekává, že se na něj bude připojovat kdekdo z celého světa. U ssh se naopak předpokládá, že se tam bude připojovat pár lidí z víceméně stálé množiny adres.

[Heron]

To jsem si kdysi také říkal. Pak jsem se ale potřeboval připojit ze sítě (maškaráda na jednu IP) k sobě na server. Na té síti byl nějaký moc čilý robůtek, který se opakovaným přihlašování na moje ssh dopracoval až na čestné místo na blacklistu (používal jsem nějaké to denyhost). Prostě jsem se tam nedostal. Následovala změna konfigurace ssh, přihlašování pouze pomocí klíčů a celkově lepší nastavení sshd.

Ona to, pravda, na rozdíl od apache, není tak úplně veřejná služba, ale stále platí, že je potřeba se tam připojit odkudkoliv (rozuměj z nedefinovatelné skupiny IP). A občas i zcela regulérně z adres, které by jinak skončily blokované.

[qiRzT]

Jasně, mě šlo spíš o to plnění logů. U apache a mail serveru je známka normálního provozu u ssh něco podezřelého. Obdobně mě u apache asi nebude zajímat každý záznam, ale u ssh by se to mohlo stát.

[CET]

Me prijde velice vtipne, ze uzivatel nedostane pristup na roota pres klic, ale dostane root heslo

Kdyz uz, tak pristup pres sudo s vlastnim heslem. A pristup pres klic bych klidne dovolil - oba dva pristupy pak lze jednoduse spravovat pro ruzne uzivatele.

A root heslo nedavat nikomu uz jenom z toho duvodu, ze nekdo pak napise takovou prasarnu jako echo rotovoheslo | ssh $shost sudo -S -v. Vlastni heslo nepisu NIKAM, Windows heslo mam v /etc/auth/domain.ad pro autofs na windows shares a je jenom pro cteni rootovi. SSH klic a GPG klic mam s heslem na disku.

No jinak OK, akorat casem se to treba naucis zpameti a pak uz tohle potrebovat nebudes:)

[Milan]

Dobrý den ..

dekuji za postrehy, ale

nikde jsem nepsal, že jsem nedostal přístup na roota přes klíč. Prostě jsem ho nezaváděl.

Přístup přes ssh je pouze na klíč (nopasswd) a pouze z určených IP (asi 5 adres) . Pokud se vyskytne situace, kdy musím přistoupit z neprivilegované IP, udělám si tunel přes náš server. (jen klíč, fail2ban).

Klíč do rootova authorized keys si můžu kdykoliv udělat, ale nepotřebuju ho.

Rootovo heslo je tedy komukoliv na prd, pokud se fyzicky ke stroji nedostane, což už by byl průšvih sám o sobě i bez znalosti hesla

Zpaměti to skoro umím, ale je super připojit se během vteřinky na libovolný stroj zadáním

sshx0 154

nebo ne ? Nebo si mountnout vzdálený filesystém

sshf 154 

A samozřejmě - při použití ssh-agenta.

[mike]

hmm... zase jedno takove to dilema: udelat si tooly na Míru , ktere budou fungovat jen "u vas" nebo radeji memorovat oblibene kombinace std. prikazu, ktere pak muzete v klidu pouzivat vsude.
Nevim jak vy, ale ja jsem uviznul uprostred:

vnitrofiremni prostredi - Míra

zakaznici - Biologicky mixer a.k.a lidska pamet
Co se tyce ssh, tak me se HODNE libi bash-complete. Funguje i na dalsi veci. Mam take pocit, ze pro ssh je snad i nejaka moznost konfiguratoru nebo to bylo jen pro telnet?
Jak to vidite vy?

[Josef Kufner]

A úplně nejlepší je to zkřížit tak, že máš standardní konfigurák ~/.ssh/config a z toho máš vygenerované menu.

[sidik]

juj, pěkné

[Milan]

Tak tohle je dobrýý

Už delší dobu dumám, že tohle vypisování převedu přes Python a PyQt4 do GUI.. ale zase nevím, jestli bych se akorát nezdržoval klikáním

jako .. příkazová řádka je jeden z důvodů, proč nepoužívám některé jiné OS, to co umí bash na Li .. no jo GNU/Linuxu je těžká vidět jinde.

mnohokrát taky provádím vzdálené spouštění určitých programů (tedy ne přes VNC) a to jsou možnosti, které fakt obdivuju. jinak s tím ssh -X mám docela problém, protože kvalita připojení vyžaduje maximální úspornost (tak jak jsem doladil vncviewer), ale u ssh -X žádná taková volba není. Nebo neumím googlit ?

[Josef Kufner]

Tak ono to většinou vypadá tak, že ťuknu do F12, otevře se mi menu, pak "S", aby se otevřelo správné podmenu. Pak už jen nějaká ta šipka a enter nebo dva.

Celkově to vychází rychleji než psaní čehokoliv do terminálu, protože nemusím vzpomínat, jak se ten server přesně jmenuje. Ono sice při takovéto konfiguraci stačí prosté "ssh nějakýserver". Na scp to je fajn, ale když jde o nějaký server, kam nelezu každý den, tak se ta nabídka sakra hodí.

O klikacím dialogu/seznamu jsem taky uvažoval, ale to menu je takové praktičtější, rychle se ovládá z klávesnice a hlavně tam mám i hromadu dalších věcí, jako třeba jas displeje (Fn a PgUp/Down jsou moc daleko na jednu ruku) nebo výběr zvukovky na kterou bude mplayer hrát (lokální nebo domácí server).

Hodně dobré je si tam dát i pár příkazů xrandr (reset do základního nastavení, pár komplexních nastavení a pak pro každý displej pár univerzálních voleb, různá rozlišení a podobně). Ti co čas od času někde promítají nebo mají více monitorů u notebooku to hodně ocení. Tři stisky kláves a výstup je nastaven. Pozorovat pak někoho s Windows, jak se s tím trápí, je prostě úžasné.

[Milan]

Děkuji všem přispívajícím za slušné a věcné příspěvky.

[Radek Hladik]

Pěkné. Jen bych se opravdu vyhnul tomu psaní root hesla do nějakého souboru. Podle všech bezpečnostních pouček to vede k tomu, že účet daného uživatele je pak ekvivaletní s rootem. Z tohoto pohledu pak opravdu doporučuji použít ten klíč pro roota. Pak je možnost udělat místo sudo něco jako ssh root@127.0.0.1 'command '. Jediná věc, co tomu bránila k dosažení dokonalosti (alespoň tak cca rok zpátky, co jsem to zjišťoval) byla, že OpenSSH neumělo omezit nějaký rootovský klíč na použití z localhostu.

Jen pro zajímavost: Teď jsem, už asi po x-te, dočetl Kukaččí Vejce (Cliff Stoll) a ikdyž ty popisované věci jsou o několik úrovní v historii, princip zůstává pořád platný.

P.S. Nezalohují se někam ty skripty, včetně toho root hesla?

[Josef Kufner]

Spíš než

ssh root@server 'command'

je lepší udělat

ssh vyhrazeny_uzivatel@server 'sudo command'

a nastavit sudo tak, aby se neptalo na heslo a povolilo jen ten jeden konkretni command. Pak ani zveřejnění toho scriptu i s klíčem neznamená předání roota (ale záleží na tom, co ten command dělá). Jako další vylepšení by mohlo být nastavení toho celého command i se sudem jako login shell, aby ten vyhrazeny_uzivatel nemohl spustit nic jiného (ono vůbec je vlastní script místo loginshellu supr věc).

[Michal Kubeček]

… je lepší udělat

ssh vyhrazeny_uzivatel@server 'sudo command'

a nastavit sudo tak, aby se neptalo na heslo a povolilo jen ten jeden konkretni command.

V čem je to lepší než když rovnou pro ten klíč povolím jen příslušný příkaz? Mně to připadá jen komplikovanější.

[Radek Hladik]

Já jsem spíš měl na mysli případ, kdy chce pod rootem spouštět libovolné příkazy a ne předem definované. Pakud je to pár předem daných příkazů, pak je samozřejme sudo jasná volba...

[pavlix]

Spíš než

ssh root@server 'command'

je lepší udělat

ssh vyhrazeny_uzivatel@server 'sudo command'

Nebo využít prostředky SSH a udělat to samé bez sudo.

[Milan]

Děkuji za postřeh ... Tohle je vážně velká slabina celého řešení .... uvědomoval jsem si to i dříve, ale náhradu jsem nehledal.. napadá mně, při spuštění scriptu se jednou zeptat, uložit do proměnné ...

Budu muset něco vymyslet ..

[pavlix]

Pěkné. Jen bych se opravdu vyhnul tomu psaní root hesla do nějakého souboru.

Doporučuju klíč :).

Podle všech bezpečnostních pouček to vede k tomu, že účet daného uživatele je pak ekvivaletní s rootem.

Což nemusí být za všech okolností špatně.

Pak je možnost udělat místo sudo něco jako ssh root@127.0.0.1 'command '.

Nenapadá mě nic, v čem by to mělo být lepší než sudo.

Jediná věc, co tomu bránila k dosažení dokonalosti (alespoň tak cca rok zpátky, co jsem to zjišťoval) byla, že OpenSSH neumělo omezit nějaký rootovský klíč na použití z localhostu.

Zajímavé, já to zjišťoval myslím v podobné době a OpenSSH to umělo. Podle nějakého namátkou vybraného howto to umělo nejspíš už v roce 2006 nebo dříve.