Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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 updateaptitude install dansguardian squid3Kilka 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 ACCEPTiptables -A INPUT -i eth1 -s 192.168.1.0/24 -p tcp --dport 8080 --syn -m state --state NEW -j ACCEPTiptables -t nat -A PREROUTING -i eth1 -s 192.168.1.0/24 -p tcp --dport 80 -j REDIRECT --to-port 8080W 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 8080em1 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 ACCEPTiptables -A INPUT -i eth1 -s 192.168.1.0/24 -p tcp --dport 8080 --syn -m state --state NEW -j ACCEPTiptables -t nat -A PREROUTING -i eth1 ! -s 192.168.1.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:8080A 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:aptitude install ddclientnano /etc/ddclient.confOpenBSD:pkg_add ddclientDo pliku /etc/rc.local (OpenBSD) dopisujemy:/etc/rc.d/ddclient startW pliku ddclient.conf wpisujemy:

protocol=dyndns2# jeśli adres ip ma być pobrany z karty sieciowejuse=if, if=eth0# lub jeśli adres ip ma być pobrany za pośrednictwem strony www# tak się dzieje jeśli Twój ISP przydziela adresy nieroutowalneuse=web, web=myip.dnsomatic.comserver=updates.opendns.comlogin=nazwa_użytkownikapassword='hasło'ssl=yesnazwa_sieci_w_opendns

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ż).dns_nameservers 208.67.222.222 208.67.220.220Opró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:53iptables -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 ;-) 

linux

Komentarze

0 nowych
Axles   16 #1 19.03.2013 16:49

przydałby sie taki tekst pokazujący jak to na windiwsie tez zrobić.

StawikPiast   10 #2 19.03.2013 17:31

Dla Windows w przedsiebiorstwie to najlepiej bedzie Forefront server, następca ISA server.

W_tym_temaciE   5 #3 19.03.2013 18:03

Swoją drogą, czy ktoś używa OpenDNS do blokowania reklam? Działa to dobrze, czy raczej nie?
I, czy da się wyłączyć to blokowanie na poszczególnych stronach (bo poza stronami chamsko atakującymi wyskakującymi reklamami, są jeszcze te normalne - i je chciałbym wspierać), około trzech, maksymalnie pięciu.

Autor edytował komentarz.
N4R   3 #4 20.03.2013 16:01

I tutaj widać wyższość komercyjnych rozwiązań takich jak IPS, czy UTM jeśli chodzi o blokowanie stron HTTPS, np. takich ja Facebook.

parranoya   8 #5 21.03.2013 11:40

@N4R
Jasna sprawa, tylko ile to kosztuje? Nie zawsze to się opłaca. Na przykład u mnie w firmie mamy 6 oddziałów 2-3 osobowych. Zakup komercyjnego rozwiązania IPS lub UTM dla każdego oddziału to zdecydowanie zbyt duże koszty.

N4R   3 #6 21.03.2013 16:21

Jeśli porównujemy koszty to ta kwestia jest akurat oczywista, ale zawsze dochodzą takie jak skuteczność i funkcjonalność (zaawansowane silniki skanerów, rozbudowane moduły zapory itd) oraz komfort pracy (webowe konsole). Ale i tak propsy za to, że pomimo jak sam to nazwałeś małych oddziałów dziala tam coś, wiecej jak podstawowy router TP-Linka.

przemol96   5 #7 24.03.2013 20:49

@N4R

Orientujesz się może jak wyciąć na UTM (NETASQ U30) facebooka po HTTPS? Przy deszyfracji ruchu ładnie działa, ale każda inna strona po HTTPS jest "upośledzona" przestają działać style, nie ma połowy elementów itp..

  #8 25.03.2013 11:33

Dobry poradnik dla tych co ograniczają wolnoć innym, przetłumaczyć na białoruski, chiński i będzie można sprzedać i nieźle zarobić. Pracownik powinien jak niegdyś niewolnik siedzieć w obroży na szyji i pracować na swojego pana, na nic nie klikać, nigdzie nie wchodzić bez pozwolenia swojego pana.

parranoya   8 #9 25.03.2013 16:57

@matiz443
A co w tym dziwnego, że pracodawca chce mieć pewność, że pracownicy pracują a nie siedzą na Facebooku? Nikt nikogo nie ogranicza, po pracy niech każdy klika gdzie ma ochotę. Jeśli ktoś mi płaci to robię to za co mi płaci. Jeśli komuś to nie pasuje to przecież może się zwolnić z pracy i żyć samą wolnością.
Skończysz szkołę, pójdziesz do pracy to zapewne zmienisz zdanie. Ech, dzieciaki... :-))

  #10 13.04.2013 15:13

Prackowników powinno się rozliczać z realizacji zadań, a nie z tego czy w pracy siedzą na pejsbooku. Mnie nik nie pyta czy siedziełem w nocy w weekend żeby zrealizować chore założenia. Ale zarówno ja jak i mój pracodawca uznajemy że skoro praca została wykonana, to nieważne czy w pracy oglądam tzw. 'dupy' czy przeglądam portale internetowe. I to jest zdrowe podejście.

N4R   3 #11 18.04.2013 20:41

@przemol96
W Netasq możesz zamiast deszyfracji HTTPS wykorzystać gotowy plugin w module IPS (ASQ) do blokowania ruchu HTTPS Facebook. Nie musisz wtedy nawet aktywować funkcjonalności deszyfracji HTTPS, jeśli jej ogólnie nie potrzebujesz, co pozwoli pozbyć się problemów z opisywanym przez Ciebie rozjeżdżaniem się stron.