Filtrowanie treści WWW, czyli co wolno Wojewodzie...

Poniższy tekst można potraktować jako osobny lub jako rozszerzenie poprzednich wpisów.

Co Pan taki ciekawski?

Powodów do filtrowania treści WWW (i ruchu internetowego w ogóle) jest wiele i każdy ma inne ale głównie są to pracownicy przesiadujący na Facebooku, oglądający treści erotyczne, P2P itp.

Filtrowanie treści przesyłanych protokołem HTTP jest bardzo łatwe. Wystarczy serwer proxy Squid i Dansguardian. Jak zainstalować i wstępnie skonfigurować ten tandem w systemie OpenBSD opisałem tutaj (konfiguracja Squid i Dansguardian dla BSD i Linuksa jest identyczna). Zdaję sobie sprawę z tego, że OpenBSD to niestety egzotyka w rodzinie systemów uniksopodobnych a prym wiedzie Linux, dlatego poniższy wpis opisuje konfigurację dwóch systemów: OpenBSD i Linux Debian.

Instalacja w Debianie:

apitude update

aptitude install dansguardian squid3

Kilka chwil i gotowe. Podczas instalacji tworzone są skrypty startowe dla tych programów, dzięki czemu będą uruchamiały się automatyczne razem z systemem. Dokładną konfigurację tych programów pomijam, ponieważ jest to temat rzeka i "niestety" trzeba poczytać dokumentacje.

Nie będziesz mi mówił co mam robić...

No to trzeba by jeszcze jakoś nakłonić użytkowników do korzystania z serwera proxy. Najprościej jest to zrobić dopisując odpowiednie regułki do firewalla na routerze. Jeśli proxy pracuje na routerze (co ze względów bezpieczeństwa jest niezalecane) regułki firewalla dla Linuksa wyglądają następująco:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i eth1 -s 192.168.1.0/24 -p tcp --dport 8080 --syn -m state --state NEW -j ACCEPT

iptables -t nat -A PREROUTING -i eth1 -s 192.168.1.0/24 -p tcp --dport 80 -j REDIRECT --to-port 8080

W przypadku OpenBSD sprawa jest znacznie prostsza:

pass in on em1 proto tcp from 192.168.1.0/24 port www rdr-to 192.168.1.10 port 8080

em1 to w moim przypadku nazwa sterownika karty sieciowej po stronie LAN

Jeśli serwer proxy pracuje na innym komputerze (w tym przypadku ip owego komputera to 192.168.1.10), linuksowe reguły firewalla wyglądają tak:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i eth1 -s 192.168.1.0/24 -p tcp --dport 8080 --syn -m state --state NEW -j ACCEPT

iptables -t nat -A PREROUTING -i eth1 ! -s 192.168.1.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:8080

A w OpenBSD wygląda tak: :‑))

pass in on em1 proto tcp from 192.168.1.0/24 port www rdr-to 192.168.1.1 port 8080

Masz jakiś pomysł?

No dobra, ale co z ruchem HTTPS? Można deszyfrować dane "w locie" stosując technikę SSL Bump, której implementacja jest raczej kłopotliwa (w przypadku Debiana konieczne jest wkompilowanie w  Squida obsługi SSL, OpenBSD dostarcza odpowiednio przygotowany pakiet Squida) a do tego w naszym kraju chyba nielegalna (możemy przez przypadek przechwycić czyjeś hasła np. do banku). Można też wklepać do regułek firewalla adresy ip zabronionych stron. Jak to zrobić w przypadku bardzo dużej kolekcji adresów napisałem tutaj, lecz mimo to jest to metoda żmudna i często nie przynosi oczekiwanych rezultatów, ponieważ wiele serwisów stosuje tzw. round robin DNS.

Coś wymyślę...

Rozwiązaniem tego problemu (i nie tylko tego) jest usługa świadczona przez www.opendns.com. Konto na własne potrzeby jest bezpłatne (przynajmniej kiedyś było), firmy muszą płacić ale uważam, że warto. W skrócie, polega ona na korzystaniu z zarządzalnych serwerów DNS. Użytkownikom ze zdefiniowanej sieci (rozpoznawani są po adresie ip) możemy "wyłączać" kawałki internetu. Tak to mniej więcej wygląda:

