 |
|
|
|
Система фильтрации интернет-трафика
Система фильтрации интернет-трафика Целью данных записок является создание простой в управлении и в то же время гибкой в настройке системы фильтрации интернет-трафика. Строить её мы будем на основе FreeBSD 4.5 + Squid + SquidGuard + Berkeley DB 3.2.9 + Apache. Стоит отметить, что обсуждаемые в этой статье приемы будут работать и на основе Linux. В принципе такой комплекс можно построить на любой UNIX-совместимой системе. Главная проблема – необходимость использования версий SquidGuard и Squid для этой системы. Apache можно заменить любым другим веб-сервером или использовать уже существующий веб-сервер. Кстати, веб-сервер можно запустить на отдельной машине под управлением любой операционной системы. Не стоит отчаиваться, если база данных Berkeley DB еще не портирована для вашей платформы. SquidGuard легко может работать и без нее. Вы можете спросить, зачем нам нужны все эти сложности? Как и любой другой ресурс, интернет-трафик имеет обыкновение заканчиваться. Да и канал от нас к провайдеру не резиновый, отсюда вывод – необходимо тем или иным способом ограничить аппетиты пользователей. С другой стороны, если начальство поймает кого-то из сотрудников за просмотром порносайтов или скачиванием mp3, нагоняй получит не только провинившийся. Администратор будет виноват в том, что позволяет сотрудникам тратить оплачиваемый организацией трафик на всякую ерунду. В то же время стоит помнить, что каждая организация имеет свои правила использования ресурсов сети Интернет. Довольно часто в списке запретов можно встретить не только эротику, но и сайты анекдотов, форумы и чаты. Например, бесплатные почтовые сайты могут быть запрещены из соображения секретности. Одновременно можно запретить пользователям скачивать из внешней сети выполняемые файлы. Это существенно снижает опасность вирусного заражения сети. Кроме того, перед нами все еще стоит задача экономии трафика. Существенно снизить его потребление поможет запрещение бесполезной для нас баннерной рекламы. Вы могли бы спросить, что в баннерах плохого? Squid – кеширующий прокси-сервер, соответственно, скачиваемые файлы ложатся в локальный кеш. При следующих запросах эти файлы уже не будут скачиваться из Интернета. Проблема в том, что баннерная реклама построена на применении механизма CGI (Common Gateway Interface), расшифровывается как «общий интерфейс шлюза». Характерным признаком которого является использование знака «?» в адресной строке запроса. Например, адрес одного из баннеров «Украинской Баннерной Сети» выглядит так: http://banner.kiev.ua/cgi-bin/bi.cgi?h" + user + "&"+ pid + "&" + page + "&2. К сожалению, CGI используется не только для баннерной рекламы, но и для чатов, форумов, сетевых магазинов и прочей полезной сетевой функциональности. То есть везде, где необходимо получить от пользователя данные. Затем полученные данные должны быть обработаны, а результаты работы CGI необходимо вернуть пользователю. Значит для каждого пользователя не только запросы, но и ответы будут разными. Поэтому класть полученные документы в кеш squid бесполезно. По умолчанию squid не использует кеш при работе с динамическими документами. В свою очередь, это значит, что одни и те же баннеры будут выкачиваться бесконечно. Подменяя баннеры пустыми картинками с локального веб-сервера, можно значительно снизить количество потребляемого трафика. Многие администраторы, столкнувшись с этими проб-лемами, могут утверждать, что они легко решаются с помощью штатных средств Squid. Я не стану отрицать, что Access Control List (списки контроля доступа), сокращенно ACL, используемые в Squid, – это довольно мощный инструмент. Но для работы с ним требуется достаточно большой опыт. С другой стороны, трудно представить, как администратор будет разбираться, какие сайты он должен блокировать. Остается только вслед за пользователями ходить на все часто посещаемые сайты, и постепенно запрещать неугодные. Учитывая количество сайтов в Интернете, а также распространенность баннерной рекламы, такой путь выглядит утопией. В начале такого ошибочного пути кажется, что нужно всего лишь записывать все запрещенные сайты в отдельные файлы с помощью ACL-записей типа: acl porno src "/usr/local/squid/etc/porno.lst" acl erotic src "/usr/local/squid/etc/erotic.lst" А затем запрещать их всех скопом. Но обслуживание такой системы способно превратиться в головную боль уже на первой тысяче сайтов. Squid загружает списки контроля доступа в оперативную память. С добавлением новых сайтов размер файла будет постоянно расти. Соответственно, и Squid будет занимать все больше оперативной памяти. В связи с тем, что список запрещенных сайтов неупорядочен, поиск в нем будет занимать довольно продолжительное время. SquidGuard выполняет за 12 секунд 100 000 запросов к базе, содержащей 205 900 записей. Тестирование проводилось на машине с процессором Pentium 500 МГц. Такой скорости удается добиться за счет того, что SquidGuard хранит список сайтов в форме B-дерева. Как мы видим, средствами Squid все вышеописанное выполнить достаточно тяжело. И тут в поле нашего внимания попадает класс программ под названием редиректоры. С разной степенью легкости эти программы позволяют решать наши проблемы. Используемый нами SquidGuard тоже является редиректором. Давайте коротко опишем его возможности.
В качестве кандидатов на место SquidGuard претендовали squirm и Jesred. После тестирования от squirm пришлось отказаться, потому что список фильтрации поддерживается всего один на всех пользователей. Соответственно запретить что-либо конкретному пользователю не представляется возможным. Запрещать приходится либо всем, либо никому. К тому же список сайтов приходится хранить в виде довольно сложных и неудобных для восприятия регулярных выражений. По моему мнению, такое ограничение не позволяет использовать squirm в сетях средних и больших размеров. Затем мне под руку попался Jesred. Несмотря на то что Jesred является модернизированным потомком squirm и имеет более гибкий синтаксис файла шаблонов, он все еще страдает от тех же проблем. Единственное улучшение в этой области – достаточно высокая скорость работы и возможность пропускать запросы некоторых пользователей без фильтрации. Как вы понимаете, в этом случае ни о каком гибком разграничении полномочий пользователей речь не идет. Ну что же, теперь, когда с формальностями и изучением начальной теории покончено, приступим к установке. Я думаю, нижеприведенных инструкций по настройке Apache и Squid хватит, чтобы установить их в комплектации по умолчанию. Для получения более подробных сведений вам стоит посетить следующие сайты: В процессе компиляции всего программного обеспечения вместо стандартного make мною использовался gmake, но это опять же вопрос личных предпочтений. Мне кажется, что gmake работает стабильнее и быстрее. В качестве прокси-сервера я использовал squid 2.5.STABLE1. На момент написания статьи это была самая свежая версия. Взять ее можно на http://www.squid-cache.org/Versions/v2/2.5. Рекомендуется всегда использовать самые новейшие из стабильных версий программ. Такой подход позволит в дальнейшем избежать многих проблем со стабильностью и безопасностью работы тех или иных инструментов. # tar zxvf squid-2.5.STABLE1-src.tar.gz # cd squid-2.5.STABLE1 # ./configure # gmake # gmake install После инсталляции редактируем файл конфигурации squid, находящийся в файле /usr/local/squid/etc/squid.conf. Должно получиться примерно следующее: # Обрабатывать запросы на порт 3128 http_port 3128 hierarchy_stoplist cgi-bin ? # Запрещаем кешировать CGI acl QUERY urlpath_regex cgi-bin ? no_cache deny QUERY # Размер оперативной памяти, отводимой под кеш cache_mem 64 MB # Тут мы будем брать файлы стандартных сообщений об ошибках error_directory /usr/local/squid/share/errors/Russian-koi8-r # Максимальный размер объекта, записываемого в кеш maximum_object_size 16384 KB # Здесь у нас будет храниться кеш. Отводим под него 5000 Мб. # Приказываем создать 16 директорий первого уровня и 256 второго уровня. cache_dir ufs /usr/local/squid/cache 5000 16 256 # Протокол доступа к кешу cache_access_log /usr/local/squid/logs/access.log # Тут находится протокол работы кеша cache_log /usr/local/squid/logs/cache.log # Протокол работы менеджера кеша cache_store_log /usr/local/squid/logs/store.log # Под этим пользователем будем ходить по Ftp ftp_user vasa@pupkin.ru # Если Squid уже скачал 60% файла, а пользователь отказался его забирать, то все равно продолжать скачивать файл. quick_abort_pct 60 # Время жизни запросов, завершившихся ошибкой. Например, «connection refused» или «404 Not Found» negative_ttl 1 minutes # Время жизни успешного DNS-запроса. positive_dns_ttl 6 hours # Время жизни DNS-запросов, завершившихся ошибкой. negative_dns_ttl 5 minutes # Поддержка нестандартных http-клиентов half_closed_clients on # Минимальные рекомендуемые права acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 # Ssl acl SSL_ports port 443 563 # http acl Safe_ports port 80 # ftp acl Safe_ports port 21 # https, snews acl Safe_ports port 443 563 # gopher acl Safe_ports port 70 # wais acl Safe_ports port 210 # unregistered ports acl Safe_ports port 1025-65535 # http-mgmt acl Safe_ports port 280 # gss-http acl Safe_ports port 488 # filemaker acl Safe_ports port 591 # multiling http acl Safe_ports port 777 acl CONNECT method CONNECT # описываем наших пользователей acl users src "/usr/local/squid/etc/users.txt" # Разрешаем соединения только по правильным портам. И раздаем всем права доступа http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access allow users http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access deny all # Адрес пользователя, которого будут уведомлять о переполнении кеша cache_mgr root@test.ru # Пользователь, от имени которого будет работать Squid cache_effective_user nobody # Группа, от имени которой будет работать Squid cache_effective_group nogroup # Включать ли IP-адрес клиента в заголовок http-запроса forwarded_for on # Разрешаем управлять кешем с помощью cachemgr.cgi. В качестве пароля будем использовать слово «passwd» cachemgr_passwd passwd all # Включаем сбор статистики по каждому клиенту client_db on Обращаю ваше внимание на строку acl users src «/usr/local/squid/etc/users.txt». Она означает, что список пользователей, которым разрешен доступ к squid, находится в файле /usr/local/squid/etc/users.txt. Файл списка имеет следующий формат: #Петрова Наталья (Снабжение) 192.168.10.91/32 #Иванов Владимир (Доставка) 192.168.10.92/32 #Сергеев Игорь (Плановый отдел) 192.168.10.93/255.255.255.255 #Кривоухина Ирина (Лаборатория) 192.168.10.94/255.255.255.255 #Синицына Светлана (секретарь генерального директора) 192.168.10.95/255.255.255.255 Реально в списке содержатся не имена пользователей, а IP-адреса их машин. Как вы смогли убедиться, все устроено достаточно просто. Решено работать с отдельным файлом, содержащим список пользователей, чтобы не перегружать главный конфигурационный файл. Users.txt должен иметь те же права доступа, что и squid.conf, для того чтобы squid мог читать его содержимое. # chown nobody:nogroup /usr/local/squid/etc/users.txt Возможен и другой вариант управления доступом к web. При этом доступ во внешнюю сеть средствами squid не ограничивается. Разграничением доступа в этом случае будет заниматься SquidGuard. Для тех пользователей, чей адрес не внесен в файл /usr/local/squidGuard/squidGuard.conf, производится перенаправление на страницу запрещения. Соответственно, эти пользователи никогда Интернета не увидят. Чтобы добиться такого эффекта, нужно удалить из squid.conf строки: acl users src "/usr/local/squid/etc/users.txt" http_access allow users http_access deny all И добавить в squid.conf вместо них строку: http_access allow all Мне больше нравится второй вариант разграничения доступа. Если использовать традиционную схему разграничения прав, то проверка прав доступа происходит дважды. Сначала внутри Squid, а затем в SquidGuard. Мне кажется, что управлять доступом в одной точке гораздо удобнее. Но это опять же дело вкуса. Настало время создать директорию, в которой у нас будет храниться кеш squid. # mkdir /usr/local/squid/cache А тут у нас будут лежать логи. # mkdir /usr/local/squid/logs Нужно позаботиться, чтобы директории /usr/local/squid/cache и /usr/local/squid/logs были доступны пользователю, от имени которого работает squid. Узнать имя этого пользователя можно так: # cat /usr/local/squid/etc/squid.conf | grep cache_effectiv
Получается, что пользователя зовут nobody, группа у него nogroup. # chown -R nobody /usr/local/squid/cache /usr/local/squid/logs # /usr/local/squid/sbin/squid -z Внутри директории /usr/local/squid/cache создаем иерархию директорий для хранения кеш-файлов. Заглянув в /usr/local/squid/cache, вы сразу поймете, что имелось в виду под словом иерархия. Запускаем squid. # /usr/local/squid/sbin/squid -D А на другой консоли смотрим, какие сообщения об ошибках появляются в файле протокола. # tail -f /var/log/messages Если все сделали правильно, тогда должны увидеть что-то подобное:
Это значит что, squid у нас заработал. Теперь примемся за установку Russian Apache. Я использовал весрсию 1.3.27 PL30.16. Ну а вы, как всегда, берите новейший дистрибутив ftp://ftp.lexa.ru/pub/apache-rus/apache_1.3.27rusPL30.16.tar.gz. Распаковываем его и ставим в комплекте по умолчанию. # tar zxvf apache_1.3.27rusPL30.16.tar.gz # ./configure # gmake # gmake instal Запускаем apache: /usr/local/apache/bin/apachectl start Создаем директорию, где будут лежать пустой баннер и файл mp3 с каким-либо забавным звуком. # mkdir /usr/local/apache/htdocs/replace Кладем туда 1x1.gif и my.mp3. Берем модифицированный block.cgi и копируем его в /usr/local/apache/cgi-bin Выставляем ему нужные права: # chown nobody:wheel /usr/local/apache/cgi-bin/block.cgi # chmod 500 /usr/local/apache/cgi-bin/block.cgi block.cgi – это perl-скрипт, который будет вызываться каждый раз, когда пользователь попытается посетить запрещенную страницу. Взять его можно из архива с дистрибутивом squidGuard. В первоначальном варианте этот скрипт назывался squidGuard-1.2.0/samples/squidGuard.cgi.in. Можно использовать его, но все же лучше взять слегка модифицированный мною вариант. Мой скрипт, наверное, лучше, потому что руссифицированный. На его исправление ушло почти два часа. Итак, все подготовительные работы окончены, и самое время взяться за установку squidGuard 1.2.0. Для его работы необходимо иметь Berkeley DB обязательно версии 3.2.9. В свою очередь, Berkeley DB не соберется без libtool. Довольно запутаная получается цепочка. Но бояться не стоит. Берем libtool из коллекции портированных приложений (http://www.freebsd.org/cgi/pds.cgi?ports/devel/libtool) и, как обычно, выполняем распаковку, компиляцию, а затем и установку: # tar zxvf libtool-1.3.4.tar.gz # cd libtool-1.3.4 # ./configure # gmake # gmake install С выполнением этих действий не должно возникнуть никаких сложностей. Скачиваем Berkeley DB 3.2.9 с http://www.sleepycat.com/update/index.html. Забираем два патча http://www.sleepycat.com/download/patchlogs.shtml. И снова: # tar zxvf db-3.2.9.tar.gz Копируем патч-файлы в получившуюся после распаковки дистрибутива директорию db-3.2.9. Затем применяем их для модификации исходного кода. # cp patch.3.2.9.1 patch.3.2.9.2 ./db-3.2.9 # cd /usr/local/src/db-3.2.9 # patch -p0 < patch.3.2.9.1 # patch -p0 < patch.3.2.9.2 А теперь снова компиляция. # cd build_unix # ../dist/configure # gmake # gmake install Забираем squidGuard-1.2.0 с http://www.squidguard.org/download. Распаковываем и компилируем: # tar zxvf squidGuard-1.2.0.tar.gz # cd squidGuard-1.2.0 # ./configure --prefix=/usr/local/squidGuard --with-db=/usr/local/BerkeleyDB.3.2 --with-sg-config=/usr/local/squidGuard/squidGuard.conf --with-sg-logdir=/usr/local/squidGuard/log --with-sg-dbhome=/usr/local/squidGuard/db Разберемся с ключами, передаваемыми программе configure:
# gmake # gmake test # gmake install Cоздаем для хранения файлов протоколирования работы squidGuard директорию /usr/local/squidGuard/log. # mkdir /usr/local/squidGuard/log Официальный список блокируемых доменов можно взять на сайте squidGuard – http://www.squidguard.org/blacklist. Также доступен список от MESD – http://squidguard.mesd.k12.or.us/blacklists.tgz. И еще один хороший список от Dansguardian – http://blacklist.dansguardian.org/cgi-bin/download.pl?type=download&file=bigblacklist. Кратко сравним их между собой:
Итак, вполне очевидно, что лучше всего взять список MESD или Dansguardian. Какой из них выбрать – оставляю на ваше личное усмотрение. И тот, и другой обновляются довольно часто. Но во избежание перегрузки сервиса, не стоит качать списки чаще чем раз в неделю. Скачав себе один из списков, распакуем его в директорию /usr/local/squidGuard/db: # tar zxvf blacklists.tgz -C /usr/local/squidGuard # mv /usr/local/squidGuard/blacklists /usr/local/squidGuard/db В директории /usr/local/squidGuard/db появилось несколько поддиректорий. В свою очередь, в каждой из них лежат файлы:
Если бы мы взяли официальный список squidGuard, то внутри каждой директории можно было бы увидеть файлы обновлений к базам с такими названиями:
Внутри каждого из этих файлов находятся записи вида: +xratedpornsite.com +209.51.157.43 -zena.cenhost.com -scuzz.xtac.com Также в директории находятся файлы:
С записями вроде: -silva.org/look_at_me +recom.it/fuck/beatrice Записи, начинающиеся знаком «+», – это запрос на добавление строчки в главную базу. Соответственно, строки с минусом имеют обратное назначение. К сожалению, применить файлы обновления можно только к базе в формате Berkeley DB. Выполняется это действие командой: # squidGuard -u Мне кажется, что такой способ обновления не очень удобен. Поэтому нам следует либо отказаться от списка доменов, составленного squidGuard, либо написать конвертор обновлений в нормальный формат. Разобравшись с форматом базы, приступим к конфигурированию squidGuard. Cоздаем файл /usr/local/squidGuard/squidGuard.conf. И вносим в него вот это: # тут у нас лежат логи logdir /usr/local/squidGuard/log # здесь базы dbhome /usr/local/squidGuard/db # описываем адреса отдела ИТ src it-department { ip 192.168.10.222-192.168.10.223 } # отдел доставки src dostavka { ip 192.168.10.101, 192.168.10.104 } # отдел снабжения src snab { ip 192.168.10.105 } # говорим, что все обращения к файлам *.mp3 нужно перенаправить на http://192.168.10.9/replace/my.mp3 rewrite mp3 { s@.*.mp3$@http://192.168.10.9/replace/my.mp3@r # и запротоколировать это событие в файле /usr/local/squidGuard/log/rewr_mp3 log rewr_mp3 } # описываем базу порносайтов dest porn { domainlist porn/domains urllist porn/urls # записать протокол в файл /usr/local/squidGuard/log/porn log porn } # описываем базу рекламы dest ads { domainlist ads/domains urllist ads/urls # записать протокол в файл /usr/local/squidGuard/log/ads log ads # подменяем все баннеры прозрачным изображением размером 1x1 пиксель redirect http://192.168.10.9/replace/1x1.gif } # описываем свою собственную базу баннерных систем dest banners { domainlist banners/domains # в этом файле записаны выражения типа baner, banner, ads, # show_ads expressionlist banners/expressions urllist banners/urls # перенаправляем все запросы на прозрачный gif размером 1x1 пиксель redirect http://192.168.10.9/replace/1x1.gif log banners } # описываем домены, которые никогда не должны блокироваться вне зависимости от списка скачиваемого из сети dest local-ok { domainlist local-ok/domains urllist local-ok/urls } # описываем домены, которые должны быть заблокированы всегда вне зависимости от списка скачиваемого из сети dest local-block { domainlist local-block/domains urllist local-block/urls # и перенаправляем все запросы на block.cgi redirect http://192.168.10.9/cgi-bin/block.cgi?clientaddr=%a&clientname=%n&clientident=%i&clientgroup=%s&targetgroup=%t&url=%u } # начинаем раздавать права acl { # отделу ИТ можно все, кроме рекламы it-department { pass local-ok !banners !ads all } dostavka { pass local-ok !porn !banners !ads !local-block all redirect http://192.168.10.9/cgi-bin/block.cgi?clientaddr=%a&clientname=%n&clientident=%i&clientgroup=%s&targetgroup=%t&url=%u rewrite mp3 } # отделу снабжения разрешаем только то, что определено в local-ok snab { # так можно дать пользователю доступ только к избранным сайтам pass local-ok none redirect http://192.168.10.9/cgi-bin/block.cgi?clientaddr=%a&clientname=%n&clientident=%i&clientgroup=%s&targetgroup=%t&url=%u rewrite mp3 } # действия, выполняемые по умолчанию, если пользователь не описан ни в одном src default { # блокируем все pass none redirect http://192.168.10.9/cgi-bin/block.cgi?clientaddr=%a&clientname=%n&clientident=%i&clientgroup=%s&targetgroup= Not_Authorized&url=%u # пишем логи в файл /usr/local/squidGuard/log/default log default } # закрываем список acl } Кстати, не забудьте скачать мою базу баннеров: http://onix.opennet.ru/files/banners.tar.gz. Потом вы сможете вносить в нее свои собственные записи. Иначе при запуске squidGuard будет жаловаться на ее отсутствие и становиться в режим холостой работы. В этом режиме он будет пропускать все запросы без обработки. Покончив с файлом конфигурации, продолжим настройку squidGuard. Даем права пользователю, от имени которого будет работать squidGuard на директории log и db. Так же поступаем и с файлом squidGuard.conf. # chown -R nobody /usr/local/squidGuard/log/usr/local/squidGuard/db # chown nobody /usr/local/squidGuard/squidGuard.conf SquidGuard может работать с текстовыми базами данных, но в таком случае при каждом запуске ему приходится создавать в оперативной памяти бинарное дерево всех загружаемых баз в формате Berkeley DB. Этот процесс занимает длительное время. Подобных задержек можно избежать, если заранее самому создать базы в нужном формате. На моей машине после создания баз время загрузки сократилось почти в 10 раз. Поэтому мы напишем скрипт (http://onix.opennet.ru/files/rebuid_base.tar.gz) для перестройки баз и перезапуска squidGuard с новыми базами. # cat > /usr/local/squidGuard/bin/rebuid_base.sh #!/bin/sh /usr/local/squidGuard/bin/squidGuard -C all chown -R nobody /usr/local/squidGuard/db killall -HUP squid ^D Устанавливаем нужные права доступа на файл rebuid_base.sh. Убедимся, что этот скрипт имеет право запускать только пользовать root. # chmod 100 /usr/local/squidGuard/bin/rebuid_base.sh # /usr/local/squidGuard/bin/rebuid_base.sh Запустив rebuid_base.sh, необходимо дождаться нормального завершения задачи. Теперь во всех директориях, упомянутых в разделах dest конфигурационного файла, появились файлы баз данных domains.db и urls.db. Перед тем как подключать squidGuard к squid, необходимо протестировать его локально. Для начала немного теории. Squid передает данные на стандартный ввод редиректора. Редиректор, в свою очередь, обрабатывает запрос и выдает на стандарный вывод результаты своей работы. Затем squid забирает эти данные. Редиректор отвечает на запрос от squid либо пустой строкой, если перенаправление не требуется, либо измененным URL. Формат запроса от squid к редиректору выглядит так:
Для того чтобы проверить, как squidGuard будет реагировать на запросы пользователей, скачиваем написанную мною тестовую программу test.tar.gz (http://onix.opennet.ru/files/test.tar.gz). Распаковываем ее и кладем полученный файл test.pl в /usr/local/squidGuard/bin/. Устанавливаем файлу test.pl разрешение на выполнение. Затем запускаем test.pl и вводим тестируемый адрес. После этого в файле result.txt смотрим результаты работы squidGuard. Набор тестируемых сайтов можно изменять прямо в файле test.pl. Если результаты теста вас удовлетворили, значит самое время объединить squidGuard и Squid. В файл /usr/local/squid/etc/squid.conf добавляем строки: # если ни один из экземпляров squidGuard не отвечает, то работать напрямую redirector_bypass on # где находится squidGuard redirect_program /usr/local/squidGuard/bin/squidGuard # сколько экземрляров squidGuard запускать redirect_children 1 Перезапускаем squid. В свою очередь, squid самостоятельно выполнит перезапуск всех дочерних процессов редиректоров. # killall -HUP squid В конце файла /usr/local/squidGuard/log/squidGuard.log ищем такие строки: 2002-10-15 16:11:04 [10653] squidGuard 1.2.0 started (1034683864.337) 2002-10-15 16:11:04 [10653] squidGuard ready for requests (1034683864.353) Если они есть, значит все работает как положено. Теперь сделаем так, чтобы Squid и Apache запускались автоматически при каждой загрузке машины. # cat > /usr/local/etc/rc.d/apache.sh #!/bin/sh /usr/local/apache/bin/apachectl start ^D # cat > /usr/local/etc/rc.d/squid.sh #!/bin/sh /usr/local/squid/bin/squid -D ^D # chmod 100 /usr/local/etc/rc.d/apache.sh /usr/local/etc/rc.d/squid.sh Настало время перезагрузить машину. Это даст нам возможность посмотреть, как сервисы поведут себя при возможных перебоях в подаче электричества. В качестве маленького бонуса можно наладить автоматическое обновление базы доменов. Для скачивания файла базы доменов нам понадобится программа wget – http://www.freebsd.org/cgi/pds.cgi?ports/ftp/wget. Конечно, можно было обойтись и стандартным fetch. Но все же wget работает гораздо надежнее. Распаковываем и ставим как обычно. # tar zxvf wget-1.8.2.tar.gz # cd wget-1.8.2 # ./configure # gmake # gmake install Смотрим, куда он у нас установился. # where wget Пишем скрипт (http://onix.opennet.ru/files/rebuid_ba-se.tar.gz), который будет выкачивать обновления с сайта MESD и класть их в директорию /usr/local/squidGuard/update. Затем архив с обновлениями будет распакован и скопирован в директорию /usr/local/squidGuard/bd. После этого будет произведена перестройка баз и перезапуск squid. #cat > /usr/local/squidGuard/bin/update_blacklist.sh #!/bin/sh /usr/local/bin/wget -q --cache=off "http://squidguard.mesd.k12.or.us/blacklists.tgz" -O /usr/local/squidGuard/update/blacklist.tgz tar zxvf /usr/local/squidGuard/update/blacklist.tgz -C /usr/local/squidGuard/update/ cp -R -f /usr/local/squidGuard/update/blacklists/* /usr/local/squidGuard/bd rm -R /usr/local/squidGuard/update/blacklists /usr/local/squidGuard/rebuid_base.sh ^D Теперь даем нашему скрипту нужные права. # chmod 100 /usr/local/squidGuard/bin/update_blacklist.sh Создадим временную директорию, в которую будут распаковываться обновления. # mkdir /usr/local/squidGuard/update Настраиваем планировщик на выполнение нашего задания. # crontab -e -u root MAILTO="admin@test.ru" 1 0 * * 7 /usr/local/squidGuard/bin/update_blacklist.sh Назначаем выполнение обновления на 0 часов 1 минуту каждого воскресенья. Уведомление о выполнении этого задания приказываем направлять на адрес admin@test.ru. Теперь осталось раздать всем пользователям подобающие права и можно отдыхать. |
АНДРЕЙ БЕШКОВКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
