SSH nebo Secure SHell nahradil Telnet někde v 90. letech minulého století jako preferovaný protokol pro vzdálený přístup, a to z dobrého důvodu. SSH umožňuje administrátorům – nebo uživatelům – přistupovat ke vzdálenému shellu přes zabezpečený tunel připojením jejich SSH klienta k SSH serveru. SSH si také poradí s přenosy souborů, které by měly nahradit FTP, i když existuje překvapivý počet situací, které stále spoléhají na staré dobré FTP s čistým textem.
Proč? Fuj.
Z výše uvedených důvodů jsou moderní linuxové systémy spravovány pomocí SSH. Většina zkušených správců systému miluje přímý přístup a výkon, který získávají relativně snadným bezpečným připojením k shellu jejich systému. V tomto článku budu hovořit konkrétně o démonu serveru OpenSSH, sshd . Probereme některé bezpečnostní problémy, na které můžete narazit, a jak je zmírnit – nebo přímo vyřešit.
Proč potřebujeme SSH
Jak jsem již zmínil, SSH je mocný nástroj. Prostřednictvím relace SSH můžete připojit virtuální terminál přímo k cílovému systému. Ve špatných rukou může být tato schopnost problematická, tak proč necháváme takovou moc přístupnou? Síla SSH zahrnuje křehkou rovnováhu. Během několika minut může administrátor otevřít zabezpečenou relaci na svém serveru, aby mohl reagovat na incident. Jednoduchost je elegantní.
SSH je také jádrem automatizačních nástrojů, jako je Ansible. Ansible může aplikovat změny na systém prostřednictvím SSH bez potřeby agenta. Všechny změny se místo toho provádějí pomocí SSH a Pythonu.
SSH lze také použít, jak jsem již zmínil, pro bezpečný přenos souborů. Například rsync tunely přes SSH pro bezpečnou synchronizaci dat. SSH lze také použít k tunelování přes jeden systém a dostat se do jiného, což je skvělé pro odstraňování problémů, ale také skvělé pro útočníka.
Pokud vás předchozí odstavce nepřesvědčily, zopakuji toto:SSH je mocný nástroj a jako každý mocný nástroj ho lze zneužít. Pokud se útočníkovi podaří získat bezpečný shell do vašeho systému, je konec hry. A útočníci to vědí, takže neustále hledají systémy s SSH otevřené světu, aby mohli zaútočit.
Zamknout SSH
Jediným nejčastějším útokem proti SSH je hrubá síla. Na mých systémech se mi osobně nikdy nepovedlo, že by útok hrubou silou proti SSH uspěl. Než jsem však začal dodržovat jednoduchá pravidla zamykání, mohu vám říci, že to určitě zkusili.
Rychlé vyhledávání na Shodan – vyhledávač, který cílí na zařízení připojená k internetu – ukazuje 20 984 090 systémů s SSH otevřenými světu. Je nutné je takto nastavit? Mohu vám téměř zaručit, že každý z těchto systémů obdrží několik útoků hrubou silou SSH za sekundu. Zatímco jsem psal tento článek, spustil jsem droplet na Digital Ocean, nechal SSH otevřený světu a sledoval /var/log/secure . Asi za 20 minut jsem viděl první sondu SSH. Během hodiny začala záplava útoků hrubou silou.
Jun 23 01:35:33 centos-s-1vcpu-1gb-sgp1-01 sshd[10926]: Did not
receive identification string from 81.22.45.137 port 61000
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Invalid
user fake from 104.248.132.25 port 36050
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]:
input_userauth_request: invalid user fake [preauth]
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Received
disconnect from 104.248.132.25 port 36050:11: Bye Bye [preauth]
Stručně řečeno, špatné heslo na výchozím sshd instalace může být vše, co stojí mezi padouchy a vaším systémem. I když je výchozí konfigurace pro OpenSSH slušně bezpečná, může být posílena. Naštěstí pro vás mám návrhy.
Omezit přístup k portu 22
Začněte tím, že zkontrolujete, zda je výchozí port SSH (port 22) otevřen světu. Můžete to udělat spuštěním Nmap, který prozkoumá vaši síť podle vašich specifikací:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-22 20:56 EDT
Nmap scan report for 167.71.200.117
Host is up (0.26s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh Zúžení toho, kdo má přístup k portu 22, je nejzákladnější věcí, kterou můžete pro zabezpečení systému udělat. Uvědomuji si, že tato taktika nemusí fungovat pro každý scénář. Možná provozujete veřejný systém nebo možná CIO hodně cestuje a může přistupovat k systémům z mnoha různých míst (o VPN si povíme trochu). Jde mi o to, že můžete mít pádný důvod, proč musí být SSH absolutně otevřené široké veřejnosti. Přemýšlejte velmi je těžké se této konfiguraci vyhnout. Udělal jsem to, ale hlavně z lenosti. Obvykle existuje lepší způsob.
Pokud používáte poskytovatele cloudu, nakonfigurujte skupinu zabezpečení tak, aby přijímala pouze provoz SSH ze sítě, ze které pracujete. Tento úkol by měl být jednoduchý, pokud k tomuto poskytovateli přistupujete z podnikového prostředí. Pravděpodobně máte svůj vlastní rozsah IP adres, což znamená, že jej můžete přidat na seznam povolených a blokovat vše ostatní. Pokud však přistupujete k poskytovateli cloudu z domova, možná budete muset provést několik triků, abyste přidali dynamicky přidělovaný blok IP vašeho ISP na bílou listinu. Použití skupiny zabezpečení by vám mělo v případě potřeby umožnit změnit rozsah IP adres prostřednictvím samoobslužného portálu vašeho poskytovatele cloudu.
Pokud hostujete systém, který není za firewallem, použijte hostitelský firewall k blokování portu 22 odkudkoli kromě vašeho rozsahu IP adres, pomocí stejných metod, které jsem právě popsal. Problém je samozřejmě v tom, že pokud jste zablokováni kvůli změně vaší IP adresy, bude pro vás obtížnější provést potřebné změny.
A nezapomeňte, že podnikové prostředí má své výhody. Pokud je váš server v podnikové síti, existuje velká šance, že existuje síťový firewall, který můžete použít k uzamčení přístupu SSH, takže tuto skutečnost využijte ve svůj prospěch. Obrana do hloubky, lidi, to je věc!
Vyžadovat VPN pro vzdálený přístup
Dobře, pojďme si tedy promluvit o tom cestujícím CIO, který to absolutně potřebuje přístup k ssh z hotelového pokoje. Řešení se zdá být zřejmé těm z nás, kteří byli kolem bloku, ale pokud uvažujete o otevření přístupu SSH celému světu, možná budete potřebovat slyšet toto:VPN nebo virtuální privátní síť vám umožní vytvořit šifrovaný tunel. z koncového bodu – jako je notebook vašeho CIO v hotelu na Maui – zpět do vaší podnikové sítě v Seattlu. Toto připojení je chráněno svým vlastním způsobem a šifrováno.
Vaše desítky serverů, které nejsou přístupné světu, by se však mohly stát přístupnými prostřednictvím tohoto jediného bodu. Ano, tento postup přesouvá cíl útoku na VPN, ale to znamená, že je tu ještě jedna překážka, kterou musí padouši překonat.
Zakázat přístup root
Nyní se dostáváme ke skutečnému sshd konfigurace. Démon OpenSSH má možnost nazvanou PermitRootLogin . Ve výchozím nastavení je tato možnost nastavena na Yes , protože když nainstalujete některé systémy, nejprve existuje pouze root. Když nastane tato situace, potřebujete účet root pro přístup k systému a provedení počáteční konfigurace.
Doporučuji přidat uživatele během procesu instalace nebo jako součást vašeho zlatého obrazu a hned na začátku vypnout přihlášení root. Není důvod se přihlašovat jako root a rozhodně není důvod se přihlašovat jako root přes SSH. Změňte tedy konfigurační řádek na:
PermitRootLogin no Implementujte autentizaci na základě klíče
Zpočátku jsem jako pohodlí používal autentizaci na základě klíče. Vygeneroval jsem soukromý klíč, přidal jsem veřejný klíč ke svým authorized_keys soubor na serverech, které jsem spravoval, a mohl jsem se pak bezpečně připojit k mým systémům bez hesla. To ušetřilo čas a umožnilo automatizaci. VYHRÁT! Až později jsem zjistil, že ověřování založené na klíči SSH lze využít k eliminaci pokusů o heslo hrubou silou.
Chcete-li vygenerovat klíč, spusťte ssh-keygen na počítači Mac nebo Linux. Možná to teď můžete vy, Windowsáci, udělat nativně, ale na počítačích s Windows jsem vždy používal PuTTYGen (a poté klíč použil s klientem PuTTY). Budete požádáni o typ klíče a jeho délku. V poslední době jsem vyráběl 4096bitové klíče RSA. Čím více bitů, tím těžší je klíč prolomit. Tak proč ne?
[gangrif@meliodas ~]$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gangrif/.ssh/id_rsa): ./test-key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./test-key.
Your public key has been saved in ./test-key.pub.
The key fingerprint is:
SHA256:xfHOf4t3V3CCkJ+3FbEnQusAjBwOjBXfOa9WdGXBMqc [email protected]
The key's randomart image is:
+---[RSA 4096]----+
| ++o.+. ....+o.|
| . .+o..+o+o+o..|
| o + =o=B..o|
| = *E.+.+|
| S o +. * |
| o .. .|
| o . o|
| . .o+|
| ...o|
+----[SHA256]-----+
To, co pak skončíte, je nový soubor s názvem test-key (v tomto případě) a test-key.pub . Klíč v test-key je můj soukromý klíč a test-key.pub obsahuje veřejný klíč. Chraňte soukromý klíč svým životem. Veřejný klíč však můžete nechat ležet, kdekoli chcete, protože bez soukromého klíče je k ničemu.
[gangrif@meliodas ~]$ cat test-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDAQxmjoHO6i4Kkq8vp49KtqAsMcw+ptgvd+PGjxVYkDPGdzRZpJhq0c3BDstFs86ENlojs61zZaP3MihLR0BlDdIyM3jh9TmVvmOPiylhu4X9QliAca/ODxyVp76OpTKm+QcgBi/7i/JNiJdEgcSy8izB0Oil7LZjIhS6wCs3mQFVbkPXPfe1lmHQIcuMDOKO0RuyecY/lrKodcr/YbEE4GsM/P11QdDPZ78lq83G3H5vqLqMrxVKkLw7Z4//+PZPFFxi/N1EBwBp/uPEo4MfD1IwSmnKromRlkYTdOYlbiCNosdvEobtMARySdqjv7RDn0Iwb3JxioUW6jQdAXfl8d01LvX/0Yb1tq5hF44ahwvI6TyoB4z3DRs+3cFiMPWQR7LK8/qQOvHk5I2NMBAV9KuSN2ML0d7xeB8tglw38PYjhZsXl/t2rAWT4n8PU0o6+Hrrli+WEfvk8QWpLesmBBmzG0sLjH0mXBU/xN4UBLLJNlrsUQ/TzEsdknntMhh7leOzechlU3PiTNuUitweT9NqLJwCP+CHbeSJn2M5qzb090CPnCGpnr2GOfm2dL+RfHQi2R1Cf04nBDq3WuhAPJY5SoEw2llfSgA2GlOdhcY9N9Bl9rLUBPgQ6ttBd7qZJ6E3BkiPlHnU+kSSpYr8Gkw1oDGbtd2UUjExZqvz4rQ== [email protected]
Na počítačích, ke kterým se chcete připojit bez použití hesla, zkopírujte veřejný klíč do .ssh/authorized_keys (nebo to nechte udělat uživatelem, v závislosti na situaci). Nyní říkám bez hesla, ale stále musíte odemknout soukromý klíč pomocí hesla, které jste nastavili při generování. Nastavili jste heslo, že?
Tento klíč můžete také vzdáleně zkopírovat na server pomocí ssh-copy-id .
Zakázat ověřování na základě hesla
Pamatujete si, když jsem řekl, že autentizace na základě klíče vám otevírá možnost zcela zablokovat pokusy o hrubou sílu SSH? Zde je návod. S vašimi soukromými a veřejnými klíči vás SSH již nevyzve k zadání hesla, že? Proč tedy nechávat tuto cestu otevřenou jako vektor útoku?
Na každý linuxový server, který spustím, přidám svůj veřejný klíč jako součást naší základní instalace a vypnu ověřování heslem SSH ještě předtím, než se systém vůbec dostane do sítě. Toto je nastavení přímo v sshd konfigurační soubor . Opět platí, že výchozí nastavení umožňuje ověřování heslem, protože tato funkce musí fungovat při konfiguraci. Až budete mít klíče na svém místě, vypněte to.
PasswordAuthentication no Gratulujeme, nyní jste imunní vůči útokům hrubou silou pomocí hesla.
Vězení uživatele SSH s chroot
chroot —obvykle vyslovované jako „chi-root“ nebo „ch-root“ – příkaz je úhledný nástroj. Umožňuje vám změnit kořenový adresář, který vidí proces a jeho potomci, odtud název. Je to skvělé pro řešení problémů se systémem, kde máte přístup k disku, ale nelze jej spustit. Stačí připojit jeho disk a chrootovat do /mnt/whatever.
Toto je také elegantní bezpečnostní nástroj pro něco jako shell server. Při přihlášení můžete uživatele chrootovat, takže doslova nevidí zbytek souborového systému. Nedělám to často, ale pro uživatele je to velmi životaschopné vězení. Tady jsem našel to, co vypadá jako slušný zápis.
Otáčení
Stojí za to zvážit rotaci hesla a klíče ssh. Pokusím se zde nastínit dobré a špatné.
Zásady a střídání hesel
Zásady hesel spojím se střídáním hesel, protože spolu souvisí. Zásady hesel, které vynucují složitost, jsou skvělým způsobem, jak přimět uživatele, aby si vybrali „silné“ heslo. To však má určitá omezení, zejména pokud je spojeno s libovolným (tj. časovaným) vypršením platnosti hesla. Mohl bych napsat celý článek o tom, jak vnímám zásady a rotaci hesel, ale pokusím se to zde uvést stručně.
Minulý rok NIST udělal něco jako o-face na svých pokynech pro hesla a změnil několik svých návrhů, které byly zakořeněny ve většině našich myslí po většinu naší kariéry. Komunita Infosec (do které se motám) už roky navrhuje, aby 8znaková náhodná hesla nebo minimální délka 8 znaků s přísnými pravidly složitosti dělala pro hygienu hesel HARM více, než aby jí pomáhala. Zkombinujte přísná pravidla složitosti se zásadou střídání hesel po 3–6 měsících a připravte své uživatele na frustraci. Tato frustrace vede k opětovnému použití hesla a dalším špatným návykům. Dobře si tedy rozmyslete, zda to chcete svým uživatelům vnutit. Nová doporučení se přiklánějí k vypršení platnosti pouze v případě, že existuje podezření na porušení nebo kompromitaci, a k zásadám, které vedou vaše uživatele k silným přístupovým frázím spíše než k heslům. "Toto je můj p@ssw0rd 2019." je mnohem těžší uhodnout a prolomit než „W1nt3r2019“. Což je mimochodem běžné jak pro tvůrce hesel, tak pro červené týmy. Mějte však na paměti, že pokud žádáte chytré administrátory, aby svá hesla střídali, nemusíte mít tento problém (protože chápou, PROČ to dělají a jak je to důležité). Ale pro vaše uživatele obecně se libovolné vypršení platnosti a složitá „hesla“ stávají minulostí.
Střídání soukromého klíče SSH
Jako každý identifikátor, který lze vygenerovat, může být dobré zvážit pravidelné střídání soukromého klíče. Váš soukromý klíč není tak snadné ukrást nebo uhodnout jako heslo, ale je možné, že někdo zvedl váš klíč bez vašeho vědomí. To se dostává do oblasti „jak paranoidní byste chtěli být“. Změna hesla na vašem soukromém klíči však nestačí. Toto heslo odemkne tento klíč, pokud dnes stáhnu váš klíč a zítra si heslo změníte, kopie, pokud váš klíč, který mám, má stále vaše staré heslo. Pokud to uděláte správně, musíte vygenerovat zcela nový klíč. Nyní je vhodný čas prodloužit délku klíče, pokud se standard od posledního vygenerování klíče posunul nahoru. Možná si vygenerujete nový klíč pokaždé, když vám zaměstnavatel vydá nový notebook, možná to uděláte jednou ročně k pracovnímu výročí. Nenašel jsem však řešení, které by to zvládlo za vás.
Mějte na paměti, že vygenerování nového klíče znamená, že všechny veřejné klíče, které máte na světě, jsou nyní neplatné. Nebo alespoň nejsou platné s vaším novým klíčem. K umístění nového veřejného klíče budete pravděpodobně muset použít svůj starý klíč.
MFA
Vícefaktorová autentizace se stává standardem. Někteří lidé se pokusili tvrdit, že klíče SSH jsou formou MFA, ale tak trochu nejsou. Zvláště pokud jste zakázali ověřování hesla. Můžete však integrovat mfa jako TOTP nebo YubiKey do konfigurace PAM vašeho systému. Řešení centrálního ověřování, jako je FreeIPA, to usnadňují.
Závěr
Takže tady to máte, doufám, že si tyto informace vezmete a použijete je ve svých systémech, abyste zlepšili svou bezpečnost. Nebuďte jedním z těch 21 milionů systémů s SSH otevřeným světu. Není k tomu žádný důvod.
Děkujeme za přečtení!
Tento článek byl původně publikován na Undrground.org. Znovu publikováno se svolením.