Bezpečné PC: Infrastruktura Blog

Zobrazují se příspěvky se štítkemInfrastruktura Blog. Zobrazit všechny příspěvky

pondělí 21. května 2012

DNS Každá žádost Cannon - Potřebujete další balíčky

Máme zprávu od našeho čtenáře Tuukka, kdo sledoval záplavu DNS každou žádost pravděpodobně falešných IP adres. Co zatím víme je, že to vypadá, že DNS Reflexní zesílení útoku. Ty obvykle používají obecné rekurzivní DNS dotazy na špatně nakonfigurované vláčení služby DNS. Tato akce se liší v tom, že odraz je cílenější. DNS "Všechny" rekordní dotazy byly zaslány pouze pro domény, pro které je autoritativní server, který od server se samozřejmě odpovědi bez ohledu na dostupné rekurze. Tyto události byly validovány v reálném čase pozorování jedním z našich rutiny. Zde je to, co zatím víme.

Hit List:

Zdroj IP spoofed
Povodňová trvá až 60 sekund na 500 dotazů v čemž svědčí, ale pravděpodobně by mohlo být více)
Povodeň přijde z určeného IP a zdá se, zaměřit se více domén na autoritativní server
Všechny pozorované požadavky jsou podobné tak daleko
To se zdá být podobný tomu, co jiní vidět [1]

Příklad DNS položka protokolu:

xxxx je podvržené / cílový server
example.com/10.1.1.1 je "odráží" DNS server

21-May-2012 13:21:41.757 dotazy: INFO: Klient xxxx # 20475: Zobrazit externí: Dotaz: example.com JAKÝMKOLIV více let odst. 10.1.1.1)

21-May-2012 13:21:41.897 dotazy: INFO: Klient xxxx # 59247: Zobrazit externí: Dotaz: example.com JAKÝMKOLIV + (10.1.1.1)

21-May-2012 13:21:42.054 dotazy: INFO: Klient xxxx # 18676: Zobrazit externí: Dotaz: example.com JAKÝMKOLIV + (10.1.1.1)

21-May-2012 13:21:42.059 dotazy: INFO: Klient xxxx # 28530: Zobrazit externí: Dotaz: example.com JAKÝMKOLIV + (10.1.1.1)

21-May-2012 13:21:42.193 dotazy: INFO: Klient xxxx # 6489: Zobrazit externí: Dotaz: example.com JAKÝMKOLIV + (10.1.1.1)

Máme zájem vědět, pokud jste viděli to a to, co jste udělal pro zmírnění žádné škodlivé účinky těchto událostí. Prosím přidat komentář k dejte nám vědět.

Chceme také, aby DNS záznamy a záznamy paketů zachycení událostí popsaných v tomto deníku. Tam je ještě mnoho naučit o tomto chování.

Vidíte-li jakýkoliv dotaz odchozí povodně vaší síti: Zkuste identifikovat zdrojový stroj. Bylo by zajímavé vidět, co způsobí, že nástroj pro dotazy.

[1] http://dyn.com/active-incident-notification-recent-chinanetany-query-floods/

neděle 20. května 2012

Dostal balíčky? Liché duplicitní DNS odpovědí 10.x IP adres

Toto je vyjasnění deníku Danově ze včerejška. Máme zájem slyšet, jestli někdo jiný vidí DNS odpovědí od RFC1918 bez směrovatelnými IP adresy, zejména z 10.0.0.0 / 8. Zatím máme jen jednu zprávu, a snažíme se zjistit, jestli je to něco, co silně rozšířené, nebo něco jedinečného pro tohoto uživatele.

Tento čtenář poprvé zaznamenali problém, když firewall hlásil déle sice klesl pakety z 10.x adres. Dva příklad dotazy, které způsobily problém, jsou A dotazy na 25280.ftp.download.akadns.net a adfarm.mplx.akadns.net.Čtenář obdrží dvě odpovědi: Jedna "normální" odpověď z adresy dotaz byl zaslán, a druhý odezvu od 10.x adresu. V důsledku toho by problém bez povšimnutí, i když klesl 10.x odpověď. Obě odpovědi poskytují stejnou odpověď, takže to nemusí být útok, ale více konfigurací.

Jako vedlejší poznámku, zpočátku DNS protokol výslovně povoleno pro odpovědi na přicházející z IP adresy jiné, než je ten dotaz byl na adresu:

