PROXY NARZĘDZIA ZWIĘKSZAJĄCE
POZIOMY BEZPIECZEŃSTWA

Najważniejsze zagadnienia:

1. Serwer Proxy

2. Korzystanie z serwera Proxy

3. Filtrowanie kontrolą dostępu

4. Zarządzanie

5. Bezpieczna i odporna sieć

6. SOCKS

7. Udostępnienie usług na zewnątrz

8. Proxy ARP jako alternatywa dla podsieci

 
   

Serwer Proxy

Serwer proxy (ang. proxy server) przechwytuje i bada ruch na poziomie warstwy aplikacji TCP/IP. Od użytkownika sieci prywatnej wymaga się, aby najpierw połączył się
z serwerem proxy, zanim będzie łączyć się z serwerem aplikacji w Internecie. Większość serwerów proxy tworzących ściany ogniowe oferuje usługi TELNET i FTP. Ponieważ usługi te znajdują się w warstwie aplikacji, wymagane są oddzielne serwery proxy dla każdej z nich. Klient proxy może być implementowany na kilka sposobów tak, jak pokazano w dalszym tekście.

Zadaniem serwera proxy jest przechwycenie połączenia użytkownika z aplikacją internatową, uwierzytelnienie użytkownika, sprawdzenie, czy ma prawo korzystania
z aplikacji i dopiero wtedy zezwolenie na dostęp do serwera w Internecie. Podobne usługi są świadczone użytkownikowi nawiązującemu łączność od strony Internetu, jeśli chce mieć dostęp do serwera aplikacji w prywatnej sieci.
 
 

Na rysunku 1 przedstawiono zasadę pracy usługi TELNET z wykorzystaniem serwera proxy. Klient usługi TELNET (A) znajduje się w sieci prywatnej. Aby skorzystać z usługi, klient A rejestruje się w serwerze proxy TELNETu na komputerześcianie ogniowej. Serwer proxy sprawdza tożsamość klienta oraz to, czy dany użytkownik ma dostęp do usługi TELNET w Internecie. Jeżeli tak, użytkownik uzyskuje zgodę na wysłanie żądania TELNET do komputera w sieci Internet. Przykładowa procedura korzystania z serwera proxy jest opisana poniżej.
 
 

l. Klient A znajdujący się w sieci prywatnej wysyła żądanie usługi TELNET do komputera-ściany ogniowej. Jest to nowa procedura postępowania, ale nie wymaga modyfikacji oprogramowania użytkownika.

2. Serwer proxy usługi TELNET wysyła użytkownikowi prośbę o wprowadzenie identyfikatora i hasła.

3. Użytkownik wprowadza identyfikator i hasło. Server proxy sprawdza tożsamość użytkownika poprzez weryfikację jego identyfikatora i odpowiadającego mu hasła. Jeżeli użytkownik nie zostanie uwierzytelniony, jego żądanie zostaje odrzucone. Jeżeli zaś uwierzytelnienie użytkownika powiedzie się, przechodzi się do kroku 4.

4. Użytkownik wysyła żądanie TELNET do serwera TELNETu na komputerze B
w Internecie.

5. Serwer B sprawdza tożsamość użytkownika. Jeżeli uwierzytelnienie użytkownika powiedzie się, przechodzi się do kroku 6. W przeciwnym wypadku żądanie jest odrzucane.

6. Cały ruch pakietów przepływających od klienta A do serwera B jest przechwytywany przez program ściany ogniowej, który zastępuje adres źródłowy pakietu IP swoim adresem. W ten sposób zapobiega się udostępnianiu adresów wewnętrznych komputerów w sieci prywatnej komputerom w Internecie.[1]

Korzystanie z serwera proxy

Jak wcześniej powiedziano technika proxy wymaga implementacji serwera proxy na komputerze pełniącym rolę ściany ogniowej. Po stronie klienta można wybrać jedno z trzech rozwiązań:

