SSH-zabezpečení a konfigurace, přihlášení veřejným klíčem.

27.9.2009 14:50 | Přečteno: 7095× | poslední úprava: 27.9.2009 20:12

Konfigurace SSH (/etc/ssh/sshd_config)

Nastavíme port na 2222 directivou: Port 2222. Číslo si samozřejmě může vybrat každý sám. To proto, že útočník se zkouší dostat na port 22 na kterém SSH defaultně běží. Tím, že nastavíme jiný port mu situaci ztížíme.
Vypneme autentizaci pomocí hesla directivou: PasswordAuthentication no
Zamezíme přihlašování jako root directivou: PermitRootLogin no
Pokud chceme pracovat jako root tak se nejprve přihlásíme pod naším uživatelským jménem a pak se pomocí su přihlásíme na roota. Je to zase proto, že když už by se útočníkovi povedlo dostat na náš server tak nebude mít root práva. Bude mít práva uživatele...
Vypneme přihlašování bez hesla directivou: PermitEmptyPasswords no
Povolíme autentizaci veřejným klíčem directivami: PubkeyAuthentication yes; AuthorizedKeysFile %h/.ssh/authorized_keys2

Vytvoření a umístění klíčů
Vygenerujeme pár klíčů příkazem ssh-keygen -b délka -t typ. Příklad: ssh-keygen -b 2048 -t rsa. Při generování se nás program zeptá na passphrase. Ta by měla vypadat jako těžko prolomitelné heslo (malá, velká písmena, čísla, nealfanumerické znaky)
klíč bude uložen v $HOME/.ssh/id_rsa, resp. $HOME/.ssh/id_rsa.pub. id_rsa je privátní klíč který střežíme jako oko v hlavě nesmí se dostat do cizích rukou. Pokud by se tak stalo tak by se potenciální útočník snažil uhodnout passphrase. V případě, že by se mu to povedlo tak by měl přístup na náš server. Nakopírujeme veřejný klíč do souboru authorized_keys2 a to proto abychom se mohli pomoci jeho připojovat k serveru. cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys2

Vytvoření klíče pro putty
Nainstalujeme putty tools a zkonvertujeme vygenerovaný privátní klíč (syntaxe je: puttygen /path/to/ssh-gen-privatekeyfile -O private -o /path/to/putty-formatted-privatekeyfile). Tím dosáhneme toho že se pomocí tohoto klíče budeme moct přihlašovat i přes putty z windows.
sudo aptitude install putty-tools
puttygen $HOME/.ssh/id_rsa -O private -o $HOME/.ssh/putty_private.ppk
V našem případě je putty_private.ppk privátní klíč se kterým bude putty pracovat.

Přihlašování z Linuxu a z Windows
Ve Windows spustíme putty a ve sloupci nalevo najedeme na connection->ssh->auth. Klikneme na browse a vybereme cestu k privátnímu klíči (v našem případě putty_private.ppk). Pak se můžeme připojit...
Pokud se přihlašujeme z Linuxu pak je syntaxe následující: ssh -p 2222 uzivatel@IP_adresa -i /cesta/k/souboru/s/privatnim/klicem. Argument -i se zadává pouze v případě, že jsme na stroji na kterém není $HOME/.ssh/id_rsa (privátní klíč) a cestu je nutné zadat ručně. Např. když budete u cizího stoje a klíč budete mít třeba na flashce.

DenyHost
Instalujeme ho pomocí aptitude(Debian atd.) nebo Yum (Fedora atd.)Tento daemon slouží k ochraně SSH serveru před útočníky. Pokud se někdo snaží opakovaně připojit tak je zapsán na „černou listinu“ do souboru hosts.deny. DenyHost také využívá databázi s IP útočníků a díky tomu je rozezná ještě před tím než se budou snažit opakovaně uhodnout vaše heslo. Nastavení konfiguračního souboru /etc/denyhosts.conf je na této adrese http://aboutme.ic.cz/?q=node/133. Domovská stránka je pak zde http://denyhosts.sourceforge.net/.

Pokud by bylo něco nesrozumitelné tak napište a já se to pokusím opravit. Tento článek je vlastně takový souhrn mých poznatků ohledně konfigurace SSH. Není v něm zmíněn např. TCP Wrapper, ale to jen z toho důvodu, že ho nepoužívám. Přikládám tedy odkaz kde je popis jeho použití. Sice je to s něčím jiným než SSH, ale je to analogický případ.http://deja-vix.sk/sysadmin/tcp_wrappers.html#top        

Komentáře

[houska]

To proto, že útočník se zkouší dostat na port 22 na kterém SSH defaultně běží. Tím, že nastavíme jiný port mu situaci ztížíme

Tim udelame leda tak to, ze se nam nebudou tolik plnit logy pokusy o prihlaseni. Rozhodne to bezpecnost nezvysi!

RSAAuthentication yes;

manual rika: This option applies to protocol version 1 only.
jestli si dobre pamatuju tak protokol 1 se silne nedoporucuje

neco malo dsa vs. rsa

[polo23]

RSAAuthentication yes tak s timhle se omlouvam ... mel jsem starsi zdroj informaci. Ted jsme si to vygooglil a mate pravdu. Jinak co se tyka toho portu tak jsem jineho nazoru. Podle me se bezpecnost zvysi alespon nepatrne pac nekteri roboti vyhledavaji jen port 22. Podle me kazdy robot neni nastaven tak aby prohledal vsech 65536 portu. Myslim ze s tim byste mohl souhlasit. Tu zmenu portu jsem bral jako zakladni vec. A co se tyka toho clanku s RSA vs DSA...myslim ze je na kazdem kam se prikloni. Nikdo ale nemuze rict ze RSA 2048bit je slaby nebo ze se da v realnem case na realnem stroji prolomit.

[Mrkva]

Podle me se bezpecnost zvysi alespon nepatrne pac nekteri roboti vyhledavaji jen port 22.

Bezpečný systém je ten, na který nejdou uhádnout hesla bruteforcem, nějaký port nehraje roli.

[pht]

Ah, slavná debata o portu. Tak čo třeba: port roli hraje, a bezpečný systém neexistuje?

[Ondřej Kubečka]

Bezpečný systém existuje, není připojen k síti a pokud možno je v sejfu tak, aby se k němu nedalo dostat ani fyzicky.

Jo, a port fakt nerozhoduje. Když už někdo bude chtít škodit, tak se sotva zarazí na takové prkotině, že se nejdříve musí rozhlédnout, co kde poslouchá. Krom toho, pokud tam běží služeb více, tak si asi stejně asi vybere něco děravější než ssh.

[pht]

Bezpečný systém existuje, není připojen k síti a pokud možno je v sejfu tak, aby se k němu nedalo dostat ani fyzicky.

Pokud se k němu dá nějak dostat, tak není (absolutně) bezbečný, pokud se k němu nedá dostat, tak není užitečný.

Když ... sotva ... pokud ... asi

To jsou nějaké Vaše předpoklady. Ověřte si, zda sedí s realitou.

[Ondřej Kubečka]

Ale užitečnost nebyla zmíněna jak podmínka. Takže bezpečný systém existovat může, ale. ;)

Ano, předpokládám, že je to podobné jako s autem, když budou chtít, tak mi ho ukradnou, alarm, zamykání zpátečky, pískování oken (a to jsou dle mého oproti přečíslování portů reálné způsoby relativního zvýšení bezpečnosti)... stranou.

Ale pokud realita říká něco jiného, mohu uznat svůj mylný předpoklad. Nějaké odkazy a/nebo zkušenosti byste tam pro mě neměl, kfyž už o mluvíte o realitě? Takhle ve vzduvhu samo o sobě to s prominutím vypadá jako Váš názor nebo předpoklad. ;)

[pht]

Ale užitečnost nebyla zmíněna jak podmínka.

Bez toho by to nebyla taková sranda. Jak se říká, není problém systém izolovat, problém je zaručit správnou výměnu informací.

Ale pokud realita říká něco jiného, mohu uznat svůj mylný předpoklad.

Za prvé, jak jsem se zmínil již v nějakém vlákně níže...

Krom toho, pokud tam běží služeb více, tak si asi stejně asi vybere něco děravější než ssh.

...tohle není úplně palčivý problém. Naopak, většinu času byste měl předpokládat, že už se tam dostali... pokud ale budete mít pevnou půdu pod nohama, můžete s tím něco dělat. Co skutečně musíte chránit, je způsob, jak se na systém dostat s neomezenými právy.

Když už někdo bude chtít škodit, tak se sotva zarazí na takové prkotině, že se nejdříve musí rozhlédnout, co kde poslouchá.

Podceňujete tupou sílu botnetů a naopak přeceňujete jejich schopnosti, podívejte se například na odkaz v tomto příspěvku (případně i na ty příspěvky, tenkrát jsem se nějak rozepsal)...

