Hlavní navigace

Ramond: past na falešné IPv6 směrovače

31. 10. 2013
Doba čtení: 6 minut

Sdílet

Jedním z problémů protokolu IPv6 v lokálních sítích jsou falešná ohlášení IPv6 směrovačů. Protože je nový protokol připraven na rychlou automatickou konfiguraci, je možné celou konfiguraci sítě změnit jediným nesprávným paketem. Program Ramond představuje jednoduchý způsob, jak problém obcházet.

Problém máte, i když IPv6 nemáte

Možná si po přečtení perexu říkáte, že se vás problém netýká, protože IPv6 jednoduše ve své síti nepodporujete. Jenže tak to není. Stačí, pokud je vaše síť schopná transportovat IPv6 pakety a zároveň umožňuje všesměrové šíření paketů (broadcast), což jsou společné vlastnosti většiny počítačových sítí. Pokud se v takové síti z jakéhokoli důvodu objeví ohláška IPv6 směrovače (RA), všechna zařízení v síti, která IPv6 podporují, podle ní nakonfigurují směrování. Protože je standardně IPv6 preferováno před IPv4, budou zařízení nově získanou IPv6 konektivitu používat, kdykoli to bude možné.

Důsledek takového stavu záleží na konkrétním obsahu přijaté ohlášky. Půjde-li o útočníka, bude ohlášený směrovač plně funkční a jeho snahou bude provést na datech, která tímto směrovačem projdou, aktivní odposlech (útok typu Man-in-the-Middle). Nebo může jít o DoS útok, kdy bude ohlašována cesta k nefunkčnímu směrovači, takže zařízení bez podpory Happy Eyeballs projeví poměrně nepříjemné zdržení. O těchto problémech a možných řešeních pojednává informativní RFC 6104: Rogue IPv6 Router Advertisement Problem Statement.

Jde o klasickou zranitelnost spojové vrstvy

Příčina popsaných problémů není ani nová, ani specifická pro IPv6. Už od dob, co se pro automatickou konfiguraci IPv4 začal používat protokol DHCP se tu a tam objeví falešný DHCP server, soupeřící s tím pravým o právo přidělovat adresy, který dokáže velmi solidně zkomplikovat funkčnost IPv4 protokolu. Stejně tak útočníci už spoustu let znají útok zvaný otrávení ARP cache. Zkrátka, dokud nenajdeme způsob, jak na úrovni spojové vrstvy autentizovat data, je třeba s podobnými problémy počítat.

Ochranná opatření v hardwaru

Spoustu známých zranitelností je možné vyřešit na úrovni hardwaru. Většina ethernetových přepínačů vyšší třídy například obsahuje funckionalitu zvanou DHCP snooping. Ta umožňuje nastavit, ze kterých fyzických rozhraní mohou do sítě pronikat DHCP odpovědi, takže i když je v síti spuštěn falešný DHCP server, nedokáže síť rozbít. Pro nezvané IPv6 směrovače se v posledních letech objevuje na podobném principu fungující RA Guard.

Všechny tyto funkce ale zároveň představují porušení vrstvového modelu sítě, kdy zařízení pracující na spojové vrstvě rozhoduje o osudu rámce nejen na základě dat spojové vrsty, ale je nuceno nahlížet i do vyšších vrstev. To obvykle také znamená, že takovéto rozhodování není prováděno ve vyhrazeném hardwaru, ale v řídicím počítači (control plane) přepínače. To má zase negativní vliv na rychlost. Může se tak snadno stát, že zatímco běžná propustnost přepínače dosahuje desítek i stovek gigabitů za sekundu, dokáže zařízení zahltit podezřelý provoz o mnohem menší velikosti.

Opatření organizačního charakteru

Zranitelnost spojové vrstvy je také možné eliminovat jednoduše tak, že nedopustíme, aby jedna spojová vrstva propojovala více nezávislých subjektů, které by si tak mohly navzájem škodit. Takže každý uživatel má svůj samostatný segment, ve kterém je kromě jeho vlastních zařízení už jen jedno rozhraní směrovače. Případný nežádoucí provoz na spojové vrstvě tak uškodí pouze tomu, kdo takový provoz sám generuje.

Už z popisu takového opatření je ale jasné, že není pro všechny. Kromě vyšších nároků na výkon směrovače bude také problém v IPv4 adresování. Při použití běžného postupu každý segment spotřebuje nejméně čtyři adresy, což si v době vyčerpaných zásob IPv4 adres jistě kdekdo nebude moci dovolit. A pak jsou tu třeba veřejné bezdrátové sítě, kde je takové oddělení spojových vrstev v podstatě nemožné.

Protiútok nástrojem ramond

