Pokyny pro snížení expozice

Vytvoření bezpečné infrastruktury je náročný úkol, který vyžaduje značné množství času a zdrojů. Před implementací jakéhokoli rozhodnutí a mechanismu je nutné pečlivě zvážit poměr nákladů a přínosů. Tento guide poskytuje doporučení ohledně: které vlastnosti infrastruktury je třeba upřednostnit při snižování rizik; příliš teoretického přístupu k optimalizaci těchto vlastností a nakonec dvou technických opatření k řešení části dané situace.

29. 9. 2025 Ádám Ruman Správci IT

Vytvoření bezpečné infrastruktury je náročný úkol, který vyžaduje značné množství času a zdrojů. Před implementací jakéhokoli rozhodnutí nebo mechanismu je nutné pečlivě zvážit poměr nákladů a přínosů. Tento guide poskytuje doporučení ohledně: vlastností infrastruktury, na které je třeba se primárně zaměřit za účelem snížení rizika; příliš teoretického přístupu k optimalizaci těchto vlastností a nakonec dvou technických opatření k řešení části dané situace.

Priorita #1: Expozice infrastruktury a její optimalizace v teorii

❓ Vymysleli jsme si právě novou terminologii?

🗣️ Možná... 🤷‍♂️

I když možná nejste obeznámeni s pojmem Expozice, termín útočný povrch vám pravděpodobně není cizí. Pokud nyní izolujete sociální, psychologické a lidské aspekty útočné plochy, zůstane vám čistě technická podmnožina, což je přesně to, co znamená expozice infrastruktury.

Proč bych se měl zajímat o expozici?

❓ Dokážete vymyslet nepsané pravidlo kybernetické bezpečnosti?

🗣️ Jakýkoli majetek, ke kterému mají přístup zlovolné entity, bude (dříve či později) napaden.

Jinými slovy, pokud je něco vystaveno, stane se terčem útočníka. Co to znamená při navrhování bezpečné infrastruktury?

Mechanismus s vysokým poměrem hodnoty a nákladů pro zabezpečení vaší infrastruktury snižuje její vystavení riziku.
O vystavení hrozbám je třeba uvažovat multidimenzionálně a zohlednit různé kontaktní plochy vaší infrastruktury a zařízení.
Nezapomeňte na použitelnost. Příliš přísná omezení vystavení hrozbám začnou narušovat její správné fungování. (Vždy zohledňujte důvěrnost, integritu a dostupnost jako jeden celek.)

🥜 Omezení expozice ve zkratce znamená: zpřístupnění pouze klíčových fragmentů infrastruktury na správných kontaktních plochách, s řádnou správou; zároveň je nutné dbát na to, aby přístup k těmto fragmentům nebyl pro oprávněné strany příliš složitý.

Kontaktní plochy

Kontaktní plochy lze definovat pro jednotlivá zařízení a služby, ale nejčastěji je lze zobecnit na stroje s podobnými „úkoly“. Definování kontaktních ploch znamená definování vnějších skupin entit, uvnitř kterých mají všechny entity stejnou sadu atributů.
Prvním atributem, který je třeba zvážit, je potřeba dosahu: zda by entita měla být schopna komunikovat se strojem. Tento atribut rozděluje všechny entity do dvou skupin: požadované a nežádoucí.

Při výběru entit, které by měly být požadovány, dodržujte pravidla minimálních oprávnění a zásady potřeby vědět.

The entities must be further attributed with trust: entities are either untrusted or slightly-trusted. Untrusted entities are those which we do not know anything about, while slightly trusted are either part of the intranet (including those that can connect via VPN), owned or used by an authorized personnel, ...

Subjektům musí být dále přiřazena důvěryhodnost: subjekty jsou buď untrusted (nedůvěryhodné), nebo slightly-trusted (mírně důvěryhodné). Nedůvěryhodné subjekty jsou ty, o kterých nic nevíme, zatímco mírně důvěryhodné jsou buď součástí intranetu (včetně těch, které se mohou připojit přes VPN), vlastněné nebo používané oprávněným personálem, ...

Při navrhování atributu důvěry dodržujte pokud možno pravidla Zero Trust.

Na základě těchto atributů vznikají různé technické možnosti zabezpečení kontaktních ploch, alespoň teoreticky. Nežádoucí entity by měly být izolovány od subjektů v síti, zatímco diferenciace založená na důvěře by měla být prováděna v rámci služby.

Kontaktní plochy vám mohou pomoci stanovit priority úkolů v oblasti omezení expozice.

Expozice v praxi