l. Zmienić procedurę uruchamiania usługi przez użytkownika: można zmodyfikować procedurę postępowania użytkownika tak, aby uwzględniała pośrednictwo ściany ogniowej. Ten sposób przedstawiliśmy przy omawianiu zasady pracy serwera proxy. Ważną zaletą takiego podejścia jest to, że nie wymaga ono zmian w oprogramowaniu klienta. Pozwala więc realizować dostęp do Internetu za pomocą standardowego oprogramowania. Metoda ta jest bardzo atrakcyjna, jeżeli weźmie się pod uwagę wielkość oferty oprogramowania TCP/IP pracującego po stronie klienta.

Wadą tej metody jest to, że użytkownik musi być przeszkolony, gdyż musi wykonać dodatkowe czynności związane z rejestrowaniem się na serwerze proxy. W dużych instytucjach, korzystających z aplikacji TCP/IP od długiego czasu, takie szkolenie użytkowników może być procesem czasochłonnym i drogim.

2. Dostosować oprogramowania klienta: metoda ta wymaga modyfikacji oprogramowania klienta i zapewnia użytkownikom przezroczysty dostęp do Internetu.

Przezroczystość ta jest osiągnięta za pomocą odpowiednio zmodyfikowanego oprogramowania klienta i ściany ogniowej, która przechwytuje i ukierunkowuje ruch pakietów generowany przez aplikację.

3. Zastosować technikę "niewidzialnego proxy" (ang. invisible proxy): w tym wypadku, zarówno oprogramowanie klienta, jak i procedury użytkownika, nie wymagają zmian. Wszystkie zmiany wykonane są w oprogramowaniu ściany ogniowej. Z punktu widzenia klienta wymaga to takiego wyznaczania trasy pakietu, aby cala komunikacja do i z Internetu realizowana była za pośrednictwem ściany ogniowej. Użytkownik wysyła żądanie potączenia z serwerem w Internecie. Ściana ogniowa, przejrzysta dla użytkownika, przechwytuje je, sprawdza tożsamość użytkownika, weryfikuje żądanie i w zależności od wyniku realizuje połączenie.

W momencie podłączenia sieci do Internetu ruch sieciowy wzrasta w tempie wykładniczym, powodując szereg problemów. Administrator staje wtedy przed potrzebą regulowania obciążenia sieci tak aby zapewnić dostęp do istotnych źródeł informacji jednocześnie ograniczając połączenia z nieodpowiednimi serwisami, eliminując wirusy i selektywnie szyfrować transmisje w celu zapewnienia poufności. Rozwiązaniem tego typu problemów jest właśnie proxy serwer (cache server), będący efektywnym systemem replikującym
i filtrującym dostęp do określonych serwerów Web. Istotnie obniża obciążenie sieci, steruje dostępem do zasobów i ma możliwość kodowania transmisji. Jak sama nazwa (cache) mówi - są to serwery podręczne mające za zadanie przetrzymywanie przez określony czas danych, których zażądał użytkownik.
 
 

Efektywna replikacja

Moduł replikacyjny Proxy Servera kopiuje określone dane tylko wtedy, kiedy jest to potrzebne. Redukuje to w istotny sposób czas odpowiedzi na żądania przeglądarek Web komunikujących się z zasobami Intranet i Internet. Replikacja na żądanie jest inteligentnym systemem powielającym, umieszczającym często czytane dokumenty w pamięci notatnikowej (cache) serwera. Oczywiście Proxy Server bada wersje i daty dokumentów zapewniając zawsze dostęp do aktualnej informacji. Istnieje także możliwość kopiowania zawartości określonych serwerów z wyprzedzeniem, co może być bardzo użyteczne w utrzymywaniu sprawnego systemu informacyjnego w przedsiębiorstwie o rozproszonej topologii.

• Efektywna, przeźroczysta replikacja dokumentów Web na żądanie.

• Automatyczne kierowanie odwołań HTTP do serwera Proxy i dostarczanie aktualnych dokumentów z pamięci notatnikowej.

• Możliwość kopiowania pojedynczych stron lub całych serwisów.

• Możliwość replikacji poprzez komendy pracujące w tle.

• Odświeżanie danych w pamięci notatnikowej w określonych przedziałach czasowych w celu zabezpieczenia się przed utrudnionym dostępem w godzinach szczytu.

