Odpověď závisí na vaší ochotě riskovat. Omezení přístupu k portu SSH pouze na známé adresy IP výrazně snižuje povrch útoku. Ať už může nastat jakýkoli problém (úniky soukromého klíče, 0 dní v SSH atd.), Může ho zneužít pouze útočník pocházející z těchto konkrétních IP adres. V opačném případě může útočník přistupovat k portu odkudkoli, což je obzvláště špatné v případě neopravené chyby zabezpečení SSH s exploitem dostupným ve volné přírodě.

Je jen na vás, jak důležité je systém a jeho data jsou pro vás. Pokud to není tak kritické, může být vhodné pohodlí portu SSH otevřeného světu. Jinak bych pro každý případ doporučil omezit přístup. Těžkých 0 dní v SSH se neobjevuje každý den, ale nikdy nevíte, kdy nastane další.

Klíč ssh bude distribuován malé skupině lidí.

Ne, nedělejte to. Nikdy nesdílejte soukromé klíče. Vyzvěte své lidi, aby sami generovali páry klíčů a sbírali jejich veřejné klíče. Přijměte přiměřená opatření, abyste zajistili, že pubkeys skutečně pocházejí od správných lidí.

Nebo vám nevadí potíže, můžete místo toho vyzkoušet jednotné ověřovací schéma, například SSH CA, abyste se mohli podepsat jsou to certifikáty, které lze bezpečně distribuovat (certifikát je bez soukromého klíče k ničemu).

LDAP je ještě lepší, ale s malými servery bych se neobtěžoval. Je příliš složité jej nastavovat a udržovat.

Otevření portu SSH na internetu není nezabezpečené samo o sobě . Záleží na tom, jak se autentizuje. SSH skenování probíhá každou minutu na internetu. Zkuste jej nechat zapnutý jen jeden den a zkontrolujte /var/log/auth.log , zda neobsahuje neplatná uživatelská jména.

Řekl bych, že pokud používáte ověřování pomocí veřejného klíče a aby byla soukromá část zabezpečena, nikdo na váš server nemůže v reálném čase hrubou silou, vzhledem k tomu, že běžné implementace SSH, jako je OpenSSH, často nevyskakují 0 dní. Sdílení soukromého klíče není bezpečné ani pohodlné. Klíč může během přenosu uniknout, pravděpodobně v určitém okamžiku ani nevíte. To je nebezpečné.

Odpověď Ne, není to triviálně nejisté, ale stále to není ideální.

Spravuji několik instancí AWS a zatímco většina z nich má skupiny zabezpečení omezující příchozí přístup SSH, existuje obchodní potřeba, aby jeden z nich naslouchal na portu 22 pro všechna připojení.

Jako takový je tento hostitel každý den zasažen tisíci skriptovaných (skiddy) připojení. To je při přihlášení označeno zprávami MOTD jako

  Poslední přihlášení: Pá 19. června 23:17:36 UTC 2020 na bodech / 2 Poslední neúspěšné přihlášení: So 27. června 01:00:44 UTC 2020 od 120.70.103.239 na ssh: notty Od posledního úspěšného přihlášení došlo k 21655 neúspěšným pokusům o přihlášení. Host1234 ~ # dateSat 27. června 01:12:18 UTC 2020  

Takže to je zhruba 2500 denně sto za hodinu. Určitě většina z nich bude jednoduše automatizovaná sonda, ale co se stane, když bude nalezena a zneužita zranitelnost nulového dne?
Omezením expozice snížíte riziko.

Řešení zahrnují jedno / některé / všechny:

• Použít skupiny zabezpečení AWS k povolení připojení pouze ze specifických IP adres na internetu
• Použít VPN řešení a vyžadují, aby SSH bylo provedeno přes VPN. VPN může poslouchat všechny zdroje, mít certifikáty a 2FA a obecně přidávat další vrstvy. OpenVPN funguje dobře, nebo existuje několik nabídek AWS, které provádějí stejný úkol.
• Přesuňte SSH na jiný port - není to žádné přidané zabezpečení, ale tím se sníží počet pokusů o připojení ssh, a proto hluk. Kdokoli, kdo si stojí za svou sůl, prohledá stejně všechny porty, nejen výchozí.
• Pokud MUSÍTE poslouchat SSH promiskuitně, prozkoumejte řešení jako který přidá zdroje do /etc/hosts.deny , pokud selžou více než Xkrát za Y minuty, a může je po nějakém dni znovu odstranit.
• Prozkoumejte IPv6 - jako změnou naslouchacího portu IPv6 prodlužuje čas potřebný na skenování, takže kluzáci mají více prostoru pro vyhledávání. Prohledávání v6 se však stále děje.

Sshing-in zařízení je pro mě hardware, takže mají platný uživatelský certifikát a vždy se úspěšně ověřují. Napsali jsme skript, který prohledá / var / log / secure a vyhledá výraz „uživatel nebyl nalezen“ nebo podobný a okamžitě tyto zdroje trvale přidá do souboru hosts.deny.
Uvažovali jsme o tom, že bychom to rozšířili tak, aby blokovaly celé podsítě na základě vyhledávání, ale to ještě nebylo potřeba.

