IGMP-snooping i testy odpowiedzi (PDF Available)

Rozdział
IGMP-snooping i testy odpowiedzi
Mariusz Tomaszewski
Politechnika Łódzka, Katedra Informatyki Stosowanej
[email protected]
Maciej Szmit
Politechnika Łódzka, Katedra Informatyki Stosowanej
[email protected]
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
Router
???
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
B
transmisja multicastowa
C
Switch
F
E
D
Rysunek 2. Filtrowanie multicastów (źródło [1]).
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)
A
B
B
Switch
D
Krok 1
C
Switch
Krok 2
C
Router
Unicast
Router
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
Router
Internet
Sieć
wewnętrzna 2
Router
Switch
Router
Sieć
wewnętrzna 3
Router
dostępowy
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.
2.
3.
4.
5.
Fairhurst G. Ethernet Switches, 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)
IP-Multicasting
Technology
Part
2:
Switches
vs.
Routers
http://www.intelligraphics.com/articles/ipmulticasting2_article.html (odsyłacz sprawdzony
22.01.2006)
Multicast
(including
Broadcast)
Addresses
http://www.cavebear.com/CaveBear/Ethernet/multicast.html
Multicasts
on
the
LAN,
Internet2
Engineering
Workshop
http://andrew.triumf.ca/AG/multicast/internet2-multicast-workshop-may-2004-2-LANSSM.pdf
Deering S. Host Extensions for IP Multicasting, RFC 1112
Tytuł rozdziału ...
6.
7.
8.
9.
10.
11.
12.
13.
7
Fenner W. Internet Group Management Protocol, Version 2, RFC2236
Cain B., Deering S., Kouvelas I., Fenner B., Thyagarajan A., Internet Group Management
Protocol, Version 3, RFC 3376
Adams A., Nicholas J., Siadak W. Protocol Independent Multicast - Dense Mode (PIM-DM):
Protocol Specification (Revised), RFC 3973
Technika
IP
multicast
czeka
na
odkrycie
NetWorld
9/2000
http://www.networld.pl/artykuly/7089.html (odsyłacz sprawdzony 22.01.2006)
Network
Infrastructure
in
Windows
2000
http://www.netscum.dk/technet/prodtechnol/windows2000serv/plan/int2ksrv/c0618759.mspx
(odsyłacz sprawdzony 22.01.2006)
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
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
Program WinAntiSniffer http://m--szmit.republika.pl/zasoby.html (odsyłacz sprawdzony
22.01.2006)