• Serwery odległe są informowane przez Proxy o dostępie nawet w przypadku pobierania stron z pamięci wewnętrznej (cache).

• Możliwość budowania hierarchicznych łańcuchów serwerów Proxy.

• Sterowanie dostępem do zasobów poprzez gwarantowanie lub odrzucanie odwołań na bazie identyfikatora/hasła użytkowego, grup użytkowników, adresów IP, nazw DNS (z możliwością użycia tekstowych wyrażeń reguralnych).

• Skanowanie przychodzących plików pod kątem wirusów transmitowanych poprzez HTTP lub FTP. Alarmowanie administratora w przypadku wykrycia wirusa.

• Filtrowanie zawartości dla odnośników URL, typów MIME i tagów HTML.

Filtrowanie i kontrola dostępu

Proxy Server może kontrolować dostęp do określonych dokumentów, kartotek lub serwerów. Administrator może sterować dostępem w oparciu o następujące mechanizmy: identyfikator/hasło, adres IP, nazwy odległych komputerów i dowolnie komponowane wzorce nazw domenowych DNS. Serwer sprawdza także zawartość transmitowanych stron pod kątem istnienia wirusów.

Wysokowydajny pomost

Skalowalność i wysoka wydajność czyni z Proxy Servera optymalne rozwiązanie problemu bezbolesnej komunikacji w sieciach Intranet i Internet. Obsługa bibliotek programistycznych Netscape Server Plug-in API pozwala wdrożyć dowolne inne technologie i zintegrować je
z działającym systemem, dostosowując rozwiązanie do indywidualnych potrzeb.

Proxy Server pracuje w oparciu o wysokowydajny motor HTTP pozwalający utrzymywać pamięć notatnikową o rozmiarze do 128GB z 70 milionami unikalnych adresów URL.

Zarządzanie

Proxy Server może być łatwo umieszczony w sieci serwerów pośredniczących, tworząc inteligentny system, łatwo konfigurowalny przez administratora. Serwery mogą być ustawione w łańcuch o określonej hierarchii i optymalnie użytkowane za pośrednictwem techniki APC (Automatic Proxy Configuration), wdrożonej w Netscape Communicatorze. Serwer może być także administrowany z odległej stacji roboczej przy pomocy Communicatora z zapewnieniem poufności transmisji. Interfejs administratora jest prosty
i intuicyjny, czyniąc wszystkie zadania proste w realizacji. Dodatkowo, serwer jest zgodny ze standardem SNMP Ver. 1 i 2, co ułatwia integrację z innymi systemami zarządzania sieciami.

Bezpieczna i odporna sieć

O efektywności sieci decyduje jej najsłabszy punkt, którym najczęściej jest brama do Internetu. Z drugiej strony, poza pocztą elektroniczną, usługi Web są aktualnie najczęściej wykorzystywane w Intranet i Internet. Proxy Server to rozwiązanie zarówno bezpieczne jak i efektywne. Jest to pomost do usług Internet, przez który przechodzą wszelkie odwołania do serwerów Web. Oznacza to, że użytkownicy sieci lokalnej nie mają bezpośredniego dostępu do Internetu, ale korzystając z Proxy postrzegają serwery informacyjne tak, jakby łączyli się
z nimi bez pośredników. Jest to rozwiązanie nader bezpieczne, bowiem nie wymaga połączenia całej sieci z Internet, a jedynie serwera Proxy. Stacje robocze są zatem odcięte od Internetu, a Proxy Server pracuje jak firewall. Jest to także rozwiązanie, dzieki któremu możemy regulować ruch w sieci. Administrator może ograniczyć dostęp do pewnych popularnych serwerów. Wszystkie transmisje są szczegółowo monitorowane i mogą być później analizowane pod kątem np. wewnętrznego systemu rozliczeń.

Dzięki możliwości automatycznych odpowiedzi oraz połączeń z innymi serwerami Proxy
w przypadku braku dostępu do odległego serwisu informacyjnego, Proxy Server powiększa także stopień odporności sieci.