[Filip Jirsák]

Naopak, většinu času byste měl předpokládat, že už se tam dostali.

Je mnohem snazší zabezpečit počítač před útokem po síti, než před útokem lokálního uživatele. Takže pokud na počítači nemusí mít možnost spouštět svoje procesy nikdo cizí, je daleko lepší chránit počítač před útokem po síti, a o lokální zabezpečení se pak už starat nemusíte.

[Mrkva]

Jojo, jenže pak někdo najde nějakou chybu :)

[Ondřej Kubečka]

je daleko lepší chránit počítač před útokem po síti, a o lokální zabezpečení se pak už starat nemusíte.

Jinak bych s Vámi v ostatním vesměs i souhlasil, ale tohle je vyloženě školácká chyba. ;)

[Filip Jirsák]

Proč by to byla školácká chyba? Když budu věnovat stejnou energii, kterou bych věnoval zabezpečení proti útoku zevnitř, zabezpečení proti útokům po síti, dosáhnu daleko lepšího zabezpečení - protože zabezpečit počítač proti síťovým útokům je snazší. Samozřejmě si musím být jist, že se nikdo žádným způsobem do počítače nedostane. Což v případě, že má na serveru účet jenom správce a neběží tam žádné aplikace, které by umožnily třeba přes PHP spouštět externí příkazy, jde zajistit celkem snadno.

Nemusíte se starat o lokální zabezpečení nemělo znamenat, že když nemá nikdo jiný na počítač přístup přes SSH, nemusím se pak vůbec o nic na počítači starat a můžu si na server nainstalovat libovolně děravou PHP aplikaci. To samozřejmě ne. To bych pořád bral jako síťový útok. Myslel jsem tím to, že se pak nemusím starat o všechny lokálně zneužitelné díry v jádře apod. Samozřejmě musím vždy posoudit, zda není zneužitelná v mém systému, ale je dost velká pravděpodobnost, že nebude. Když dovolím někomu jinému vzdálené přihlášení a možnost spouštět libovolný kód na serveru, týká se mne jakákoli lokálně zneužitelná chyba.

[Ondřej Kubečka]

Bez toho by to nebyla taková sranda. Jak se říká, není problém systém izolovat, problém je zaručit správnou výměnu informací.

Výměna informací? Ta bude vždy na úkor bezpečnosti. Já jsem pouze narážel na to, že bezpečný systém možný je, ale má to svou cenu. ;)

Za prvé, jak jsem se zmínil již v nějakém vlákně níže...

Přiznám se, že jsem to prošel letem světem a viděl tam něco o množství informací v logu. No to je poněkud slabé. Jestli si logy budu přebírat pokud možno automatizovaně z různých portů nebo z jednoho podle obsahu se nezdá býti až tak zásadní. Navíc si dovedu představit celou řadu lidí, kteří si řeknou: zvýšil jsem zabezpečení přesunutím výchozího portu, mohu klidně spát... a je v lozích ani nebudou řešit (a napáchali jsme více škody, než užitku).

Co skutečně musíte chránit, je způsob, jak se na systém dostat s neomezenými právy.

Lokální neprivilegovaný uživatel je dost škody sám o sobě a řekl bych tak 80% cesty k uid 0 již uražených. Mnozí lidi si ještě dají tu práci řešit zabezpečení zvenku a s pocitem falešného bezpečí se vybodnou na vnitřek (vč. nastavení síťování ostatních systémů uvnitř bez přímého přístupu ven).

Podceňujete tupou sílu botnetů

Asi ano. Zde mohu být falešným pocitem bezpečí ukolébáván já, ale měl jsem dojem, že dostatečně dlouhý klíč (hlášení heslem je samozřejmě vypnuté) dá tomu botnetu na hrubou sílu dost práce (a než uspěje, tak si toho třeba někdo všimne).

a naopak přeceňujete jejich schopnosti

Právě že nikoliv. Nečekám, že budou louskat klíče. Takže jedinou zatím popsanou výhodu vidím v tom obsahu logů, ale to je možná pohodlné, ale jako přínos pro bezpečnost diskutabilní.

podívejte se například na odkaz

Dík, odkazy vítány. Ale taky je tam pouze vyjádřeno přesvědčení autorů.

Prostě jak to říci jinak. Přesouvání portů nic neřeší. Ukažte mi nějaký Váš systém se "zabezpečením" pomocí přesunutí SSH portu kamkoliv jinam a dejte mi svolení si jej "ojet" a já Vám za chvíli řeknu, kde Vám tam SSH poslouchá a to nejsem žádný lamač, ale bývalý admin (už to několik let nedělám), který si nikdy do systémy neodbýval s úmysly zlými ani dobrými. Pokud by Vás někdo chtěl snažit kompromitovat, tak už pak jen svému botnetu řekne, tomuhle týpkovi se hlaš na tenhle port a hrubá síla vesele zkouší.

Náhodně generovaný port, který si dočasně vygenerujete na základě nějaké akce a pošlete třeba textovkou. Nebo port knocking... To bych jako další úroveň zabezpečení klidně označil, ale samotné přesouvání portu SSH nikoliv a spíše je to "opruz" pro mě (sítě s omezením na odchozí komunikaci, jak tu někdo zmiňoval; buď řešit .ssh/config nebo si komplikovat syntaxi pro věci jako rsync...). Asi něco jako "ochrana" proti kopírování a různé DRM úlety: legitimního uživatele naštve, piráta nezastaví (ještě že už se hudba vrací na CDDA).

A ještě taková douška. Když jsem adminoval, sám jsem poslouchal na portu jiném než 22, ale z praktických důvodů. FW měl SSH jen z jednoho stroje uvnitř právě na port 22. Zvenku byl zcela jiný port přesměrovaný na port 22 na nějaký stroj uvnitř, který sloužil ke vstupu. Prostě káži vodu a piji víno. ;)

[pht]

zvýšil jsem zabezpečení přesunutím výchozího portu, mohu klidně spát... a napáchali jsme více škody, než užitku

Aneb sirky nepatří do rukou dětem a blbcům...

Lokální neprivilegovaný uživatel je dost škody sám o sobě a řekl bych tak 80% cesty k uid 0 již uražených.

To záleží na tom kolik těch privilegií má. Obvykle budou nejdřív ojíždět různé webové aplikace, kde třeba dostanou úroveň správce nebo získají informace o zákaznících, ale už se nedostanou tak daleko, aby mohli vykonávat libovolné pžíkazy v shellu. Znamená to pak různé stupně znepokojení pro Vás jako správce a pro majitele těch dat, ale každopádně ten r00t-expl0it-centrizmus z 90. let je už trochu za náma. Pokud stále uvažujete tímto směrem, tak se podívejte do kalendáře a pak na nějaké statistiky o útocích na netu...

a než uspěje, tak si toho třeba někdo všimne

A třeba taky ne, když mám každý den v logu tisíc neúspěšných přihlášení jako přes kopírák.

Zde mohu být falešným pocitem bezpečí ukolébáván já, ale měl jsem dojem, že dostatečně dlouhý klíč (hlášení heslem je samozřejmě vypnuté)

A nejste třeba taky ukolíbán pocitem, že zabezpečení přes klíče je To Nejlepší Zabezpečení (tm)?

Přesouvání portů nic neřeší. Ukažte mi nějaký Váš systém se "zabezpečením" pomocí přesunutí SSH portu kamkoliv jinam a dejte mi svolení si jej "ojet" a dadadadada lalalalala rozbitej gramofon co už jsme slyšeli 10x

Ale řeší! Je to nádherný a jednoduchý způsob jak se zbavit botnetů, který Vám jdou po sshd na portu 22 (což je momentálně 100% botnetů). Nebudou Vám louskat perníček, nebudou Vám zatěžovat výpočetní prostředky, budete mít krásně čisté logy, pokud někdy jen jednou uděláte nějakou botu v nastavení, nebo se objeví další geniální patch pro openssl, tak to může být poslední, byť slabá obrana, a může rozhodnout, jesli budete pwned do hodiny nebo mít dost času si to opatchovat. A pokud někdy v budoucnu začnou roboti dělat Masivní Portscan (tm) tak na tom nebudete o nic hůř než dnes s sshd na portu 22.

Je to akorát další přežitek: tváří v tvář jednoduchému a efektivnímu opatření si začít vymýšlet sofistikované útočníky, říkat že je to neefektivní protože VY byste to prorazil, případně zavádět desetkrát složitější výmysly typu auto blokátor, port knock, které přinášejí desetinásobné riziko, že něco rozbijete. Je mi úplně jedno, jestli to nějaký franta hacker obejde do tří nebo pěti minut, tohle opatření tam není pro něj, ale pro těch sto tisíc ostatních, kteří se snaží dnes a denně. Přesunutí portu JE bezpečnostní opatření a má svoje místo ocaď |---| pocaď, a já jsem nikdy neřekl nic víc a nic míň. Pokud někdo má problémy kvůli dostupnosti služby, nebo s nastavením konfiguráku, nebo je jen líný, tak to pochopím, ale říkat že "to je k ničemu protože chytrý útočník blabla" je ignorance nejvyššího ražení.

