Jak działa Conficker?

Do tej pory o robaku Conficker pisało się dużo, ale przy okazji niekonkretnie. Teraz garść informacji, które mogą być faktycznie przydatne dla administratorów serwisów.

Botnet Conficker, jeden z najgroźniejszych i najbardziej medialnych robaków internetowych, wykorzystuje do komunikacji ze swoim centrum kontroli (Command & Control) protokół HTTP, łącząc się z serwerem (serwerami) kontroli (tzw. kontrolerem) na porcie 80. w celu pobrania nowego pliku binarnego.

Serwery, z którymi łączy się bot, lokalizowane są z wykorzystaniem DNS, poprzez pseudolosową codzienną generację nowej listy kilkuset domen (najnowsza wersja Confickera generuje nawet 50 000 domen dziennie – najbardziej obecnie popularna wersja generuje tylko 450 domen).

Conficker odpytuje DNS o każdą domenę z listy i próbuje połączenia z uzyskanym w ten sposób adresem IP, licząc na to, że pod którymś adresem znajdzie swój serwer kontroli. Tylko niektóre z wygenerowanych domen wskazują na serwer ze złośliwym kodem, co nie zmienia faktu, że wiele serwerów może zostać odpytanych "przy okazji" przez poszczególne boty, a więc serwery, na których postadowione są zupełnie niewinne serwisy WWW.

Takie (prawdopodobnie) niezamierzone przez twórców tego robaka działanie może hipotetycznie doprowadzić do ataku Distributed Denial of Service na istniejące serwisy WWW.

Specjaliści zajmujacy się analizą kodu Confickera uzyskali na szczęście algorytm, którym posługuje się Conficker w celu wygenerowania listy domen – celów ataku/pobrania nowych binariów. Część tych domen jest już dawno zarejestrowana, a pod tymi nazwami znajdują się różnorakie serwisy, jak chociażby witryna www.nask.pl. Każda domena na liście może być celem nieświadomego ataku Confickera, skutkując poważnymi zaburzeniami w funkcjonowaniu serwisów.

Na stronie www.conficker.pl publikujemy listę nazw domen, które mogą być celem takiego nieświadomego ataku bota.

Jeśli Twoja domena znajduje się na tej liście, warto przedsięwziąć środki celem zmniejszenia skutków ewentualnego ataku DoS (Denial of Service) na Twój serwis WWW.

Zmiany w rejestrze .PL

Zbliża się termin konferencji Future Business Trends in the Domain Industry. Na konferencji mamy potwierdzony udział (oprócz grona prelegentów) ponad 130 gości, w tym wielu reprezentujących zagraniczne podmioty zainteresowane naszym rynkiem domenowym (pierwotnym i wtórnym). Wśród gości konferencji będą także przedstawiciele Komisji Europejskiej oraz ICANN-u.

Wśród prelegentów mamy przedstawicieli naszego rodzimego rynku: home.pl, AZ.pl, dropped.pl, a także przedstawicieli najdynamiczniejszych rejestrów z zagranicy: .RU, .CZ, .NL, .TEL oraz .MOBI. Swoje prezentacje będą mieli także najwięksi reprezentanci rynku wtórnego, tacy jak SEDO oraz NameDrive, oraz największy zagraniczny Partnerzy NASK: Key-Systems. Swój slot czasowy będzie miał także rejestr .BERLIN – prawdopodobnie jedna z pierwszych nowych TLD, które pojawią się w Internecie w Roku 2010.

Tak jak zapowiadaliśmy, na konferencji przedstawimy także nowe zasady współpracy z Partnerami. Wśród najważniejszych kwestii, o których będą mówili przedstawiciele NASK, znajdzie się wdrożenie jeszcze 2009 roku przez NASK w kanale partnerskim rozliczeń typu pre-paid oraz pobieranie opłat za nieudane rejestracje (próba zarejestrowania domeny, która jeszcze nie została zwolniona do rejestracji) oraz opłat od operacji rezerwacji domeny.

Szczególnie nieudane próby rejestracji/rezerwacji domen, które nie są jeszcze dostępne do rejestracji, powodują niepotrzebne obciążenia całego systemu. Obciążenia te generowane są przez kilkanaście podmiotów, a cierpią na tym pozostali Partnerzy.

W nowym systemie wszystkie te aspekty powinny znaleźć rozwiązanie, a niewielka opłata za nieudane próby rejestracji wprowadzi mechanizmy rynkowe do konkurencji i zapewni bezpieczne funkcjonowanie systemu, bez konieczności wprowadzania ograniczeń administracyjnych.

Podobnie niepotrzebna rezerwacja domen ogranicza możliwości zdobycia nazwy domenowej przez faktycznie zainteresowane podmioty. Na prezentacji NASK nie zabraknie też informacji o planowanych na 2009 rok promocjach.

