W chwili, gdy powstaje ten opis, polska dokumentacja Freesco w .pdf nie zawiera jeszcze opisu instalacji i pełnej konfiguracji Squida. Może ją kiedyś opiszę, ale, szczerze mówiąc, nie bardzo widzę powód, ponieważ mnie samemu Squid zainstalował się z paczki gładziutko i bez żadnych problemów, z ustawieniami domyślnymi – a nigdy wcześniej z nim nie pracowałem. Zakładam więc, że masz już działającego Squida.
Metodę tu przedstawioną opracowałem sam – nie jest najlepsza, ale wykorzystuje wyłącznie Squida, tj. nie są do niej potrzebne pakiety typu JunkBuster albo SquidGuard (tego ostatniego zresztą chyba nie ma w wersji pod Freesco).
Wszystkie umieszczone w niniejszym opisie definicje siłą rzeczy są nieścisłe, podobnie jak i sama definicja pornografii, i musimy się z tym pogodzić.
Założenia przyjąłem takie:
1. Będziemy blokować domeny o jawnie ‘seksualnych’ nazwach, np. www.xxx.foo
2. Będziemy blokować ścieżki URL zawierające jawnie ‘seksualne’ słowa, w ten sposób uniemożliwiając m. in. WYSZUKIWANIE takich słów – bo, jak wiadomo, strona z wynikami zawiera w swoim adresie wyszukiwane słowo.
3. Postaramy się, w miarę możliwości, nie blokować wyszukiwania słów ‘dwuznacznych’, tj. takich, których może szukać ktoś zupełnie niewinny, w zupełnie uczciwym celu.
Aby dojść do kompromisowej skuteczności okazało się konieczne rozbicie słów na dwie listy: ‘jednoznaczną’ i ‘dwuznaczną’.
Lista jednoznaczna zawiera słowa, których obecność sprawdzana będzie w całym adresie, tj. w nazwie domeny ORAZ w ścieżce do podstrony (tj. PO znaku / ).
Lista dwuznaczna zawierać będzie słowa, których obecność będzie sprawdzana wyłącznie w nazwie domeny, natomiast po znaku / już nie.
Dlaczego? Może przykład.
Lista jednoznaczna zawiera np. słowo ‘sex’. W wyniku blokowania nie można otworzyć stron:
http://www.sex.com
http://www.domena.pl/obrazki/sex
http://www.szukacz.com/wynikwyszukiwaniasłowa=sex
Gdyby lista jednoznaczna zawierała słowo ‘piersi’, wynik byłby analogiczny. Ale to oznaczałoby, że nie można by było uzyskać wyników zupełnie niewinnego wyszukiwania wyrażenia ‘rak piersi’ – a przecież nie o to nam chodzi.
Dlatego dla słów dwuznacznych tworzymy drugą listę, która będzie sprawdzana tylko w domenie.
Porównajmy:
http://www.piersi.com – chwilowo nie ma takiej, ale gdyby była, uznałbym ją za podejrzaną z powodu samej nazwy. Dlatego nasz filtr domenowy powinien ją zablokować, i pewnie słusznie. Natomiast strona http://www.akademia-medyczna.com/piersi – zostanie uznana za niewinną, a więc filtr jej nie zablokuje. Skuteczność tego podejścia widać np. w Onecie po wyłączeniu filtra rodzinnego. Wpisanie słowa “czekoladki” otworzy listę całej masy stron typu www.cukrownie.pl – które dadzą się otworzyć. Ale znaleźć tam można też pornograficzne – i one prowadzą zwykle do domen z seksem w nazwie, a więc zostaną zablokowane filtrem przeszukującym tylko domenę.
Innymi słowy, uważam, że niewinne strony będą na niewinnych domenach, nawet, jeśli w nazwie ścieżki wystąpią ‘seksualne’ wyrazy. Natomiast strony pornograficzne będą na dobrze znanych domenach, których nazwy nie wzbudzają wątpliwości, nawet, jeśli nazwa ścieżki jest niewinna (np. galeria). Filtrowanie będzie tym skuteczniejsze, im więcej wyrazów będziemy w stanie zgromadzić na obu listach. Ja mam ich w tej chwili około 300 (thank you, Batman!).
Jak wspomniałem wyżej – to tylko założenia. Filtracja nigdy nie będzie 100% skuteczna i nigdy w 100% bez efektów ubocznych. Ale opisany wyżej układ pracuje na moim serwerze i sprawdza się dość dobrze.
Teraz realizacja.
1. W katalogu /mnt/router/packages/squid/etc tworzymy pliki zakazane_domeny i zakazane_urlsy.
Umieszczamy w nich po jednym słowie w wierszu. Pierwsza linia może zawierać komentarz po znaku #.
Zakazane_domeny zawiera słowa dwuznaczne (czekoladki, foki, lalki, pedaly …), a zakazane_urlsy – jednoznaczne (tych jest dużo więcej; oto parę lżejszych: babe, bzykan, sluts, hustler, xxx, zwilzon …). UWAGA: Stwierdziłem, że filtr może nie działać prawidłowo, jeśli w tych plikach znajdują się puste wiersze – należy je usunąć; również linię ostatnią. No i oczywiście słowa, które widać w przykładzie są celowo pozbawione odmiennych końcówek, żeby filtr je „łapał”.
2. W pliku /mnt/router/packages/squid/etc/squid.conf udajemy się najpierw do sekcji acl i dodajemy od siebie pod linią acl CONNECT method CONNECT:
#obyczajówka
acl zakazane_urlsy url_regex -i „zakazane_urlsy”
acl zakazane_domeny dstdom_regex -i „zakazane_domeny”
(Nazwy w cudzysłowiu odwołują się do plików stworzonych w punkcie 1 – najlepiej jest podać pełną ścieżkę, u mnie jest to /mnt/router/packages/squid/etc/. Opcja –i sprawia, że filtr będzie ignorował wielkość liter w URL.)
3. W tym samym pliku udajemy się do sekcji INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS i dodajemy pod nią (a przed http_access allow localnet):
http_access deny zakazane_urlsy
http_access deny zakazane_domeny
Prawdopodobnie będziemy też musieli dodać plik z wyjątkami dozwolone_urlsy (np. na słowo “dowcipy” :).
Stworzymy do niego acl w sposób identyczny, jak podałem powyżej, a regułkę http_access allow wstawimy powyżej regułki deny (reguły analizowane są po kolei).
Następnie zapisujemy plik i wykonujemy restart squida poleceniem ‘rc_squid restart’.
Ponieważ nie wszyscy znają angielski, warto przetłumaczyć stronę z komunikatem o braku dostępu, którą wyświetli squid – konkretnie jest to plik
mnt/router/packages/squid/etc/err_access_denied
Zwłaszcza istotny jest jego fragment “Please contact your service provider if you feel this is incorrect” (Jeśli uważasz, że nastąpiła jakaś pomyłka, skontaktuj się z administratorem – ze mną jak na razie jeszcze nikt się nie skontaktował :). Do tego pliku warto wtedy dodać również na początku tag polskiego kodowania liter, tj.
META http-equiv=”content-type” content=”text/html; charset=ISO-8859-2″
Oczywiście warto też podać Squidowi prawidłowy adres e-mailowy administratora (ustawia się go w linii cache_mgr w pliku squid.conf).
===
Osobną sprawą jest wymuszenie na użytkownikach korzystania ze squida. W tym celu musimy go skonfigurować jako transparentny proxy. Składają się na to dwa elementy: regułka ipfwadm oraz zmiana w squid.conf.
Najpierw element pierwszy:
ipfwadm -I -i accept -P tcp -S 10.0.0.0/24 -D 0.0.0.0/0 80 -r 3128
Jest to reguła, która przekierowuje wszystkie pakiety pochodzące z sieci 10.0.0.0 i zmierzające gdziekolwiek na port 80 na własny interfejs Freesco, na port 3128, gdzie nasłuchuje Squid (przy domyślnej instalacji). Jeśli reguła wpisana jest prawidłowo, możemy ją przetestować: wpisanie dowolnego adresu w przeglądarce będzie zwracać błąd Squida „Invalid URL”, zawierający wszystkie znaki z adresu po nazwie domeny (czyli np. / albo /strona.htm). Na tym etapie konfiguracji jest to jak najbardziej prawidłowy objaw.
Teraz element drugi układanki: udajemy się do squid.conf i modyfikujemy podaną niżej sekcję do takiego kształtu:
#transparentny squid
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
hddpd_accel_uses_host_header on
Po czym restartujemy squida i gotowe.
Dla sadystycznych administratorów
Podaję też konfigurację blokowania ściągania binariów (oczywiście, jeśli transfer http odbywa się za pośrednictwem Squida, np. transparentnego).
Postępujemy analogicznie jak wyżej: tworzymy plik zakazane_binarki i wpisujemy w nim (jeden wpis na linię) np. .zip, .avi. A w squid.conf wstawiamy:
acl zakazane_binarki urlpath_regex
„zakazane_binarki”
i poniżej:
http_access deny zakazane_binarki
Należy uważać z blokowaniem .exe, ponieważ sporo wyników kwerend (np. serwis rozkładu jazdy PKP) zawiera w adresie np. ‘query.exe’, więc natychmiast zostaniemy zbombardowani protestami. Można obejść to tworząc np. dozwolone_binarki (z wpisem query.exe) i wstawiając
http_access allow dozwolone_binarki
nad linią http_access deny zakazane_binarki.
Autor: Andrzej Januszkiewicz Data: 2002-11-18 00:00:00