Ale taky je tam pouze vyjádřeno přesvědčení autorů.

Jakýkoli text je stěží něco lepšího než přesvědčení autora A vyjádřením svého přesvědčení výše uzavírám debatu o sshd portu.

[Filip Jirsák]

Ale řeší! Je to nádherný a jednoduchý způsob jak se zbavit botnetů, který Vám jdou po sshd na portu 22 (což je momentálně 100% botnetů).

Já jsem se těchhle botnetů zbavil už pouhým zákazem přihlašování heslem, což bych udělal stejně. Pořád nevím, k čemu je dobré zbavovat se jich ještě jednou, když už jsem se jich zbavil. Botnety přesunem portu neutečou dál, nebudou se mého serveru bát víc, nic takového. Přesouváním portu pořád jen odrážíte útok, který už byl odražen.

[Ondřej Kubečka]

zvýšil jsem zabezpečení přesunutím výchozího portu, mohu klidně spát... a napáchali jsme více škody, než užitku

Aneb sirky nepatří do rukou dětem a blbcům...

Tak nějak. Takže ať si každý nastaví SSH podle svého přesvědčení, ale když píšu (jinak povedený) návod pro nejširší veřejnost, tak bych neměl jen tak mezi řečí říkat, že si zabezpečím počítač přesunutím portu.

Pokud stále uvažujete tímto směrem, tak se podívejte do kalendáře a pak na nějaké statistiky o útocích na netu...

Ale ne, jako jehož data byla zcizena z databáze pojištovny (a neřeknou to, dokud se nezovete, to mě naštvalo ještě více) a zatím úplně nevím, co s tím dělat.

Ale to je zcela mimo debatu o přesouvání portů. Možná jsem fakt 100 let za opicema, ale nějak si nedovedu úplně představit, co jiného než přístup (ať už za jakýmkoliv účelem) nebo DoS by kdo kutil útokem na SSH.

Jinými slovy máte pravdu, ale v kontextu přesouvání portů je to irelevantní. ;)

A třeba taky ne, když mám každý den v logu tisíc neúspěšných přihlášení jako přes kopírák.

Pardon, ale umět si naparsovat logy tak, aby mi něco řekly snad patří k zákaldním dovednostem a úkolům admina... nebo se za těch pár let, co to nedělám tolik změnilo?

A nejste třeba taky ukolíbán pocitem, že zabezpečení přes klíče je To Nejlepší Zabezpečení (tm)?

Možná. Naštěstí už neadminuji, takže pokud nemám zcela aktuální informace o stavu, tak to ničemu tolik nevadí. Takže otevřeně přiznávám, že jsem se domníval, že při současných technických možnostech je útok (hrubou silou nebo jinak) na přiměřeně dlouhé klíče nepoměrně problematičtější, než najít si port, kde poslouchá SSH (nebo nějaká jiná pro útok příhodnější služba).

Ale řeší! ...

Co na to říci jiného než, že víra je lidského ducha důstojná. Já Vám to neberu pro Vaše osobní přesvědčení. Ostatně jak si nastavíte své systémy je jenom a jenom Vaše věc a zodpovědnost. Já se jen trochu bojím tvrzení, pro zvýšení bezpečnosti přesuneme port.

Jakýkoli text je stěží něco lepšího než přesvědčení autora

To ano, ale pokud autor chce, aby případně ten názor pak sdíleli i jiný, tak je třeba futrovat daty.

A vyjádřením svého přesvědčení výše uzavírám debatu o sshd portu.

To je rozumné. Dalším krokem by byla náboženská válka. ;) A to za to nestojí.

[pht]

když píšu (jinak povedený) návod pro nejširší veřejnost, tak bych neměl jen tak mezi řečí říkat, že si zabezpečím počítač přesunutím portu.

To záleží co si představujete Vy a veřejnost pod pojmem zabezpečím ... pokud chcete být "politicky korektní" tak to neříkejte, ale na druhou stranu ze stejných důvodů ani neříkejte opak.

Ale ne, jako jehož data byla zcizena z databáze pojištovny (a neřeknou to, dokud se nezovete, to mě naštvalo ještě více) a zatím úplně nevím, co s tím dělat.

Řekl bych že i u nás z toho plynou nějaké zajímavé právní důsledky pro pojišťovnu. Dále to bude na Vaší milosti a/nebo houževnatosti.

Jinými slovy máte pravdu, ale v kontextu přesouvání portů je to irelevantní. ;)

Připomínám že tuhle sekci jsem psal v kontextu Vašeho tvrzení, že útočník si asi najde jinou, děravější službu.

Pardon, ale umět si naparsovat logy tak, aby mi něco řekly snad patří k zákaldním dovednostem a úkolům admina... nebo se za těch pár let, co to nedělám tolik změnilo?

Nejsem si jist, jestli jste pochopil, o čem mluvím. Parsování logů Vaši situaci nezmění. Musíte najít způsob, jak mezi tisíci stejnými hláškami najít jednu, která Vás možná zajímá víc, nebo spolehlivě říct, že tam taková není.

Jinými slovy pokud Váš operátor (ten kdo čte logy) bude čelit záplavě hlášek vyvolanou boty, tak ji za chvíli začne ignorovat, což se rovná situaci nelogovat vůbec.

Takže otevřeně přiznávám, že jsem se domníval, že při současných technických možnostech je útok (hrubou silou nebo jinak) na přiměřeně dlouhé klíče nepoměrně problematičtější, než najít si port, kde poslouchá SSH (nebo nějaká jiná pro útok příhodnější služba).

To máte pravdu ale v kontextu debaty je to irelevantní (což je parafráze, ale myšlená vážně).

[Filip Jirsák]

To záleží co si představujete Vy a veřejnost pod pojmem zabezpečím ... pokud chcete být "politicky korektní" tak to neříkejte, ale na druhou stranu ze stejných důvodů ani neříkejte opak.

Ale ať se to do návodu klidně uvede, ale s porovnáním účinnosti - třeba že na škále od 1 do 100 má přihlášení klíčem hodnotu 80 a přesun na jiný port hodnotu 0,01.

Nejsem si jist, jestli jste pochopil, o čem mluvím. Parsování logů Vaši situaci nezmění. Musíte najít způsob, jak mezi tisíci stejnými hláškami najít jednu, která Vás možná zajímá víc, nebo spolehlivě říct, že tam taková není.

Jinými slovy pokud Váš operátor (ten kdo čte logy) bude čelit záplavě hlášek vyvolanou boty, tak ji za chvíli začne ignorovat, což se rovná situaci nelogovat vůbec.

To myslíte vážně? Přesunutím na jiný port útoky neustanou, jenom skončí v dřívější fázi (už při navazování spojení). Takže přesunem na jiný port se útoků nezbavíte, pouze je to dosti specifický způsob, jak se vyhnout logování těch útoků. Úplně stejný filtr, který na logy aplikujete takto, můžete aplikovat na logy i v případě, kdy sshd necháte na portu 22.

[Ondřej Kubečka]

Řekl bych že i u nás z toho plynou nějaké zajímavé právní důsledky pro pojišťovnu. Dále to bude na Vaší milosti a/nebo houževnatosti.

A čas, to je vždycky problém. Jinak jsem se díval do legislativy (tedy zejména zákon 101/2000 Sb. v aktuálním znění), a průšvih to samozřejmě je. Teď se jako další krok chystám obrátit na ÚOOÚ.

[pht]

Možná byste mohl své snažení zdokumentovat na blogu.

[miro]

Něco málo dsa vs. rsa zde. IMHO z toho vyplývá srovnatelná odolnost DSA a RSA, takže pro vyšší než osmdesátibitovou bezpečnost je v současnosti vhodnější RSA, anžto v ssh-keygen AFAIK ještě není implementován standard FIPS-186-3, takže DSA klíč o jiné délce než 1024 bitů zatím nelze (na rozdíl od RSA klíče) vytvořit.

[Dibur_X]

hmm, nevim jestli jsem četl spravně, ale mě z toho vyplivá, DSA je asymetrická a tedy po rozvoji kvantovych pc vezme uplně za své. A rsa vydrží i pak i když bude mít jen poloviční bezpečnost v tom jejich vyjadřování... chapu to spravně z toho článku?

[Filip Jirsák]

To je pokus vyvolat flamewar? Pravda je, že na tohle téma už tu dlouho nebyl…

Nastavíme port na 2222 directivou: Port 2222. Číslo si samozřejmě může vybrat každý sám. To proto, že útočník se zkouší dostat na port 22 na kterém SSH defaultně běží. Tím, že nastavíme jiný port mu situaci ztížíme.

