Поточна версія на 12:58, 1 березня 2010

<<

SquidGuard це такий програмний додаток до Squid який дозволяє гнучко керувати доступом до ресурсів світових тенет користувачів вашого проксі. Він має власний окремий файл налаштувань, що спрощує контроль саме за доступом.

Встановлення

Щоб встановити SquidGuard достатньо дати команду: apt-get install squidGuard

Після встановлення пакунку ви отримаєте файл налаштувань у каталозі /etc/squid та потрібні для роботи самого SquidGuard каталоги та файли у var/lib/squidGuard. Під var/lib/squidGuard/db навіть будуть бази з якими вже можно починати працювати.

Налаштування

До пакунку вже включено попередньо налаштований файл налаштувань. Можливо, навіть, вам не доведеться нічого міняти щоб розпочати роботу. Проте, перевірити налаштування треба все одно. Наприклад, там заборонено доступ до www пошти у робочий час. Крім того, треба прописати шлях до файлу squidGuard у налаштуваннях самого Squid.

Налаштування у Squid

Для цього треба скорегувати два-три рядка у файлі /etc/squid/squid.conf.

redirect_program /usr/bin/squidGuard  # шлях до файлу
redirect_children 5                   # скільки процесів перенаправлення запитів може бути відкрито одночасно
redirector_bypass on                  # дозволити запити до ресурсів оминаючи сам squidGuard

Навіть один процес squidGuard зможе обслужити дуже велику кількість запитів. Головний виграш від кількості процесів більше одного, як кажуть, можна отримати на багатопроцесорних системах. Останній рядок дозволяє користувачам оминати контроль коли squidGuard не встигає за кількістю запитів. Кажуть, заборона прямих звертань оминаючи фільтр у такій ситуації "валить" Squid.

Налаштування SquidGuard

Визначення базових каталогів

Детальну інформацію щодо всіх можливостей налаштування SquidGuard ви можете подивитися у його документації. Але поглянемо на налаштування "з коробки". Файл досить "розлогий". Починається він з визначення двох змінних. dbhome визначає базовий шлях до баз з адресами які ми будемо використовувати у правилах доступу. logdir -- показує де буде розміщено файл журналу роботи SquidGuard.

dbhome /var/lib/squidGuard
logdir /var/log/squid

Тут коментарі, як кажуть, зайві.

Керування доступом з урахуванням часу

Наступним іде блок визначення робочого часу:

#
# TIME RULES:
# abbrev for weekdays: 
# s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat

time workhours {
       weekly mtwhf 09:00 - 18:00
       date *-*-01  09:00 - 18:00
}

Це дозволяє встановити різні правила на різні проміжки часу. У прикладі встановлюється робочий час з понеділка до п'ятниці. І за датою всі перші числа місця. Чесно кажучи, я не знаю на чому грунтується цей рядок.

Щоб це працювало у acl має бути присутнім щось такого типу:

<src> within  { ... }

Правила підстановки

Далі визначаються правила підстановки у адресах. Вам самим визначатися чи вам це треба.

#
# REWRITE RULES:
#

rew dmz {
       s@://admin/@://admin.example.com/@i
       s@://example.com/@://www.example.com/@i
}

Якщо подібна підстановка потрібна, не забудьте виправити назву домену на потрібну.

Визначення джерел

SquidGuard дозволяє розмежувати правила доступу до ресурсів за декількома критеріями. Наприклад, за ІР адресами користувачів мережі.

src lan {
      ip              192.168.2.0/24
}

Цим блоком визначається блок адрес мережі на 255 адрес. Блоків адрес можна визначити декілька. Таким чином, можна розмежувати доступ до ресурсів за діапазонами адрес. Адреси можна задавати декількома спосабами.

       ip              192.168.2.3 192.168.2.7
       ip              192.168.2.0-192.168.2.77
       iplist          iplist/blocked
       user            baduser