Korzyści

Proxy Server wyraźnie podwyższa prędkość pracy w sieci i podnosi jej ogólną wydajność, jednocześnie mając możliwość sterowania dostępem do określonych serwisów i monitorowania wszystkich transmisji.
 
 

Szyfrowanie i kodowanie transmisji

• Kodowanie transmisji na bazie szeroko zaakceptowanego standardu SSL 3.0.

• Pracuje jako pośrednik w odwołaniach stacji roboczych do zewnętrznych zasobów informacyjnych.

• Bezpieczna obsługa serwerów Web poza ścianą ognia poprzez akceptowanie połączeń SSL z przeglądarkami oraz ustanawianie nowych sesji SSL z serwerami.

• Monitorowanie i archiwizowanie wszystkich połączeń HTTP, FTP i Gopher w poszerzonym formacie.

• Automatycznie informuje przeglądarki w przypadku zamknięcia dostępu do zasobów zewnętrznych.

• Przekierowuje ruch HTTP do innego serwera Proxy w przypadku braku dostępu do serwera pierwotnego.

Krótko

• Replikacja na żądanie i za pomocą poleceń systemowych.

• Przekierowywanie do innych serwerów pracujących w łańcuchu.

• Sterowanie dostępem, filtrowanie adresów URL i skanowanie pod kątem transmitowanych wirusów.

• Automatyczna konfiguracja.

• Kodowana odległa administracja.

• Automatyczna obsługa przepełnień i balansowania obciążeń.[5]

SOCKS

SOCKS jest systemem proxy, w którym zakłada się, że oprogramowanie klienta jest dostosowywane do usług proxy. Modyfikacja polega na takiej zmianie programu klienta, aby pakiety wysyłane z sieci prywatnej do komputera w Internecie mogły być przechwycone przez serwer umieszczony na komputerze-ścianie ogniowej. Najczęściej wykorzystywanym pakietem realizującym tego typu połączenie jest pakiet SOCKS, który zawiera server SOCKS, bibliotekę klienta i zmodyfikowane wersje klientów podstawowych usług takich jak FTP i TELNET.
 
 

Rysunek 2. Ściana ogniowa oparta o protokół SOCKS
 
 

Na rysunku 2 przedstawiono typową implementację protokołu SOCKS. SOCKS wymaga modyfikacji klienta TCP/IP, tak aby przystosować go do współpracy serwerem SOCKS modyfikacja ta polega na zastąpieniu podstawowych, standardowych funkcji związanych
z realizacją usług sieciowych funkcjami z biblioteki SOCKS.

Zmodyfikowany klient często określany jest słowem socksified. Taki klient wywołuje funkcje SOCKS w sposób przezroczysty dla użytkownika. Serwer SOCKS rezyduje na komputerze pełniącym rolę ściany ogniowej i współdziała z odpowiednio dostosowanym klientami. Serwer w Internecie, z którym się komunikujemy, nie wymaga żadnej zmiany. Poniżej opisano działanie protokołu SOCKS w wersji 4.

Celem protokołu jest zdefiniowanie ogólnych zasad pracy aplikacji TCP/IP, takich aby mogła ona bezpiecznie korzystać z usług ściany ogniowej. Protokół ten jest niezależny od aplikacji, w której ma być zaimplementowany. Kiedy klient TCP/IP żąda dostępu do serwera aplikacji, program klienta musi najpierw otworzyć połączenie TCP/IP do serwera SOCKS. Standardowym numerem portu dla usługi SOCKS jest 1080. Jeżeli połączenie zostanie zaakceptowane, program klienta wysyła dane o żądanym połączeniu do serwera SOCKS. Zawierają one następujące informacje:

- port docelowy ,

- adres docelowy,

- informacje uwierzytelniające.

Serwer SOCKS weryfikuje dane zawarte w żądaniu. W wyniku tego akceptuje żądanie
i ustanawia połączenie do serwera internetowego, albo żądanie odrzuca. Ocena zależy od danych konfiguracyjnych serwera SOCKS. W każdym z przypadków serwer SOCKS wysyła odpowiedź do klienta. Odpowiedź ta zawiera informację, czy żądanie zostało zakończone powodzeniem.