Szczegóły już 16 kwietnia w Warszawie. Program konferencji można znaleźć pod adresem: SecondaryMarket2009.pl. Zapraszamy.

Domena .GOV zniknęła z Internetu na kilka godzin

Sprawdziły się czarne scenariusze, mówiące o tym, że DNSSEC jest jeszcze zbyt niedojrzałą technologią na wdrożenie produkcyjne. O racjonalnym podejściu do DNSSEC w Europie pisałem na blogu: „DNSSEC: Komisja Europejska bardziej rozsądna niż rząd USA” z lutego 2009. Niestety, rząd amerykański okazał się tak przejęty wdrożeniem nowej technologii z pobudek politycznych i po naciskach grupy zwolenników DNSSEC (polecam mój blog „Al-Kaida DNS: bojownicy DNSSEC” z listopada 2008), że zapomniał o audycie bezpieczeństwa i wdrożył technologię, która zawiera oczywiste braki.

Wystarczyły trzy miesiące, aby przekonać się, że na DNSSEC jest jeszcze zbyt wcześnie. I na szczęście przekonali się o tym ci, którzy za wszelką cenę, wbrew zdrowemu rozsądkowi, tę technologię promowali.

15 marca 2009 domena .GOV została dopisana do DLV (DNSSEC Lookaside Validation). Dzięki technologii DLV serwery DNS mogą dokonywać walidacji (sprawdzenia) domen podpisanych (zabezpieczonych w technologii DNSSEC). Amerykanie postanowili jednak użyć algorytmu NSEC3 (NSEC3 RSA SHA1 DNSKEY).

Jak się okazało, BIND, najpopularniejsze oprogramowanie dla DNS, w wersjach do 9.5 włącznie, niestety nie wspiera jeszcze algorytmu NSEC3 RSA SHA1, co objawiało się użytkownikom korzystającym z DNSSEC niepoprawną walidacją domen w domenie .GOV. Innymi słowy, BIND traktował takie domeny jak fałszywe (podpisane sfałszowanym kluczem), zamiast traktować je jako niepodpisane.

Zamiast zwiększenia bezpieczeństwa doszło do sytuacji odwrotnej – poprawnie zabezpieczona domena była traktowana jako fałszywa. Remedium na ten problem było usunięcie domeny .GOV z bazy DLV, co automatycznie powoduje zmniejszenie zaufania do DNSSEC jako technologii walidacji autentyczności wpisów w DNS.

Szczęście w nieszczęściu – mało osób korzysta z DNSSEC i problem dotknął niewielkiej liczby użytkowników Internetu. Problem ten jednak pokazał, że nie warto czasami wdrażać technologii w celach politycznych i jako eksperymentów na żywym organizmie. Na koniec warto życzyć rządzącym, aby na siłę nie wdrażali technologii, tylko po to aby zyskać uznanie w grupie lobbystów.

Słowniczek:

* .GOV = domena najwyższego poziomu dla rządu USA
* DNSSEC = DNS Security Extensions
* DLV = DNSSEC Lookaside Validation
* NSEC3 = NextSECure3

Tylko 0,3% ruchu DNS po IPv6

Urząd Komunikacji Elektronicznej organizuje debatę na temat wdrażania IPv6. To bardzo dobra inicjatywa – powinna ona wyjaśnić wiele nieporozumień, które narosły wokół IPv6.

Wiele osób uważa bowiem, że można wdrożyc IPv6 „administracyjnie”. Oczywiście, można dokonać regulacji w tym zakresie, ale czy warto stosować mechanizmy regulacyjne, zamiast pozwolić biznesowi podjąć decyzję? Innymi słowy: czy warto zaspokajać ambicję kilku osób w Komisji Europejskiej poprzez wydawanie pieniędzy operatorów (czytaj: klientów) oraz pieniędzy podatników?

Niestety, Komisja Europejska już wydaje nasze pieniądze na promocję IPv6, ale chyba nikt nie ma złudzeń co do „oszczędności” robionych w Brukseli. Debata w UKE powinna dać jasną odpowiedź na pytanie, w jaki sposób przechodzić na IPv6 w Polsce tak, aby przejście to było korzystne dla polskich klientów i operatorów, czyli jak zmaksymalizować korzyści i zminimalizować koszty, co jest szczególnie istotne w czasach kryzysu. Czasami warto być pionierem, a czasami lepiej poczekać na innych, żeby popełnili swoje błędy i uczyć się na tych błędach.

Wyczerpująca się pula?

Pierwsze z nieporozumień dotyczących IPv6, o których wspomniałem powyżej, to kończąca się pula adresów IPv4 – ma ona zostać w pełni wyczerpana już za trzy lata. Problem w tym, że pula ta wyczerpuje się tylko na poziomie centralnym – wykorzystanie przydzielonych adresów IP jest albo małe albo często nieracjonalne. Wynika z dotychczasowej polityki np. RIPE, który przydzielał bezpłatnie operatorom pule adresów, o ile Ci potrafili napisać zgrabny e-mail z uzasadnieniem.