Перший рядок задає адреси перерахуванням. Другий -- діапазон у форматі від та до. Також можна задати посиланням на файл. У цьому випадку файл треба розмістити у тому місці файлової системи куди показує змінна dbhome або записати файл з урахуванням відносного або повного шляху до нього, рядки 3 та 4. Тобто, для четвертого рядка файл повинен лежати як /var/lib/squidGuard/baduser. І вміст файлу може бути, наприклад, таким:

192.168.2.0-192.168.2.255
172.16.12.0/255.255.255.0
10.5.3.1/28

Можна напряму блокувати за базою з Тенет. Якщо ви знаєте таку базу і цілком їй довіряєте. Якось так:

acl {
       default {
               pass !dnsbl:your.preferred.blacklist.domain.com all
               redirect http://localhost/block.html
       }
}

Ви можете прописати стільки джерел скільки вам треба і досить точно побудувати групи доступу до інформації.

Бази для блокування

Всі бази з якими ви збираєтесь працювати треба прописати у файлі налаштувань SquidGuard. Непрописані бази -- теж саме, що і відсутні. Принцип досить простий:

dest ads {
       domainlist      db/ads/domains
       urllist         db/ads/urls
       expressionlist  db/ads/expressions
}

Принципово, тут нічого складного. dest -- службове слово, що визначає тип налаштувань. Далі -- назва ресурсу і у дужках шлях до преліку доменів та універсальних визначників ресурсу (URL), доступом до яких ми збираємось керувати. Третій рядок визначає шлях до файлу з регулярними виразами. Користуватися ним треба вкрай обережно. Можна "зарізати" або, навпаки, дозволити зовсім не те що хотілося. :) Шлях до файлів визначається відносно визначеної на початку файла змінної dbhome. Баз можна визначити стільки скільки треба. Як вже було зазначено вище, декілька баз є в самому пакунку. У прикладі визначення однієї з таких баз.

Розподіл доступу

Ну і саме цікаве. Власне розподіл доступу.

Нижче правила "з коробки" майже без змін:

acl {
       blocked {
               pass    none
               redirect <що_показати_замість_заблокованого>
       }

       admin {
               pass    local-ok !ads any
               rewrite dmz
               redirect <що_показати_замість_заблокованого>
       }

       lan within workhours {
               pass    local-ok !local-block !ads !aggressive !anecdotes !audio-video !chat !drugs 
!gambling !hacking mail !porn !proxy !redirector !sex !violence !warez !warez1 any
               redirect <що_показати_замість_заблокованого>
       } else {
               pass    local-ok !local-block !ads !chat any
               redirect <що_показати_замість_заблокованого>
       }

       default {
               pass     none
               redirect <що_показати_замість_заблокованого>
       }
}

Можна обійтися значно простішим варіантом або створити більш "накручений". Як вам заманеться... Головне, що тут видно як можна розмежити доступ до певних ресурсів за умовою. В нашому випадку різні правила діють у робочий та неробочий час.

Тут також не визначено конкретний redirect. Це зроблено щоб підкреслити, що він може бути різним. У пакунку це сценарій cgi-bin squidGuard-ru.cgi. Але може бути і щось інше у залежності від того який ви ресурс блокуєте.

Запуск

Після створення файлу налаштувань є ще один важливий момент. У роботі використовуються бази у форматі BerkeleyDB. Бази ж поширюються у форматі звичайних текстових файлів. Ви можете нічого з цим не робити і залишити все як є. Проте, кожен раз коли треба буде перезапустити Squid, бази будуть побудовані під час старту. Якщо баз багато і вони чималенькі... власне, Squid може і не запуститися... Кращим рішенням буде -- до першого запуску побудувати всі визначені бази:

squidGuard -C all

Наведена команда генерує всі бази, що згадуються у файлі налаштувань. Можна генерувати бази і адресно. Треба також пам'ятати про права доступу до баз. Вони дещо інші від прав на текстові файли.