Zatímco v teorii jsou volitelné mechanismy omezení expozice jednoduché, v praxi dynamická povaha a složitost sítí a infrastruktury tento proces „komplikují“. Síťová zařízení a firewally nemají dostatečný výpočetní výkon, aby udržovaly samostatné sady pravidel pro každou kontaktní plochu. Proto by stroje, které mají podobné kontaktní plochy, měly být umístěny do podsítí, aby bylo možné kontaktní plochy alespoň částečně zabezpečit na hranicích podsítí.

Kontaktní plocha pro nežádoucí a nedůvěryhodné entity se u většiny strojů překrývá, nebo spíše je dobré ji spravovat na okraji infrastruktury pomocí dosažitelnosti sítě =~ firewally. Obecně je vhodné zakázat jakoukoli dosažitelnost na této ploše a v případě potřeby použít výjimky. Pro univerzitu jsme sestavili následující seznam významných výjimek s příklady použití:

Možné nedůvěryhodné přístupy stroje MISSION

Port	Protokol	Přijatelné důvody pro výjimky
25	SMTP	Stroj je vyhrazený poštovní server.
53	DNS	Stroj je vyhrazený DNS server.
80	HTTP	Stroj je vyhrazený webový server a migrace na HTTPS není možná.
110	POP3	Stroj je vyhrazený poštovní server.
123	NTP	Stroj je vyhrazený NTP server, který poskytuje službu i externím zákazníkům.
143	IMAP	Stroj je vyhrazený poštovní server.
165	SMTP over SSL	Stroj je vyhrazený poštovní server.
179	BGP	Machine is a BGP AS perimeter router.
209	qmail	Stroj je vyhrazený poštovní server.
220	IMAP	Stroj je vyhrazený poštovní server.
443	HTTPS	Jde o dedikovaný webserver. Jde o dedikovaný VPN koncentrátor.
500	IKE	Jde o síťové zařízení nebo vyhrazený koncentrátor VPN.
853	Secure DNS	Stroj je vyhrazený doménový server.
993	IMAP-S	Stroj je vyhrazený poštovní server.
995	POP3-S	Stroj je vyhrazený poštovní server.
1194	OpenVPN over UDP	Stroj je vyhrazený koncentrátor VPN.

Pro ostatní kontaktní plochy je možným řešením správa prostřednictvím dostupnosti sítě. Pokud se mnoho kontaktních ploch překrývá, mohou být k dispozici agregace přes stroje a entity do (virtuálních) podsítí. Vytvoření těchto podsítí a agregace je zdlouhavá práce a do značné míry závisí na využití a návrhu infrastruktury. Proto zde nebudeme poskytovat žádné obecné rady.

V případech, kdy selže správa prostřednictvím dosažitelnosti sítě mezi podsítěmi, musíme se podívat na samotné stroje a služby. Existuje příliš mnoho služeb, které vám pomohou zabezpečit je všechny, proto jsme vybrali protokol SSH (jako nejčastěji používaný zástupce ve službách vzdálené správy), na kterém vám ukážeme některé obecné zásady a některé konfigurace specifické pro protokol, aby byl co nejbezpečnější.

Snížení expozice a zabezpečení SSH

V závislosti na konkrétním stavu a potřebách může být snížení expozice pro SSH pro každou infrastrukturu odlišným procesem, existují však společné body pro mnoho z nich:

Pokud není nutné, aby k SSH měl na stroji přístup kdokoli, mělo by být zakázáno.
Pokud lze požadované entity snadno agregovat do několika podsítí, měly by být nastaveny síťové nebo hostitelské brány firewall.
Nakonfigurujte SSH bezpečným způsobem, který odolá úmyslným útokům ze strany vnitřních hrozeb nebo kompromitovaných subjektů s mírnou důvěryhodností. Postupujte podle doporučeného úvodu do konfigurace SSHD (viz rozbalovací box níže).
Použijte schéma ověřování SSH k řízení kontaktní plochy prostřednictvím uživatelů a kryptografie veřejných klíčů.
U velmi složitých nebo rozsáhlých sítí implementujte princip bastionové bezpečnosti.

Doporučení pro konfiguraci SSHD

Úvod do konfigurace SSHD.

