Dlouhodobý test hardwarového firewallu RoBox - 5. díl: Testy, testy, testy

Firewally se dostávají do podvědomí uživatelů stále více - internet expanduje a ochrana počítače je nezbytná. Softwarových firewallů jsou desítky ne-li stovky, ale hardwarových? Jeden takový byl podroben testu. Jak si vedl, co lze od něj očekávat a kolik vlastně stojí?
  • 1. díl testu RoBOXu: co se vlastně skrývá v té krabičce?
  • 2. díl testu RoBoXu: zapojení, konfigurace, pro koho se hodí?
  • 3. díl testu RoBoXu: popis nejdůležitějších služeb a funkcí
  • 4. díl testu RoBoxu: jak si vede konkurence?
  • 5. díl testu RoBoXu: Testy, testy, testy
  • 6. díl testu RoBoXu: Jak to tedy vlastně nakonec dopadlo
  • Testy - Test první

    Provedl jsem dva základní testy tohoto firewallu. První spíše pro forma, který měl jen prokázat, zda v default nastavení je RoBoX opravdu neprůstřelný a zda dokáže přežít týden na otevřeném Internetu. Adresu a výzvu mi zveřejnili na několika tematických serverech (ROOT.CZ, Krypta.cz, Netem.cz a Technetu, za což jim patří dík) a tak za pomoci jejich čtenářů byl reálný provoz simulován velice věrně. Firewall podle záznamů na stroji za ním nepropustil dovnitř vůbec nic. Nezasekl se a bezpečně fungoval i po skončení testu. Takový test však opravdu nelze nijak přeceňovat a byla by obrovská ostuda, pokud by jím neprošel.

    Tento test bych přesto rozhodně nezatracoval, protože default nastavení od výrobce zůstane pro mnoho firem mnohdy i tím finálním. Asi nikdo nechce zařízení, které je po dvou dnech provozu nutné restartovat, jako je to někdy nutné u některých řešeních postavených na nejmenovaném operačním systému. Od firewallu prostě chceme určitou samozřejmou spolehlivost. Každopádně píši prošel.

    Testy - Test druhý

    Druhý test se pak již mnohem více blížil životu, tedy nastavení ve fungující firmě, která Internet aktivně využívá. Znamená to tedy, že servery má umístěné do PSN a ostatní počítače do chráněné sítě. Stroje v chráněné síti mohou volně přistupovat do Internetu i do PSN, zatímco z PSN do chráněné sítě přístup povolen není, možná s výjimkou vzdáleného logování. Z Internetu je povolen přístup jen na vybrané porty vybraných serverů v PSN.

    Skutečné nastavení pak vypadalo tak, jak to prozrazují obrázky na něž vedou odkazy v následujícím odstavci. Otevřel jsem tedy porty pro www (port TCP/80), poštu (TCP/25), ssh (TCP/22) (telnet samozřejmě ne) a vzdálenou konfiguraci a správu (77 a 443). Spustil jsem vzdálené logování na jiný počítač (TCP/514) a vytvořil alternativní administrátorské konto. Poté jsem připojil testovací počítače do příslušných sítí přes příslušné konektory a opět vystavil firewall útokům zájemců. Konfigurace filtrů je patrná z tohoto obrázku a zde je pak vidět aktuální nastavení hardwaru.

    Vyhodnocení 2.testu

    Nejprve mi dovolte trošku přiblížit pravidla a systém záznamů v log souborech RoBoXu (a GNAT Boxu obecně). Na modelové situaci filtru číslo 8 a několika záznamech z log souboru se vám pokusím přiblížit co a jak se děje od příchodu podezřelého paketu až po ohlášení události správci, je-li tato závažná. Remote Acces Filtr číslo 8: Block with ALARM any other access to any interface. Deny warning ANY ALL log alarm from ANY_IP to ANY_IP Znamená to, že jakýkoliv neočekávaný paket, který dorazí z jakékoliv IP adresy a portu na jakoukoliv IP adresu port na kterékoliv z rozhraní našeho GB firewallu, bude odhozen (drop), ale tato akce bude vyhodnocena jako ALARM. Tak bude také zalogována. V nastavení reakcí na hlášení filtrů je nastaveno, že pokud se sejde 10 alarmů během 120 sekund, bude následně odeslána zpráva správci systému mailem (je možné si vybrat z více voleb – e-mail, zpráva na pager, apod.). Toto je typické nastavení, které umožňuje snadno sledovat pokusy o skenování našeho systému. Je však nutné mít správně nastavené mailové nastavení, kteréžto jsem já v testu neměl, a tudíž se to objevilo i v kontrole nastavení RoBoXu s chybným nastavením e-mailování (modrý řádek).

    V e-mailové zprávě, která správci pak dorazí, bude takovýto modelový obsah (ukázky jsou z GB-FLASH):

    ALARM NO: 14 DATE: Fri 2002-05-17 19:49:14 CEST
    PRIORITY: 4 INTERFACE: EXTERNAL (ed0)
    INTERFACE TYPE: External ALARM TYPE: Block
    IP PACKET: TCP [61.122.74.1/22]-->[62.24.74.22/52858] l=0 f=0x14 [gw.himajin2001.com/ssh]-->[i22.dkm.cz/52858]
    DETAILED DESCRIPTION: IP packet was rejected by filter 8

    ALARM NO: 15 DATE: Fri 2002-05-17 19:49:14 CEST
    PRIORITY: 4 INTERFACE: EXTERNAL (ed0)
    INTERFACE TYPE: External
    ALARM TYPE: Block
    IP PACKET: TCP [61.122.74.1/22]-->[62.24.74.22/52857] l=0 f=0x14 [gw.himajin2001.com/ssh]-->[i22.dkm.cz/52857]
    DETAILED DESCRIPTION: IP packet was rejected by filter 8

    Z výše uvedených alarmů, je viditelné prakticky vše co může správce zajímat. Probereme si to postupně:

    Někdo se prostřednictvím počítače s IP adresou 61.122.74.1 přes gateway gw.himajin2001.com zkoušel z portu TCP/22 (ssh), vyhledávat díry na našem systému a přes ssh se připojit postupně na portech 52857 a 52858. To je typická ukázka scanu (prozkoumávání stavu otevřenosti portů)

    Na našem systému nejsou na portech 52857 a 52858 odpovídající tunnely a Remote Access filtry, takže jeho pakety došly až k poslednímu z filtrů (v daném nastavení), kterým je výše popsaný filtr 8. Ten podle zadaných pravidel paket odhodil, ale tuto událost zalogoval jako ALARM a protože nebyla ojedinělá, poslal nám (tedy správci) posléze seznam těchto pokusů jako e-mailovou zprávu. Jednotlivé řádky znamenají toto:

    • ALARM NO: 15 - číslo události počínaje první událostí v rámci jedné zprávy
    • DATE: Fri 2002-05-17 19:49:14 CEST - datum a čas, kdy k události došlo. Porovnáním časů obou následujících zpráv vidíme, že se jednalo o masivní scan, neboť oněch 10 událostí vyhodnocených jako ALARM přišlo během jediné sekundy. To nám naznačuje, že nestojíme proti profíkovi, neboť ten by nechal mezi skeny jednotlivých portů několika vteřinové mezery, aby ošálil detekční systémy.
    • PRIORITY: 4 - priorita záznamu, podle nastavení filtru a nastavení logování (je na výběr ze 7 úrovní, kde poslední je pro bezpečnostní paranoiky a umožňuje kompletní uzavření daného rozhraní, samozřejmě s hláškou správci)
    • INTERFACE: EXTERNAL (ed0) - rozhraní, na kterém byl paket zaznamenán (zde tedy externí, tj. vnější síť) a ed0 je identifikace konkrétní síťové karty (u RoBoXu sis0 až sis2)
    • INTERFACE TYPE: External - typ rozhraní - externí, v našem případě jde o útok z Internetu
    • ALARM TYPE: Block - vyvolaná akce - zablokováni komunikace, tedy zde odhozeni paketu
    • IP PACKET: TCP [61.122.74.1/22]-->[62.24.74.22/52857] l=0 f=0x14 [gw.himajin2001.com/ssh]-->[i22.dkm.cz/52857] - tady je zhuštěno poměrně mnoho informací. Použitý protokol TCP, paket přišel z IP adresy 61.122.174.1 (jehož hostname je: gw.himajin2001.com) z portu 22 (což je port dedikovaný pro ssh). Tento paket přišel na naši IP adresu 62.24.74.22 (jejíž hostname je: i22.dkm.cz) na port 52857 (který není standardně vyhrazen pro žádný protokol, službu ani aplikaci, ale často se na tyto vysoké porty zavěšují backdoory u kompromitovanýchsystémů). l=0 vyjadřuje délku přenesených dat, tedy zde toho moc nenesl a f=0x14 je nějaký stavový vektor.
    • DETAILED DESCRIPTION: IP packet was rejected by filter 8. - informace o filtru, který paket odhodil

    U ostatních událostí (TUNNEL OPEN, TUNNEL CLOSED, NAT, ALARM, WWW), které reflektují příslušnou událost je vše velmi podobné.

    GTA dodává zatím jen zmíněnou GNAT Box Reporting Utility, která je nyní ve vývojové verzi 3.2.5. Je nutné mít nainstalovanou, nebo nainstalovat MySQL databázi (je přiložená v utilitce) a pak teprve je možné se dostat k vlastním analýzám. Jedná se každopádně o vývojovou verzi, což také GTA motivuje k vývoji, neboť probíhají práce na přechodu logovacího formátu na standardní WELF formát. Ten pak bude možné analyzovat profesionálním nástrojem WebTrends Firewall Appliance Analyzer. Ale to je hudba budoucnosti. Zajímavou možností je ona freewareová utilitka ReportGen, ale zaměřuje se spíše na aktivity uživatelů než na bezpečnostní incidenty a příliš toho neumí. Je však docela dobře použitelná pro sledování aktivit na konkrétním portu a umí filtrovat podle zadaných kriterií. Bezpečnostní statistiku jsem z ní však nedostal. Není to tedy s automatizovaným zpracováním nijak špatné, ale GTA má rozhodně na čem pracovat a už aby tu WELF formát byl. Obrázky, jak taková analýza z WELF logů vypadá naleznete zde. Podstatná data již v logách jsou již nyní, ale ne právě v ideálním formátu. Pokud se vhodně nezvolí počet informací, které mají být logované, tak nebude moc platná ani oblíbená činnost profíků, totiž prohlížení logů vlastnoočně.

    Ve všech verzích GTA firewallů zatím výrazně chybí u vestavěného DHCP serveru možnost přidělovat IP adresy počítačům na vnitřních sítích na základě jejich MAC adres (unikátní číslo každé síťové karty). Snad to firma vylepší v budoucnosti, zatím má bodík dolů.