samoczynny smurfing

Witam,
postanowiłam odwołać się do tego forum, gdyż wydaje mi się, że są tu ludzie którzy będą w stanie mi pomóc.

Posiadam w domu małą sieć komputerową składającą się z jednego routera wifi, oraz 2 komputerów : jeden jest podłączony przez LAN, a drugi przez wifi. Mój problem polega na tym, że przedwczoraj nagle komputer który był podłączony przez LAN przestał pobierać od serwera dhcp routera ip i ustawiał sobie ip 169.254.3.197 oraz stracił możliwość łączenia się z internetem. Co więcej w logach routera można było odczytać wpisy typu (pomijając datę, bo ciągle się w routerze wyzerowuje):

Kod:

---

2004-12-18  00:14:03 **Smurf** 169.254.255.255->> 169.254.3.197, Type:3, Code:3 (from WAN Outbound)
2004-12-18  00:13:47 **Smurf** 169.254.255.255->> 169.254.3.197, Type:3, Code:3 (from WAN Outbound)
2004-12-18  00:13:46 **Smurf** 169.254.255.255->> 169.254.3.197, Type:3, Code:3 (from WAN Outbound)
2004-12-18  00:13:45 sending OFFER to 192.168.2.100

---

Zaczęłam próby rozwiązania tego problemu, lecz żadna nie przyniosła skutku. Podłączając komputer, który wcześniej szedł przez wifi przez ten sam LANowy kabel co ten drugi nie miałam żadnych problemów z internetem i smurfingiem. Podłączając 'wadliwy' komputer bezpośrednio do sieci z pominięciem routera też nie udało mi się uzyskać połączenia z internetem (dhcp na modemie chello nie chciało wysłać poprawnego ip). Windowsa na 'wadliwym' kompie przeinstalowałam i przeskanowałam jednak nie miało to chyba większego sensu bo problem powtarzał się gdy uruchamiałam tego kompa z linuksowego live cd.
Po wielu próbach i resetach routera i modemu nieco odwróciłam sytuację podłączając router z mac adresu kompa 'dzialajacego' i podciągajac jeszcze jeden LAN pod ten 'wadliwy'. Z chwilą podłączenia 'wadliwego' kompa do sieci zaczyna się następna fala smurfingu i syn floodowania.

Tutaj kilka logów: http://wklej.org/id/361f6f6971 , http://www.wklej.org/id/68210e3343

Nie mam pojęcia co mogłoby powodować tę falę ataków DoS skoro nie jest to wina jakiegoś wirusa na dysku.

Będę bardzo wdzięczna za każdą możliwą pomoc :)

O ile pamietam 169.254.*.* to klasa adresowa ktorej Windows uzywa jesli nie moze znalezc adresu przez DHCP. Ciekawe jest to, ze log ktory pokazales to log z routera jak rozumiem i widac ze router nie filtruje pakietow wypuszczanych na swiat albo ja nie rozumiem okreslenia '(from WAN Outbound)' w takim sensie jak rozumieja to autorzy softu routera hehe.

Sprawa jest dosc prosta... ustaw wszystko tak jak masz - aby w logu routera byly bledy jak te co pokazales. W tym samym czasie gdy beda pojawiac sie bledy odpal na linuxie jako root polecenie:

Kod:

---

tcpdump -n -s 0 -c 50000 -i eth0 -w log.cap

---

W ten sposob zalogujesz 50k pakietow w sieci LAN ktore ida miedzy komputerami. Postaraj sie jednak nie uzywac specjalnie zadnych wiekszych uslug, tzn nie laz chwilowo po stronach, nie sciagaj plikow... Jesli calosc bedzie trwala dluzej niz 15 minut i w logu nadal beda 'smerfy' to zacznij normalnie korzystac z komputera - cos przeslac itd ale nic wartosciowego - unikaj poczty/ftp/forow :) nie chce miec Twoich loginow i hasel :D

Po jakims czasie program sam zakonczy swoje dzialanie, wtedy spakuj plik log.cap z haslem, wrzuc gdzies skad moge sciagnac i podaj na PM url do pliku i haslo do archiwum. Postaram sie cos z tego wyciagnac aby zdiagnozowac co sie dzieje.

Jak na razie wyglada mi to na sytuacje, gdzie te pakiety nie trafiaja w ogole do LAN ale przyblokowuja router...

hm... a ile powinno trwać to pobieranie logow? bo juz 4 godziny tpcdump idzie a plik ma ponad 12 mb.

No to jak ma juz tyle to wystarczy - daj Ctrl+C i po sprawie, dalej spakuj, itd - jak pisalem wczesniej.

Ok - dzieki za pliczek - gratuluje dotrzymania do calych 27.5MB :)
50k pakietow to juz jest cos konkretnego do analizy hehe... pierwsze podejscie skonczylem i to co na razie widze, to:

1. Twoj router rozsyla zapytania IGMP na adres multicast najprawdopodobniej na wszystkich interfejsach jakie ma - nie ma tego jednak wiele. Dziwi mnie tylko, dlaczego wysyla to na interfejsie sieci LAN na adres MAC ktorego w tej sieci nie ma - hmmmm... pewnie mialo to isc do sieci WAN :)
Powiedzialbym, ze to jeszcze nie tragedia, mozna olac i zostawic jak jest...

2. Wystepujace w logu linie '**SYN Flood to Host**' podaja dodatkowo '(from WAN Inbound)' co dokladnie sie zgadza - to serwery irc... router zglasza duza liczbe polaczen przychodzacych - jaki ma poziom czulosci ustawiony - nie wiem, ale zglasza ze jak na jego gust to jest za duzo :) Tylko dlaczego serwery IRC chca sie laczyc z Twoim kompem ktory jest za NAT'em to juz nie wiem - ich problem hehe.

