Bezpečný přístup na veřejnou IP přes SSH

[aigor.net]

Ahoj, předtím než mě odkážete na VPN, prosím o přečtení celého dotazu..
Jedná se o server ve firmě, který spravuji. Není vystaven na netu a ven žádné služby neposyktuje. Nicméně provider nám nabídl za symbolický poplatek veřejnou IP a líbí se mi myšlenka v případě potřeby se jednoduše připojit.
V celé jejich síti jde o jediný Linux server + Win stanice, jinam se tedy připojovat nepotřebuji. GUI samozřejmě není instalováno, zajímá mě pouze SSH na občasné servisní úkony a správu. Router mikrotik.

Moje představa je vystavit libovolný port s SSH serverem, přihlašování pouze klíčem.
Připojovat se budu jednak ze svého desktopu, nebo v nouzi na cesták i z tabletu, tzn. filtrování na IP nejde použít.

Jaká jsou rizika útoku? Nedostupnost SSH (ddos) není problém, vyřeší se to autem jako postaru. Naopak možné napadení (krádež/poškození firemních dat) by znamenalo hodně velký průšvih!

Pokud neuvažuju nějaké Zero-Day chyby v openssh a pravidelně aktualizovaný server, jaké má tohle řešení možné slabiny?

[Reklama]

[Petr Krčmář]

Mám to přesně takhle na všech serverech i routerech. Otevřené SSH do světa na standardním TCP portu 22, přihlašování pouze klíči. Pokud je systém aktualizovaný, nevidím v tom žádné bezpečnostní riziko. Hesla se hádat nedají, uživatelé mají přístup jen do svého adresáře pro SFTP.

[kotelgg]

Používám roky jen hesla, občas klice na desítkách virtualech a bez problémů. Pokusu o přihlášení samozřejmě miliarda ale na 13ti mistnejch heslech bez šance. Ze začátku jsem se jakoby snažil mít zakazanyho roota a řešit všechno přes sudo, ale to je strašná ztráta času.

[Filip Jirsák]

Jak píšou ostatní, SSH nechat na standardním portu (někde blokují odchozí provoz podle portů, SSH tam obvykle potřebují pro sebe, takže se pak i z takové sítě dostanete na svůj server). Povolil bych přihlášení jenom klíčem, hádači hesel pak mají smůlu a podle mne je to i pohodlnější. Pokud byste přeci jen chtěl povolit přihlašování heslem, vyjmenujte uživatele, pro které to povolíte a u kterých si budete jistý, že mají dostatečně silné heslo. Ohlídejte si, ať máte aktuální verzi jádra a OpenSSH, abyste tam nepovolil nějaké staré protokoly nebo algoritmy, a ať na té veřejné IP adrese neposlouchají jiné programy, než to OpenSSH (a to ani po restartu – ať se vám programy pro naslouchání nepřipojují na 0.0.0.0). Klíče doporučuji použít různé pro každého klienta – když vám někdo ukradne tablet, pohodlně se na server přihlásíte z desktopu a tabletový klíč deaktivujete a nemusíte hned řešit jeho výměnu i na desktopu.

Pokud máte na těch stanicích s Windows uživatele, kteří klikají na kde co, jsou řádově větším rizikem pro firemní data, než ten OpenSSH server. U toho serveru hrozí to, že něco špatně nakonfigurujete, krádež přístupového klíče (dá se posílit zabezpečením klíče heslem – po dobu, co útočník louská heslo, máte čas na deaktivaci klíče) a zero-day v softwaru – to všechno jsou řádově menší rizika, než málo obezřetní uživatelé.

[aigor.net]

Díky za potvrzení myšlenky. Osobně už roky používám stejně jen klíče - jak už tady padlo, je to i pohodlnější.
S portem stejně budu muset udělat malou šarádu, protože i 22 někde mají bloknutou. Myšlenka je na mikrotiku otevřít 443 a tu NATovat 1:1 do 22 na server. Na TCP/80 bude zbytečně velký provoz.
A na Mikrotiku jsou samozřejmě servisní porty i služby bloknuté kromě SSH jen z místní sítě.

[Reklama]

[k3dAR]

[...] Ze začátku jsem se jakoby snažil mít zakazanyho roota a řešit všechno přes sudo, ale to je strašná ztráta času.

no to je strasna ztrata casu :-D

Kód: [Vybrat]

ssh user@server -t 'sudo -i'

[...] Klíče doporučuji použít různé pro každého klienta – když vám někdo ukradne tablet, pohodlně se na server přihlásíte z desktopu a tabletový klíč deaktivujete a nemusíte hned řešit jeho výměnu i na desktopu. [...]

nebo stejnej klic s passphrase,  na tabletu (predpokladam Android) pouzivat ConnectBot v kterem pred pripojenim odemkne klic a po zavreni ConnectBoot je passhrase zapomenuta...

