Hlavní navigace

Stavíme tunely v OpenSSH

8. 6. 2011
Doba čtení: 5 minut

Sdílet

V minulém díle našeho seriálu o zajímavých vlastnostech OpenSSH jsme si představili způsob, jak se snadno přihlašovat ke vzdáleným serverům bez nutnosti vypisovat pokaždé heslo. Dnes se společně podíváme na to, jak je možné pomocí OpenSSH stavět bezpečné tunely pro libovolné síťové protokoly.

Přesměrování agenta

Použití SSH agenta, které jsme si ukázali v minulém díle, v sobě skrývá ještě jednu zajímavou vlastnost. Vzhledem k tomu, že veškerá komunikace s ním probíhá přes jeden UNIXový soket, není problém tento soket samotným protokolem SSH tunelovat a nosit si ho s sebou, zatímco cestujeme mezi servery. Tato funkce se zapíná parametrem -A příkazu ssh. SSH server vytvoří na vzdálené straně soket s příslušnými právy a veškerý provoz z a do tohoto soketu přenese přes SSH spojení na klienta, který jej nasměruje do soketu skutečného agenta. Server také správně nastaví proměnnou SSH_AUTH_SOCK, takže z pohledu uživatele je přesměrovaný agent zcela shodný s lokálně běžícím agentem. Protože soket slouží nejen k podepisování, ale i pro ukládání klíčů, můžeme dokonce do svého lokálního agenta přidat vzdálený klíč:

user@stanice:$ ssh-add -l
1024 ab:9e:90:46:b9:fd:94:ae:fd:51:9c:cb:d1:fa:34:29 /home/user/.ssh/id_dsa (DSA)
user@stanice:$ ssh -A server.example.com
user@server:$ ssh-add -l
1024 ab:9e:90:46:b9:fd:94:ae:fd:51:9c:cb:d1:fa:34:29 /home/user/.ssh/id_dsa (DSA)
user@server:$ ssh-add
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
user@server:$ logout
Connection to server.example.com closed.
user@stanice:$ ssh-add -l
1024 ab:9e:90:46:b9:fd:94:ae:fd:51:9c:cb:d1:fa:34:29 /home/user/.ssh/id_dsa (DSA)
2048 50:b2:f0:44:c9:10:f2:0b:f6:00:38:0c:b1:cd:e7:35 /home/user/.ssh/id_rsa (RSA)

Povšimněte si, že v lokálním agentovi máme nyní uložené dva klíče a to i přesto, že spojení k serveru, na kterém je uložen druhý klíč, bylo už dávno přerušeno.

Funkce přesměrování agenta je z bezpečnostních důvodů ve výchozím nastavení vypnuta. Vzhledem k tomu, že ssh-agent promptně podepíše cokoli komukoli s právem pro zápis do příslušného soketu, znamená to, že uživatel root může kdykoli zneužit SSH agenta kteréhokoli lokálního uživatele. Při přesměrování agenta to samé platí o superuživatelích vzdálených serverů. Přesměrování bychom tedy měli používat jen na stroje, u kterých máme důvěru k jejich správci.

Tunelování protokolu X11

Úplně stejný princip funguje při tunelování protokolu X11, pomocí kterého je možné snadno spouštět vzdálené grafické aplikace. Slouží k tomu přepínač -X, pokud by nefungoval, můžete zkusit použít -Y. Nejprve je však potřeba povolit takové přesměrování v konfiguračním souboru serveru (/etc/ssh/sshd_c­onfig). Přesměrování protokolu X11 s sebou totiž nese poměrně značná rizika – každý X-klient obvykle může číst obsah kteréhokoli okna na obrazovce, stejně jako stisknuté klávesy a kliknutí myši. Aby to neměl případný útočník tak lehké, musí překonat několik překážek:

  • Vzdálený soket je svázán s loopback adresou 127.0.0.1. Útočící software tedy musí běžet na stejném počítači, jako SSH server. To ale není překážka, útočník může požadavky na SSH server protunelovat (třeba pomocí SSH).
  • Přístup k X serveru je chráněn autentizačním řetězcem (cookie), který je uložen v souboru ~/.Xauthority, čitelném pouze majiteli. SSH server automaticky vloží cookie do vzdáleného souboru, takže pro uživatele je přístup k X serveru přes tunel zcela transparentní. Útočník tedy musí buď nějakým způsobem vyčíst cookie ze souboru (což může jen superuživatel vzdáleného serveru), nebo spoléhat na to, že klient ochranu serveru pomocí cookie vypnul. Například spousta návodů k odstraňování problémů s X servery radí vyzkoušet příkaz xhost +, který právě tuto ochranu vyřazuje z činnosti.
  • X Server může podporovat tzv. bezpečný režim. To znamená, že přesměrovaným klientům povolí pouze omezenou množinu operací, zakáže tedy například čtení obsahu cizích oken nebo získávání úhozů kláves, které patří jinému oknu. Tento bezpečnější režim funguje dobře s dostatečně čerstvým Xorg a OpenSSH, použitím přepínače -X. Není-li však do X serveru podpora bezpečného režimu zakompilována, použití přepínače -X selže a uživateli nezbývá, než použít přepínač -Y. Při jeho použití jsou i vzdálení X-klienti považováni za důvěryhodné a bezpečný režim není použit.