Ztížíme mu to asi tak stejně, jako když si budeme pro server vybírat záměrně IP adresy, které mají v dekadickém zápisu 12 číslic, protože bude útočníkovi trvat dýl adresu napsat. Jinak řečeno, útočníkovi tím neztížíme prakticky nic a výsledek nestojí ani za to, abych si vzpomněl, jak se jmenuje konfigurační soubor sshd.

Vypneme autentizaci pomocí hesla directivou: PasswordAuthentication no

Ano, tohle jediné ze zmíněných věcí (spolu s přihlašováním klíčkem) bezpečnost skutečně zvýší.

Zamezíme přihlašování jako root directivou: PermitRootLogin no Pokud chceme pracovat jako root tak se nejprve přihlásíme pod naším uživatelským jménem a pak se pomocí su přihlásíme na roota. Je to zase proto, že když už by se útočníkovi povedlo dostat na náš server tak nebude mít root práva. Bude mít práva uživatele...

Opět, další opatření, které vypadá strašně účinně jenom proto, že otravuje právoplatného uživatele – bezpečnost ale nezvyšuje prakticky nijak. Pokud se útočníkovi podaří získat privátní klíč k serveru i s heslem, získá s ním nejspíš i heslo na roota. A i kdyby ne, stačí počkat si, až se příště přihlásíte.

[ja]

Pokud se útočníkovi podaří získat privátní klíč k serveru i s heslem, získá s ním nejspíš i heslo na roota. A i kdyby ne, stačí počkat si, až se příště přihlásíte.

Dovolim si silne nesuhlasit - ja napriklad mam na servery vsade kde ma pravo zapisovat nie-root uzivatel nastavene noexec, nodev, nosuid a samozrejme, ze na servery nemam ziadne gcc, ... Takze aj keby sa s nejakou bozou pomocou podarilo utocnikovi "znasilnit" moje prihlasovacie heslo na nie-root ucet tak dalej ma smolu. Podla mna maximalnu bezpecnost zabezpecuje prihlasovanie sa na server pomocou klucov z riadne doveryhodneho stroja, potom ak ina moznost nie je tak OTP, dalej uz spomenuty DenyHosts a vyssie popisane nastavenie na "disk" kde ma pravo nie-root zapisovat. Tym padom sa utocnik na server (samozrejme pri standartnej opatrnosti legalneho uzivatela) dostane na server maximalne tak pomocou nejakej bezpecnostnej diery co je ale tiez dost malo pravdepodobne ak sa admin o svoj server stara (napriklad standartne yum-cron, ...).

[Filip Jirsák]

Máte na tom serveru také pouze omezený shell a žádný Perl, Python ani jiný skriptovací jazyk? Nebo si po každém přihlášení kontrolujete, zda nemáte v shellu nastaven třeba alias na su na nějaký „vhodný“ skript? Zabezpečit počítač před lokálním uživatelem je úplně něco jiného, než zabezpečit jej před vzdáleným uživatelem – ostatně i v oznámeních o různých bezpečnostních chybách se můžete dočíst, že šlo naštěstí „jen“ o zranitelnost zneužitelnou lokálně. Takže pokud nepotřebujete povolit cizím uživatelům lokální přihlášení, je mnohem spolehlivější a jednodušší zabránit útočníkovi vůbec se na počítač dostat, ne jej tam nejprve pustit s uživatelskými právy a pak se pokoušet mu zabránit získat roota.

Navíc pokud útočník získá heslo k vašemu klíčku, může nejspíš úplně stejnou cestou a prakticky v tomtéž okamžiku získat o heslo na roota (prostě si z keyloggeru okopíruje heslo ke klíči i následné heslo na roota).

Přesouvání portu a DenyHosts jsou dobré tak akorát k tomu, aby se na server nedostal právoplatný správce, pokud se bude hlásit třeba přes nějakou pochybnou WiFi síť (z vlastního notebooku). Přihlašování na roota přes dalšího uživatele také nemá žádný význam – když útočník odposlechne heslo ke klíči, odposlechne i to na roota. Když by heslo ke klíči získal hrubou silou, řádově lépe pomůže o délku hesla roota prodloužit heslo ke klíči, než nechat útočníka hrubou silou rozlousknout ještě heslo roota.

[ja]

Máte na tom serveru také pouze omezený shell

Ano

a žádný Perl, Python ani jiný skriptovací jazyk?

Nie

Nebo si po každém přihlášení kontrolujete, zda nemáte v shellu nastaven třeba alias na su na nějaký „vhodný“ skript?

Nie je treba - vzhladom na to, ze vsetky subory vratane jeho domovskeho adresara v nie-root uzivatelovi cez ktoreho sa prihlasujem vlastni root - takze editacia .bashrc a podobne je nemozna.

je mnohem spolehlivější a jednodušší zabránit útočníkovi vůbec se na počítač dostat, ne jej tam nejprve pustit s uživatelskými právy a pak se pokoušet mu zabránit získat roota.

ale ved samozrejme, ze sa snazim o to, aby sa utocnik na stroj nedostal ani ako nie-root uzivatel len mam rad, ked mam viacnasobnu ochranu. Proste podla tvojej logiky uplne bohate staci mat perfektny robustny trezor - a podla mna by mal mat "pred sebou" aj pohybovy senzor, ochranku, zamknute dvere a kludne moze byt aj v uplne inych dverach ako by zlodej povodne ocakaval a v tych dverach kde by sa mal povodne nachadzat by mal byt iny trezor ktory je nastaveny ako pasca.

Rozumieme? Nie?

Přesouvání portu a DenyHosts jsou dobré tak akorát k tomu, aby se na server nedostal právoplatný správce, pokud se bude hlásit třeba přes nějakou pochybnou WiFi síť (z vlastního notebooku).

Spravca ktory sa pipojuje na server cez pochybnu wifi je uchyl - a spravca ktory nema v telefone zalozne GPRS, EDGE, UMTS, HDSPA, ... je taktiez uchyl

Přihlašování na roota přes dalšího uživatele také nemá žádný význam – když útočník odposlechne heslo ke klíči, odposlechne i to na roota.

A ja som bol do teraz (zrejme v mylnom domneni), ze SSH je sifrovane spojenie

Když by heslo ke klíči získal hrubou silou, řádově lépe pomůže o délku hesla roota prodloužit heslo ke klíči, než nechat útočníka hrubou silou rozlousknout ještě heslo roota.

Ja osobne na vsetky moje hesla pouzivam makepasswd --char=25 - staci to podla teba? A ano - kadzy uzivatel a aj kazdy root na kazdom servery ho ma ine a pametam si ich a snazim sa ich menit cca raz za 3 mesiace.

[Filip Jirsák]

Nie je treba - vzhladom na to, ze vsetky subory vratane jeho domovskeho adresara v nie-root uzivatelovi cez ktoreho sa prihlasujem vlastni root - takze editacia .bashrc a podobne je nemozna.

takže ten uživatel slouží jenom pro su root? Pak nechápu, k čemu je ten mezikrok dobrý.

ale ved samozrejme, ze sa snazim o to, aby sa utocnik na stroj nedostal ani ako nie-root uzivatel len mam rad, ked mam viacnasobnu ochranu. Proste podla tvojej logiky uplne bohate staci mat perfektny robustny trezor - a podla mna by mal mat "pred sebou" aj pohybovy senzor, ochranku, zamknute dvere a kludne moze byt aj v uplne inych dverach ako by zlodej povodne ocakaval a v tych dverach kde by sa mal povodne nachadzat by mal byt iny trezor ktory je nastaveny ako pasca.

V čem spočívá vícenásobnost té ochrany? Můžete mi dát nějaký příklad toho, kdy se podaří překonat první ochranu (přihlášení zaheslovaným klíčem), ale nepodaří se (se stejným úsilím) překonat tu druhou?

Spravca ktory sa pipojuje na server cez pochybnu wifi je uchyl

Proč? SSH spojení je šifrované.

spravca ktory nema v telefone zalozne GPRS, EDGE, UMTS, HDSPA, ... je taktiez uchyl

Jste si jist, že všichni tři čeští mobilní operátoři momentálně povolují odchozí spojení na libovolný port? A že tak budou dělat i v budoucnosti? Já bych na to rozhodně nespoléhal.

A ja som bol do teraz (zrejme v mylnom domneni), ze SSH je sifrovane spojenie

No vida, tak jste si toho všiml. A šifrované spojení zabrání získání hesla přímo z klávesnice (hw úprava, mikrofon, keylogger) jak?

Ja osobne na vsetky moje hesla pouzivam makepasswd --char=25 - staci to podla teba? A ano - kadzy uzivatel a aj kazdy root na kazdom servery ho ma ine a pametam si ich a snazim sa ich menit cca raz za 3 mesiace.