[Jose D]

Ze začátku jsem se jakoby snažil mít zakazanyho roota a řešit všechno přes sudo, ale to je strašná ztráta času.

zákaz přímého přihlášení roota má spíš význam v auditovatelnosti, tj. víš který konkrétní sysop co kdy udělal, a taky se lépe řeší oprávněných různých opů.

nebo stejnej klic s passphrase

nn, tady opravdu souhlas s kolegou, privátní klíč by mezi zařízeními vůbec neměl cestovat.

protože i 22 někde mají bloknutou.

Z takovýchto divných sítí bych se ven dostával spíš VPNkou a server bych nechal standardní.. Ale záleží na vkusu, bezpečnost to neovlivní.

[FKoudelka]

Je ještě moderní port knocking ?

[Jose D]

Je ještě moderní port knocking ?

https://cs.wikipedia.org/wiki/Security_through_obscurity

Nenapadá mě rozumný použití.

[Filip Jirsák]

nebo stejnej klic s passphrase,  na tabletu (predpokladam Android) pouzivat ConnectBot v kterem pred pripojenim odemkne klic a po zavreni ConnectBoot je passhrase zapomenuta...

Nikoli. Louskání hesla ke klíči může útočník dělat off-line, tedy může zkoušet hesla jak rychle chce a na jakém množství zařízení chce (resp. zaplatí). Heslo ke klíči tedy neslouží jako absolutní zabezpečení (typu „když mi ten tablet ukradnou, klidně ten klíč budu používat ještě za dva roky“), ale jenom vám dává čas příslušný klíč zablokovat. Rozumné heslo vám samozřejmě neposkytne pár sekund nebo minut, mělo by i odhodlaného útočníka zbrzdit minimálně na měsíce – bavíme se o bezpečnosti, takže je potřeba mít rezervu v řádech. I tak je lepší používat na každém klientovi jiný klíč, protože až k té ztrátě zařízení s klíčem dojde, nemusíte ve stresu všude vyměňovat klíče, ale prostě ten jeden klíč zablokujete (což samozřejmě předpokládá, že ty klíče máte pořádně označené a na serveru ten klíč snadno najdete). Postupy pro krizové situace by měly být co nejjednodušší – když vám někde ukradnou tablet, určitě budete řešit spoustu jiných věcí, než abyste se zabavoval generováním nových klíčů.

Ze začátku jsem se jakoby snažil mít zakazanyho roota a řešit všechno přes sudo, ale to je strašná ztráta času.

Chápu, že se někde sudo používá pro potřeby auditu kdo co dělal, i když mi to připadá trochu zvláštní postup. Ale pokud je někde sudo nakonfigurované tak, že se dá spustit shell pod rootem, a má to sloužit k většímu zabezpečení, je to podle mne kontraproduktivní. Víc bych se bál chybné konfigurace sudo nebo chyby v sudo než toho, že někdo něco omylem spustí pod rootem a tím napáchá škody. sudo bych dál používal k tomu, k čemu bylo původně určeno – tedy ke spuštění vybraných aplikací s vyššími oprávněními. Pokud to daná aplikace ještě vyžaduje a nedá se to řešit např. přes capabilities.

[k3dAR]

nebo stejnej klic s passphrase,  na tabletu (predpokladam Android) pouzivat ConnectBot v kterem pred pripojenim odemkne klic a po zavreni ConnectBoot je passhrase zapomenuta...

Nikoli. Louskání hesla ke klíči může útočník dělat off-line, tedy může zkoušet hesla jak rychle chce a na jakém množství zařízení chce (resp. zaplatí).

to je teorie, v praxi, kdyz pouzijes 20mistne passhrase s kombinaci male/velka pismena, cisla a specialni znaky, tak si zpocitej kolik milionu superpocitacu bys potreboval na rozlousknuti v radu let ;-)

[Filip Jirsák]

to je teorie, v praxi, kdyz pouzijes 20mistne passhrase s kombinaci male/velka pismena, cisla a specialni znaky, tak si zpocitej kolik milionu superpocitacu bys potreboval na rozlousknuti v radu let ;-)

Já bych takové heslo v praxi na tabletu zadávat nechtěl. Nehledě na to, že bych příslušný klíč stejně v případě ztráty tabletu zablokoval, protože nechci myslet na to, že pokud by se třeba za půl roku našla díra ve způsobu, jak se s tím heslem nakládá, budu muset klíče vyměnit. Navíc nějak nevidím důvod, proč bych se měl bránit použití více klíčů – znamená to přidat jeden řádek do souboru s povolenými klíči.

[k3dAR]