Wyraźną zaletą protokołu SOCKS jest jego przezroczystość dla użytkownika. Ma on dostęp do Internetu nie zdając sobie sprawy z istnienia ściany ogniowej. Nie jest wymagane szkolenie. Jednakże podejście to wymaga zmian w oprogramowaniu klienta. Oznacza to modyfikację oprogramowania stacji użytkownika. Modyfikacja ta może być wykonana
w warstwie aplikacji lub na poziomie kodu TCP/IP. W pierwszym podejściu każda aplikacja-klient, taka jak TELNET lub FTP, musi być poddana modyfikacji wiążącej ją z protokołem SOCKS (socksified). Alternatywnie, protokół SOCKS może być zaimplementowany
w podstawowym stosie TCP/IP i w ten sposób siać się przezroczystym dla aplikacji. Wtedy każda aplikacja TCP/IP może korzystać z usług SOCKS.
 

Udostępnianie usług na zewnątrz

Instytucja można posiadać pliki, przykładowo standardowe dokumenty, które chce udostępnić za pomocą usługi anonimowego FTP. Usługa ta zakłada dostęp do plików bez potrzeby uwierzytelnienia. Aby można było świadczyć takie usługi, niektóre sieci prywatne umieszczają specjalny serwer na zewnątrz ściany ogniowej. Taki zewnętrzny serwer ogranicza dostęp użytkowników Internetu tylko do zasobów na nim umieszczonych. Oczywiście połączenie wysuniętego na zewnątrz serwera z siecią prywatną powinno być dokonywane za pomocą ściany ogniowej, tak jak pokazano na rysunku 2.
 
 Uwierzytelnianie użytkownika

Podsumowując poprzedni podrozdział należy podkreślić, że każda implementacja ściany ogniowej realizowana za pomocą bramy, w dużym stopniu polega na zawartej w niej metodzie uwierzytelniania. Słaba metoda uwierzytelniania może łatwo zniszczyć skuteczność ściany ogniowej. Ten temat jest przedmiotem dalszej części rozdziału.

Typowa aplikacja TCP/IP, taka jak TELNET, wymaga od użytkownika wprowadzenia identyfikatora i hasła. Jeżeli nie wprowadzi się dodatkowej ochrony, hasło jest przesyłane
w sieci jawnie. Podstawowym problemem, który chcemy rozważyć w tym podrozdziale jest uwierzytelnianie użytkownika żądającego usługi za pośrednictwem ściany ogniowej. Drugim rozważanym problemem jest uwierzytelnienie administratora ściany ogniowej.
 
 

Rysunek 3. Uwierzytelnianie w przypadku ściany ogniowej-bramy
 

Z sieci prywatnej do Internetu

Rozważmy dwa scenariusze uwierzytelniania użytkownika pokazane na rysunku 3. Pierwszy z nich dotyczy żądania połączenia komputera z sieci prywatnej z komputerem
w Internecie i zawiera kroki 1 i 2. W kroku pierwszym klient wysyła identyfikator i hasło użytkownika do ściany ogniowej. Wymiana ta ma miejsce w bezpiecznej sieci prywatnej. Można twierdzić, że narażenie się na kradzież hasła w tym obszarze jest znacznie mniejsze niż podczas przesyłania hasła w Internecie. Po zweryfikowaniu, w kroku drugim, użytkownik przesyła identyfikator i hasło obowiązujące na zdalnym komputerze w Internecie.

Z Internetu do sieci prywatnej

W drugim scenariuszu użytkownik z Internetu rejestruje się na serwerze sieci prywatnej (krok 3 i 4 z rysunku 3). Najpierw wysyła identyfikator i hasło do ściany ogniowej. Jednakże, nawet zaszyfrowane hasło może zostać skopiowane podczas przesyłania. Umożliwia to atak typu powtórzeniowego (ang. replay), w którym intruz posługując się zaszyfrowanym hasłem (skradzionym), uzyskuje dostęp do ściany ogniowej i następnie do sieci prywatnej. Aby udaremnić taki atak, wskazane jest używanie haseł jednokrotnego użytku. Można na przykład skorzystać z któregoś typu kart generujących hasła losowe (token cards). W tym wypadku, nawet jeśli hasło zostanie skradzione, nie ma ono wartości dla intruza, ponieważ po pierwszym użyciu traci ważność.

