eksperymenty z internetem, blogami, bloxem, javascriptem, firefoxem czy różnymi użytecznymi programami czy narzędziami, tak okołoinformatycznie tudzież okołokomputerowo...

linux

czwartek, 25 sierpnia 2005
Jako, że widzę sporo zapytań z google odnośnie squidguarda, być może dotychczasowe informacje nie były zbyt wyczerpujące. Postanowiłem dopisać więc coś więcej.

squidGuard został zainstalowany w lokalizacji /usr/local/squidGuard/
katalog na logi to /usr/local/squidGuard/log
baza definicji blokowanych hostów/urli jest w podkatalogach /usr/local/squidGuard/blacklists

Moja przykładowa konfiguracja squidGuarda wygląda tak:

Ustawienia globalne zgodne z konfiguracją instalacji:
logdir /usr/local/squidGuard/log
dbhome /usr/local/squidGuard/blacklists
Definicje kategorii do blokowania:
dest porn_sites    {
domainlist porn/domains
urllist porn/urls
redirect http://localhost/sgblock.php?clientaddr=%a&clientname=%n&clientuser=%i
&clientgroup=%s&targetgroup=%t&url=%u
logfile blocking.log
}

UWAGA: linia redirect jest "złamana" dla lepszej widoczności. Powinna być jedną całością
Kategoria opiera się na zdefiniowanych domenach i urlach (domainlist/urllist). W to nie wnikam. Ufam zawartości blacklists :). Redirect jest obowiązkowy, żeby squid/squidguard wiedzieli gdzie przekazać zapytanie użytkownika w przypadku zablokowania strony. Ja przygotowałem specjalny skrypt php (patrz koniec wpisu). Można go sobie dowolnie przerabiać w zależności od tego co się chce osiągnąć. Do skryptu przekazywane są zmienne, oferowane przez squidGuarda; są przydatne do pokazywania wyczerpującej informacji, która na użytkowniku robi wrażenie, że admini wiedzą wszystko :) Logfile jest nazwą pliku, do którego logowane będą wszystkie zdarzenia blokowania/zgodności z daną kategorią.

Pozostałe kategorie są zdefiniowane analogicznie
dest aggressive_sites    {
domainlist aggressive/domains
urllist aggressive/urls
redirect http://localhost/sgblock.php....
logfile blocking.log
}

dest drugs_sites {
domainlist drugs/domains
urllist drugs/urls
redirect http://localhost/sgblock.php....
logfile blocking.log
}

dest gambling_sites {
domainlist gambling/domains
urllist gambling/urls
redirect http://localhost/sgblock.php....
logfile blocking.log
}

dest violence_sites {
domainlist violence/domains
urllist violence/urls
redirect http://localhost/sgblock.php....
logfile blocking.log
}

dest hacking_sites {
domainlist hacking/domains
urllist hacking/urls
redirect http://localhost/sgblock.php....
logfile blocking.log
}
Jak łatwo zauważyć, poszczególne kategorie różnią się tylko zawartością domainlist/urllist. Pozostałe parametry są identyczne. Redirect zawarty w poszczególnej kategorii pozwala w skrypcie blokującym rozróżniać te kategorie. Plik log jest wspólny dla wszystkich kategorii. Można mieć oczywiście różne dla różnych kategorii, tylko kto to potem będzie analizował? Ja polecam jeden plik log.
Zestaw kategorii nie obejmuje oczywiście wszystkich możliwych, które oferuje zestaw blacklists squidGuarda

Inne kategorie filtrowania:
dest customblock_sites    {
domainlist custom/domains
urllist custom/urls
redirect http://localhost/sgblock.php....
logfile blocking.log
}
Ta kategoria obejmuje własny, dowolnie zdefiniowany zestaw domen/urli. Trzeba założyć odpowiednie pliki w odpowiednim podkatalogu (custom) katalogu blacklists. Tam można wpisać cokolwiek, co uznajemy za godne blokowania a czego nie znajdziemy w kategoriach predefiniowanych. Redirect i logfile analogicznie jw. UWAGA: jakakolwiek zmiana we własnych kategoriach (dodanie, usunięcie, edycja) wymaga restartu squida, który sobie zrestartuje squidGuarda...

Strony dozwolone:
dest specific_sites_only    {
domainlist custom/domains.spec
urllist custom/urls.spec
}
A tutaj będziemy mieli do czynienia z efektem odwrotnym. Ta kategoria służy do zdefiniowania tych adresów, które będą dozwolone dla użytkowników, którzy z domysłu będą mieli wszystko zablokowane. Czasem się to przydaje (jak w moim przypadku). Nie ma tu klauzul redirect i logfile, jako że nie będzie to ruch blokowany i logowany, tylko dozwolony. Redirect będzie potrzebny potem.

Stacje roboczne / użytkownicy:
dest admin_pc    {
ip 192.168.1.254
}

dest specific_user {
user pan_kazio
}
Tutaj z kolei mamy do czynienia z definicją konkretnych użytkowników i komputerów. Można tych grup tworzyć mnóstwo, w zależności od potrzeb. Ja podałem przykład. Nazwy użytkownika bierzemy z mechanizmu autoryzacji użytkowników do squid (ja używam mysql_auth).