"Některé jmenné servery své odpovědi z různých adres, než jaká se používá pro příjem dotazu. To znamená, že resolver se spoléhat, že odpověď bude pocházet ze stejné adresy, která byla odeslána odpovídající dotazu. Toto jméno serveru chyba se obvykle setkali v systémech UNIX. " (RFC1035)

Nicméně, pozdnější v RFC2181, byl odstraněn tento požadavek:

"Nejvíce, jestliže ne všichni, klienti DNS, očekávají adresu, na které je odpověď obdržel být stejná adresa, na kterou vyvolalo dotaz odpověď byla odeslána. To platí pro servery za klienty pro účely rekurzivního dotazu rozlišení, stejně jako jednoduché resolveru klienty. adresa, spolu s identifikátorem (ID) v replice se používá pro disambiguating odpovědi a filtrování nežádoucího odpovědi. To může, ale nemusí, být záměrem, kdy byl navržen DNS, ale je nyní skutečností. " (RFC2181)

Ale my nehledáme odpovědí, které přicházejí ze špatného zdroje, ale duplicitní odpovědi. Jednou z správná a jednou z nesprávné adresy.

Zde je příklad "zbloudilý" paket předkládá čtenáři (mírně upravené pro důvodů ochrany soukromí a lépe celou obrazovku)

Internet Protocol verze 4, Src: 10.17.xy, DST: --- odstraněno ---
    Verze: 4
    Hlavička délka: 20 bytů
    Diferencované služby Obor: 0x00 
    Celková délka: 84
    Identifikace: 0x2a7e (10878)
    Flags: 0x00
    Fragment offset: 0
    Čas žít: 59
    Protokol: UDP (17)
    Kontrolní součet hlavičky: správné
User Datagram Protocol, Src Port: domain (53), DST Port: antidotemgrsvr (2247)

Domain Name System (odpověď)
    ID transakce: 0xb326
    Příznaky: 0x8400 (standardní odpovědi na dotaz, žádná chyba)
        1 ... .... .... .... = Odpověď: Zpráva je reakcí
        0,000 0 ... .... .... = Opcode: Standardní dotaz (0)
        .... 0.1 .. .... .... = Autoritativní: Server je autoritou pro doménu
        .... .. 0. .... .... = Zkrácený: Zpráva není zkrácen
        .... 0 ... .... .... = Požadovaná Rekurze: Nedělejte dotaz rekurzivně
        .... .... 0 ... .... = Rekurze k dispozici: Server nemůže dělat rekurzivní dotazy
        .... .... 0.0 .. .... = Z: vyhrazené (0)
        .... .... .. 0. .... = Odpověď není ověřen
        .... .... 0 ... .... = Neověřené údaje: Nepřijatelné
        .... .... .... 0000 = Odpověď kód: žádná chyba (0)

    Otázky: 1
    Odpovědět RR: 1
    Orgán RR: 0
    Doplňkové RR: 0

    Dotazy

        ads.adsonar.akadns.net: typ A, třída V
            Jméno: ads.adsonar.akadns.net
            Typ: (Host adresa)
            Třída: V (0x0001)

    Odpovědi

        ads.adsonar.akadns.net: typ A, třída IN, addr 207.200.74.25
            Jméno: ads.adsonar.akadns.net
            Typ: (Host adresa)
            Třída: V (0x0001)
            Čas žít: 5 minut
            Délka dat: 4
            Adr: 207.200.74.25 (207.200.74.25)

http://www.faqs.org/rfcs/rfc1035.html
http://www.faqs.org/rfcs/rfc2181.html

středa 16. května 2012

Rezervované IP adresní prostor Připomenutí

Jak jsme docházejí IPv4 adresového prostoru, mnoho sítí, místo zahrnuje IPv6, protáhnout stávající IPv4 prostoru přes více úrovní NAT. NAT pak používá "rezervována" IP adresní prostor. Nicméně, existuje více adres vyhrazena pohybuje pak uvedené v RFC1918, a ne všechny z nich by měly být použity ve vnitřních sítích. Zde je (pravděpodobně nekompletní) seznam rozsahy adres, které jsou vyhrazeny, a který jednou jsou použitelné v síti za bránou NAT.