Aktuálně blokujeme:

  host1235 ~ # grep -ci all /etc/hosts.*/etc/hosts.allow:79/etc/hosts.deny:24292

Nebudu sdílet seznam špatných zdrojových IP adres , protože některá místa považují adresy IP za osobně identifikovatelné informace (nebo PII).

Upozorňujeme, že naše adresy IP Office jsou v hosts.allow , které trumfují hosts.deny soubor, takže pokud někdo selže při přihlášení z kanceláře, pak to nezablokuje lidské uživatele.

Požádejte o vysvětlení - vím, že jsem dal mnoho detailů rukou.

Možná budete chtít zvážit použití Správce relací AWS. Když moje společnost používala AWS, zdálo se, že to není super široce známý nástroj. V podstatě to jednoduše umožňuje přihlásit se k instanci EC2 z prohlížeče (nebo příkazového řádku ^† ) přes konzolu AWS. K autorizaci používáte klíče IAM místo klíčů SSH.

S rizikem, že to bude znít jako reklama, budu pokračovat a cituji příslušnou část dokumentace.

• Žádné otevřené příchozí porty a není třeba spravovat hostitele bašty nebo klíče SSH

  Ponechání otevřených příchozích portů SSH a vzdálených portů PowerShell ve vašich instancích výrazně zvyšuje riziko entit, které budou v instancích spouštět neautorizované nebo škodlivé příkazy. Správce relací vám pomůže zlepšit pozici zabezpečení tím, že vám umožní zavřít tyto příchozí porty a zbaví vás správy klíčů a certifikátů SSH, hostitelů bastionů a skoků.

Pokud tedy do máte podezření, že ponecháte port 22 otevřený, bude to problém (a myslím, že odpověď Dementa dobře pokrývá, zda byste měli nebo neměli) pak toto je přístup, který můžete použít k jeho udržení v uzavřeném stavu při současném umožnění přístupu SSH (alespoň z určitého hlediska).

†: K použití správce relací existuje nástroj třetí strany z příkazového řádku zde.

A. Klíčový SSH je velmi bezpečný a široce důvěryhodný. Samozřejmě vždy existuje možnost zranitelnosti (např. Heartbleed) a omezení pomocí IP zvyšuje bezpečnost. Riskoval bych však, že uhodnete, že je větší pravděpodobnost, že vás někdo napadne jinými způsoby (řekněme phishing pro konzolu AWS). Zvažte vytvoření více klíčů SSH, abyste zabránili možnému kompromisu při jejich sdílení. (I když chápu, že to může být nepohodlné, protože AWS umožňuje při prvním spuštění instance pouze jeden klíč SSH.)

Ne. Není triviálně nezabezpečené mít server openssh otevřený pro příjem připojení odkudkoli.

openssh má opravdu dobrý bezpečnostní záznam a je nepravděpodobné, že by se téměř na povrch objevil nový „exploit zabijáka“ .

Mějte však na paměti, že vaše instance bude přijímat spoustu pokusů o hrubou sílu z celého světa. To nepokrývá slabé heslo!

• Zakázat ověřování pomocí hesla na úrovni serveru ssh. Proto pro přihlášení potřebujete klíče ssh.
• Nesdílejte soukromý klíč! Každý, kdo potřebuje přístup na server, by měl mít na server přidán vlastní klíč (vygenerovaný místně, nikdy neodeslaný). To zlepšuje sledovatelnost, umožňuje odebrání přístupu jedné osobě, že pokud je klíč dokonce podezřelý z ohrožení, lze jej snadno vyměnit a odstraní problémy s distribucí soukromých klíčů.
• Můžete zvážit přesun serveru na jiný port. Nejedná se o samotné bezpečnostní opatření, ale poskytne vám čistší protokoly
• Přístup můžete dále omezit tím, že budete vědět, odkud nebude připojen. Možná není možné nastavit seznam povolených přesných adres IP, které budou použity, ale možná budete vědět, ze které země budou. Nebo že se tam nikdo nepřipojuje.

Varování AWS je dobré a je dobré omezit příchozí zdroje, pokud můžete, ale nedělat to není nejisté. Všimněte si, že AWS neví, zda požadujete klíče ssh, nebo jestli máte pověření root / 1234. Toto varování bohužel odráží vysoký počet instancí, které jsou nakonec kompromitovány kvůli triviálně hloupým pověřením.