Dynamické tunelování

O statickém tunelování, pomocí přepínačů -L a -R se zde na Rootu už minimálně jednou psalo. Dovolíme si tedy problematiku přeskočit a podívat se rovnou na dynamické tunelování:

$ ssh -D1080 user@server 

Tímto jednoduchým příkazem jsme z SSH klienta vyrobili SOCKS proxy server. Všechny požadavky o spojení, které SOCKS server obdrží, protuneluje SSH protokolem a vyřídí na straně SSH serveru. Stačí tedy v aplikaci, jako je webový prohlížeč nebo poštovní klient, nastavit použití SOCKS proxy serveru (verze 5 nebo 4) s adresou localhost:1080. Od té chvíle bude veškerý provoz směrován tunelem. Jak snadné.

Dynamické tunelování je možné použít i v případě, že daná aplikace nemá podporu pro SOCKS proxy. Slouží k tomu utilitka tsocks, která obaluje volání systémové funkce connect(). Nejprve nastavíme konfigurační soubor /etc/socks/tsoc­ks.conf:

# Na lokální sítě chceme přistupovat přímo
local = 192.168.0.0/255.255.0.0
local = 172.16.0.0/255.240.0.0
local = 10.0.0.0/255.0.0.0

# IP adresa, port a verze SOCKS serveru
server = 127.0.0.1
server_port = 1080
server_type = 5

#tunelování DNS dotazu SSH SOCKS serverem nefunguje
tordns_enable = no

Pak už stačí danou aplikaci spustit s prefixem tsocks, například:

$ tsocks wget http://www.whatismyipv6.net -O out.html

OpenSSH jako VPN

OpenSSH jde v tunelovacích možnostech ještě dál – nabízí možnost vytvoření plnohodnotné virtuální privátní sítě prostřednictvím univerzálních síťových rozhraní TUN/TAP. Potřebné ingredience:

  • Rootovský přístup na oba stroje.
  • Povoleno vytváření tunelu v konfiguračním souboru serveru – volba PermitTunnel.
  • Ovladač pro Universal TUN/TAP device, který je součástí jádra. O tom, že je zaveden, se přesvědčíme kontrolou existence souboru /dev/net/tun.

Jsou-li všechny podmínky splněny, nastartujeme tunel pomocí:

# ssh -w 1:1 root@server

Pokud šlo všechno dobře, objevila se na obou koncích tunelu síťová zařízení tun1, která jsou vzájemně spojena SSH tunelem. Je na nás, abychom rozhraní nahodili (ip link set dev tun1 up), nastavili příslušné IP adresy a směrování. Na vzdálené straně k tomuto účelu můžeme připravit skript, který necháme příkazem ssh spustit jednoduše tak, že jeho název napíšeme na konec příkazového řádku:

# ssh -w 1:1 root@server setuptunnel.sh

V některém z příštích dílů seriálu si ukážeme, jak takový tunel zabezpečit, aby uživatel, který jej chce navazovat, neměl zároveň možnost využívat rootovský shell na straně SSH serveru.

SSH bez shellu

Při stavění všemožných ssh tunelů se často může stát, že vlastní terminálové spojení na vzdálený počítač je nežádoucí, nadbytečné. V takovém případě s výhodou využijeme volbu -N, která zabrání spuštění shellu. Obvykle se vyplatí v kombinaci s přepínačem -f, který přenese klienta na pozadí po dokončení autentizace.

root_podpora

Chceme-li určitý tunel udržovat permanentně v provozu, může se hodit utilitka autossh, která SSH klienta hlídá a automaticky restartuje v případě potřeby.

Obsah příští části

Příště znovu otevřeme problematiku prokazování identity. Podíváme se na serverové klíče a možnosti jejich ověřování. Ukážeme si, jak k takovému účelu použít systém DNSSEC.

Byl pro vás článek přínosný?

Autor článku

Ondřej Caletka vystudoval obor Telekomunikační technika na ČVUT a dnes pracuje ve vzdělávacím oddělení RIPE NCC, mezinárodní asociaci koordinující internetové sítě.