Není-li žádné dříve popsané opatření k dispozici, zbývá vyrazit do protiútoku. Právě k tomu slouží program ramond. Poslouchá na lince ICMPv6 zprávy s ohlášením směrovače a když nějakou přijme, provede předem nakonfigruovanou akci. Tou může být odeslání stejné ohlášky, ovšem s dobou životnosti nastavenou na nulu. Tím je účinek útočníkovy ohlášky eliminován. Zároveň je možné spustit externí program, který incident zaloguje, či se jinak pokusí útočníka zneškodnit.

Ramond je k dispozici v repozitářích Debianu Wheezy, lze jej ale i snadno zkompilovat ručně. Do serveru, na kterém poběží je potřeba svést provoz všech síťových segmentů, které má hlídat. Protože se RA šíří multicastem všem stanicím, není třeba na rozhraních konfigurovat žádné IP adresy ani zapínat promiskuitní režim. Je ale nanejvýš vhodné na všech rozhraních vypnout příjem RA v jádře, aby přijatá RA neměnila síťovou konfiguraci. To provedeme pomocí následující volby, kterou můžeme pro každé rozhraní vložit do souboru  /etc/sysctl.conf:

net.ipv6.conf.ethX.accept_ra = 0 

Pak už stačí jen nastavit konfigurační soubor. Obvykle stačí upravit vzorovou konfiguraci, například takto:

root_podpora

<?xml version="1.0" encoding="ISO-8859-15"?>
<!DOCTYPE ramond SYSTEM "ramond.conf.dtd">
<ramond>
 <mac-list name="auth_routers">
  <entry>00:11:22:33:44:55</entry>
  <entry>00:11:22:33:44:56</entry>
 </mac-list>

 <!-- do nothing on our prefixes from our routers -->
 <rule interface="eth0" mac="auth_routers" prefix="2001:db8:1::/64"></rule>
 <rule interface="eth1" mac="auth_routers" prefix="2001:db8:2::/64"></rule>

 <rule prefix="2001:db8:1::/64">
  <execute>/usr/local/bin/ramondaction.sh Prefix-1-from-unexpected-location</execute>
 </rule>
 <rule prefix="2001:db8:2::/64">
  <execute>/usr/local/bin/ramondaction.sh Prefix-2-from-unexpected-location</execute>
 </rule>

 <!-- Automatically clear 6to4 prefixes -->
 <rule prefix="2002::/16">
  <execute>/usr/local/bin/ramondaction.sh 6to4-advertised</execute>
  <clear/>
 </rule>

 <!-- Unknown prefix action -->
 <rule>
  <execute>/usr/local/bin/ramondaction.sh unknown-prefix</execute>
 </rule>
</ramond> 

Jednotlivá pravidla konfiguračního souboru jsou procházena postupně, při nalezení první shody je provedena akce a další pravidla se nevyhodnocují. Výše uvedený příklad konfigurace představuje méně přísnou variantu konfigurace, která anomální provoz pouze předává speciálnímu skriptu. Jedinou výjimkou jsou prefixy automatických tunelů 6to4, které jsou příkazem <clear/> automaticky anulovány. Skript ramondaction.sh zajišťuje logování anomálií, včetně e-mailových upozornění administrátora. Je důležité upozornit, že skript je spuštěn po každém přijatém RA a musí se sám postarat o limitování opakujících se hlášení. Já jsem skript řešil takto:

#!/bin/sh

LOGFILE="/var/tmp/ramond.log"
msg="$1 prefix: ${PREFIX}/${PREFIX_LEN}, source: ${SOURCE_ADDR} (${SOURCE_MAC}), iface: ${INTERFACE}"

if [ ! -f "${LOGFILE}" ] || ! grep -q "^${msg}" "${LOGFILE}"; then
    echo "${msg}" >> /var/tmp/ramond.log
    logger RAmond $msg
    sendmail root <<-EOF
    From: RAmond <root@localhost>
    To: Root <root@localhost>
    Subject: RAmond alert on VMservice

    ${msg}
    EOF
fi 

Užitečný doplněk, nejen kvůli Windows

Vůbec nejčastějším falešným směrovačem je nesprávně nakonfigurovaná stanice s Windows, která se chová jako 6to4 brána. I když se proslýchá, že některá z nedávných aktualizací Windows tento problém odstranila, stejně se vyplatí ramond nasadit na všechny sítě, které jsou aspoň trochu veřejné. A vůbec nezáleží na tom, co si o IPv6 myslíte, či jestli IPv6 sami poskytujete. Je ale třeba zdůraznit, že jde jen o doplňkovou ochranu, reagující na jeden konkrétní nešvar zranitelné spojové vrstvy. Stále existuje spousta dalších zranitelností spojové vrstvy, které ramond vyřešit neumí a které v nesprávných rukou dokážou způsobit velké problémy.

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ě.