Na podstawie informacji pozyskanych z systemu ARAKIS

1. Wstęp

W ostatnich tygodniach obserwowalismy znaczny wzrost aktywności w sieci uTorrent (opartej na protokole uTP). Niektóre z rejestrowanych pakietów wywoływały fałszywe alarmy systemu ARAKIS wysokiego poziomu informujące o możliwej infekcji chronionych węzłów. Co więcej, z danych dotyczących ruchu wynikało między innymi, że występowała komunikacja pomiędzy dwiema sondami systemu ARAKIS, co było bardzo mało prawdopodobne. Oznacza to, że adresy zawarte w pakietach IP składających się na ten ruch były błędne (lub podrobione). W niniejszym raporcie zebrane zostały wyniki badania tej aktwyności.

Za metodyką wykonywania testów bezpieczeństwa OSSTMM 3:

Anomalia

nieidentyfikowalny lub nieznany element, którego działania nie mogą zostać wyjaśnione na gruncie standardowych operacji. Zazwyczaj pochodzenie (przyczyna) i przeznaczenie (cel) tego elementu nie mogą być wytłumaczone [przy wykorzystaniu dostępnej o nim wiedzy – tłum.]. Anomalia może być wczesną oznaką problemu bezpieczeństwa. Ponieważ „nieznane” (unknowns) to elementy, które nie mogą być w odpowiedni sposób kontrolowane (weryfikowane), w trakcie audytu właściwym jest zarejestrowanie każdej napotkanej anomalii.

[…]

Przykłady anomalii:

W kanale PHYSSEC (PHSYSEC oznacza „fizyczny” kanał interakcji z chronionymi zasobami) anomalią mogą być martwe ptaki znalezione na dachu budynku w pobliżu sprzętu komunikacyjnego.

W kanale telekomunikacyjnym COMSEC anomalią może być zgłoszenie modemu z numeru, który nie posiada modemu.

W kanale SPECSEC (kanał spektrum elektromagnetycznego) za anomalię można uznać lokalny sygnał, którego źródła nie można ustalić, ale który nie wpływa w zauważalny sposób na chronione zasoby.

(tłum. autora)

2. Co to jest uTP?

Protokół uTP wykorzystuje do transportu protokół UDP i uzupełnia go o funkcje protokołów połączeniowych. Obudowuje on (lub: enkapsuluje) zwykłe pakiety BitTorrent. Oznacza to, że zwykły ruch BitTorrentowy znajduje się wewnątrz kanału komunikacyjnego utworzonego w warstwie uTP. Kanał ten posiada niektóre z właściwości kanału TCP, takie, jak na przykład zorientowanie na połączenie i jego kontrolę. Zwykłe pakiety BitTorrentowe korzystają z cech protokołu TCP, takich, jak na przykład potwierdzanie odbioru danych, regulowanie wielkości okna etc., natomiast w tym przypadku własności te zapewnia uTP. Po co więc kolejny protokół, skoro można korzystać z TCP? Otóż, stos UDP/uTP/BT ma za zadanie m.in. zwiększenie kontroli nad obciążeniem. Prędkość ściągania danych z Internetu przez klienta BitTorrent nie podlega takim ograniczeniom, jak na przykład transmisja z serwerów FTP i HTTP (czyli ograniczeniu pasma po stronie serwera). Dlatego przy pobieraniu dużych ilości danych może zdarzyć się, że w sieci klienta wystąpi obciążenie wysycające większość lub całe dostępne pasmo, uniemożliwiając jej poprawne funkcjonowanie. Jednym z rozwiązań jest zastosowanie ograniczeń transferu na poziomie aplikacji klienta. Nie są to bardzo rozbudowane funkcje, poza tym wielu użytkowników po prostu o nich nie pamięta. uTP natomiast pozwala na dynamiczne regulowanie przepustowości w sieci BT na poziomie protokołu i dodatkowo posiada inne możliwości, jak wspomaganie transferu u klientów o wąskim paśmie czy dzielenie linii ADSL z przeglądarką interetową.

3. Nasze obserwacje uTP (statystyki)