Uwierzytelnianie administratora

Przyjrzyjmy się procedurze rejestrowania się na komputerze pełniącym rolę ściany ogniowej użytkownika, który jest administratorem. Aby zapobiec możliwości dostania się intruza z Internetu do serwera (zawsze może on odgadnąć hasło metodą sprawdzania różnych haseł), należy przestrzegać dwóch zasad:

l. Od administratora, który chce mieć zdalny dostęp do komputera-ściany ogniowej, należy zawsze wymagać używania hasła jednokrotnego użytku.

2. Nie powinno się akceptować żądania rejestracji administratora, jeśli pochodzi ono od strony Internetu. Administrator powinien móc zarejestrować się tylko od strony sieci prywatnej. Przestrzegając tej zasady można w znacznym stopniu zredukować możliwość zawładnięcia przez internetowego intruza ścianą ogniową.

Na koniec należy przypomnieć, że pliki z hasłami są dobrze znanym celem ataku hackerów.[1]
 
 

Proxy ARP jako alternatywa dla podsieci

Kiedy host przygotowuje się do wysłania datagramu IP, najpierw określa, czy adres przeznaczenia znajduje się w tym samym segmencie sieci, czy też w innym. Jeśli adres odbiorcy należy do innego segmentu, host wysyła datagram IP na adres rutera. Jeśli host wysyłający datagram oraz adres przeznaczenia znajdują się w tym samym segmencie sieci, to pakiet przesyłany jest bezpośrednio do odbiorcy.

Warstwa łącza danych nie wie jednak nic o adresach IP. Każda maszyna ma zwykle niepowtarzalny adres sprzętowy, który nie ma nic wspólnego z adresem IP. Adresy sprzętowe przydzielane są maszynom (lub kartom interfejsów) przez producentów, bez względu na to, gdzie ta maszyna będzie używana. Adresy IP z kolei przydzielane są przez lokalnego administratora i mają strukturę, która jest kontrolowana lokalnie i zawiera wiele informacji o tym, gdzie dokładnie urządzenie się znajduje. Kiedy host IP chce wysłać datagram do lokalnego segmentu sieci, musi jakoś odwzorować adres IP przeznaczenia na odpowiedni adres sprzętowy.

Są trzy podstawowe metody odwzorowania adresów IP na adresy sprzętowe. Pierwszą z nich jest tablica lookup. Każda maszyna przechowuje skończoną listę odwzorowań adresów IP na adresy sprzętowe dla każdej z maszyn w lokalnym segmencie sieci. Choć wydaje się to bardzo proste, utrzymywanie tablicy powoduje powstawanie błędów, a uaktualnianie tablic hostów w całej sieci po zmianie jednego adresu staje się koszmarem, kiedy maszyn w sieci jest więcej niż tuzin. Drugą metodą jest algorytmiczne mapowanie pomiędzy adresami IP
i adresami sprzętowymi.Jednym z przykładów może być warstwa łącza danych pracującą
z 8-bitowymi adresami sprzętowymi. W takim przypadku host może mapować adresy IP na adresy sprzętowe używając mniej znaczącego oktetu adresu IP jako adresu sprzętowego. Taki algorytm działa nieźle pod warunkiem, że administrator ma możliwość ustawiania adresu sprzętowego i że takie proste odwzorowanie w ogóle istnieje.

Trzecią metodą, najczęściej wybieraną w przypadku zestawu protokołów IP, jest użycie sieciowej bazy danych, którą host pyta o adres sprzętowy odpowiadający jakiemuś adresowi IP. Ta baza danych może być umieszczona na pojedynczym serwerze lub dystrybuowana pomiędzy hostami, które są wtedy odpowiedzialne za udzielanie odpowiedzi dotyczących ich adresów.

