Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



26.11.2019

Baza cyberzagrożeń otwarta

Kaspersky Threat Intelligence Portal
26.11.2019

Kopia zapasowa w chmurze

Veeam Backup dla Office’a i Azure
26.11.2019

Automatyzacja jako usługa

QNAP Qmiix
25.11.2019

Jeszcze szybciej

Trzeci generacja Ryzen Threadripper
25.11.2019

Wirtualizacja na...

QNAP QGD-1600P
25.11.2019

Laserowy projektor

Optoma UHZ65UST
25.10.2019

Skalowalna infrastruktura

Red Hat OpenStack Platform 15
25.10.2019

Cienki klient 2.0

Windows Virtual Desktop
25.10.2019

Nowy sprzęt Microsoftu

Rodzina Surface się powiększa

Squid Proxy – wdrożenie i konfiguracja

Data publikacji: 26-09-2019 Autor: Konrad Kubecki
Strona, która zostanie...

Nieustanny rozwój i poprawa jakości łączy internetowych powodują, że rola serwerów proxy ewoluuje. Nie zawsze chodzi o przyspieszenie ładowania stron WWW. Wiele zastosowań dotyczy bezpieczeństwa i kontroli dostępu do zasobów internetu.

 

Podstawowa rola serwera typu proxy sprowadza się do ograniczania zapotrzebowania na łącze internetowe poprzez lokalne przechowywanie stron WWW i dostarczanie tych zasobów użytkownikom w pierwszej kolejności, zanim wykonane zostanie żądanie do serwera źródłowego. Squid obsługuje m.in. protokoły HTTP, HTTPS, FTP. Dostępne są wersje instalacyjne oprogramowania dla najpopularniejszych dystrybucji Linuksa i systemy Microsoft Windows.

W dobie szybkich łączy internetowych zasadność utrzymywania serwera proxy wydaje się dyskusyjna – szerokopasmowe wyjście na świat zbudowane na bazie światłowodu oraz połączenie w sieci LAN w standardzie 1 GB/s nieco podważa sens dodatkowego serwera buforującego, który ma przyspieszać ładowanie stron internetowych (choć przyznać trzeba, że poprawnie skonfigurowany serwer pośredniczący może pomóc i nie zaszkodzi). Akceptowalną jakość połączenia internetowego potrafią już zagwarantować sieci Wi-Fi i hotspoty uruchamiane na smartfonach, co powoduje, że użytkownicy coraz częściej korzystają z tej formy dostępu, nawet przebywając w biurze i mając do dyspozycji połączenie kablowe.

Na pierwszy plan wysuwa się więc obszar bezpieczeństwa – serwer proxy, pobierając treść z internetu do obsłużenia żądania, ukrywa adres klienta oraz jego konfigurację i przedstawia się swoim adresem. Działa zatem jako pośrednik, ukrywający klienta i występujący w jego imieniu.

Innym zastosowaniem serwera proxy jest ukrywanie rzeczywistego położenia klienta. Użycie tego typu pośrednika może pomóc np. w dostępie do treści blokowanej ze względu na lokalizację geograficzną.

Dla firm usługowych, produkcyjnych oraz urzędów serwer proxy to już niekoniecznie krytyczna usługa zauważalnie wpływająca na polepszenie osiągów dzierżawionego łącza. Dla nich Squid ma coraz większe znaczenie w innych obszarach – jednym z nich jest limitowanie dostępu do internetu. Używając serwera proxy, można zorganizować różne poziomy dostępu do sieci w zależności od roli pełnionej w organizacji. Dla określonej grupy pracowników dostęp do stron może być blokowany całkowicie, inne zespoły mogą mieć dostęp tylko do wybranych zasobów, niezbędnych do wykonywania obowiązków służbowych. Osobną grupę mogą stanowić pracownicy posiadający pełną swobodę korzystania z internetu. Żądania napływające do serwera proxy są obsługiwane zgodnie z zapisanymi w konfiguracji regułami, a aktywność użytkowników zapisywana jest w logach. Tak zebrane dane mogą następnie służyć do monitorowania i analizy ruchu sieciowego.

> INSTALACJA SERWERA

Opisana w artykule instalacja Squida przy użyciu pakietów pochodzących z oficjalnych repozytoriów CentOS-a najlepiej sprawdzi się w środowiskach testowych i niekoniecznie zalecana jest do środowisk produkcyjnych. Wynika to z faktu, że w oficjalnym repozytorium CentOS-a znajduje się starsza wersja Squida – 3.5.20. Tymczasem najnowsza wersja, dostępna na stronie projektu Squid, to 3.5.28 z czerwca 2018 r. Nowszych wersji nie ma także w innych popularnych repozytoriach, takich jak EPEL i REMI. Natomiast aktualna stabilna wersja zalecana dla środowisk produkcyjnych oznaczona jest numerem 4.8.

Squid 4 wniósł wiele zmian względem wersji 3, w tym m.in.:

 

  • całkowite wycofanie obsługi protokołu SSLv2 i częściowe wycofanie protokołu SSLv3 (docelowo obsługiwany ma być tylko TLS),
  • użycie protokołu ICAP (Internet Content Adaptation Protocol) w sesjach TLS,
  • podstawowe wsparcie dla protokołu GnuTLS (z czasem ma być rozwinięte),
  • wiele nowych tagów konfiguracyjnych możliwych do stosowania w pliku squid.conf.