Z posiadanych przez nas danych wynika, że aktywność sieci uTP, a co za tym idzie – również BT – znacznie wzrosła w ostatnich miesiącach w porównaniu na przykład do roku 2011. Wybraliśmy do analizy próbkę ruchu z 1. kwietnia roku 2011 i tego samego dnia roku 2012 w tej samej lokalizacji. Oto zestawienie statystycznych parametrów analizowanego ruchu:

Przy tworzeniu powyższego zestawienia przyjęto następujące założenia:

Analizowany ruch (pakiety składające się na anomalię) to ruch złożony z pakietów o charakterystyce podobnej do pakietów, które wywołały fałszywe alarmy w systemie ARAKIS. Wyznaczona charakterystyka jest następująca:

Pakiet wywołujący anomalię jest pakietem uTP z ustawioną flagą DATA.
Pakiet ten zawiera pakiet BT, który zawiera następujące informacje:
Hash protokołu BitTorrent: 057a315b89b54e53e2ee583dd5cd9ef60648805e
Peer protokołu BitTorrent: 0000000000000000000000000000000000000000

Można trochę osłabić te założenia i przyjąć, że na ruch-anomalię składają się także pakiety uTP SYN, które poprzedzają pakiety DATA, o takim samym gnieździe źródłowym i docelowym, jak pakiety DATA. Wtedy podsumowanie z 1. kwietnia 2012 roku wygląda następująco:

Sonda na każdy pakiet tego typu odpowiadała pakietem ICMP informującym o zamkniętym gnieździe UDP. Jeśli dodać te pakiety do ruchu składającego się na anomalię, statystyka staje się już bardzo wymowna:

Można łatwo zauważyć, że udział ruchu uTP jest nieproporcjonalnie duży w stosunku do reszty protokołów, jeśli porównać go do próbki z 2011 roku, którą wybraliśmy do porównania. Jest to także ponad 20-krotny przyrost całości ruchu. Podobne symptomy anomalii obserwowaliśmy w różnych lokalizacjach (alarmy wysokiego poziomu, statystyczne odchylenia ruchu sieciowego).

4. Analiza pakietów

Poniżej przedstawiamy poglądową ilustrację porównawczą klasycznego stosu BitTorrent i stosu uTP. Stopniowo przeanalizujemy informacje zawarte w poszczególnych warstwach.

4.1. Warstwa IP/UDP

Zacznijmy od warstwy IP/UDP. Poniżej znajduje się zestawienie źródłowych i docelowych adresów i portów analizowanych transmisji (ruch przychodzący uTP).

Hosty źródłowe (top 20):

Hosty docelowe:

Porty źródłowe (top 20):

Porty docelowe (top 20):

Adresy źródłowe posiadają dość równomierny rozkład, jeśli pominąć wyróżniające się adresy znajdujące się na szczycie listy. Adresy te pochodzą z różnych systemów AS i różnych lokalizacji geograficznych (w tym: z Rosji, Kanady, Chin, Australii, USA). Rozkład tych adresów posiada cechy sumy rozkładu równomiernego i pewnego rozkładu nierównomiernego. Może to oznaczać, że część tych adresów jest wykorzystywana w równomierny sposób (np. po kolei) lub są losowane (tj. podrabiane).

Zróżnicowany rozkład geograficzny adresów źródłowych skłania do przyjęcia raczej drugiego wytłumaczenia. Niewykluczone, że wykorzystywana jest również jakiegoś rodzaju rozproszona sieć anonimizująca. Wyrywkowo wybrane węzły nie przeszły testów na węzły sieci TOR, jednak pozostają jeszcze inne możliwości: inne rozproszone sieci anonimizujące, usługi VPN, botnety.

Jeśli chodzi o źródłowe i docelowe porty transmisji, można zauważyć, że preferowane są wysokie porty. Podobne porty są wybierane jako źródło i cel transmisji.

4.2. Warstwa uTP

Pakiet uTP (szczegółowe omówienie na stronie ze specyfikacją):

Ruch przychodzący składający się na anomalię można przedstawić jako serie przepływów z różnych źródeł składających się z dwóch pakietów uTP: uTP SYN i uTP DATA. Te pakiety składają się na opisywany w protokole uTP mechanizm nawiązywania połączenia (handshake), jednak pewne ich cechy są niezgodne z protokołem. Oto one:

4.2.1. Źródło transmisji ignoruje pakiety ICMP informujące o zamkniętym porcie.