Seznam vyhrazených IPv4 adres se pohybuje
Rozsah adres	RFC	Vhodné pro vnitřní síť
0.0.0.0 / 8	RFC1122	ne ("žádné" adresa)
10.0.0.0 / 8	RFC1918	ano
100.64.0.0/10	RFC6598	ano (s opatrností: Pokud jste "dopravce")
127.0.0.0 / 8	RFC1122	ne (localhost)
169.254.0.0/16	RFC3927	ano (s opatrností: nulová konfigurace)
172.16.0.0/12	RFC1918	ano
192.0.0.0/24	RFC5736	ne (nyní nepoužívá, může být později)
192.0.2.0/24	RFC5737	ano (s opatrností: pro použití v příkladech)
192.88.99.0/24	RFC3068	ne (6-to-4 anycast)
192.168.0.0/16	RFC1918	ano
198.18.0.0/15	RFC2544	ano (s opatrností: pro použití v benchmarkových testech)
198.51.100.0/24	RFC5737	ano (s opatrností: test-net používané v příkladech)
203.0.113.0/24	RFC5737	ano (s opatrností: test-net používané v příkladech)
224.0.0.0 / 4	RFC3171	ne (Multicast)

Nejzajímavější je v tomto kontextu RFC6598 (100.64.0.0/10), který byl nedávno přidělen, aby ISP s řadou pro NAT, která nebude v rozporu s jejich zákazníky sítě NAT. Bylo to čím dál častější problém, který NAT'ed sítě kdysi spojené s sebou například prostřednictvím VPN tunelu, mají protichůdné úkoly.

Které sítě jsem zapomněl? Budu aktualizovat tabulku na pár dní jako komentáře, pojďte dál

Dostal balíčky? Liché duplicitní DNS odpovědí 10.x IP adres

Tento čtenář poprvé zaznamenali problém, když firewall hlásil déle sice klesl pakety z 10.x adres. Dva příklad dotazy, které způsobily problém, jsou A dotazy na 25280.ftp.download.akadns.net a adfarm.mplx.akadns.net. Čtenář obdrží dvě odpovědi: Jedna "normální" odpověď z adresy dotaz byl zaslán, a druhý odezvu od 10.x adresu. V důsledku toho by problém bez povšimnutí, i když klesl 10.x odpověď. Obě odpovědi poskytují stejnou odpověď, takže to nemusí být útok, ale více konfigurací.

Jako vedlejší poznámku, zpočátku DNS protokol výslovně povoleno pro odpovědi na přicházející z IP adresy jiné, než je ten dotaz byl na adresu:

Nicméně, pozdnější v RFC2181, byl odstraněn tento požadavek:

Ale my nehledáme odpovědí, které přicházejí ze špatného zdroje, ale duplicitní odpovědi. Jednou z správná a jednou z nesprávné adresy.

Zde je příklad "zbloudilý" paket předkládá čtenáři (mírně upravené pro důvodů ochrany soukromí a lépe celou obrazovku)

Internet Protocol verze 4, Src: 10.17.xy, DST: --- odstraněno ---
    Verze: 4
    Hlavička délka: 20 bytů
    Diferencované služby Obor: 0x00 
    Celková délka: 84
    Identifikace: 0x2a7e (10878)
    Flags: 0x00
    Fragment offset: 0
    Čas žít: 59
    Protokol: UDP (17)
    Kontrolní součet hlavičky: správné
User Datagram Protocol, Src Port: domain (53), DST Port: antidotemgrsvr (2247)

Domain Name System (odpověď)
    ID transakce: 0xb326
    Příznaky: 0x8400 (standardní odpovědi na dotaz, žádná chyba)
        1 ... .... .... .... = Odpověď: Zpráva je reakcí
        0,000 0 ... .... .... = Opcode: Standardní dotaz (0)
        .... 0.1 .. .... .... = Autoritativní: Server je autoritou pro doménu
        .... .. 0. .... .... = Zkrácený: Zpráva není zkrácen
        .... 0 ... .... .... = Požadovaná Rekurze: Nedělejte dotaz rekurzivně
        .... .... 0 ... .... = Rekurze k dispozici: Server nemůže dělat rekurzivní dotazy
        .... .... 0.0 .. .... = Z: vyhrazené (0)
        .... .... .. 0. .... = Odpověď není ověřen
        .... .... 0 ... .... = Neověřené údaje: Nepřijatelné
        .... .... .... 0000 = Odpověď kód: žádná chyba (0)

    Otázky: 1
    Odpovědět RR: 1
    Orgán RR: 0
    Doplňkové RR: 0

    Dotazy

        ads.adsonar.akadns.net: typ A, třída V
            Jméno: ads.adsonar.akadns.net
            Typ: (Host adresa)
            Třída: V (0x0001)

    Odpovědi

        ads.adsonar.akadns.net: typ A, třída IN, addr 207.200.74.25
            Jméno: ads.adsonar.akadns.net
            Typ: (Host adresa)
            Třída: V (0x0001)
            Čas žít: 5 minut
            Délka dat: 4
            Adr: 207.200.74.25 (207.200.74.25)