ARP-Address Resolution Protocol

W najczęściej używanych mediach sieci LAN standardową metodą odwzorowywania adresów jest Address Resolution Protocol (ARP). Używając tego protokołu wysyłający pakiet host wysyła najpierw komunikat za pomocą sprzętowej usługi broadcast (o ile to możliwe), prosząc maszynę o danym numerze IP, by odpowiedziała przez odesłanie swego adresu sprzętowego. Kiedy wskazana maszyna odpowie, maszyna nadająca wysyła kolejne datagramy IP, wykorzystując przekazany adres sprzętowy odbiorcy. Ponieważ jest bardzo prawdopodobne, że w najbliższej przyszłości zostaną przesłane kolejne datagramy, nadawca zachowuje w pamięci używane odwzorowanie, by móc go użyć w przyszłości.

Zwykle każda maszyna odpowiada na zapytania dotyczące jej własnego adresu IP. Nie ma jednak ograniczeń w protokole, które nie pozwalałyby, aby dana maszyna odpowiadała przez przekazanie odwzorowania adresów IP, do których trasa prowadzi przez ruter. W takim przypadku ruter odpowiada na pytanie przesyłając swój własny adres. Maszyna wysyłająca pytanie akceptuje ten adres jako obowiązujące mapowanie, a kolejne datagramy adresowane na to IP wysyła na adres sprzętowy interfejsu rutera. Działanie takie znane jest jako proxy ARP lub ARP hack.

Proxy ARP wymyślono jako sposób na złagodzenie przejścia do konfiguracji sieci wykorzystujących podsieci IP. Wiele maszyn pracuje z oprogramowaniem, które nie rozumie masek podsieci. Maszyny te wierzą, że wszystkie hosty w sieci klasowej będą dostępne bezpośrednio przez warstwę łącza danych, a ARP użyją w stosunku do maszyn pracujących
w innych podsieciach. Zapewniając obsługę proxy ARP ruter IP sprawia, że maszyny te funkcjonują w podsieci IP, bez konieczności uaktualniania ich oprogramowania do nowszej wersji. Maszyny, które nie potrafią pracować w podsieciach IP, są obecnie rzadkością. Wielu ludzi wierzy jednak, że proxy ARP jest użyteczne jako alternatywa do konfigurowania poprawnych masek podsieci (a czasem nawet rutowania) na hostach pracujących w sieci. Często nie rozumieją oni wad, jakie niesie ze sobą nieostrożne stosowanie proxy ARP, aż jest za późno i trzeba rekonfigurować całą sieć.

Problemy związane z Proxy ARP

Włączanie wszędzie usługi proxy ARP ma pewne zalety dla zapracowanego administratora sieci. Nie musi on już wtedy informować administratorów sieci LAN oraz użytkowników, jakie są ich maski podsieci, ani wyjaśniać, co to jest maska podsieci. Hosty pracujące w końcowych sieciach mogą nawet nie wiedzieć nic o rutowaniu IP i wszystko otrzymywać od muszą być wysyłane do rutera IP. Kiedy pierwszy pakiet jest gotowy do wysłania, host ARP, nawet adres IP odległych miejsc. W takim przypadku to rutery wykonują całą pracę.

Jednym z problemów, jaki powstaje przy wykorzystywaniu ARP, jest to, że obciążenie ruterów, które i bez tego protokołu jest duże, wyraźnie wzrasta. Poprawnie skonfigurowany host IP, który komunikuje się z czterema maszynami znajdującymi się w innym segmencie sieci, wie, że wszystkie datagramy wchodzące w skład tych sesji, posługując się ARP, uzyskuje adres sprzętowy rutera i zapamiętuje go w pamięci podręcznej ARP, by móc go użyć ponownie. Kolejne trzy sesje będą rutowane przez ten sam ruter, ale host ma już informację o adresie sprzętowym rutera, więc nie musi wysyłać kolejnego pytania. Natomiast maszyna posługująca się proxy ARP musi wysłać zapytanie ARP o adres sprzętowy każdej z maszyn, z którą się komunikuje. W naszym przypadku działanie to zwiększa liczbę ramek ARP aż czterokrotnie. Jeśli pomnoży się to przez wszystkie maszyny dołączone do wszystkich interfejsów ruterów, dodatkowe obciążenie ruterów może być znaczne. Ponieważ zapytania ARP wysyłane są jako broadcast, kierowany do wszystkich maszyn w lokalnym segmencie, każda maszyna pracująca w tym segmencie musi przerwać normalną pracę
i sprawdzić nadchodzące pytanie ARP, upewniając się, czy nie dotyczy ono jej adresu IP.
Tak więc stosowanie proxy ARP zwiększa nie tylko obciążenie ruterów, ale także innych hostów w sieci.