W specyfikacji protokołu uTP nie jest opisana poprawna reakcja na wiadomości ICMP. Jednak klient uTP próbujący nawiązać połączenie powinien poprawnie zinterpretować tą wiadomość i uznać nawiązanie połączenia jako niemożliwe.

4.2.2. Źródło transmisji ignoruje brak pakietu uTP STATE i wysyła pakiet DATA.

Bez pakietu STATE nie posiada ono poprawnego numeru potwierdzenia, bez którego nawiązanie połączenia jest niemożliwe. Zamiast poprawnego numeru potwierdzenia umieszcza on w tym miejscu 0, co stanowi odstępstwo od protokołu. W trakcie badań wysyłaliśmy pakiety o podobnej konstrukcji do klienta uTorrent i odpowiadał on pakietem FIN i kończył konwersację. Przypuszczamy, że jest to efekt nieprzestrzegania protokołu.

4.2.3. Inne, interesujące lub niezwykłe cechy pakietów uTP:

Większość pakietów w polu timestamp difference ma wartość 0:

timestamp difference microseconds (top 10):

Większość pakietów w polu window size ma wartość 0x380000 (3670016 w systemie dziesiętnym)

window size (top 10):

Wartości pól timestamp microseconds w dwóch pakietach w tych samych przepływach różni się o wielokrotność 10000 mikrosekund.

Część tych właściwości może wynikać z konkretnych implementacji protokołu, ale inne sprawiają, że stosowanie tego protokołu traci sens. Jest bardzo mało prawdopodobne, że przy tak wysokiej rozdzielczości tak schematyczne wartości w polu timestamp microseconds były zgodne z rzeczywistością. Jeśli te wartości są sfałszowane, protokół traci swoje możliwości kontroli konsumpcji pasma i jego stosowanie w tym celu nie ma sensu.

4.3. Warstwa BitTorrent

