Tento příspěvek je o Hardening SSH Configuration
Úvod
SSH se stalo standardním nástrojem pro vzdálenou správu systémů založených na UNIXu. Démon SSH (sshd ) je standardně nainstalován na téměř všech hlavních systémech. Navíc sshd také nám poskytuje mnoho možností konfigurace.
Poznámka :Tento článek je pokračováním mého předchozího tématu o Lynis. I když jsem se snažil, aby to bylo čitelné samo o sobě. Možná budete chtít zvážit přečtení předchozí, abyste získali nějaký kontext.
Výchozí nastavení openssh (verze SSH vyvinutá projektem OpenBSD) se řídí filozofií „secure by default“, takže většina konfigurací je sama o sobě bezpečná. Nicméně při provádění kontroly lynis auditu jsem obdržel nějaké návrhy ohledně konfigurací. Pojďme si tedy projít návrhy, abychom dále posílili našeho démona SSH. Také se vyjádřím k tomu, zda vypnutí/zapnutí některých z nich zlepšuje zabezpečení.
Zpevnění konfigurace SSH
Návrhy zahrnují úpravu našeho sshd konfigurace. Jako výchozí cesta pro sshd config je /etc/ssh/sshd_config , to je místo, kde bychom se měli podívat.
TCP a přesměrování agentů
Jak je vidět ze snímku obrazovky, lynis doporučuje nastavit AllowTCPForwarding a AllowAgentForwarding na ne. Je dobrou radou používat pouze to, co je vyžadováno, takže pokud ji nepoužíváme, měli bychom tuto možnost zakázat. Vypnutím této možnosti se však nezlepší zabezpečení, pokud má uživatel přístup k shellu, v takovém případě si může nastavit své vlastní forwardery (jak je uvedeno v sshd_config(5) manuálová stránka).
ClientAliveCountMax
ClientAliveCountMax a ClientAliveInterval jsou dvě související možnosti. Maximální počet, vynásobený intervalem aktivního klienta v sekundách, určuje, kdy připojení přestane reagovat. Nechápu, jak by to ovlivnilo bezpečnost. Možná budu muset udělat další průzkum. Snížení hodnoty by však nemělo bolet.
Komprese
SSH nám umožňuje komprimovat data odeslaná po ověření prostřednictvím této možnosti. Na pomalých modemech může komprese zvýšit rychlost připojení. Na většině moderních systémů by to však nemělo mít žádný vliv. Kromě toho nás může také seznámit s útoky BREACH, jak je uvedeno v tomto komentáři na GitHubu. Vezměme si proto lynis' návrh.
Úroveň protokolu
sshd zaznamenává zprávy do journald ve výchozím nastavení na většině distribucí GNU/Linux. Tato možnost řídí úroveň podrobností, které mají být protokolovány. lynis doporučuje nastavit toto z INFO na VERBOSE, což může pomoci při odstraňování problémů atd. Manuální stránka sshd_config(5) upozorňuje však, že nastavení na vyšší úroveň (např. DEBUG) může narušit soukromí jejích uživatelů. Takže opravdu nevidím žádné zlepšení zabezpečení vyladěním tohoto nastavení.
MaxAuthTries
Tato hodnota určuje, kolik pokusů o ověření povolit na jedno připojení. Navíc, když selhání pokusu o připojení dosáhnou poloviny této hodnoty, pak sshd zahájí protokolování poruch. Proto má smysl tuto hodnotu snížit.
MaxSessions
Hodnota této možnosti určuje, kolik relací shellu má být povoleno na připojení. Nemyslím si, že by bylo potřeba ssh na jeden server několikrát najednou. Navíc je zde také tmux což nám umožňuje provádět multiplexování, které chceme, aniž bychom museli otevírat více relací. Takže má smysl přijmout tento návrh.
Port
Můj výklad tohoto návrhu je, že bychom měli nastavit sshd naslouchací port na nějakou jinou hodnotu. To se ukáže jako užitečné při obraně proti většině botnetů, které skenují internet a hledají zranitelné stroje na výchozích portech. Nicméně každý, kdo zná základy mapování sítě (nástroje jako nmap ) bude vědět, že to nepomůže. Nicméně nastavme ji na jinou než výchozí hodnotu.
TCPKeepAlive
Nastavení této možnosti na ANO pomůže serveru upozornit na výpadek připojení. Tímto způsobem relace na serveru nevisí donekonečna. Proto si myslím, že je lepší tuto možnost nevypínat.
Přesměrování X11
Ačkoli většina ssh relace mají být založeny pouze na textu. Openssh však také poskytuje funkci pro otevírání GUI aplikací na serveru, které se zobrazí na klientovi. Funguje to tak, že X server otevře kanál zpět klientovi. Problém je v tom, že X11 nebyl nikdy navržen s ohledem na bezpečnost. Předpokládá, že všechny programy jsou důvěryhodné od doby, kdy je spustili my. Ale jak tato odpověď ukazuje, s X11Forwarding může server ovládat klienta, a tak být schopen provádět příkazy shellu na klientovi. Takže raději tuto funkci zapněte, pokud ji nepotřebujeme.
Závěr
Bezpečnost je jako vždy velmi složité téma. Nemůžeme vždy vědět, kdy je systém bezpečný. Kromě toho je zdání zabezpečení ještě horší než žádné zabezpečení.
V tomto článku jsem prošel různými konfiguracemi včetně těch velmi malých detailů, které by mohly pomoci zlepšit zabezpečení našeho ssh serveru. Ale jako vždy zpevněte svůj systém podle vašeho modelu ohrožení.
Takže víte o Hardening SSH Configuration