A víte o tom, že kdybyste místo 25 znaků použil 26, uděláte toho proti útoku hrubou silou víc, než přihlašováním na roota přes dalšího uživatele s 25znakovým heslem? A proti jiným útokům, než je útok hrubou silou, jsou obě varianty odolné také stejně.

[ja]

No - nemam chut sa tu hadat (diskutovat) a tak na zaver poviem len jedno - ty mas svoju predstavu o bezpecnosti a ja zasa tu svoju - teba staci bohovsky trezor a ja chcem okrem neho aj spustu dalsich blbosti - a nie - tie dalsie blbosti ma neotravuju - aj doma na bezpecnostnych dverach mam bohovsky bezpecnostny zamok - ale dal som si este druhy - pridavny - takze asi tak.

[Filip Jirsák]

Není potřeba se hádat, stačilo by napsat, jak ta přidaná „spousta dalších blbostí“ zlepšuje bezpečnost. Pokud nijak, klidně si je používejte dál, jenom bych tomu neříkal opatření na zvýšení bezpečnosti.

problém je právě v tom, že si lidé velice často neuvědomují, jak velký je rozdíl v různých způsobech zabezpečení. Takže pak naflákají jeden způsob zabezpečení přes druhý a mají pocit, že těch vrstev zabezpečení mají dost. Přitom ve skutečnosti tam mají jediné skutečné zabezpečení a zbytek jsou hračky. Ukolébá je ale pocit, že tam těch vrstev přece mají spoustu, a pak si nedávají pozor na to, aby to jediné skutečné zabezpečení opravdu udržovali bezpečné.

Kdo to myslí se zabezpečením opravdu vážně, nemůže vedle sebe napsat přihlašování zaheslovaným klíčem a přesun sshd na jiný port nebo zákaz přihlášení na roota, jakoby to byla stejná úroveň zabezpečení. Je to jako kdyby někdo tvrdil, že se o své peníze nebojí, protože je má uložené v bankovním trezoru, a v tom trezoru je navíc ještě schoval pod slamník.

[Jendа]

No, zatím jsem nikde nenašel jediný argument, který by ospravedlnil PermitRootLogin No.

[ja]

Ono vseobecne by ma zaujimalo, ze na co to tam ty blazni tvorcovia SSH davali tu moznost ak je to neospravedlnitelne :-/

[trekker.dk]

Tvůrci SSH to tam dali proto, že to uživatelé chtěli - to s ospravedlnitelností nemá co do činění.

[Jendа]

Jste si jist, že všichni tři čeští mobilní operátoři momentálně povolují odchozí spojení na libovolný port? A že tak budou dělat i v budoucnosti? Já bych na to rozhodně nespoléhal.

Nechci kecat, ale Twist Surf+, které mám, povoluje jenom 80 a 443 - takže přesun/přesměrování SSH portu alespoň na jednom přístroji (z něj už se protuneluju) je nutnost.

[pht]

potom ak ina moznost nie je tak OTP ... samozrejme pri standartnej opatrnosti legalneho uzivatela

Možností je hodně, ale věřit v opatrnost uživatelů je jedna z nejhorších možností.

[pht]

abych si vzpomněl, jak se jmenuje konfigurační soubor sshd

Pak byste měl jít od toho

[Filip Jirsák]

Proč? Já už mám přístup přes sshd zabezpečený, a to tak, že přesun sshd na jiný port bezpečnost nezvýší. Pokud bych chtěl bezpečnost ještě zvyšovat, nebudu sshd přesouvat na jiný port, ale zvolím něco, co bezpečnost skutečně zvýší.

To přesouvání sshd na jiný port je jako nalepit na dveře lísteček „dál nechoďte, prosím“. Pokud je to jediná ochrana, chtělo by to asi investovat do lepšího zabezpečení, a koupit aspoň obyčejný zámek. No a pokud už má někdo vstup ochráněn trezorovými dveřmi, nebude za ně asi dávat takovýhle lísteček. Zvláštní je, že v reálném světě to nikoho nenapadne, ale při zabezpečování počítače to kde kdo považuje za užitečné. Přitom zatím nikdo nebyl schopen říci, k čemu je to dobré. Proti jakému druhu útoku, který není pokryt jinou ochranou, je tedy účinná změna portu?

[pht]

Proč?

Poukazoval jsem na to, že nevíte, kde je konfigurák sshd.

Přitom zatím nikdo nebyl schopen říci, k čemu je to dobré.

Věřím, že už se o to pár lidí pokusilo, jak v této, tak v jiných diskusích. Takže chyba bude asi na Vašem přijímači.

[Filip Jirsák]

Věřím, že už se o to pár lidí pokusilo, jak v této, tak v jiných diskusích. Takže chyba bude asi na Vašem přijímači.

Musím vás zklamat, ale zatím se o to nikdo nikde nepokusil. Ostatně žádný rozumný důvod nejspíš neznáte ani vy, jinak byste jej napsal, že.

[pht]

Musím vás zklamat, ale zatím se o to nikdo nikde nepokusil.

To je asi proto, že pro Vás nejsou dostatečně "rozumné". Jenže Vaše definice "rozumného" stojí na nějakých předpokladech, které nemají s rozvahou o bezpečnosti moc společného. Jmenovitě:

No a pokud už má někdo vstup ochráněn trezorovými dveřmi, nebude za ně asi dávat takovýhle lísteček.

Předpokládáte, že přítomnost silnějšího zabezepčovacího mechanizmu automaticky zneplatňuje všechny slabší.

To je základní chyba při zabezpečování sítě nebo počítače – naopak musíte předpokládat toho nejschopnějšího útočníka.

Podobným způsobem předpokládáte, že útočník vždy vynaloží všechny dostupné prostředky, aby dosáhl cíle (který nedefinujete).

To máte štěstí, že jste zatím nenarazil na žádnou síť, kde by v podmínkách provozu bylo něco jako: povolené porty odchozí komunikace jsou udp/53, tcp/80, tcp/443 a tcp/22.

Kupujete použitelnost za bezpečnost, což je možná pro Váš případ nutné, ale nepředpokládejte, že potřeby každého jsou stejné, a tudíž že by třeba někdo nemohl posílit bezpečnost na úkor použitelnosti.

Zabezpečení se nedá dělat tak, že si řeknete: „No, on bude útočník hloupý, on vyzkouší jenom defaultní port a vyzkoušet jiný port jej nenapadne.“

Je mi líto, ale zabezpečení se nedá dělat tak, jak to tu stavíte Vy: bez nějaké aspoň trochu korektní úvahy o tom, co chci vlastně chránit, před kým to chci chránit, jaké mám omezení a možnosti. Co se stane, když selže jedna nebo druhá pojistka. A nedá se to už vůbec dělat tak, že jste se kdysi nějak rozhodl a od té doby si na tom stojíte.

[Filip Jirsák]

Předpokládáte, že přítomnost silnějšího zabezepčovacího mechanizmu automaticky zneplatňuje všechny slabší.

Ano, to předpokládám. Co se vám na tom předpokladu nezdá?

Podobným způsobem předpokládáte, že útočník vždy vynaloží všechny dostupné prostředky, aby dosáhl cíle (který nedefinujete).

Nepředpokládám. Ale vím, že když mám počítač zabezpečený proti silnějšímu útočníkovi, je automaticky zabezpečen i proti tomu slabšímu. Takže nemusím vymýšlet ještě nějaké extra zabezpečení proti těm slabším útočníkům, a můžu ten čas věnovat raději ještě lepšímu zabezpečení proti silnějším útočníkům.

Kupujete použitelnost za bezpečnost, což je možná pro Váš případ nutné, ale nepředpokládejte, že potřeby každého jsou stejné, a tudíž že by třeba někdo nemohl posílit bezpečnost na úkor použitelnosti.

Přesun sshd na jiný port posiluje bezpečnost jedině v případě, kdy adresu a heslo vystavíte někde na web. Jakmile nastavíte rootovi nějaké rozumné heslo, udělal jste pro bezpečnost nesrovnatelně víc, než stěhováním sshd na jiný port.

Co se stane, když selže jedna nebo druhá pojistka.

No právě. Tak si to konečně zkuste rozepsat. Co se stane, když útočník získá privátní klíč (selže tedy ochrana heslem/klíčem)? Proskenuje porty a k sshd se přihlásí. K čemu byla druhá pojistka? K ničemu. Co se stane, když útočník proskenuje porty (selže „pojistka“ přesunutí portu)? Útočník se zkusí přihlásit, zjistí, že to lze jedině klíčem a skončil. K čemu byla pojistka přesunutí portu? Opět k ničemu. Takže co se stane s celkovou bezpečností, když „pojistku“ s přesunem portu vynecháte? Vůbec nic, bezpečnost zůstane stejná, jako před tím. Takže k čemu ten přesun portu je?