Pravidlo	Konfigurační položka	Pravidlo položky (Ruby)	Bezpečnostní zdůvodnění
Konfigurace sshd musí být umístěna v očekávané cestě /etc/ssh/sshd_config.	-	-	Umístění konfigurace na očekávaném místě usnadňuje audit.
Konfigurace sshd musí být vlastněna uživatelem root:root a mít přístupová práva rw-r--r-- nebo přísnější.	-	-	Uživatelé nesmí upravovat konfiguraci sshd. Čtení je u bezpečných konfigurací v pořádku.
Soukromé hostitelské klíče SSH musí být v očekávaných umístěních /etc/ssh/ssh_host_<type>*key.	-	-	Auditovatelnost.
Soukromé hostitelské klíče SSH musí být vlastněny root:root a mít přístupový režim rw-------.	-	-	Soukromé klíče musí být chráněny z hlediska integrity a důvěrnosti.
Veřejné hostitelské klíče SSH musí být v očekávaných umístěních /etc/ssh/ssh_host*<type>_key.pub	-	-	Auditovatelnost.
Soukromé hostitelské klíče SSH musí být vlastněny root:root a mít přístupový režim rw-r--r--.	-	-	Veřejné klíče musí být chráněny z hlediska integrity.
Zakázat následující slabé šifrovací režimy: 3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc.	Ciphers	!~/cbc/	Tyto sady šifer jsou považovány za prolomitelné útočníkem.
Zakázat následující slabé algoritmy výměny klíčů: diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1.	KexAlgorithms	!~/sha1/	Tyto algoritmy výměny klíčů jsou považovány za prolomitelné útočníkem.
Zakázat následující slabé MAC algoritmy: hmac-md5, hmac-md5-96, hmac-sha1, hmac-sha1-96, umac-64@openssh.com, hmac-md5-etm@openssh.com, hmac-md5-96-etm@openssh.com, hmac-sha1-96-etm@openssh.com, umac-64-etm@openssh.com, umac-128-etm@openssh.com.	MACs	!~/umac\|sha1\|md5/	Nedostatečná délka; útočník může zlomit MAC a provést MITM.
Přístup přes SSH je omezen whitelisty.	AllowUsers \| AllowGroups	not nil && != '*'	Pouze uživatelé, kteří potřebují přístup přes SSH, by jej měli mít. Whitelisty jsou méně náchylné k chybám v konfiguraci.
Používejte vhodné SSH bannery.	Banner	not nil	Banner by měl obsahovat zásady organizace a název hostitele.
Omezit klientská připojení.	ClientAliveInterval	in (1..600)	Interval, po kterém se při neaktivitě klienta posílají keepalive požadavky; pomáhá zmírnit vyčerpání prostředků.
Omezit klientská připojení.	ClientAliveCountMax	in (1..5)	Maximální počet keepalive požadavků před odpojením klienta; zmírňuje vyčerpání prostředků.
Omezit možnosti přesměrování (forwarding).	DisablePortForwarding	== 'yes'	Omezuje zneužití SSH pro skrývání komunikace útočníka.
Omezit metody autentizace.	GSSAPIAuthentication	== 'no'	Snižuje útočný povrch.
Omezit metody autentizace.	HostBasedAuthentication	== 'no'	Snižuje útočný povrch.
Nepoužívat .rhosts.	IgnoreRhosts	== 'yes'	Snižuje útočný povrch; vynutí zadání hesla i z „důvěryhodných“ hostů.
Omezit neúspěšná přihlášení.	LoginGraceTime	== 60	Minimalizuje riziko útoků hrubou silou.
Nastavit vhodnou úroveň logování.	LogLevel	=~/VERBOSE\|INFO/	Pomáhá při vyšetřování incidentů.
Omezit počet neúspěšných pokusů o přihlášení na jedno spojení.	MaxAuthTries	<= 4	Minimalizuje riziko útoků hrubou silou.
Omezit čekající požadavky na autentizaci.	MaxStartups	== '10:30:60'	Zmírňuje útoky na vyčerpání prostředků.
Omezit souběžné relace.	MaxSessions	<= 10	Zmírňuje útoky na vyčerpání prostředků.
Neumožnit prázdná hesla.	PermitEmptyPasswords	== 'no'	Snižuje riziko neoprávněného přístupu.
Zakázat přihlášení účtu root přes SSH.	PermitRootLogin	== 'no'	Ztěžuje útoky hrubou silou a zlepšuje nepopiratelnost.
Zakázat změny uživatelského prostředí v SSH relacích.	PermitUserEnvironment	== 'no'	Zmírňuje obcházení bezpečnostních kontrol.
Používat PAM modul.	UsePAM	== 'yes'	Umožňuje kontroly účtu a relace; zásadní, pokud je povolena heslová či challenge-response autentizace.
Používat moderní verzi protokolu.	Protocol	== 2	Tato verze poskytuje lepší bezpečnostní primitiva.
Používat strict mode.	StrictMode	== 'yes'	Brání používání nezabezpečených domovských adresářů a oprávnění klíčů.
Propojit se syslogem.	SyslogFacility	== 'AUTH'	Předává údaje o přihlášeních do auth.log.
Omezit hostitelské klíče na výchozí.	HostKey	== %w[/etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_ed25519_key]	Chrání proti útokům typu man-in-the-middle.
Omezit metody autentizace (UseLogin).	UseLogin	== 'no'	Jedná se o zastaralou metodu.
Používat oddělení privilegií.	UsePrivilegeSeparation	== 'yes'	Spouští SSH relace v omezeném podprocesu.
Ignorovat soubory known_hosts uživatelů.	IgnoreUserKnownHosts	== 'yes'	Slabý způsob autentizace.
Používat autentizaci veřejným klíčem.	PubkeyAuthentication	== 'yes'	Spoléhejte na bezpečnější metodu autentizace.
Omezit metody autentizace (hesla).	PasswordAuthentication	== 'no'	Nepovolujte standardní heslovou autentizaci.
Omezit metody autentizace (challenge-response).	ChallengeResponseAuthentication	== 'no'	Zakázat, protože je založená na heslech.
Omezit metody autentizace (Kerberos).	KerberosAuthentication	== 'no'	Považováno za méně bezpečné než publickey.
Po odhlášení automaticky mazat cache lístků Kerberos.	KerberosTicketCleanup	== 'yes'	Omezuje expozici přihlašovacích údajů.
Po odhlášení automaticky mazat GSSAPI cache.	GSSAPICleanupCredentials	== 'yes'	Omezuje expozici přihlašovacích údajů.
Nepoužívat TCP keepalive.	TCPKeepAlive	== 'no'	Tyto zprávy jsou nešifrované a podvržitelné; používejte šifrované keepalive požadavky.
Neumožňovat plnohodnotné tunely přes SSH.	PermitTunnel	== 'no'	Tunelování by mělo být realizováno specializovaným softwarem.
Zakázat TCP forwarding.	AllowTcpForwarding	== 'no'	Mohl by umožnit obcházení firewallu.
Zakázat agent forwarding.	AllowAgentForwarding	== 'no'	Umožňuje převzetí identity útočníkem.
Neumožnit hostitelům připojení na přesměrované porty.	GatewayPort	== 'no'	Reverse tunelování by nemělo být povoleno.
Zakázat X11 forwarding.	X11Forwarding	== 'no'	Snižuje útočný povrch.
Pro X11 používat localhost.	X11UseLocalhost	== 'yes'	Snižuje útočný povrch.
Nepoužívat MOTD (Message of the Day).	PrintMotd	== 'no'	Nečíst a netisknout z potenciálně kompromitovaného souboru.
Nezobrazovat údaje o posledním přihlášení.	PrintLastLog	== 'no'	Zbytečné zveřejnění informací.
Používat RSA hostitelské klíče o správné délce (4096 bitů).	-	-	Menší modulo RSA je náchylnější k útokům.
Nezajišťovat přepis sshd_config parametry na příkazové řádce.	ps aux \| grep '.*sshd -D'	!~/-oCiphers\|-oKexAlgorithms\|-oHostKeyAlgorithms/
Zajistit, aby /root/.ssh/known_hosts bylo prázdné.	-	-	Kontrolovat pravidelně; uživatel root by se neměl přihlašovat na jiné servery.
Zajistit, aby /root/.ssh/authorized_keys bylo prázdné.	-	-	Další vrstva zajištění „žádný root přes SSH“.
Zajistit, že sshd běží na portu 22.	Port	== 22	Auditovatelnost; lepší spolupráce s ochrannými mechanismy síťových prvků.