No i teraz właściwe filtrowanie ruchu:
acl     {
specific_user {
pass specific_sites_only none
redirect http://localhost/sgblock.php?clientaddr=%a&clientname=%n&clientuser=%i&
clientgroup=%s&targetgroup=%t&url=%u
}
admin_pc {
pass all
}
default {
pass !admin_sites_only !porn_sites !aggressive_sites !drugs_sites
!gambling_sites !violence_sites !hacking_sites !customblock_sites all
}
}

UWAGA: linie redirect i pass są "złamane" dla lepszej widoczności. Powinny być jedną całością :)
Mamy tu do czynienia z następującymi elementami:
  • specific_user -> jeśli użytkownik zdefiniowany w tej grupie będzie próbował ruchu internetowego, to zostanie przepuszczony tylko dla stron zdefiniowanych przez kategorię specific_sites_only. Pozostałe próby będą blokowane. Dopiero tutaj niezbędny jest redirect, który blokując niedozwolony ruch będzie odsyłał na stronę informacyjną. To jest odrobinę niestandardowe zachowanie squidGuarda, troszkę się nad tym męczyłem, ale działa poprawnie.
  • admin_pc -> cały ruch ze stacji o zadanym adresie, niezależnie od użytkownika będzie przepuszczany, bo kto jak kto ale admini lubią mieć dostęp do wszystkiego :). Oczywiście lepsze jest używanie opcji z konkretną nazwą użytkownika, ale tak też można.
  • default -> ruch domyślny dla wszystkich innych, których squidGuard nie znalazł w algorytmie filtrowania (w nim, czyli sekcji acl, kolejność umieszczenia definicji ma znaczenie!). Tutaj przepuszczany będzie cały ruch, który nie należy do zdefiniowanych kategorii blokowania.

To wszystko.
Więcej można poczytać na stronie konfiguracji squidGuarda.
Opisany plik konfiguracyjny można ściągnąć tutaj (squidguard.conf.txt -> usuń txt).
Skrypt blokując przydatny jako redirect tutaj (sgblock.php.txt -> usuń txt).

Przydało się?
czwartek, 02 czerwca 2005
Jako, że obserwuję sporo przekierowań z google.pl w temacie squidguarda, być może warto napisać coś o moich doświadczeniach, coś czego nie ma na standardowej stronie...

Oczywiście mówimy o narzędziu filtrowania treści, opartym o filtrowanie domen, adresów url bądź też wyrażeń regularnych, które współpracuje z serwerem proxy SQUID.
Wobec tego, po ściągnięciu i instalacji (to jest dobrze opisane) trzeba przygotować plik konfiguracyjny squidGuard.conf (o tym dalej) oraz wpisać następujące informacje o nim do pliku konfiguracyjnego serwera proxy (squid.conf).

#program wykonywalny zainstalował się w /usr/local/bin/squidGuard
#konfiguracja i pliki blacklists są w lokalizacji /usr/local/squidGuard/
redirect_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf
#ilość procesów fitrujących otwartych przez proxy:
#to zależy od ilości użytkowników proxy i natężenia ruchu
#dla 25 użytkowników liczba 5 to było za mało,
#liczba 15 była akurat, tzn. nie pokazywały się komunikaty proxy
redirect_children 15

Do transparentnego działania i nie filtrowania żadnej treści wystarczy w pliku squidGuard.conf wpisać:

acl {
    default {
        pass all
    }
}

Bardziej zaawansowane możliwości można dodawać w późniejszym czasie i opiszę je w oddzielnej notce (albo można sobie sprawdzić na http://www.squidguard.org/config/)
Niestety, po każdej zmianie w pliku squidGuard.conf musiałem restartować cały proxy squid (nie szukałem innej metody...)
środa, 13 kwietnia 2005
Po kilku tygodniach experymentów udało mi się skonfigurować:
  • proxy squid (wersja 2.5.STABLE9)
  • z autoryzacją użytkowników w oparciu o tabelę bazy MySQL i moduł mysql_auth (wersja 0.8),
  • z filtrem i blokowaniem nieautoryzowanych domen w oparciu o squidGuard (wersja 1.2.0)
  • z prezentacją logów za pomocą Webalizera (wersja dostarczona razem z RH9)
  • z automatycznym importem logów do serwera MySQL za pomocą polecenia mysqlimport (np. w celu analizy za pomocą Accessa i myODBC
Wszystko to pięknie działa na kompie PII 550MHz z 256MB RAM, 40GB HDD i 1 kartą sieciową 100Mbps, na linuxie Red Hat 9.
Bo jakoś lubię RH :))

Gdyby ktoś był zainteresowany taką konfiguracją (lub jej elementami) to można kontaktować się ze mną na priv: sgk@NO-SPAM-NO.eranet.pl (usuń NO-SPAM-NO...)
bloxowe porady

RSS


dodaj do netvibes

Add to Google


pobierz Spiceworks - darmowe oprogramowanie do zarządzania infrastrukturą IT