Než budeme pokračovat, je potřeba si ujasnit jednu věc. K čemu je dobrá ochrana, která je namířena proti stejnému druhu útoku, jako jiná ochrana, ale je řádově slabší? Neodchytí tedy žádného útočníka, kterého by neodchytila i ta silnější ochrana a nijak se nepozná, zda je ta slabší ochrana nasazena, nebo není. K čemu je tedy dobrá?

[pht]

Ano, to předpokládám. Co se vám na tom předpokladu nezdá?

Silnější opatření zneplatňuje slabší, jen když se týká téhož. Např. při ochraně klíčem je klíč 1024b silnější opatření, než 512b, při přesunu portu je silnější opatření náhodný nebo měnící se port, popř. (po troše vyjasnění co je co) technika zvaná "port knocking". Ochrana klíčem a přesun portu ale nemají vůbec nic společného. I přesto však mezi tyto dvě věci stavíte relaci a předpokládáte, že (absolutní) síla jednoho může zneplatnit druhé. Stejným uvažováním bychom dospěli k závěru, že než mít ochranu klíčem o velikosti 4 (čtyři) bity, tak je lepší přesunout sshd na jiný port a ochranu klíčem zrušit?

Jakmile nastavíte rootovi nějaké rozumné heslo, udělal jste pro bezpečnost nesrovnatelně víc, než stěhováním sshd na jiný port.

Opět vycházíte z domněnky, že bezpečnost je jednodimenzionální veličina (nebo ještě lépe binární :) ... bohužel to tak není.

Co se stane, když

Co se stane když Vás někdo s pistolí v ruce poprosí o přihlášení, k čemu je pak dobrý privátní klíč? Na to řeknete něco ve stylu "blá, no ale". Jenže to přesně demonstruje moji pointu, počítáte jen s jedním profilem útoku a navíc jen na jedné úrovni a nejste ochoten přemýšlet níž nebo výš, ani doleva nebo doprava. Jak jsem říkal, začněte s formální úvahou o tom, co chráníte, proti komu, kolik na to máte prostředků Vy a kolik oni.

[Filip Jirsák]

Silnější opatření zneplatňuje slabší, jen když se týká téhož. … Ochrana klíčem a přesun portu ale nemají vůbec nic společného.

Samozřejmě, že jsou to opatření proti témuž – proti získání přihlašovacích údajů a přihlášení standardní cestou s jejich využitím.

Jak jsem říkal, začněte s formální úvahou o tom, co chráníte, proti komu, kolik na to máte prostředků Vy a kolik oni.

Já už jsem s tím začal. Mám sshd zabezpečené klíčem, útočník je robot, který se snaží uhádnout heslo. Je to zabezpečení klíčem dostatečné? Ano, je. Takže k čemu je přidávání „ochrany“ přesunem portu, kterou robot prolomí během pár vteřin? K ničemu.

Nebylo by lepší, kdybyste místo obecných úvah o profilech a úrovních útoků napsal jeden jediný příklad útoku, kdy ochrana klíčem stačit nebude, ale ochrana přesunutím na jiný port ano?

[pht]

Samozřejmě, že jsou to opatření proti témuž – proti získání přihlašovacích údajů a přihlášení standardní cestou s jejich využitím.

V tom případě je popisovaný útok bouchačkou také pouze "získání přihlašovacích údajů a přihlášení standardní cestou s jejich využitím", a nezdá se mi, že byste se proti takovému útočníkovi bránil. Ale měl byste počítat s co nejsilnějším útočníkem, ne? A navíc pokud budete chodit v neprůstřelném brnění, tak můžete přihlašování přes klíč hned zrušit, protože imunita proti silnějšímu útoku Vás okamžitě ochrání před kdejakým prevítem, který ani nemá tu bouchačku?

robot prolomí během pár vteřin

Jedna z mnohých point je, že neprolomí.

Nebylo by lepší, kdybyste místo obecných úvah o profilech a úrovních útoků napsal jeden jediný příklad útoku, kdy ochrana klíčem stačit nebude, ale ochrana přesunutím na jiný port ano?

Ne nebylo, protože na tom to stojí a padá. Chodil jste na vysoké škole na analýzu a zkusil jste se učitele zeptat jestli by nebylo lepší místo těch důkazů a vět Vám rovnou říct jak spočítat písemku?

Pokud budete přemýšlet dále svým stylem, je zbytečné Vám dávat další příklady a čekat že jednou procitnete. Začněte přemýšlet jinak, a najednou si takových příkladů najdete sám dvacet.

[Filip Jirsák]

V tom případě je popisovaný útok bouchačkou také pouze "získání přihlašovacích údajů a přihlášení standardní cestou s jejich využitím", a nezdá se mi, že byste se proti takovému útočníkovi bránil. Ale měl byste počítat s co nejsilnějším útočníkem, ne? A navíc pokud budete chodit v neprůstřelném brnění, tak můžete přihlašování přes klíč hned zrušit, protože imunita proti silnějšímu útoku Vás okamžitě ochrání před kdejakým prevítem, který ani nemá tu bouchačku?

Aha, tak to abychom si nejprve nadefinovali některé základní pojmy. Takže „schopnější útočník“ znamená útočník, který dokáže všechno, co méně schopný útočník, ale ještě něco navíc. Takže útočník, který z vás mámí heslo s pistolí v ruce, je schopnější než útočník, který si heslo přečte z lístečku na monitoru,jedině v případě, kdy si to heslo z lístečku na monitoru také umí přečíst.

Jedna z mnohých point je, že neprolomí.

Pro robota není žádný problém svůj útok místo na port 22 nasměrovat na všechny porty, na kterých dokáže navázat TCP spojení.

Pokud budete přemýšlet dále svým stylem, je zbytečné Vám dávat další příklady a čekat že jednou procitnete. Začněte přemýšlet jinak, a najednou si takových příkladů najdete sám dvacet.

Já přemýšlím tak, že vezmu nějaký typ útoku, a snažím se proti němu postavit co nejlepší obranu (v rámci možností – finančních, časových apod.). Když to vyřeším, podívám se stejně na další typ útoku, který ještě nemám pokrytý, a postupuju stejně. Typů útoků je omezený počet – útok na hardware, útok na chybu v softwaru (chyba v jádru OS, chyba v aplikaci), získání přístupových údajů (útok hrubou silou, odposlechnutí, sociální inženýrství). Tahle metoda mi připadá mnohem lepší, než vaše metoda, kdy si náhodně volíte nějaké konkrétní druhy útoku (jednou je to útočník s pistolí, po druhé ňouma, co neumí do pěti počítat), a proti každému takovému útoku najdete nějaké „řešení“. Pak vás ale zaskočí, když ten ňouma do pěti počítat umí a neumí až do deseti.

[trekker.dk]

Pro robota není žádný problém svůj útok místo na port 22 nasměrovat na všechny porty, na kterých dokáže navázat TCP spojení.

To je jednak 60000× náročnější na zdroje a druhak to ten robot zpravidla neudělá, protože bude spíš zaměřen na kvalitu a ne na kvantitu - když na portu 22 nenajde SSH, tak se přesune na další server v seznamu, protože je to jednodušší, než na tom prvním serveru hledat SSH někde jinde.

[Filip Jirsák]

Pokud útočník poslal robota na váš server, s neúspěchem na jednom portu se rozhodně nespokojí a pošle ho prozkoumat všechny porty. Pokud jde o robota, který postupně zkouší na co narazí a tam na portu 22 zkouší známá hesla, ten neuspěje ani u serveru, kde přihlášení heslem není povoleno. Zatím jsme se se přesunem portu stále dostali jenom k útočníkovi, který je natolik schopný, že získá váš privátní klíč, ale natolik neschopný, že ho odradí, když nenajde sshd na portu 22. Jak velká je asi pravděpodobnost, že něco takového nastane?

[polo23]

...mala. Vzpomnel jsem si na Vas priklad kdyz mame trezorove dvere tak proc na ne davat listek neklepat. Ja jsem si ted vzpomnel na celkem casty jev... lide majici psa maji taky casto na brankach cedulku ze objekt je hlidan psem. To co jste ted napsal je pravda. Ale kdyz se na to podivame z pohledu utocnika tak on ma robota ktery ma zjistit IP a port na kterem vali SSH a pak tam praskat hesla. Tim ze dam jiny port nez 22 tomu utocnikovi ztizim utok pac pak on nebude prohledavat vsechna IP s portem 22, ale vsechna IP se vsemi porty. Coz muze trvat az 65536x dele. Proto si myslim ze nektere skenery zjistuji pouze aktivitu na portu 22. Stalo by ho hodne vypocetniho vkonu skenovat VSECHNO.

[Petr Tomášek]

Jejdamane, to je píčovina! Lidi, co mají psa a dají ceduli na vrata to dělají proto, aby se zbavili odpovědnosti, kdyby náhodou ten pes někoho porafal...