❗K dispozici pouze ve verzích starších než 7.5.

Bastion

Princip bastionu znamená umístění zprostředkujícího vstupního bodu do infrastruktury, který zpracovává správu více kontaktních ploch pro všechny stroje poskytující stejnou službu. Poté je dosažitelnost mezi stroji a bastionem a mezi bastionem a vnějšími entitami. Tímto způsobem bastion agreguje všechny stroje pod jednou IP adresou a může agregovat požadované entity pro všechny chráněné stroje.

Bastiony se obvykle skládají z clusteru serverů pro zajištění dostupnosti, ale pro zúčastněné strany se jeví jako jediný proxy bod.

Další kontaktní plochy jsou pak spravovány prostřednictvím samotného bastion hostitele, a to centralizovaným způsobem. Poskytuje rozhraní pro autentizaci a autorizaci, které může být nezávislé na síťových identifikátorech, může podporovat řízení přístupu na základě rolí (RBAC) a agregovat externí entity odpovídajících kontaktních ploch do skupin. Kromě toho poskytuje rozsáhlé možnosti účtování.

Implementace bastionů je křehký a zdlouhavý proces. Naštěstí existují některá hotová řešení, jako například open-source Bastion od OVH, částečný open-source teleport od Gravitational nebo HashiCorp Boundary.

Tento výsledek byl podpořen projektem SOCCER, financovaným na základě grantové dohody č. 101128073, s podporou Evropského centra kompetencí pro kybernetickou bezpečnost (ECCC).