Gwozdz programu...

3. Karta sieciowa Chaintec - MAC 00:50:70:A1:08:C8 - to badziewie nie dostalo adresu przez DHCP, windows przydzielil adres z puli 169.254.0.0/16 (tym razem dokladnie 169.254.7.28) i to cos rozsyla co 12-13 sekund po 8-14 pakietow UDP prubujac znalezc w sieci LAN komputery ktore chca gadac przez otoczenie sieciowe (szuka innych windowsow aby zobaczyc co udostepniaja w otoczeniu sieciowym). Najpierw szuka tzw. Master Browser'a a gdy nie dostaje odpowiedzi szuka innych maszyn w grupie roboczej MSHOME - jest to wiec najpewniej jakis anglojezyczny Windows (MSHOME to domyslna nazwa grupy roboczej w anglojezycznym WinXP na przyklad).

Skad teraz biora sie wpisy w logach mowiace o ataku SMURF i to jeszcze "from WAN Outbound"? Router widzi te pakiety i przesyla dalej, poniewaz nie sa adresowane do jego sieci LAN. Jest to normalne zachowanie routerow. Loguje je jeszcze z adresem LAN zrodla, ale po chwili puszcza je na interfejs WAN, robiac po drodze NAT, czyli przy wyjsciu na swiat widac je z adresem WAN routera (tutaj moge sie tylko domyslac ze tak wlasnie jest - wiekszosc routerow tak robi). Oczywiscie adresat to 169.254.255.255 czyli broadcast dla tej klasy B - efekt oczywisty, router rozpoznaje to jako SMURF'a (z reszta nieprawidlowo).

WNIOSEK:
Powiedzialbym, ze ten USRobotics (router) jest zle skonfigurowany - jedynie punkt 2 powyzej jest prawidlowym zachowaniem jak widac z loga, choc mozna sie klocic, dlaczego akurat przy takiej ilosci polaczen zglasza blad - moze przydalby mu sie tuning parametrow, moze nie - nie wiem, nie widze konfiguracji.
Na 100% zla konfiguracja jest podnoszenie alarmu o ataku SMURF gdy pakiety przechodzace przez router sa adresowane na broadcast. Najwidoczniej jest to jedyne kryterium oceny i kwalifikowania pakietow a to nie jest juz dobrze... Po pierwsze taki pakiet nie powinien w ogole wyjsc z routera (a jesli jest zatrzymywany dalej to nie powinien powstawac wpis w logu), po drugie SMURF uzywa ICMP a nie UDP jak pakiety net-bios ktore tutaj powoduja takie zamieszanie, po trzecie router nie loguje wszystkich podejrzanych pakietow - z wklejonych logow widac ze lapie i raportuje jedynie co ktorys i to bez widocznych regul - cos na zasadzie, 'jak zdaze zlapac i przeczytac, to Ci opowiem' - ocena dla zespolu inzynierow u producenta - naciagane 3+.

ROZWIAZANIE:
Rozwiazan nie ma wiele... ja polecilbym w sumie dwa:
1. Znalezc kompuer co ma karte o adresie MAC 00:50:70:A1:08:C8 (bedzie to cos windowsowego na 99% i to pewnie anglojezyczne) i odlaczyc dziada od sieci.
2. Olac temat i przestac czytac logi - nie polecam, ale moze to byc jedyny sposob jesli nie nzajdziesz "sprawcy". 169.254.*.* to w wiekszosci przypadkow windowsy (o czym tutaj mowi poszukiwanie MSHOME i charakterystyka sposobu wysylania pakietow - natretnie, bez logiki, drze jape az ktos moze uslyszy, ehhh) ktore nie dostaly IP z DHCP (to moze dotyczyc tez nie-windowsow).

RFC 3300 mowi jasno:

Cytat:

---

Napisał http://www.faqs.org/rfcs/rfc3330.html

169.254.0.0/16 - This is the "link local" block. It is allocated for
communication between hosts on a single link. Hosts obtain these
addresses by auto-configuration, such as when a DHCP server may not
be found.

---

Skad jednak w sieci LAN wziela sie karta, ktora jest podlaczona a nie dostaje IP z DHCP?! Czyzby router mial filrowanie adresow MAC i ta karta nie byla dopisana (wtedy nie dostanie nic z DHCP i powstanie taka sytuacja). Moze to komputer z 2 kartami i sa one w trybie bridge i cos gdzies nie dziala jak trzeba (teoretycznie nie ma to prawa tworzyc takich problemow ale jestem za stary aby tak powiedziec - kilka razy juz to widzialem w praktyce).

To by bylo na tyle - mam nadzieje ze odpowiedz zadowalajaca i wystarczajaco dokladna i choc troche 'na wesolo' hehe. Jakos nie widze w tych pakietach nic wiecej co byloby dziwne - regularny ruch internetowy, zadnych specyficznych rzeczy.

Jesli masz jeszcze jakies pytania, to smialo :)

Dziękuję za taką obszerną odpowiedź, miło jest się dowiedzieć co i dlaczego się dzieje :)

Sproboje pokombinowac w takim razie z tym dlaczego ta karta nie chce zadnego ip od dhcp uzyskac (pomimo tego ze router widzi ten komputer pod dobrym ip - 192.168.2.102), moze sie zepsula. A jak nie to sproboje z inna karta, moze wtedy ruszy.

Jeszcze raz wielkie dzieki za wytlumaczenie sytuacji :D