-rw-r--r--  1 root squid 243791 Dec 21 23:06 domains
-rw-rw-r--  1 root squid 643072 Jan 14 13:42 domains.db
-rw-r--r--  1 root squid     78 Jan 13 13:36 domains.diff
-rw-r--r--  1 root squid 110842 Dec 21 23:33 urls
-rw-rw-r--  1 root squid 307200 Jan 11 17:45 urls.db
-rw-r--r--  1 root squid     58 Jan 11 17:45 urls.diff

У прикладі з'явилися файли ще одного типу. Це *.diff. Вони дуже корисні коли ви користуєтесь "чужими" базами але бажаєте їх трохи підправити. Щось таки дозволити, а щось додатково заборонити. Кожен раз вносити зміни у отримані файли баз не надто зручно. А часом про це можна і зовсім забути. Файли з суфіксом .diff дозволяють тримати доповнення до баз окремо від самих баз.

Формат дуже простий. Один запис на рядок зі знаком плюс або мінус. Плюсові записи поповнюють базу. Мінусові -- вилучають запис з бази. Якось так:

+www.wchat.com.ua
-chatenabled.mail.google.co.in
-chatenabled.mail.google.com

Створивши такий файл, треба перестворити базу:

squidGuard -u BL/chat/urls

Прописувати ці файли у налаштуваннях програми не треба.

Далі можна провести тестування працездатності виконаних налаштувань як це описано у документації. Всі повідомлення про помилки будуть у журналі squidGuard.log який ми розмістили за змінною logdir. Поки там будуть скарги на неможливість чогось -- сам Squid працювати не буде. Запускати squidGuar окремо нема потреби. Він буде запускатися кожен раз коли Squid опрацьовує черговий запит, якщо, звичайно, ви визначили директиву його виклику у налаштуваннях Squid. Просто запустіть Squid з цими налаштуваннями коли вирішите, що все готово до роботи.

Надалі, кожен раз коли щось змінилося у налаштуваннях squidGuar треба перезапустити Squid. Також варто закачати та підключити більш повні бази з одного з рекомендованих сайтів. Просто закачуєте потрібні бази та кладете їх поряд з пакетними. Прописуєте у налаштуваннях squidGuar, генеруєте .db файли і презапускаєте Squid. Ну і, звичайно ж, не забудьте додати їх у правила доступу...

Підміна блокованих сторінок

Принципово, ви можете і не підміняти блокований зміст. Все буде працювати і без цього. Але трохи не естетично... Для того щоб ваш преглядач html сторінок заповнив чимось місце відведено авторами сторінки під блокований зміст використовується директива типу

redirect http://localhost/block.html

у правилах керування доступом. Тут може бути відсилання до статичного html файлу, якогось сценарію чи голосового повідомлення. Все залежить від вашого бажання та того, що ви блокуєте. У пакунку пренаправлення іде до сценарію cgi-bin. Сам сценарій також запаковано разом з усім іншим. Його лише треба покласти до відповідного каталогу доступної вам діючої веб-служби.

У нашому Apache 2 з коробки такі сценарії не виконюються. Буде треба дозволити виконання cgi через

a2enmod cgi

якщо команда httpd2 -V дає щось таке:

Server MPM:     Prefork
threaded:     no
forked:     yes (variable process count)

або a2enmod cgid якщо

Server MPM:     Worker
 threaded:     yes (fixed thread count)
 forked:     yes (variable process count)

Ну і звичайно ж описати каталог з скриптами у налаштуваннях потрібного вузла. Щось типу такого:

<Directory /var/www/html/cgi-bin>
       AddHandler cgi-script .cgi
       Options ExecCGI
   </Directory>

Чи встановлено все потрібне для виконання обраного сценарію можна перевірити якось так:

    perl -c squidGuard-ru.cgi
 squidGuard-ru.cgi syntax OK

У мене наче все гаразд. :)

Посилання

Звичайно це не все. Ви легко знайдете додаткові відомості з цього питання за допомогою вподобаної пошукової служби.

<<

SquidGuard: відмінності між версіями