Kolejną wadą rozpowszechniania proxy ARP jest fakt, że usługa ta powoduje powstawanie błędów w konfiguracji sieci. Pracuję obecnie z zestawem maszyn w lokalnej sieci kampusowej, które mają zapisaną trasę domyślną wskazującą na adres IP, który nie został nikomu przydzielony, ale będzie wykorzystany jako adres rutera w kolejnej podsieci. Ruter działający w lokalnej podsieci został skonfigurowany do obsługi proxy ARP wiele lat temu
i do dziś nie sprawdzono, czy usługa ta jest jeszcze potrzebna. Źle skonfigurowane maszyny działające w tej sieci szczęśliwie poprawnie wysyłały pakiety. Jeśli jednak taka konfiguracja pozostałaby nadal niewykryta , to jakakolwiek zmiana w sieci mogłaby spowodować,
że maszyny te przestałyby się komunikować z kimkolwiek. Koszmarem dla każdego administratora jest sytuacja, w której po dokonaniu jakiejś zmiany w jednym miejscu sieci nagle ni stąd, ni zowąd przestaje coś działać w innym miejscu.

Na nieszczęście niektórzy producenci ruterów domyślnie włączają proxy ARP na wszystkich interfejsach. Sądzą, że proxy ARP pomaga w traktowaniu sieci IP jako sieci typu
plug-and-play, zwłaszcza w przypadku małych miejsc, gdzie administratorzy nie mają dużego doświadczenia w konfigurowaniu sieci. Choć w niektórych przypadkach tak się rzeczywiście dzieje, nadal obstaję przy swoim zdaniu, że proxy ARP robi więcej złego niż dobrego.
Na szczęście łatwo w większości dostępnych obecnie ruterów wyłączyć obsługę proxy ARP.

Kiedy niezbędne jest użycie proxy ARP ?

Mimo wad proxy ARP, konieczne jest zastosowanie go, gdy pojawi się problem komunikacji w sieci. Zdarza się, że w Twojej sieci będą pracowały hosty, które nie potrafią obsługiwać podsieci IP. Jeśli nie możesz usunąć takich komputerów z sieci, to nie ma innego wyjścia, jak zastosować obsługę proxy ARP w segmencie lub segmentach, gdzie są one dołączone. Innym, dość częstym, przypadkiem, jest sytuacja, kiedy masz w sieci host, który nie może poprawnie komunikować się z hostami pracującymi w podsieci 0 i podsieci 1 (same bity 1). (Pamiętaj, że te dwie podsieci są formalnie zarezerwowane.) Kiedy natrafisz na taki host, możesz nie mieć innego wyjścia, jak tylko okłamać go, że jego maska podsieci jest maską dopuszczalnej podsieci, przez co będzie myślał, że adresy, z którymi się komunikuje, nie pochodzą z podsieci zerowej lub jedynkowej. Oczywiście konieczne będzie również uruchomienie proxy ARP na ruterze obsługującym ten segment. Pamiętaj, że musisz uważnie kontrolować wykorzystanie proxy ARP i nie należy posługiwać się nim w całej sieci. Postaraj się trzymać maszyny, które naprawdę wymagają tej usługi, w jak najmniejszej liczbie segmentów. Możliwe, że uda się je wszystkie zebrać w jednym segmencie, dzięki czemu proxy ARP można będzie uruchomić tylko na jednym interfejsie rutera.[3]
 

---