[Filip Jirsák]

To ale pořád spoléháte na to, že útočník nebude skenovat jiné porty, než port 22. Ale co mu v tom brání? Když se útočník zaměří na vás, nemá vůbec žádný problém s vyzkoušením všech portů. Pokud píšete o automatických skenech, to se bojíte toho, že vám takovýhle robot uhodne vaše heslo? Vždyť máte přihlášení heslem zakázané, tím jste všechny tyhle automaty, které hledají stroje se slabým heslem, vyřešil.

Podívejte se na to jinak. Brání přesun na jiný port útoku na chybu v softwaru nebo OS? Nebrání. Brání to útoku, kdy někdo od vás získá přístupové údaje? Nebrání. Takže zbývá útok hrubou silou – hledám, kde na vašem počítači běží sshd a jaké je k němu heslo. Použijte teď jenom jednu ochranu. Nejprve zákaz přihlášení heslem, přihlášení pouze klíčem, který máte zaheslovaný. Bál byste se takový počítač vystavit na internetu? Já ne. A teď druhý způsob zabezpečení, ponecháte přihlášení heslem, slabé heslo a přesunete sshd na jiný port. Vystavil byste takový počítač na internetu? Já ne. Ta první ochrana (přihlášení jen klíčem a bezpečné uložení klíče) je mnohem silnější, a přitom pokrývá všechny druhy útoků, jako přesun portu – a spoustu dalších.

Když máte vyřešen problém s útočníkem, který může všechny porty proskenovat, je zbytečné řešit útočníka, který má stejné možnosti, ale zkouší jenom port 22 – takový útočník je slabší a máte jistotu, že neprojde tím, čím neprojde ani silnější útočník.

[polo23]

Jako jasne mate pravdu ze ten klic pokryva vsechny mozne pripady. To s tim portem je pak mozna teda jen zvykem ktery mi ve skole namlatili d ohlavy. Bylo to asi proto, ze ten co nas ucil se prihlasoval na svuj komp na koleji heslem... Myslim ze by jsme tuhle debatu uz mohli ukoncit. Cekal jsem 2-3 prispevky a ne 70!:) Netusil jsem ze me nasbirane zkusenosti rozpoutaji takovou valku:)

[miro]

Netusil jsem ze me nasbirane zkusenosti rozpoutaji takovou valku:)

Vy jste tu nový, že? PermitRootLogin no a nestandardní port ssh jsou tu témata velmi vděčná, to je ta sedmdesátka ještě slabota. Viz např. 1, 2, 3.

[Jendа]

Pokud budete přemýšlet dále svým stylem, je zbytečné Vám dávat další příklady a čekat že jednou procitnete. Začněte přemýšlet jinak, a najednou si takových příkladů najdete sám dvacet.

Ať přemýšlím, jak přemýšlím, žádný příklad jsem nenašel. Možná je to tím, že jsem na vysoké nechodil na analýzu (zatím chodím na gymnasium). Mohl byste mě, prosím, popostrčit?

[pht]

Pokud Vás to nenapadne, tak stačí pořádně pročíst co psali jiní zde a jinde a máte tam vše podstatné.

[Filip Jirsák]

Já jsem teda zaznamenal jediný argument, a to že se přesunem na jiný port zabrání plnění logů. A pak tedy ještě několik argumentů, že když už je tam pořádná ochrana (zákaz přihlášení heslem), ničemu neuškodí přidat tam ještě nějakou hračku.

[Jendа]

Přečetl, a jediné, co jsem našel, byly plné logy.

[pht]

A co na to říkáte? I kdyby to bylo to jediné, tak Vám za to nestojí?

[Jendа]

#29

[pht]

A co s tím?

Jak budete řešit zahlcené logy? A apache umožňuje přihlášení administrátora do shellu?

[Filip Jirsák]

Apache neumožňuje přihlášení administrátora do shellu, ale bude se uživatelům na jiném portu blbě hledat. Z toho důvodu se plnění logů Apache neřeší jeho přesouváním na jiný port, ale konfigurací logování. Přičemž konfigurace logování je celkem univerzální způsob, jakým lze zahlcené logy řešit. Vypnutí serveru, přestřižení síťového kabelu nebo přesun serveru na jiný port sice jako vedlejší efekt může mít méně zápisů do logů, nicméně správce sítě by se měl kýženého efektu snažit dosáhnout metodou k tomu určenou, která nemá další následky.

[pht]

Apache je podstatně méně citlivá služba, takže si obvykle může dělat třeba suchý z vrby a mě to nebude tankovat, ale nevysvětlil jste mi jak chcete efektivně snížit SnR logu sshd, kde je docela podstatné vědět pokud možno co nejdříve o tom "chytrém útočníkovi", a ne o hordách robotů.

[Filip Jirsák]

Tak ne že by mne těch 20 řádků v logu za den nějak moc trápilo, ale když už to chcete nějak řešit, přesměroval bych třeba hlášky sshd „invalid user name“ do nějakého jiného souboru, případně bych jejich logování úplně zakázal. Ono se o tom chytrém útočníkovi z logů asi taky moc nedozvím, protože nepředpokládám, že by mi o tom, co dělá, sepisoval záznamy do logu. Pokud byste náhodou měl problém s tím, jak bych si mohl dovolit některé hlášky do logu vůbec nezaznamenávat, pak vězte, že je to z pohledu útoků a logování to samé – útoky trvají dál (i když je sshd na jiném portu), ale nezaznamenávají se do logu.

[Václav HFechs Švirga]

Dobrý příspěvek, určitě využiju, až zas budu konfigurovat ssh server. Jistě, guru ví o všem všechno, a když někdo, kdo se dopídil k něčemu, o tom podělí se světem, masivně ho zkritizou kvůli pyčovinám dost agresivním a konfliktním stylem (jak tu vidím). S klíčema to neumím, takže pro mě paráda. K portu - když jsem kdysi nastavoval ssh server, taky jsem port měnil. Dejme tomu, že změna portu nezvýší bezpečnost (konkrétního hackera nezastaví), ale sníží množinu útočníků - botů a server je míň vytížený zahazováním požadavků (řekněme menší logy ;)), takže změna veskrz pozitivní. A nevýhodu u změny portu nevidím. Takže proč to kurva nedělat?

[Filip Jirsák]

řekněme menší logy

Ano, to je výborná taktika. Když na vás někdo útočí, zavřete oči. A hned žádný útok nevidíte. To je panečku obrana…

A nevýhodu u změny portu nevidím.

To máte štěstí, že jste zatím nenarazil na žádnou síť, kde by v podmínkách provozu bylo něco jako: povolené porty odchozí komunikace jsou udp/53, tcp/80, tcp/443 a tcp/22. Až se potkáte třeba s nějakou WiFi síti na vysoké škole, zjistíte, že sshd na nestandardním portu vám může být k ničemu.

[polo23]

Tak tady bych jeste teda dodal ze server (resp muj notebook) mam doma a nemam jej v zadne podivne siti kde by byly blokovany urcite odchozi porty. Dalsi vec jak uz napsal Václav HFechs Švirga ta zmena portu je opravdu hlavne proto ze vselijaci boti jsou naprogramovani tak aby skenovali zname porty. To ze zvolim neznamy port se alespon nekterym z nich vyhnu. Nechci aby to vypadalo neuctive ale doktorandi kteri me tohle ucili ve skole nejsou nejaci debilove. Uci Linux a bezpecnost uz nekolik let.  Co tu popisujete mi prijde trochu jak extremni situace... Ja jsem se snazil udelat navod na prihlaseni pomoci klice jak z Windows tak z Linuxu a pomoci nasbiranych zkusenosti zvysit zabezpeceni SSH serveru. Myslim ze kazdy z tech kroku eliminuje alespon cast potencialnich utocniku.

[miro]

IMHO šlo spíš o to, že by někdy člověk mohl potřebovat přístup na server přes hotspot v nějaké kavárně. Prostě to může být problém pro člověka, který neví, odkud se bude potřebovat někdy v budoucnu k tomu serveru přihlašovat. Možná mezi tyto lidi nepatříte.

[polo23]

Asi tady doslo k nedorozumneni... Pan Jirsák napsal: povolené porty ODCHOZI komunikace jsou udp/53, tcp/80, tcp/443 a tcp/22. Tzn. kdyz se prihlasuju z nejake pochybne site tak jsou povoleny vetsinou vsechny porty a to proto ze napr kdyz se hlasim na web port 80 tak odchozi port je muj zdrojovy ktery muj web browser dostane prideleny od OS. S tim ale ja nemam problem. Ten by byl pokud byste napsali ze ta pochybna wifi by neumoznovala jine CILOVE porty nez jak zminuje pan Jirsak. To pak jo... v takovem pripade byste meli pravdu.