Já bych takové heslo v praxi na tabletu zadávat nechtěl. Nehledě na to, že bych příslušný klíč stejně v případě ztráty tabletu zablokoval, protože nechci myslet na to, že pokud by se třeba za půl roku našla díra ve způsobu, jak se s tím heslem nakládá, budu muset klíče vyměnit. Navíc nějak nevidím důvod, proč bych se měl bránit použití více klíčů – znamená to přidat jeden řádek do souboru s povolenými klíči.

ja s takovym "heslem" zadavanem na telefonu problem nemam...
nerozporoval sem vyhodnost oddelenych klicu pro zarizeni, pouze zminil druhou moznost mit klic stejnej ale zabezpecenej passphrase (a ano logicky, silnou)...
puvodne si psal ze pri ztrate tabletu clovek nemusi rychle resit vymeny klicu, ted pises (kdyz sem upozornil na moznost silne passphrase ktere potrebuje miliony superpocitacu k rozlousknuti v radu let) ze za pul roku muze byt nalezena dira...
jinak "tve" reseni ma take mouchu, kdyz mi ukradnou tablet a nebudu mit u sebe NB, nebo nekoho na telefonu, tak nemuzu na serveru zrusit ten ukradenej klic a s tvojim snadnym heslem mi ho nekdo rozlouskne driv nez se k NB dostanu ;-)

[Filip Jirsák]

nerozporoval sem vyhodnost oddelenych klicu pro zarizeni, pouze zminil druhou moznost mit klic stejnej ale zabezpecenej passphrase (a ano logicky, silnou)...

Možnost to je. Ale má ta možnost nějaké výhody?

puvodne si psal ze pri ztrate tabletu clovek nemusi rychle resit vymeny klicu, ted pises (kdyz sem upozornil na moznost silne passphrase ktere potrebuje miliony superpocitacu k rozlousknuti v radu let) ze za pul roku muze byt nalezena dira...
jinak "tve" reseni ma take mouchu, kdyz mi ukradnou tablet a nebudu mit u sebe NB, nebo nekoho na telefonu, tak nemuzu na serveru zrusit ten ukradenej klic a s tvojim snadnym heslem mi ho nekdo rozlouskne driv nez se k NB dostanu

Asi jste můj příspěvek nečetl úplně pozorně. Psal jsem o tom, že heslo by mělo být takové, aby ho útočník reálně zkoušel několik let. Počítám samozřejmě s nějakou rezervou, výkon se neustále zvyšuje, odhodlaný útočník si může pronajmout nějaký botnet s grafickými kartami nebo si to zaplatí v cloudu, takže počítám s teoretickou odolností toho hesla v řádu měsíců. Pokud se nenajde žádná chyba v implementaci. Takže mám několik měsíců na to dostat se k tomu notebooku – to mi připadá jako dostatečný čas. Ale zase pokud by k té ztrátě/krádeži skutečně došlo, nebudu tu rezervu několika měsíců využívat do poslední minuty (navíc se pohybuju v řádech, takže nedává smysl „řádově měsíce“ převádět na minuty), ale budu se snažit ten klíč (a třeba spárování s Google účtem a další) řešit bez zbytečného odkladu, v řádu hodin nebo maximálně jednotek dní. Tím opět získávám smysluplnou bezpečnostní rezervu.

Podstatné je to, že ochranu heslem (sebesilnějším), na kterou může útočník útočit off-line, nechápu jako absolutní ochranu „navždy“, je to časově omezená ochrana. A na takovou ochranu mám nějaké minimální požadavky, ale pokud je splní, už mne nezajímá, že za současné situace je ta ochrana  přemrštěná a teoreticky bych se tedy na ní mohl dívat jako na neomezenou. Prostě je omezená a v případě úniku ten klíč zneplatním. Stejně jako bych zneplatnil certifikát k privátnímu klíči uloženému na čipové kartě, kdybych tu kartu ztratil – bez ohledu na to, že přístup k privátnímu klíči je chráněn PINem a po třech neúspěšných pokusech se přístup zablokuje. Jde o to, že pokud chcete něco mít bezpečné, musíte mezi tím, co je teoreticky bezpečné, a tím, co reálně používáte, mít odstup v dostatečných řádech, ne v jednotkách. Protože až příliš často dochází k tomu, že se někomu podaří prolomit přes několik řádů.

[Jose D]

nerozporoval sem vyhodnost oddelenych klicu pro zarizeni, pouze zminil druhou moznost mit klic stejnej ale zabezpecenej passphrase (a ano logicky, silnou)...

to není druhá možnost, to je prostě špatně.

:-D

;-)

;-)

S ohledem na frekvenci mrkacích smajlíků ve tvých postech je ještě možný, že tvé bezpečnostní metody byly myšleny jako sarkasmus. Ale nejsem si 100% jistý