Tym oto sposobem decydujemy co użytkownik naszej sieci może oglądać niezależnie od tego czy strona korzysta z HTTP czy HTTPS.

W oddziałach firmy korzystamy z neostrady, a ponieważ identyfikacja klientów Opendns odbywa się na podstawie adresu ip właśnie, konieczne jest stosowanie programu ddclient. Ddclient obsługuje protokół wykorzystywany przez wielu dostawców usług obsługi dynamicznych adresów ip np. dyndns.com. Instalacja i konfiguracja jest bardzo prosta. Debian:

[code=]aptitude install ddclient[/code]

nano /etc/ddclient.conf

OpenBSD:

pkg_add ddclient

Do pliku /etc/rc.local (OpenBSD) dopisujemy:

/etc/rc.d/ddclient start

W pliku ddclient.conf wpisujemy:

[code=]protocol=dyndns2[/code]

[code=]# jeśli adres ip ma być pobrany z karty sieciowej[/code]

[code=]use=if, if=eth0[/code]

[code=]# lub jeśli adres ip ma być pobrany za pośrednictwem strony www[/code]

[code=]# tak się dzieje jeśli Twój ISP przydziela adresy nieroutowalne[/code]

[code=]use=web, web=myip.dnsomatic.com[/code]

[code=]server=updates.opendns.com[/code]

[code=]login=nazwa_użytkownika[/code]

[code=]password='hasło'[/code]

[code=]ssl=yes[/code]

[code=]nazwa_sieci_w_opendns[/code]

Znów mi rozkazujesz?

Jeśli oprócz opendns wykorzystujesz Squida, w jego pliku konfiguracyjnym squid.conf należy wpisać adresy DNS z których ma korzystać a co za tym idzie, również przeglądarki użytkowników (przeglądarka dostaje treść z naszego proxy przecież).

[code=]dns_nameservers 208.67.222.222 208.67.220.220[/code]

Oprócz tego warto dopisać regułki firewalla przekierowujące cały ruch DNS do serwerów opendns co wpływa na wszystkie programy zainstalowane na komputerach w sieci LAN. Jak zwykle linuksowe regułki są trochę bardziej zagmatwane:

iptables -t nat -A PREROUTING -s 192.168.1.0/24 -i eth1 -p udp --dport 53 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to-destination 208.67.222.222:53

iptables -t nat -A PREROUTING -s 192.168.1.0/24 -i eth1 -p udp --dport 53 -m statistic --mode nth --every 2 --packet 1 -j DNAT --to-destination 208.67.220.220:53

A w OpenBSD prościej:

pass in on em1 proto tcp from 192.168.1.0/24 port domain rdr-to {208.67.222.222 208.67.220.220} port domain

Dlaczego akurat tak? Po co rozkładać ruch DNS na dwa serwery? Ano po to konfiguruje się dwa serwery DNS: podstawowy i zapasowy, że jak jeden nie działa to ruch przejmuje drugi. Jeśli ruch przekierujemy tylko na serwer podstawowy, to w przypadku jego awarii nasza sieć też padnie. A tak, jak klient nie uzyska odpowiedzi od serwera DNS, zapyta drugi raz, wówczas firewall automatycznie prześle zapytanie pod drugi serwer na liście. Oczywiście sieć będzie działała powoli ale przynajmniej będzie działała w ogóle. Tym samym sposobem możemy uzyskać prymitywne równoważenie obciążenia, które opisałem w tutaj.

I to wszystko?

Z całą pewnością metod filtrowania ruchu sieciowego jest znacznie więcej, jednak te stosuję u siebie i sprawdzają się znakomicie. Kto zna lepsze sposoby niech śmiało wygarnie w komentarzu.

P.S.

Jeśli wśród czytających ten wpis są osoby, których gnębi admin stosujący podobne praktyki, proszę, nie czytajcie tego wpisu ;-)