Firewalle i proxy serwery: Serwer proxy SOCKS Następna strona Poprzednia strona Spis treści 8. Serwer proxy SOCKS 8.1 Konfigurowanie serwera Proxy SOCKS proxy server dostępny jest z adresu: ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz. Zawiera przykładowy plik konfiguracyjny w katalogu nazwanym: " socks-conf " . Zdekompresuj i untaruj te pliki w dowolnym katalogu i postępuj według instrukcji. Miałem kilka problemów kiedy kompilowałem go. Upewnij się, że twój Makefile jest prawidłowy. Jedną z ważniejszych rzeczy jest pamiętanie o konieczności dodania serwera proxy do /etc/inetd.conf. Aby móc odpowiedzieć na żądania musisz dopisać następującą linię: socks stream tcp nowait nobody /usr/local/etc/sockd sockd 8.2 Konfiguracja serwera proxy Program SOCKS potrzebuje dwóch oddzielnych plików konfiguracyjnych. Jeden z nich mówi tym komu udzielić dostępu a drugi w jaki sposób przekazywać żądania do właściwego serwera proxy. Plik decydujący o dostępie powinien znajdować się na serwerze. Plik dotyczący przekazywania dostępu (routingu) powinien znajdować się na każdej z maszyn Unixowych. W wypadku DOSa i częściowo MaCów komputery powinny mieć swój własny routing. Plik dostępu.Access File W wersji 4.2 Beta SOCSKsów plik dostępu nazywa się " sockd.conf " . powinien zawierać dwie linie: zezwolenia i zakazu. Każda z linii posiada trzy pozycje: identyfikator (permit/deny) adres IP modyfikator adresu Identyfikator to permit lub deny Powinieneś użyć obu: każdy we właściwej linii. Adres IP powinien zawierać czterobajtowy adres w typowej dal IP notacji. np. 192.168.2.0. Modyfikator adresu także jest normalnym IP i pracuje jak maska. Rozwinięcie tego adresu da 32 bity (1 albo zero). Na przykład, w tej linii: permit 192.168.2.23 255.255.255.255 zezwalam na dostęp maszynom w których adres pasuje co do bitu z zadanym: pasuje tu tylko 192.168.2.23 permit 192.168.2.0 255.255.255.0 zezwala na dostęp maszynom z gdyby od 192.168.2.0 do 192.168.2.255, w formie całej klasy C. Nie powinieneś mieć następującej linii: permit 192.168.2.0 0.0.0.0 dającej dostęp dla wszystkich adresów. Tak więc pierwsza linia daje zezwolenie dla tych adresów którym chcesz go dać, a druga zakazuje reszcie. Aby zezwolić na dostęp wszystkim z klasy 192.168.2.xxx potrzeba linii: permit 192.168.2.0 255.255.255.0 deny 0.0.0.0 0.0.0.0 Zwróć uwagę na pierwsze " 0.0.0.0 " w linii zakazu. Z maską 0.0.0.0 taki adres nie istnieje. Wszystkie zera zostały tam wprowadzone bo są łatwe do zapisu. Dopuszczalne jest umieszczenie większej ilości jeden zapisów w każdej z linii. Konkretni użytkownicy mogą ponadto otrzymać lub tracić prawo dostępu. jest to wykonywane przy pomocy autentyfikacji przy pomocy ident. Nie wszystkie systemu używają ident, włączając w to Trumpet Winsock , dlatego też nie włączam tu przykładów. Dokumentacja do SOCKS jest całkiem dobra w tej kwestii. Tablica trasowania Tablica routingu w SOCS jest niestety nazywana socks.conf. Tablica routingu mówi klientom SOCKS kiedy używać socks a kiedy nie. Na przykład, w twojej sieci 192.168.2.3 nie potrzebuje używania socks do połączenia z 192.168.2.1. Po prostu łączy się bezpośrednio, po Ethernecie. Definiuje się automatycznie 127.0.0.1 jako loopback. Oczywiste jest, że nie potrzebujesz rozmawiać przez ścianę ogniową z samym sobą... Są trzy typy rekordów: deny direct sockd Deny mówi SOCKS kiedy ma odmówić żądaniu. Rekord ten ma takie same trzy pola jak sockd.conf: identyfikator, adres i maska. Ogólnie, dopóki jest to modyfikowane przez sockd.conf, maska w pliku dostępu jest ustawiona na 0.0.0.0. Jeśli chcesz pozwolić na dzwonienie do siebie możesz to zrobić tutaj. Rekord direct mówi które do których adresów nie używać SOCKS. Te adresy będą doręczone bez serwera proxy. Jeszcze raz, mamy trzy pola: identyfikator, adres i maska. direct 192.168.2.0 255.255.255.0 W ten sposób kierujesz bezpośrednio cały ruch w chronionej sieci. Rekord z sockd mówi komputerowi które z hostów są serwerem SOCKS Składnia jest następująca: sockd @=<serverlist> <IP address> <modifier> Zwróć uwagę na fragment: @= . Pozwala on na wprowadzenie listy serwerów proxy. W naszym przykładzie używamy tylko jednego. Ale możesz mieć wiele w celu zwiększenia przepustowości i obniżenia możliwości awarii. Pola adresu IP i maski działają jak w innych przykładach. Specyfikujesz adres i zakres jego obowiązywania. DNS zza firewalla Ustawienie usługi DNS zza firewalla jest prostymzadaniem. Potrzeba jedynie ustawienia DNS na maszynie z firewallem.I inne maszyny za firewallem będą go używały. 8.3 Współpraca z serwerami proxy Unix Aby twoje aplikacje działały z serwerami proxy potrzebujesz je zsockisy... ( " sockified " ). Będziesz potrzebował dwóch różnych telnetów (jeden do komunikacji bezpośredniej drugi przez serwer proxy). SOCKS przychodzą z instrukcją jak zSOCKifikować program, i z paroma programami przygotowanymi na tę modłę. Jeśli używasz zSOCKIfowanej wersji gdziekolwiek bezpośrednio SOCKS automatycznie przełączy cię na właściwą wersję. Z tego powodu trzeba zmienić nazwy wszystkich programów w naszej chronionej sieci i zstąpić je wersjami zSOCKisowanymi. Finger stanie się finger.orig, telnet stanie się telnet.orig i tak dalej. Musisz powiedzieć SOCKS o każdym w pliku include/socks.h. Dobre programy są w stanie dostarczać tablic trasowania i zsocksifikować się same. Jednym z nich jest Netscape Navigator. Możesz używać serwerów proxy przez wprowadzenie adresu serwera (192.168.2.1 w naszym wypadku) w polu SOCKs w Menu Proxies. Każda aplikacja potrzebuje przynajmniej minimalnej informacji o tym co jest serwerem proxy. MS Windows i Trumpet Winsock Trumpet Winsock przychodzi z wbudowanymi możliwościami współpracy z serwerem proxy. W setup menu wprowadź adres serwera, i adresy komputerów dostępnych bezpośrednio. Program przekieruje na serwer wszystkie pakiety mające wyjść na zewnątrz. Ustawienie serwera pośredniczącego do pracy z pakietami UDP. Pakiet SOCKS pracuje jedynie z pakietami TCP, pomijając UDP. Powoduje to trochę mniejszą jego użyteczność. Wiele użytecznych programów, takich jak na przykład talk i Archie używa UDP. Jest jednak pakiet który może być użyty jako serwer proxy dla UDP: UDPrelay stworzony przez Toma Fitzgeralda [e-mail]. Niestety w chwili pisania tego tekstu nie jest on zgodny z Linuxem. 8.4 Wady serwerów proxych Serwer proxy, jak pokazałem powyżej jest narzędziem bezpieczeństwa. Używanie go zwiększa dostępność do Internetu z ograniczoną liczbą adresów wiąże się jednak z wieloma niedogodnościami. Serwer proxy pozwala na większą dostępność internetu z sieci chronionej, ale pozostawia wnętrze całkowicie niedostępne z zewnątrz. Oznacza to brak możliwości uruchomienia wewnątrz sieci rozmaitych serwerów, talk i archie, oraz bezpośredniego wysyłania listów do chronionej sieci. Poniższe uchybienia wyglądają nieznacząca, ale sposób myślenia przebiega następująco: Otrzymałeś informację o błędach w twojej chronionej sieci. Jesteś w domu, i decydujesz się sprawdzić to. Ale nie możesz. Nie jesteś w stanie dostać się do żadnego z komputerów ponieważ znajdują się za ścianą ogniową. Twoja córka poszła do college`u. Chciałbyś wysłać jej list. Chcesz z nią porozmawiać o pewnych prywatnych sprawach, i wolałbyś raczej by twoja poczta była kierowana bezpośrednio na twój komputer. Ufasz swojemu administratorowi, ale to jednak prywatna poczta. Niemożliwość użycia usług działających z UDP jest wielką wadą serwerów proxych. Choć mam nadzieję, że już niedługo. Przypadek FTP pokazuje jeszcze jeden problem z serwerami proxymi. Kiedy pobieram pliki lub wydaję komendę ls, serwer FTP otwiera gniazdo (,,socket'') na maszynie klienckiej i wysyła o tym informację. Serwer proxy nie pozwala na to, tak więc FTP nie działa w sposób prawidłowy. Poza tym serwery pośredniczące działają powoli. Z powodu większej wydajności większość innych metod dostępu do Internetu będzie szybsza. Jeśli masz przydzielony adres IP, i nie martwisz się o bezpieczeństwo, nie używaj ścian ogniowych i/lub serwerów proxych. Jeśli nie masz nr. IP, i także nie martwisz się o bezpieczeństwo swojej sieci, możesz użyć jednego z ,,emulatorów IP'' takich jak Term, Slirp lub TIA. Term jest dostępny z ftp://sunsite.unc.edu/, Slirp z ftp://blitzen.canberra.edu.au/pub/slirp, zaś TIA z http://markertplace.com/. Pakiety te pracują szybciej, pozwalają na szybsze połączenia i na większy dostęp z sieci wewnętrznej do internetu. Serwery pośredniczące są dobre dla tych który mają duże sieci z komputerami mającymi mieć dostęp ,,w locie'' do internetu z jednorazowym ustawieniem, i minimalnym wkładem pracy potem. Następna strona Poprzednia strona Spis treści