Po drátě 6: Řešení úlohy č. 16

Další z experimentů letošního ročníku. Proč bychom účastníkům simulovali virtuální počítač, když jim můžeme poskytnout rovnou celou virtuální síť? Tentokrát trochu složitější, než byla ta v loňské traceroutové úloze. Vypadala takto:

Pomocí SSH jste byli připojeni ke stroji auckland.pd, kde běžel DHCP server, ochotný přidělit vám IP adresu v síti 10.10.0.0/24 a nabídnout se jako router a nameserver pro zbytek privátní sítě. Heslo měl vydat stroj eiger.pd, ale sveřepě to odmítal, že prý 403 forbidden.

Pár pokusů s traceroutem odhalilo alespoň část topologie sítě, ale nikde žádná indicie o tom, jak se dostat k heslu. Koho ale napadlo zeptat se webového serveru na .htaccess (přeci jenom, hrdě se hlásil ke kmeni apachů), dozvěděl se, že hesla se vydávají pouze klientům ze sítě 172.16.0.0/16.

Pokud si adresu z tohoto rozsahu přidělíme, nepingneme si ani na Auckland, natožpak na Eigera. Není divu: nikdo v síti totiž neví, že má odpověď na náš ping routovat k nám. Místo toho ji routují na Dakar, kde jsou packety vraceny jako nedoručitelné.

Pomůže ovšem všimnout si, že Auckland do VPNky co 10 sekund vysílá hello packety od routovacího protokolu OSPF, nota bene naprosto nezabezpečeného. Pokud si na svém stroji také zprovozníme OSPF router, nic nám nezabrání, abychom do světa vysílali naši vlastní routu do sítě 172.16.0.0/16, ať už s nižší metrikou, nebo prostě jenom nějakou specifičtější podsíť.

Pak už si Eiger dal říci a vydal heslo cumulonimbus.

Dodejme ještě, že .htaccess nebylo potřeba objevit. Po OSPF jste se totiž mohli dozvědět kompletní topologii sítě včetně existence externí routy do podezřelé sítě 172.16.0.0/16.

Zajímavosti

S vytvářením úlohy jsme si užili spoustu legrace. Původní nápad použít některý z existujících simulátorů sítí se po nárazu na realitu přetvořil na nápad napsat si vlastní simulátor. Pak se ale naštěstí zjistilo, že podpora containerů v jádru Linuxu za posledních pár let dostatečně vyspěla, takže už není problém si uvnitř jednoho jádra pořídit několik samostatných TCP/IP stacků a propojit je virtuálními ethernety. Debugování ovšem bylo dobrodružné.

Za implementaci OSPF vděčíme projektu BIRD. Jestlipak jste ho někdo k řešení použili?

Někdo si s úlohou natolik nevěděl rady, že se pokoušel obcházet všechny stroje, scanovat na nich porty a hledat bezpečnostní díry. Ale uznejte, úloha na crackování tu už byla a jedna v ročníku stačí. Jen za ty statisíce packetů od nmapu jsme nebyli moc vděční. Na zátěži serveru se to sice skoro nepoznalo, ale pravidla to zakazují a navíc, kdo má pak ty logy číst? :-)

Nápad na úlohu je prastarý a pravděpodobně pochází od Vojty Pavlíka. Tehdy jsme ho ovšem zamítli jako nerealizovatelný. Medvěd na to nicméně zapomněl a zrealizoval ho.

Re: Po drátě 6: Řešení úlohy č. 16 Tomáš Janoušek (25. 1. 2012 - 13:16) Sbalit(1)
Já BIRD použil. Rozcházet si u sebe dočasně quaggu se mi opravdu ani trošičku nechtělo, byť jsem s ní narozdíl od BIRDu už uměl. :-)
Re: Po drátě 6: Řešení úlohy č. 16 playeeer1 (25. 1. 2012 - 14:30) Sbalit(2)
Taky jsem pouzil BIRD, ale az po marnem pokusu o rozjeti quaggy :).
Re: Po drátě 6: Řešení úlohy č. 16 Michal Kubeček (25. 1. 2012 - 16:05) Sbalit(1)
Já s quaggou neměl problém, tedy kromě toho, že jsem do konfigurace
ospfd zapomněl napsat síť 10.10.0.0/24 a pak jsem strávil hodinu
zjišťováním, proč mi zarputile ignoruje přicházející Hello pakety...