[Filip Jirsák]

Povolené porty odchozí komunikace jsou něco jiného, než povolené odchozí porty komunikace

[Filip Jirsák]

Server můžete mít kde chcete, ale až se k němu budete chtít připojit ze svého počítače z nějaké kavárny nebo z vysokoškolské sítě, a dostanete se jenom na port 22, bude vám server běžící na portu 2222 k ničemu. A není to žádná extrémní situace, různé „napůl otevřené“ WiFi sítě (podnikové pro hosty, vysokoškolské, v restauracích) mívají omezení jen na určité porty velice často. Pravda, nemusí tam být povolen ani port 22, ale správce té sítě ji zpravidla také chce používat a také se chce připojovat ke svým serverům, takže povolený port 22 najdete rozhodně častěji, než váš náhodný port.

Nevím, k čemu je dobré to vyhýbání se robotům skenujícím porty. Když je zakázané přihlášení heslem, robot si stejně neškrtne, a těch pár paketů na navázání spojení nemůže server položit. Takže přesouváním na jiný port se stejně chráníte před něčím, před čím byste měl být už dávno ochráněn. Důležitější je chránit se před něčím, co je propracovanější, než roboti náhodně hádající hesla. Nejnebezpečnější je vždy útok zacílený konkrétně na váš počítač. Takže byste se měl snažit chránit před takovým typem útoku. A když budete ochráněn před takovým útokem, jste automaticky ochráněn i před těmi roboty.

To, že to učí doktorandi a dokonce několik let, je zajímavé, ale pořád to neodpovídá na otázku, k čemu je to dobré. Zabezpečení se nedá dělat tak, že si řeknete: „No, on bude útočník hloupý, on vyzkouší jenom defaultní port a vyzkoušet jiný port jej nenapadne.“ To je základní chyba při zabezpečování sítě nebo počítače – naopak musíte předpokládat toho nejschopnějšího útočníka.

[polo23]

Vim... rika se doufej v lepsi ale pocitej s horsim. Ja jsme ten port zmenil z toho duvodu aby odpadli aspon Ti hlopi utocnici. Samozrejme...kdo me chce dostat si proskenuje vsechny porty. Ale jak rikam kazdym krokem jsem se snazil eliminovat nejakou skupinu... Podle me to je ta myslenka.

[Filip Jirsák]

Copak přihlašování klíčem neeliminuje ty hloupé útočníky úplně stejně? Opravdu nevím, k čemu je dobré dělat nějakou extra obranu proti hloupým útočníkům, když máte obranu proti chytrým útočníkům. Vždyť ta druhá stačí. Ta první vás maximálně ukolébá v pocitu, že už jste pro obranu udělal dost, ale žádné zlepšení nepřinese. Proto mi přesouvání na jiný port (stejně jako přihlašování přes dalšího uživatele) připadá kontraproduktivní: kdybyste to neudělal, budete mít pocit, že je potřeba zabezpečení ještě nějak vylepšit, a uděláte to pořádně. S tímhle „zabezpečením“ sice reálně bezpečnost nezvýšíte, ale máte pocit, že už jste udělal dost, a dalším zabezpečením se zabývat nebudete.

[Kvakor]

Na druhou stranu, pokud jou logy zahlcené útoky od hloupých útočníků, je mnohem snažší v nich přehlédnout útoky od těch chytrých.

[Filip Jirsák]

Pokud jsou logy zahlcené, řešil bych zahlcené logy, a ne přesouvání sshd na jiný port. Mně se nejvíc plní logy webového serveru, že bych ho taky přesunul na jiný port?

[Heron]

[miro]

Použití direktivy PermitRootLogin no a následné "su-ování" po přihlášení přes normálního uživatele možná může bezpečnost spíš o něco snížit, než by ji nějak zásadně zvyšovalo. Viz např. zde.

[Radek Hladik]

Osobně doporučuju použít permitrootlogin without-password, což zajistí, že root se může přihlásít pouze certifikátem. Je to samozřejmě o flamewaru, ale například editování konfiguráku jEditem přes SFTP je velice příjemná věc. A přes su(do) to SFTP jen tak neprotlačim. A nejen editování konfiguráků, příkladů se dá najít spousta.

Další věc, která není v článku zmíněná, je ssh-agent (například pod windows putty pageant), který umožňuje klíč do sebe nahrát a používat. Také je možné ssh autentizaci "protlačit" skrtze ssh, takže když se někam přihlásím, a pak se hlásím dál, tak můžu použít ssh agenta na svém klientském stroji, ikdyž je to vlastně přes dvě ssh spojení. A pageanta jsem si upravil tak, že a) ukáže bublinu, když použije klíč a b) pokud klíč nebyl nějakou dobu použitý, vyžádá si cosi jako PIN.

[rastos]

PubkeyAuthentication je defaultne "yes", nie?

Prečo authorized_keys2 a nie authorized_keys ?

Z mojej skúsenosti - najčastejšie býva problém s prístupovými právami pre privátny kľúč alebo pre .ssh adresár. Chcelo by to doplniť paragraf o tom, aké sú s tie správne hodnoty.

Prilejem olej do flamwaru o porte : prečo sa tanky nenatierajú reflexnou oranžovou farbou?

[pht]

Chcelo by to doplniť paragraf o tom, aké sú s tie správne hodnoty.

Betonfest (i z jiného hlediska) je 0700 na ~ a ~/.ssh a 0400 na ~/.ssh/authorized_keys. Teoreticky to první nemusí být, pokud má někdo věci typu ~/public_html.

[Jendа]

a 0400 na ~/.ssh/authorized_keys

Spíš ~/.ssh/id_?sa, ne?

[Filip Jirsák]

V authorized_keys jsou veřejné klíče, s jejichž odpovídajícími privátními se můžete přihlásit – takže tam by měla být práva rw- pouze pro vlastníka, ostatní nic, tedy 0600. Takže kdo si do toho souboru může přidat svůj klíč, může se pak na ten účet přihlásit.

id_rsa je privátní klíč, ten by na serveru vůbec neměl být (*), měl by být jen na počítačích, ze kterých se přihlašujete (pracovní stanice, notebook apod.). A s právem pouze pro čtení pro vlastníka, takže 0400.

(*) Pokud se ze serveru nechcete hlásit někam dál, třeba kvůli zálohám, ale k tomu je pak dobré vyčlenit extra uživatele.

[Jendа]

Jo my mluvíme o právech na serveru. Tak to jo.

[pht]

To je pravda, původně se mluvilo o právech na privátní klíče. V praxi je ale problém spíš se sshd, ne ssh. Zatímco ssh-keygen si práva na vytvořeném souboru umí nastavit v souladu se svými ideály, sshd Vás potichu odmítne přihlásit, obvykle kvůli právům k authorized_keys, případně adresáře po cestě.

[Filip Jirsák]

sshd je potichu, což se ovšem nedá říci o správci, zvláště pokud je server daleko a přihlášení heslem zakázáno bez ověření, že funguje přihlášení klíčem

[hruskin]

Prilejem olej do flamwaru o porte : prečo sa tanky nenatierajú reflexnou oranžovou farbou?

 

+1

 

[Ondřej Kubečka]

Protože by se rychle strašně zaprasily?

[Petr Tomášek]

Když vám tohle nějaký admin udělá, je to na zabití. Bezpečnost to rozhodně nezýší a přitom to zamezí např. použítí SFTP protokolu (a to nemluvím např. o vzdáleném zálohování kupř. pomocí mysqldump, nebo "ssh xyz tar czf - adresare | cat > zaloha.tgz")...

[marbu]

Souhlasim ze presouvani portu je podivne. Kdyz uz to nekdo udela, tak si ale porad muzes v konfiguraku (~/.ssh/config) prenastavit port pro konkretni stroj a vsechno co uvadis bude fungovat dal bez nutnosti nestandardni port pokazde uvadet.

[marbu]

A ted mi doslo ze s vama vlastne souhlasim, protoze rec nebyla o presouvani portu ale o zakazu prihlaseni roota. Coz by davalo smysl jen v pripade, kdy by ten stroj nebylo potreba nijak spravovat (:, jinak mnohem lepsi jsou volby without-password, pripadne forced-commands-only.

[trekker.dk]

zamezí např. použítí SFTP protokolu

Zamezí? Tvůj SFTP klient neumí na vyžádání použít jiný port?

[houska]

ssh xyz tar czf - adresare | cat > zaloha.tgz

ano to je opravdu problem ...

ssh -p 2222 xyz tar czf - adresare | cat > zaloha.tgz

[Filip Jirsák]

Autoři dvou komentářů nade mnou by si měli nejprve přečíst titulek komentáře – PermitRootLogin no se portů netýká…

[trekker.dk]

A autor prvního příspěvku ve vlákně by se měl pro změnu odnaučit psát podstatné informace do titulku příspěvku :-/