openssh má docela dobrou pověst zabezpečení. Když se podívám do svého archivu výstrah zabezpečení Debianu (nejde o vyčerpávající hledání, v knihovnách používaných programem openssh mohly být problémy, které jsem nezjistil). Vidím asi jedno upozornění za rok, ale většina z nich se jeví jako relativně malé problémy (některé problémy s výčtem uživatelských jmen, některé problémy v klientovi, problémy s eskalací privilage pro uživatele, kteří jsou již ověřeni na serveru s jinou než výchozí konfigurací, některé obchází omezení proměnných prostředí

Jedna chyba však vyniká. V roce 2008 došlo v Debianu openssl k opravdu ošklivé chybě, což znamenalo, že klíče generované pomocí openssl nebo openssh ve zranitelném Debianu systémy mohly být vynuceně vynuceny. Kromě toho klíče DSA, které byly na zranitelném systému pouze použity , byly potenciálně ohroženy, pokud útočník provozoval zranitelný klíč (buď pomocí čichání, nebo v případě klíčů hostitele z Když se taková chyba zabezpečení stane veřejnou, můžete mít velmi omezený čas na přizpůsobení, než ji botneti začnou používat.

Takže nejlepší je minimalizovat množství věcí, které přímo vystavujete Internet, takže když přijde opravdu ošklivá chyba, kterou můžete rychle zmírnit. Nutnost provést nouzovou aktualizaci na několika systémech je mnohem lepší, než to udělat na každém systému najednou.

Samozřejmě je to nákladné, přístup pouze k jednotlivým systémy na vaší VPN nebo se musí odrazit přes více serverů se může stát hlavní PITA. Nakonec musíte rozhodnout, která rovnováha je pro vás to pravé.

Ne, není to „triviálně nejisté“, ale AWS nikdy neřekla, že tomu tak bylo. Místo toho doporučuje dělat něco jiného, ​​protože dělat něco jiného je v souladu se standardními osvědčenými postupy. Těmto osvědčeným postupům se můžete vyhnout, pokud si myslíte, že to víte lépe, ale vzhledem k tomu, že váš OP pojednává o myšlence sdílení soukromého klíče mezi více uživateli, velmi důrazně doporučuji pouze vyhovět každému upozornění na zabezpečení, které vám AWS pošle. V nejhorším případě zbytečně strávíte čas „over-engineeringem“. V nejlepším případě se vyhnete vážným následkům.

Pokud někdo nemá můj soukromý klíč ssh, jak je možné ponechat instanci AWS na 0.0.0.0, ale pouze na portu 22 prostřednictvím nezabezpečeného ssh?

Není to „nejisté“ Zvyšte riziko porušení pouze v případě, že v SSH existuje neznámá nebo neopravená chyba zabezpečení.

Protože používáte AWS, můžete pomocí IAM umožnit členům týmu přidávat vzdálené adresy IP, které přicházejí od sebe .

Upozorňujeme, že toto varování obsahuje několik dalších vrstev. Nejprve možná nebudete chtít přiřadit veřejnou IP adresu strojům ve vaší interní podsíti.

Místo (pouze) filtrování IP ve skupině zabezpečení a VPC ACL, které nemají síť dosažitelnou bez skoku hostitel, správce relací nebo VPN je další měření.

Pomáhá to také proti náhodnému překonfigurování skupin zabezpečení (a zachování a povolení dalších síťových služeb). Pomáhá také proti zneužití úrovně IP jádra nebo rizikům DOS. Je to součást zabezpečení do hloubky a vrstvených přístupů, které se řídí zásadou neumožnění jakéhokoli přístupu, kterému se lze vyhnout - i když tím nenajdete okamžitou hrozbu.

Před veřejnými cloudy Dáte-li velkou důvěru v ochranu perimetru, totéž lze použít pro softwarově definované architektury v cloudu, kde by mikro segmentace měla být ve skutečnosti normou.

Krátká odpověď:

• Změnit výchozí port ssh
• Odstranit výchozí banner ssh
• Nesdílejte soukromé klíče
• Omezit povolené ips
• Přidejte denní cronjob pro instalaci bezpečnostních aktualizací

Správná konfigurace sshd nedovolí náhodným lidem přihlásit se do vaší instance ec2 záměrně, ale je možná nesprávná konfigurace nebo zranitelnost.

Použití portu 22 je běžné a nesmírně populární cíl pro skenování zranitelností. S otevřenou konfigurací brány firewall bude testována vaše konfigurace sshd a software .

Většina uživatelů EC2 poskytuje SSH pouze pro sebe, takže ji nabízí jako veřejnou služba je rozhodně zbytečné riziko.

Pokud chcete poskytovat SSH koncovým uživatelům, pak je veřejná služba. Uvědomte si, že přijímáte tuto odpovědnost. Některé osvědčené postupy jsou (ale nejsou omezeny na): buďte velmi opatrní při úpravě konfigurace a ujistěte se, že jsou aktualizace pravidelně instalovány.

Někdo výše zmínil použití aplikace Amazon Session Manager, kterou také velmi doporučuji prozkoumat .

Za předpokladu, že ji nakonfigurujete správně , nejenže není „výrazně nezabezpečená“; není vůbec zranitelný, kromě vulvů na úrovni celosvětové katastrofy, u nichž se neočekává, že budou existovat. Vážně, infrastruktura pro správu AWS je slabším článkem než OpenSSH.

Nyní existuje řada možných způsobů, jak ji špatně nakonfigurovat, včetně toho, který jste uvedli ve své otázce, distribuce sdílený soukromý klíč. Rozhodně to nedělejte. Nikdy byste neměli zacházet se soukromým klíčem někoho jiného; měli by vám dát své veřejné klíče. Rovněž by neměly být povoleny žádné jiné možnosti ověřování než pubkey - žádná hesla, žádná GSSAPI, žádná PAM atd.