Najlepszą metodą wdrożenia tej wersji jest pobranie plików źródłowych ze strony squid-cache.org/Versions/v4 oraz kompilacja. Takie postępowanie wydaje się najpewniejsze w kontekście bezpieczeństwa, doboru funkcji i wydajności działania Squida. Minusem jest natomiast nieco trudniejsza instalacja. Można także posłużyć się nieoficjalnym repozytorium, w którym znajduje się wiele pakietów różnych wersji Squida, począwszy od 3.4, a na 4.7 kończąc. W tym przypadku instalacja jest prostsza i ogranicza się do standardowego użycia polecenia yum install. W tym celu konieczne jest skonfigurowanie dodatkowego repozytorium w systemie – należy utworzyć plik /etc/yum.repos.d/squid.repo i umieścić w nim treść:

[squid]
name=Squid repo fro Centos 7
baseurl=http://www1.ngtech.co.il/repo/centos/7/x86_64
failovermethod=priority
enabled=1
gpgcheck=0

Instalację Squida inicjujemy poleceniem:

 



Następnie przeprowadzamy podstawową konfigurację usługi, aby uruchamiała się automatycznie wraz ze startem systemu operacyjnego. Uruchomiamy również usługę na żądanie:


> URUCHOMIENIE USŁUGI

Cyklicznym zadaniem po instalacji i uruchomieniu Squida powinna być aktualizacja usługi, tak aby była odporna na najnowsze podatności. Aktualizacje bezpieczeństwa do Squida są publikowane kilka razy w roku. Dotyczą głównie takich kategorii zagrożeń jak: Cross Site Scripting, Heap Overflow oraz Denial of Service. Większość wykrytych zagrożeń za cel stawia siłowe wyłączenie procesu Squida, co przekłada się na niedostępność usługi dla korzystających z niej użytkowników.

Sprawdzenie, czy usługa nasłuchuje:



Port 3128 jest domyślnym portem wykorzystywanym przy usługach typu proxy. Jeżeli na serwerze jest uruchomiony firewall, niezbędne będzie dodanie wyjątku dla portu 3128/tcp:


Weryfikacja, czy nowy port został dodany do konfiguracji:




Na tym etapie instalacji można już przetestować działanie serwera. W przeglądarce systemu klienta wystarczy ustawić namiary na serwer proxy i... zacząć z niego korzystać. Na przykład w Firefoksie wybieramy Preferences | Network proxy | Manual proxy configuration i w polu HTTP Proxy wpisujemy nazwę lub adres IP serwera oraz port 3128. Pobieranie stron internetowych przez klienta będzie generowało wpisy w pliku /var/log/squid/access.log. Przykładowe zapisy z aktywności serwera proxy:

1563786454.291 114 192.168.122.157 TCP_MISS/200 1880 GET http://pogoda.pl/ – HIER_DIRECT/62.121.130.63 text/html
1563786543.097 78 192.168.122.157 TCP_MISS/301 821 GET http://google.pl/ – HIER_DIRECT/216.58.215.99 text/html
1563787245.690 1 192.168.122.157 TCP_DENIED/403 4071 GET http://interia.pl/ – HIER_NONE/- text/html

Pojedynczy wpis w logach niesie sporą dawkę informacji o sposobie obsługi żądania:

 

  • time – moment rozpoczęcia obsługi żądania;
  • czas trwania – liczony w milisekundach czas, jaki był potrzebny od otrzymania żądania do zakończenia wysyłania odpowiedzi do klienta;
  • adres klienta – adres IP komputera korzystającego z serwera proxy;
  • kod wyniku – pole składające się z dwóch informacji. Pierwsza z nich wyjaśnia, co serwer proxy zrobił z żądaniem – czy odpowiedział klientowi, wysyłając do niego treść żądanej strony z pamięci podręcznej, czy np. odrzucił żądanie ze względu na reguły kontroli dostępu. Druga część pola zawierającego kod wyniku to numer kodu HTTP. Numer 200 oznacza, że żądana treść została dostarczona do klienta w sposób poprawny. Kod 301 informuje o tym, że oczekiwana treść została trwale przeniesiona (zmienił się jej URI) i będzie wyszukiwana pod innym adresem. Kod 403 oznacza, że serwer odrzuca żądanie i nie dostarczy treści do klienta;
  • bity – rozmiar danych dostarczonych do klienta w tym żądaniu;
  • metoda żądania – w powyższym logu pojawia się metoda GET, która oznacza wyszukiwanie obiektów. Inne przykładowe metody to: HEAD, POST, PUT, CONNECT, DELETE;
  • żądany zasób – w tym przypadku są to adresy stron internetowych, które były ładowane w przeglądarce;
  • kody hierarchiczne – w powyższym przykładzie kod HIER_DIRECT oznacza, że serwer proxy przekazał żądanie bezpośrednio do serwera źródłowego, a HIER_NONE, że nie podjął kroków. Częścią tego fragmentu linii jest także źródłowy adres IP serwera, którym Squid posłużył się w celu obsługi żądania;
  • typ zawartości – opisuje, jakiego rodzaju była zawartość dostarczona do klienta. Informacja ta pobierana jest z nagłówka HTTP.

 

[...]

 

Specjalista ds. utrzymania infrastruktury i operacji. Zajmuje się problematyką budowy i utrzymania centrów przetwarzania danych oraz zarządzania nimi i koordynowaniem zmian dotyczących krytycznej infrastruktury IT. 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"