Rozdział IGMP-snooping i testy odpowiedzi Mariusz Tomaszewski Politechnika Łódzka, Katedra Informatyki Stosowanej mtomasz@kis.p.lodz.pl Maciej Szmit Politechnika Łódzka, Katedra Informatyki Stosowanej mszmit@kis.p.lodz.pl Streszczenie W referacie przedstawiono problem wywołany przez niestandardową obsługę multicastów przez tanie urządzenia dostępowe, który występuje w przypadku zdalnego wykrywania trybu ogólnego kart sieciowych przy pomocy testów odpowiedzi. 1. Wstęp Koncepcja multiemisji i adresów grupowych (ang. multicast) jest jednym z elementów protokołu IP w wersji 4. Adresowanie grupowe używane zazwyczaj jako alternatywa dla adresowania rozgłoszeniowego (ang. broadcast) miało w zamyśle na celu zmniejszenie natężenia ruchu sieciowego oraz zmniejszenie obciążenia interfejsów sieciowych maszyn, nie należących do poszczególnych grup multicastowych. W praktyce realizacja multiemisji pozostawia czasem sporo do życzenia, a obsługa multicastów jest bardzo często niedopracowana. Poniżej przedstawiamy jedno z zagadnień, w których niestandardowa obsługa multiemisji przez urządzenia trzeciej warstwy jest przyczyną kłopotów. 2. IGMP-snooping, CGMP, PIM-snooping Jednym z najpoważniejszych problemów związanych z adresowaniem grupowym jest brak obsługi multicastów przez routery łączące różne sieci. Istnieją wprawdzie protokoły i standardy obsługi ruchu multicastowego (porównaj: [8], [9]) jednak ich implementacje w urządzeniach różnych firm potrafią znacznie różnić się międy sobą.
2 I. Nazwisko Najwięksi dostawcy Internetu oferują w swoich sieciach szkieletowych obsługę multicastów, podobnie twórcy sieciowych systemów operacyjnych, w których funkcjonują często programy agentowe działające właśnie w oparciu o multicasty, jednak nie każde urządzenie potrafi multicasty obsłużyć poprawnie. W sytuacji, w której w dwóch segmentach sieci (III warstwy) umieszczone są rozwiązania działające w oparciu o multicasty, ich zachowanie będzie zależało od użytego sprzętu i oprogramowania (por. rys. 1). Multiemisja Sieć 1??? Sieć 2 Rys. 1. Multiemisja w sieci posegmentowanej w trzeciej warstwie W przypadku routera obsługującego protokół IGMP (Internet Group Management Protocol) oraz protokoły routingu multicastowego, multiemisja z sieci 1 może być przekazana do sieci 2, w przypadku routera nie obslugującego IGMP multicast nie zostanie przekazany. Nie każdy router obsługujący IGMP obsługuje specjalne protokołu routingu przeznaczone dla multiemisji (na przykład nie obsługuje ich oprogramowanie routera w Windows 2000 server zobacz [10]), co oczywiście będzie miało negatywny wpływ na możliwość wykorzystania tego routera w większych sieciach, w których powinny być stosowane protokoły dynamicznego routingu pakietów multicastowych. O ile w dużych sieciach korporacyjnych i w Internecie możliwe jest uzgodnienie szczegółów implementacji obsługi multicastów (w szczególności w Internecie funkcjonuje obszar objęty zwany MBone), o tyle małe sieci skazane są na tanie urządzenia, których producenci traktują czasami multicasty z dużą dowolnością. Zgodnie z zasadą hermetyzacji (ang. encapsulation) pakiety IP zaadresowane adresem grupowym (należącym do klasy D) powinny być zapakowane w ramki ethernetowe, w których nagłówku powinien być umieszczony fizyczny adres odbiorcy informacji. W systemie adresów fizycznych MAC adresy grupowe oznaczono poprzez ustawienie wartości 1 najmniej znaczącego bitu najbardziej znaczącego bajtu. Dla przykładu adres 01-00-0C-CC-CC-CC używany jest przez protokół rozpoznawania urządzeń CISCO (Cisco Discovery Protocol, CDP). Spis adresów grupowych Ethernetu można znaleźć w Internecie pod adresem [3]. W przypadku urządzeń trzeciej i wyższych warstw modelu ISO/OSI obsługa multicastów jest stosunkowo prosta. Wystarczy przeadresować przychodzący pakiet multicastowy na adresy (unicastowe) wszystkich urządzeń zaliczonych do danej grupy, przy czym za zgłoszenie się urządzenia do takowej odpowiada protokół zarządzania grupami (ang. Internet Group Management Protocol zobacz [5], [6], [7]). W przypadku urządzeń warstwy drugiej (w szczególności switchy) pojawia się szereg problemów. IGMP jest protokołem warstwy III (operuje na adresach logicznych), zwykłe przełączniki nie mogą go zatem używać. Producenci przełączników sieciowych wypracowali różne podejścia do problemu multicastów. Najmniej eleganckie, ale jak się wydaje najskuteczniejsze z nich, polega na
Tytuł rozdziału... 3 traktowaniu ramek grupowych jak ramki rozgłoszeniowej. Skutkuje to wprawdzie utratą wszelkich korzyści, które różnią multicast od broadcastu, ale za to jest bezpieczne i nie sprawia problemów. Inne podejście zakłada jakiś sposób filtrowania ramek wychodzących ze switcha, tak aby informacja była przekazywana tylko do wybranych urządzeń (zob. rys. 2). A transmisja multicastowa B F C E Rysunek 2. Filtrowanie multicastów (źródło [1]). D W najprostszym przypadku zasady przekazywania multicastów mogą być przez administratora ustawiane ręcznie, jednak jest to wysoce niewygodne, choćby dlatego że multicastami posługują się różne systemy inteligentnych agentów programowych, które mogą być instalowane i używane na różnych maszynach, więc wymagana byłaby ciągła rekonfiguracja zasad, co na dłuższą metę byłoby męczące. Alternatywną metodą jest podsłuchiwanie (ang. snooping) przez switcha komunikatów IGMP (a więc wyposażenie przełącznika w ograniczone rozumienie protokołu warstwy III) dotyczących przyłączania/odłączania się przez urządzenie do poszczególnych grup multicastowych. Technika ta jest nazywana IGMP-snooping. Dla obszarów tranzytowych (ang. transit area) w mbone posługujących się protokołem Protocol Independent Multicast (zobacz: [8]) istnieje analogiczne eksperymentalne rozwiązanie PIM-snooping (zobacz: [4]). Istnieje również rozwiązanie autorstwa firmy CISCO działające w oparciu o firmowy protokół CGMP (Cisco Group Management Protocol) opierające się na wymianie informacji pomiędzy routerem obsługującym grupy multicastowe (III warstwy) a przełącznikiem. Oczywiście wymagane jest, aby oba urządzenia obsługiwały protokół CGMP, co w praktyce zawęża zakres urządzeń stosujących to rozwiązanie do urządzeń CISCO. Jakkolwiek snooping wydaje się stosunkowo łatwy do zaimplementowania, to związane są z nim pewne trudności. Niezgodności w obsłudze multiemisji przez urządzenia drugiej warstwy prowadzą czasem do nieoczekiwanych błędów. W pracy
4 I. Nazwisko [4] opisano dwa przypadki problemów spowodowanych przez niestandardową obsługę multicastów przez switche. Jeden z nich dotyczył programu Norton Ghost, który zawieszał się w obecności przełączników obsługujących IGMP w wersji 3, drugi zbyt inteligentnego przełącznika obsługującego PIM (o czym nie wiedział jego administrator), który to przełącznik wygrywał proces wyboru routera głównego (destignated router) PIM, co prowadziło do skierowanie ruchu multicastowego do niewłaściwej sieci i w konsekwencji do unieruchomienia wszytkich usług działających w oparciu o multicasty. 3. Multicasty a wykrywanie snifferów W naszych referatach (między innymi [11] oraz [12]) prezentowaliśmy program służący do zdalnego wykrywania trybu ogólnego (ang. promiscuous) kart sieciowych za pomocą testów odpowiedzi. Testy te sprowadzają się do przesłania do podejrzanego komputera odpowiednio spreparowanej ramki (z błędym adresem docelowym MAC), w której umieszczony jest pakiet zawierający żądanie odpowiedzi (ARP Request lub ICMP Echo Request) zaadresowany adresem IP podejrzanego komputera. Z uwagi na zaimplementowanie w systemach operacyjnych wirtualne filtry pakietów jedynymi adresami MAC odbiorcy mogą być niektóre z adresów multicastowych (multicastów ethernetowych). W przypadku sieci wykorzystującej koncentratory, w której obecne są zwykłe routery (na przykład komputery z dwiema kartami sieciowymi pracujące pod kontrolą systemu operacyjnego NetWare albo Linux, czy też routery firmy CISCO) dzialanie programu jest zgodne z oczekiwaniem (tj multicasty nie przedostają się wprawdzie na drugą sronę routera ale też nie reaguje na otrzymane ramki. Na nieoczekiwane problemy natrafiliśmy w sieciach wykorzystujących tanie routery (a właściwie router-switche) firm D-link oraz Lucent. Urządzenia te wyposażone są w kilka portów sieciowych (ethernetu), które mogą być przypisane do różnych segmentów sieci wewnętrznej. Zazwyczaj urządzenie posiada wbudowaną obsługę rozwiązań typu NAT (translacja adresów sieciowych na adresy z puli adresów prywatnych np 192.168.xxx.xxx) i interface webowy pozwalający odpowiednio skonfigurować porty. Niestety działanie tych urządzeń w zakresie obsługi multicastów jest dość niestandardowe. Mianowicie przyjmują one, że w przypadku otrzymania ramki zaadresowanej grupowym adresem MAC, należy jej zawartość przesłać do komputera w segmencie, z którego ramka nadeszła jako ramkę unicastową, tak aby adres odbiorcy ramki był adresem MAC komputera, którego IP zawarte jest w pakiecie niesionym przez ramkę. W przypadku wysłania multicastowej ramki zawierającej broadcastowy pakiet urządzenie prześle do sieci broadcastową ramkę z broadcastowym pakietem. Mechanizm ten występuje w przypadku, gdy przesyłany jest pakiet IP i wyłącznie wtedy, gdy multicastowy MAC jest z zakresu FF:FF:FF:FF:FF:00-FF:FF:FF:FF:FF:FE (przynajmniej w przypadku testowych przez nas urządzeń D-Link). W przypadku pakietu ARP-reply i innych multicastowych MACów mechanizm ten nie działa. Jest to zachowanie zbliżone do zachowania m-routera: urządzenie zamienia multicast na unicast dla sieci wewnętrznej, tej z której multicast otrzymało (zobacz rysunek 3), zmniejszając jednocześnie TTL pakietu IP o
Tytuł rozdziału... 5 jedność, traktuje więc wszystkie komputery w segmencie jako człownków odpowiednich grup multicastowych. D A transmisja multicastowa (multicast MAC i unicast IP) Krok 1 C B D Krok 2 A C B Unicast Rysunek 3. Konwersja multiemisji na unicasty Konsekwencją takiego zachowania się urządzenia jest w przypadku testów odpowiedzi fałszywe wykrycie (ang. false positive) snifferów na wszystkich sprawdzanych komputerach w segmencie (komputery otrzymuja pytanie w ramce zaadresowanej prawidłowym unicastowym adresem MAC, na które powinny odpowiedzieć). Dokładniej w segmencie pojawiają się dwa pytania jedno w ramce multicastowej (na które odpowiadają tylko komputery z interfejsem pracującym w trybie promiscuous o ile oczywiście są wrażliwe na ten rodzaj testu (porównaj [12]) oraz drugie (w ramce unicastowej), na które odpowie każdy z komputerów. Co gorsza, jeśli w sieci jest więcej niż jedno tego typu urządzenie, co zdarza się w przypadku podziału sieci wewnętrznej (konfiguracja stosowane często na przykład w pracowniach studenckich, każda z pracowni znajduje się za osobnym routerem) liczba ramek odpowiednio się zwiększa (porównaj rys. 4).
6 I. Nazwisko Sieć wewnętrzna 1 Internet Sieć wewnętrzna 2 dostępowy Sieć wewnętrzna 3 Rysunek 4. Segmentacja sieci wewnętrznej 4. Rozwiązanie problemu Nasuwającym się rozwiązaniem było dodanie do wykrywającego sniffery przy pomocy testu odpowiedzi ICMP programu zliczania multiplikacji ramek poprzez wysłanie, przed uruchomieniem właściwego testu, ramki multicastowej zawierającej pakiet adresowany do komputera na którym uruchomiono program i zliczenie przychodzących ramek unicastowych. Z kolei w testach odpowiedzi informację o wykryciu sniffera należało umieścić w przypadku, gdy liczba przychodzących odpowiedzi jest o jeden większa niż liczba wykrytych urządzeń. Rozwiązanie to zostało zaimplementowane w kolejnej wersji programu WinAntiSniffer, która można znaleźć w sieci pod adresem [13]. LITERATURA 1. Fairhurst G. Ethernet es, Department of Engineering at the University of Aberdeen http://www.erg.abdn.ac.uk/users/gorry/course/lan-pages/switch.html (odsyłacz sprawdzony 22.01.2006) 2. IP-Multicasting Technology Part 2: es vs. s http://www.intelligraphics.com/articles/ipmulticasting2_article.html (odsyłacz sprawdzony 22.01.2006) 3. Multicast (including Broadcast) Addresses http://www.cavebear.com/cavebear/ethernet/multicast.html 4. Multicasts on the LAN, Internet2 Engineering Workshop http://andrew.triumf.ca/ag/multicast/internet2-multicast-workshop-may-2004-2-lan- SSM.pdf 5. Deering S. Host Extensions for IP Multicasting, RFC 1112
Tytuł rozdziału... 7 6. Fenner W. Internet Group Management Protocol, Version 2, RFC2236 7. Cain B., Deering S., Kouvelas I., Fenner B., Thyagarajan A., Internet Group Management Protocol, Version 3, RFC 3376 8. Adams A., Nicholas J., Siadak W. Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised), RFC 3973 9. Technika IP multicast czeka na odkrycie NetWorld 9/2000 http://www.networld.pl/artykuly/7089.html (odsyłacz sprawdzony 22.01.2006) 10. Network Infrastructure in Windows 2000 http://www.netscum.dk/technet/prodtechnol/windows2000serv/plan/int2ksrv/c0618759.mspx (odsyłacz sprawdzony 22.01.2006) 11. Szmit M., Gusta M., Tomaszewski M., Budowa, działanie i wykrywanie snifferów w sieci ethernet. Materiały konferencyjne X Konferencji Sieci i Systemy Informatyczne Łódź 2002 str. 197-215 12. Tomaszewski M., Szmit M., Zdalne wykrywanie trybu ogólnego interfejsu sieciowego w wybranych systemach operacyjnych, Wysokowydajne sieci komputerowe. Zastosowania i bezpieczeństwo, Wydawnictwa Komunikacji i Łączności, Warszawa 2005, str. 723-727 13. Program WinAntiSniffer http://m--szmit.republika.pl/zasoby.html (odsyłacz sprawdzony 22.01.2006)