Wielu operatorów może spokojnie rozwijać swój biznes przy wykorzystaniu mniejszej puli adresowej, przydzielając adresy dynamicznie szczególnie dla kllientów domowych, a firmy w wielu wypadkach mogą skorzystać z rozwiązań NAT, zamiast wykorzystywać stały adres IP do każdego komputera.

Dodatkowo, nierówności w przydziale adresów pomiędzy USA a resztą świata powodują, że wielkie pule adresów są w posiadaniu niewielkiej grupy firm i uniwersytetów. I tak przykładowo własne odrębne pule adresów typu „/8” posiadają pojedyncze firmy amerykańskie takie jak Xerox, HP, Apple, Ford (sic!), Halliburton, Eli Lily&Company, Prudential, Merck i wiele innych. Własną pulę adresów „/8” ma również MIT, a AT&T ma aż dwie pule „/8”.

Przykładowo: cała Afryka ma tyle adresów, co HP, Apple oraz AT&T razem wzięte. Mówienie więc o wyczerpywaniu się puli to zwykłe bajki. Myślę też, że jak faktycznie adresów IPv4 będzie brakowało, a IANA nie poprawi procesu gospodarowania adresami, to tacy giganciu jak np. Ford czy AT&T zarobią juz niedługo trochę pieniędzy na „wydzierżawieniu” części swojej puli komercyjnie dla ISP.

Dodatkowo, samych nieprzydzielonych adresów IPv4 jest aż 30% całości, bo oprócz adresów rozdzielonych pomiędzy RIR a nie przydzielonych dla ISP, istnieją niektóre pule adresów we władzy IANA które moga bez większych problemów jednak trafić do wykorzystania komercyjnego.

Jak można sobie poradzić z tym problemem?

Poniżej zamieszczam listę zaleceń odnośnie do rozwiązania problemu IPv4.

1. Realokacja – odbieranie pul adresowych przez RIR od ISP, którzy nie udowodnią, że faktycznie potrzebują danego zakresu adresów IP w wersji 4.
2. Przekazanie pul adresów pomiędzy RIR (przykładowo z ARIN do RIPE).
3. Pobieranie przez RIR opłaty (minimalnej, ale jednak) za każdy adres przydzielony dla ISP.
4. Pobieranie opłat przez ISP od tych klientów, którzy potrzebuja stałego adresu IP.
5. Handel pulami adresów IPv4 pomiędzy ISP.

Skoro problem wyczerpujacej się puli nie jest najważniejszy, to dlaczego jest tak duże parcie na powszechne wdrożenie IP w wersji 6? Powodów jest kilka:

1. Presja polityczna w Europie, szczególnie ze strony prezydencji francuskiej (w 2008) na szybkie wdrażanie protokołu IPv6. Ten punkt powoduje, że IPv6 jest politycznie poprawne. A wiadomo, że jak coś jest politycznie poprawne, to nie powinno się z tym dyskutować. I chyba to jest najważniejszy powód zainteresowania IPv6. Protokół ten obok globalnego ocieplenia oraz kryzysu jest tematem o „jasnej tezie”, a dyskusja „na argumenty” o zaletach IPv6 przypomina znany kawał „Pytanie: dlaczego tanie wino jest dobre? Odpowiedź: bo jest dobre i tanie”.
2. Nacisk ze strony inżynierów/naukowców, którzy pracowali nad protokołem IPv6 i dla których wdrożenie IPv6 to kwestia amibicji.
3. Nacisk ze strony dostawców sprzętu (routery, firewalle), krórzy zarobią np. do dodatkowych usługach doradczych oraz sprzedadzą mniej obeznanym klientom dodatkowe kilka pudełek.
4. Brak działań po stronie IANA i RIR w zakresie lepszej gospodarki adresami.

Na wspomnianej na początku tego wpisu debacie przedstawię także trochę statystyk odnośnie do faktycznego wdrożenia IPv6, a dokładnie jak wygląda faktyczne zainteresowanie (popyt) usługami z wykorzystaniem protokołu IPv6 w Europie na przykładzie domen internetowych. Pierwsza z tych statystyk znajduje się w tytule bloga – tak to nie pomyłka, ruch IPv6 do DNS jest poniżej 0,3%, a z tego ruchu część to monitoring DNS.

I jeszcze pozostaje mi zaprosić wszystkich na samą debatę. Odbędzie się ona w siedzibie Warszawskiej Szkoły Zarządzania, ul. Siedmiogrodzka 3A w Warszawie, 24 marca o godzinie 11.00. Bezdyskusyjnie jest to debata, na której każdy ISP powinien się pojawić, bo wiadomo: nieobecni głosu nie mają.