http://www.faqs.org/rfcs/rfc1035.html
http://www.faqs.org/rfcs/rfc2181.html

Liché DNS odpovědí od 10 sítí a RFC1323 ovlivňujících firewally

Čtenář Bob napsal hlášení vidět stále častěji příchozí odpovědi DNS na UDP 53, platných odpovědí DNS, ale přicházejí ze zdrojových adres na 10.xxx / 8 rozsahu . Odpovědi se zdají být z internetových Roots DNS servery, které jsou dotazování kořen.

Někdo jiný tento druh chování?

V uplynulém týdnu další pár čtenářů napsal ve vykazování problémy s přístupem na webové stránky ISC. SANS NOC uvádí, že RFC-1323 časování dostávali odstraněna naším firewall, aby se zabránilo úniku informací, ale kontrolní součet nebyl aktualizován. Paket byl následně klesl o koncového zařízení.

Zdá se, že vliv uživatelů pomocí proxy Bluecoat web.Budeme mít více na příspěvek na toto téma po celý den.

RFC1323 TCP rozšíření popisuje používané ke zlepšení výkonnosti oproti vysokým zpoždění sítě a vysokorychlostních sítí
Jedná zahrnovat Scaled Window Options Round Trip Time měření (RTTM) a ochrana proti zabalené pořadovými čísly (PAWS)

Zmen okno Možnosti jsou realizovány po kousku se převádí na 16bit okna pole do 32 bitové pole tím, že přidá volbu určující, kolik vyhrazená místa k posunu (nebo násobit), aby si skutečnou velikost okna. Připomeňme si velikost okna je to, kolik bajtů uzel vyrovnávací paměti, než je třeba vysílač zpomalit.

Tcpdump zobrazuje tuto možnost jako WS = 6 pro faktorem 6 za TCP možností

Wireshark zobrazuje tuto možnost jako například: "Okno Měřítko: 7 (vynásobením 128)"

Round Trip Time měření (RTTM), nebo TCP volba 8 obsahuje hodnotu časového razítka nebo TSval soubor o odesílateli s jeho odeslání čas, 32 bitová hodnota a časový údaj Echo Reply odst. TSecr), který je platný pouze v případě, že průvodní příznak ACK TCP nastavit. Tato 32 bitová hodnota Echos časové razítko hodnotu stanovenou druhým nebo vzdálené hostitele na zasedání TCP. Tyto hodnoty jsou sledovány v čase odhadnout a přizpůsobit se měnícím se podmínkám provozu.

PAWS poskytne jednoduchý mechanismus odmítnout staré duplicitní segmenty, které by mohly porušit otevřené TCP spojení. Používá stejné časové značky v RTTM, základní myšlenkou je, že segment může být zlikvidován jako starý duplikát, pokud je přijata s časovou značkou méně než nějaké časové razítko nedávno obdržel v této souvislosti.

Zde je to, co Bluecoat má říkat na téma: https://kb.bluecoat.com/index?page=content&id=FAQ1006

PAWS hledá časového razítka k postupující a používá se, aby co nejvíce dat v tranzitu je možné, mezi komunikujícími uzly.

Riziko pro přenos dat je v tomto případě, pokud dva hostitelé nebo jejich zprostředkovatelé nemůže jednat o společný způsob komunikace s nebo bez těchto možností. To se může stát s firewally, jako v našem případě, nebo nekompatibilní koncových bodů. Je zajímavé, že Windows realizovány tyto možnosti v systému Windows 2000, ale ani tomu, aby mohli ve výchozím nastavení do Windows 2008.