W enkapsulowanych pakietach BT znajduje się hash: 057a315b89b54e53e2ee583dd5cd9ef60648805e. Ten hash dotyczy informacji o plikach wideo zawierających film „Avgust. Vosmogo”. Jest to rosyjski film akcji, który swoją premierę miał 21. lutego 2012 roku. Przy analizowaniu ruchu z innych lokalizacji zarejestrowaliśmy podobne pakiety (w stosie UDP/uTP/BT) zawierające hashe dotyczące informacji o innych plikach zawierających wspomniany film oraz plikach zawierających inny rosyjski film: „Shpion” (więcej o znaczeniu pola hash: http://wiki.theory.org/BitTorrentSpecification#Tracker_Request_Parameters).

Poniżej przedstawiamy interesujące korelacje czasowe pomiędzy publikacją torrentów, a transmisjami zawierającymi odpowiadające im hashe:

hash – data publikacji torrenta – data zarejestrowanych transmisji

c11ba392ef3dd57942112641ce8f1d9b96f0ddd5 – 26.02.2012 – 17.03.2012
057a315b89b54e53e2ee583dd5cd9ef60648805e – 17.03.2012 – 01.04.2012

W badanym ruchu z 1. kwietnia 2012 roku 99.99% pakietow uTP DATA zawierało hash 057a315b89b54e53e2ee583dd5cd9ef60648805e.

Omawiane pakiety zawierały również identyfikatory peerów BT (więcej o znaczeniu tego pola: http://wiki.theory.org/BitTorrentSpecification#peer_id).

peer IDs (top 10):

Jak widać, większość pakietów zawierała w tym polu ciąg zer.

Oto informacje dotyczące tych torrentów uzyskane od popularnych trackerów torrentowych:

tracker – seeders – peers

– 057a315b89b54e53e2ee583dd5cd9ef60648805e – Avgust. Vosmogo

https://torrentproject.com

http://xxxxxxxxxxxx:80/announce – 17 – 0
http://xxxxxxxxxxxx/announce – 16 – 0
http://xxxxxxxxxxxx:6969/announce – 11 – 0
http://xxxxxxxxxxxx/announce – 12 – 0
http://xxxxxxxxxxxx/announce – 9 – 0
http://xxxxxxxxxxxx/announce – 4 – 1

http://torrentz.eu

http://xxxxxxxxxxxx:2710/announce – 172 – 9
udp://xxxxxxxxxxxx:80/announce – 17 – 0
udp://xxxxxxxxxxxx:80/announce – 10 – 1 hour
http://xxxxxxxxxxxx/announce.php – 3 – 0
udp://xxxxxxxxxxxx:80/announce – 3 – 0
http://xxxxxxxxxxxx/announce.php – 2 – 0

http://bitsnoop.com

http://xxxxxxxxxxxx/announce.php – 3 – 0
http://xxxxxxxxxxxx/announce.php – 0 – 1
http://xxxxxxxxxxxx/announce – 1 – 0
http://xxxxxxxxxxxx:3310/announce – 0 – 1
http://xxxxxxxxxxxx:6969/announce – 0 – 0
http://xxxxxxxxxxxx/announce.php – 2 – 0
http://xxxxxxxxxxxx/announce – 1 – 0
http://xxxxxxxxxxxx/announce – 1 – 0
http://xxxxxxxxxxxx/announce – 1 – 0
http://xxxxxxxxxxxx/announce – 15 – 0
udp://xxxxxxxxxxxx:80/announce – 13 – 0

– c11ba392ef3dd57942112641ce8f1d9b96f0ddd5 – Avgust. Vosmogo

http://torrentz.eu

udp://xxxxxxxxxxxx:80/announce – 62 – 0

https://torrentproject.com

http://xxxxxxxxxxxx/announce – 22 – 0
http://xxxxxxxxxxxx/announce – 26 – 0
http://xxxxxxxxxxxx:6969/announce – 27 – 0
http://xxxxxxxxxxxx:80/announce – 43 – 0
http://xxxxxxxxxxxx/announce – 42 – 0
udp://xxxxxxxxxxxx/announce – 50 – 1

Można zauważyć małą liczbę peerów. Dla porównania przedstawiamy informacje o innych torrentach, bardzo popularnych (dot. serialu Lost) i mniej popularnych (Naruto, Nocznoj Dozor)

– ab53cb0d665b34fcdf1939b271660b48297b5a74 – Lost

http://torrentz.eu

http://xxxxxxxxxxxx:6969/announce – 167 – 932
udp://xxxxxxxxxxxx:80/announce – 157 – 763
udp://xxxxxxxxxxxx:80/announce – 144 – 779
http://xxxxxxxxxxxx:8000/announce – 19 – 188
http://xxxxxxxxxxxx:8080/announce – 16 – 176
http://xxxxxxxxxxxx/announce – 16 – 194
http://xxxxxxxxxxxx/announce – 8 – 23
http://xxxxxxxxxxxx:3310/announce – 6 – 91
http://xxxxxxxxxxxx:6969/announce – 4 – 38
http://xxxxxxxxxxxx/announce.php – 1 – 0
http://xxxxxxxxxxxx/announce.php – 1 – 1
udp://xxxxxxxxxxxx:80/announce – 1 – 11
http://xxxxxxxxxxxx:6969/announce – 0 – 1
http://xxxxxxxxxxxx:9090/announce – 0 – 17
http://xxxxxxxxxxxx:6969/announce – 0 – 32
http://xxxxxxxxxxxx/announce – 0 – 1
http://xxxxxxxxxxxx/announce – 0 – 24

https://torrentproject.com

http://xxxxxxxxxxxx/announce – 139 – 829
http://xxxxxxxxxxxx/announce – 142 – 830
http://xxxxxxxxxxxx:6969/announce – 173 – 948
http://xxxxxxxxxxxx:80/announce – 189 – 1012
http://xxxxxxxxxxxx/announce – 192 – 1016
udp://xxxxxxxxxxxx/announce – 182 – 982

– 799db5ad3c746823a8df170bb1a717835c1dccc8 – Naruto

http://torrentz.eu

http://xxxxxxxxxxxx:3310/announce – 169 – 16
http://xxxxxxxxxxxx:6969/announce – 75 – 12
http://xxxxxxxxxxxx:2710/announce – 71 – 11
http://xxxxxxxxxxxx:8000/announce – 68 – 11
http://xxxxxxxxxxxx:8080/announce – 57 – 10
http://xxxxxxxxxxxx:6969/announce – 23 – 5
http://xxxxxxxxxxxx/announce – 6 – 0
http://xxxxxxxxxxxx/announce – 6 – 2
http://xxxxxxxxxxxx:6969/announce – 3 – 5
udp://xxxxxxxxxxxx:80/announce – 2 – 0
http://xxxxxxxxxxxx:6969/announce – 2 – 2

https://torrentproject.com

http://xxxxxxxxxxxx/announce – 64 – 8
http://xxxxxxxxxxxx/announce – 53 – 4
http://xxxxxxxxxxxx:6969/announce – 64 – 5
http://xxxxxxxxxxxx:80/announce – 57 – 4
http://xxxxxxxxxxxx/announce – 57 – 4
udp://xxxxxxxxxxxx/announce – 60 – 5

– db839a0773d32a8def122f5e930b2ccf4a21ead2 – Nocznoj Dozor

http://torrentz.eu

http://xxxxxxxxxxxx:3310/announce – 27 – 7
http://xxxxxxxxxxxx:6969/announce – 20 – 3
udp://xxxxxxxxxxxx:80/announce – 13 – 2
udp://xxxxxxxxxxxx:80/announce – 1 – 0

https://torrentproject.com

http://xxxxxxxxxxxx/announce – 18 – 6
http://xxxxxxxxxxxx/announce – 14 – 7
http://xxxxxxxxxxxx:6969/announce – 13 – 4
http://xxxxxxxxxxxx:80/announce – 15 – 3
http://xxxxxxxxxxxx/announce – 13 – 3
udp://xxxxxxxxxxxx/announce – 17 – 3

Statystyki dot. badanych torrentów posiadają w większości wielu tzw. seederów i bardzo mało (najczęściej – 0) peerów. Jest to raczej niezwykły rozkład, w większości przypadków proporcje, jeśli nie są zupełnie odwrotne, to nie są aż tak wyraźne.

5. Hipotezy

W wyniku badania ruchu składającego się na anomalie występujące w naszych honeynetach nie udało się jednoznacznie ustalić jego przyczyn i skutków. Oto kilka zebranych hipotez dot. tego ruchu:

5.1 Źródła anomalii

5.1.1. Adresy źródłowe są podrobione.

Taką możliwość potwierdza równomierny charakter jednego ze składników rozkładu adresów oraz – przede wszystkim – adresy źródłowe, które należą do naszych honeynetów, w których żadne węzły nie inicjują transmisji.

5.1.2. Adresy źródłowe są prawdziwe.

W trakcie dokładniejszego badania odnaleźliśmy połączeniową sesję TCP z pakietami BT częściowo odpowiadającym charakterystyce (posiadają taki sam hash). Nawiązanie sesji TCP za pomocą podrobionych adresów źródłowych IP jest możliwe, ale bardzo trudne i praktycznie niemożliwe w sieciach WAN, dlatego można przypuszczać, że adres źródłowy tej transmisji był prawdziwy. Jest również bardzo mało prawdopodobne (głównie ze względu na korelację czasową), że wspomniana sesja była niezwiązana z anomalią. Zawierała podobny pakiet BT (ten sam hash), jednak zawierała też niezerową wartość peera. Niewyluczone, że pod adresem tym funkcjonował zwykły klient uTP lub BT.

5.1.3. Pula adresów źródłowych zawiera zarówno adresy prawdziwe, jak i podrobione.

Najbardziej prawdopodobna możliwość.

5.1.4. Porty źródłowe i docelowe to standardowe porty dla konwersacji uTP.

Tej kwestii nie zbadaliśmy jeszcze dokładnie. Z obserwacji poczynionych w trakcie badań z klientem uTorrent wynika, że ten klient domyślnie oczekuje na połączenia na porcie 12144. Może on zostać zmieniony przez użytkownika lub wylosowany. Porty transmisji mogły zostać wyznaczone na podstawie obserwacji publicznych trackerów.

5.1.5. Źródłem transmisji nie jest zwykły klient uTP, tylko inny program lub skrypt służący innemu celowi niż wymiana danych.

Wskazują na to cechy pakietów uTP – okrągłe wartości timestampów, nieprzestrzeganie protokołu uTP, ignorowanie wiadomości ICMP. Wybieranie adresów docelowych z honeynetów systemu ARAKIS przemawia za tą hipotezą.

5.2 Efekty anomalii

5.2.1. Transmisje służą zatruwaniu sieci uTP/BT

Z danych zebranych z publicznych trackerów wynika, że stosunek seederów do peerów dzielących się plikami o hashu 057a315b89b54e53e2ee583dd5cd9ef60648805e i innych hashach dot. filmu „Avgust. Vosmogo” jest niespotykany i może być wynikiem zatruwania elementów sieci uTP/BT (np. przez dystrybuowanie fałszywych danych dot. peerów – ciągów zer).

5.2.2. Transmisje służą mapowaniu sieci uTP/BT

Możliwe, że transmisje służą do wyznaczenia mapy sieci węzłów sieci uTP/BT. Automat mapujący klasyfikowałby badany węzeł jako klienta uTP na podstawie odpowiedzi:
Poprawna odpowiedź uTP – węzeł jest klientem uTP
Zła odpowiedź uTP – węzeł nie jest klientem uTP

Przeciwko tej hipotezie jednak świadczą następujące fakty:
Pomimo odpowiedzi ICMP Port unreachable źródło wysyła kolejny pakiet, chociaż klasyfikacji można dokonać na podstawie tej odpowiedzi.
Część pakietów posiada sfałszowany adres źródłowy, co praktycznie uniemożliwia automatowi odebranie odpowiedzi i dokonanie klasyfikacji.

5.2.3. Transmisje stanowią atak na systemy teleinformatyczne

Możliwe, że wysyłane pakiety wprowadzają niektóre aplikacje w nieprzewidziany przez ich autora stan – są exploitami. Z pobieżnej analizy publicznie dostępnych informacji dot. podatności klienta uTorrent nie wynika, że ta hipoteza jest prawdziwa, jednak posiadamy za mało wiedzy na temat innych klientów oraz nieopublikowanych luk, żeby stwierdzić to z pewnością. Możliwe, że niektóre cechy pakietów uTP (np. zerowa wartość numeru potwierdzenia) lub BT (zera w polu peer id) mogą wprowadzić niektóre aplikacje w nieprzewidziany stan.

Anomalia poprzez swój charakter (duża część ruchu z całego dnia) stanowi wyraźne zakłócenie pracy systemu teleinformatycznego, czego dobrym dowodem jest generowanie dużej ilości fałszywych alarmów wysokiego poziomu. W kontekście polskiego prawa, europejskiej konwencji o cyberprzestępczości i kodeksów amerykańskich (oraz pewnie wielu innych źródeł prawa w różnych krajach) można dyskutować, czy tworzenie tego ruchu jest zgodne z prawem.

Kodeks karny, rozdział XXXIII, Art. 269a.:

Kto, nie będąc do tego uprawnionym, przez transmisję, zniszczenie, usunięcie, uszkodzenie, utrudnienie dostępu lub zmianę danych informatycznych, w istotnym stopniu zakłóca pracę systemu komputerowego lub sieci teleinformatycznej,podlega karze pozbawienia wolności od 3 miesięcy do lat 5.

Convention on Cybercrime, Chapter 2, Article 5:

Each Party shall adopt such legislative and other measures as may be necessary to establish as criminal offences under its domestic law, when committed intentionally, the serious hindering without right of the functioning of a computer system by inputting, transmitting, damaging, deleting, deteriorating, altering or suppressing computer data.

[…]

Article 7:
Each Party shall adopt such legislative and other measures as may be necessary to establish as criminal offences under its domestic law, when committed intentionally and without right, the input, alteration, deletion, or suppression of computer data, resulting in inauthentic data with the intent that it be considered or acted upon for legal purposes as if it were authentic, regardless whether or not the data is directly readable and intelligible. A Party may require an intent to defraud, or similar dishonest intent, before criminal liability attaches.

5.2.4. Obserwowany przez nas ruch przynajmniej częściowo jest echem

Możliwe, że część zarejestrowanych przez nas pakietów jest echem zdarzeń (incydentów), które wystąpiły w innych sieciach.

5.3. Znaczenie anomalii

5.3.1. Zatruwanie sieci / mapowanie

Za tą tezą przemawiają dane pobrane z publicznych trakerów. Bez wnikania w szczegóły reakcji klientów torrentowych można stwierdzić, że w trackerach rejestruje się mało peerów pobierających dyskutowane zasoby. Możliwe, że jest to wynik funkcjonowania mechanizmów, których nie możemy na razie dokładnie opisać, ale które wywołują rownież opisywaną anomalię. Można bez problemu wskazać przynajmniej jedną grupę potencjalnych autorów i beneficjentów zatruwania sieci uTP: koncerny multimedialne lub ich podwykonawcy. Prowadzenie przez te instytucje tego typu kampanii nie byłoby precedensem. Niewykluczone też, że generowany ruch ma służyć mapowaniu sieci BitTorrent i zbieraniu informacji, które zostaną wykorzystane w innych projektach.

5.3.2. Błędna implementacja / eksperyment

Nieprzestrzeganie protokołu uTP może być wynikiem błędnej implementacji protokołu uTP w mało popularnym lub niedojrzałym kliencie BitTorrentowym. Niewykluczone też, że omawiana anomalia jest wynikiem jakiegoś sieciowego eksperymentu.

5.3.3. Ruch maskujący

Jeśli uznać, że ruch składający się na anomalię zawiera mieszankę prawdziwych i fałszywych źródeł, można wysunąć przypuszczenie, że część tego ruchu posiada dobrze określone przyczyny i skutki, natomiast część (większość) stanowi ruch maskujący. Ruch zawierający poprawne numery sekwencji i adresy (niepowodujący zerwania sesji), pomimo, że w mniejszej ilości, mógłby okazać się efektywny przy zatruwaniu lub mapowaniu sieci uTP.

5.3.4. Echo ataków na inne sieci

Możliwe, że część obserwowanego przez nas w honeynecie ruchu stanowi echo ataku prowadzonego w innych sieciach. Części ruchu, które czynią tą możliwość bardziej prawdopodobną to m.in.: pakiety z flagami uTP STATE (odpowiednik pakietów TCP SYN/ACK przy echach ataków DDoS) oraz transmisje połączeniowe z identyfikatorami peerów, które wyglądają na poprawne.

6. Podsumowanie

Po dotychczasowej analizie opisywanego ruchu nie udało się ustalić jednoznacznie jego źródła ani przeznaczenia. Dlatego w kontekście metodyki prowadzenia testów bezpieczeństwa OSSTMM, oraz uznaniu chronionych systemem ARAKIS sieci jako chronione zasoby, nadal stanowi ona anomalię. Jednak w przeciwieństwie do anomalii powstającech samoistnie (tj. bez udziału człowieka), jak na przykład (w kanale data network COMSEC) widmowe ramki w sieciach Ethernet:

Za Cisco CCNA:

Fluke Networks przyjęło termin „widmowa ramka” na ekreślenie energii (szumu) wykrytego w medium które posiada cechy ramki, ale brakuje mu poprawnego pola SFD.

(tłum. autora)

Rejestrowanie pakiety są na tyle skomplikowane, że można z dużym przypuszczeniem stwierdzić, że zostały zaprojektowane. Wątpliwą kwestią jest jedynie, czy ich postać i ilość jest wynikiem celowego działania (np. zatruwanie sieci), czy też błędem w oprogramowaniu.

W punkcie 5. przedstawiliśy sformułowane przez nas hipotezy dotyczące anomalii.

Być może dokładniejsze badania pozwoliły by zrozumieć naturę opisywanego ruchu i usunąć go z kategorii anomalii.

Glosariusz

μTP – (również: uTP) protokół transportowy wykorzystywany do przenoszenia pakietów protokołu BitTorrent
μTorrent – (również: uTorrent) klient sieci BitTorrent obsługujący protokół uTP
BitTorrent – (również: BT) rozproszona sieć P2P, także protokół zaprojektowany w celu dzielenia się plikami
ARAKIS – system analizy i agregacji incydentów sieciowych stworzony i obsługiwany przez NASK
OSSTMM – (ang. Open Source Security Testing Methodology Manual) podręcznik metodyki przeprowadzania testów bezpieczeństwa
ICMP – internetowy protokół komunikatów kontrolnych
TCP – połączeniowy protokół umożliwiający komunikację pomiędzy aplikacjami sieciowymi
IP – protokół sieciowy służący do przesyłania danych pomiędzy odległymi węzłami
UDP – bezpołączeniowy protokół umożliwiający komunikację pomiędzy aplikacjami sieciowymi