squid, squidguard, sarg в Debian’е

Для чего используются squid, squidguard, sarg? Прокси-сервер squid используют для кэширования, что снижает потребление внешнего трафика, squidguard позволяет гибко фильтровать трафик, а sarg поможет собрать статистику, кто больше всех сидит в Интернете вместо работы, при помощи анализа логов. Все три эти программы можно использовать в комплексе, что обеспечит эффективную работу с офисным трафиком.

Настроим по порядку все три программы. Для начала установим пакеты:

apt-get install squid squidguard sarg

squidguard

В первую очередь настроим SquidGuard, после чего его будет использовать прокси-сервер Squid.
В первую очередь скачиваем списки, по которым будет осуществляться фильтрация. На сайте SquidGuard есть несколько списков. Я выбрал этот, он свободен к использованию в частных и некоммерческих целях.

wget http://www.shallalist.de/Downloads/shallalist.tar.gz

Скачанный файл распаковываем в директорию /var/lib/squidguard/db, в которой должны лежать директории BL/adv, BL/drugs, BL/gambling и другие директории, которые вам необходимы, либо все, содержащиеся в архиве.

tar -xf shallalist.tar.gz -C /var/lib/squidguard/db

Чтобы в дальнейшем можно было использовать эти файлы от имени пользователя proxy, необходимо изменить права владения:

chown -R proxy:proxy /var/lib/squidguard/db

Теперь редактируем основной конфигурационный файл SquidGuard — /etc/squidguard/squidGuard.conf, предварительно скопировав первоначальный.

cp /etc/squidguard/squidGuard.conf /etc/squidguard/squidGuard.conf.orig

Открываем файл на редактирование.
В самом начале идут две строчки:

dbhome /var/lib/squidguard/db
logdir /var/log/squidguard

Параметр dbhome определяет директорию, в которой хранятся файлы, содержащие списки блокируемых ресурсов, параметр logdir определяет директорию, в которой хранятся логи. После этого идут определения временных правил:

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

s — воскресенье
m — понедельник
t — вторник
w — среда
h — четверг
f — пятница
a — суббота
При помощи директивы date можно определить произвольную дату, либо задать шаблон дат при помощи маски.

После этого идут описания источников трафика, например такие:

src director {
        ip 192.168.0.11
}

src admin {
        ip 192.168.0.10
}

src managers {
        ip 192.168.0.15-192.168.0.20
        within workhours
}

src workers {
        ip 192.168.0.21-192.168.0.100
        within workhours
}

Затем идут описания открываемых сайтов по категориям.

dest good {
}
dest local {
}
dest drugs {
  domainlist BL/drugs/domains
  urllist BL/drugs/urls
  redirect http://192.168.0.2/blocked.html
}
dest adult {
  domainlist BL/porn/domains
  urllist BL/porn/urls
  redirect http://192.168.0.2/blocked.html
}
dest social {
  domainlist BL/socialnet/domains
  urllist BL/socialnet/urls
  redirect http://192.168.0.2/blocked.html
}
.....

Здесь вы можете определить все группы сайтов, которые будут фильтроваться. В директиве redirect указывается адрес некоторой ссылки на локальном сервере, который должен существовать. По этому адресу будет находиться страница с текстом «Blocked», например. И в конце файла идут правила фильтрации:

acl {
  admin {
    pass any
  }
  director {
    pass any
  }
  managers within workhours {
    pass good local !social !drugs !adult any
  } else {
    pass good local !drugs !adult any
  }
  workers within workhours {
    pass good local !social !drugs !adult any
  } else {
    pass good local !drugs !adult any
  }
  default {
    pass local none
    redirect http://192.168.0.2/blocked.html
  }
}

В данном пример директор и админ имеют доступ ко всему интернету, а менеджеру и рабочие имеют доступ к хорошим источникам, локальным сайтам, не имеют доступа к сайтам о наркотиках, сайтам для взрослых и к социальным сетям, а по окончании рабочего дня доступ к сайтам социальных сетей разрешен. Вы, естественно, можете добавить дополнительные правила.
Теперь обновляем базу данных адресов и доменов и меняем права на полученные файлы

squidGuard -d -C all
chown -R proxy:proxy /var/lib/squidguard/db

Теперь SquidGuard готов к работе, переходим к настройке squid.

squid

Squid будем настраивать в режиме прозрачного проксирования. Клиентами будут компьютеры, находящиеся в локальной сети с маской 192.168.0.0/24.
Открываем на редактирование файл /etc/squid/squid.conf, предварительно сделав резервную копию.

cp /etc/squid/squid.conf /etc/squid/squid.conf.orig

Сам файл отлично прокомментирован, каждый параметр описан с примерами. Прежде всего создаем правило, определяющее компьютеры, находящиеся в локальной сети. Закомментируем строки, включающие «acl localnet»

# acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
# acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
# acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

Нам нужно определить маску сети, которая будет считаться локальной сетью

acl localnet src 192.168.0.0/24

Немного ниже находим строчку

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

После этой строчки необходимо вставить правило для доступа из локальной сети

http_access allow localnet

Теперь надо подключить программу-редиректор, которой является SquidGuard. Находим «url_rewrite_program», который по умолчанию закомментирован. Включаем программу переписи URL и добавляем дополнительные параметры:

url_rewrite_program /usr/bin/squidGuard
url_rewrite_children 10

Параметр url_rewrite_children лучше всего подбирать эмпирически, то есть методом подбора наилучшего значения. Если потомков будет слишком мало, то трафик будет обрабатываться медленно, что скажется на скорости Интернета, если же их будет слишком много, то ресурсы будут расходоваться неэффективно. Количество подбирается так, чтобы при минимальных расходах ресурсов обеспечивалась оптимальная скорость доступа, без заметных задержек, чтобы скорость доступа с использованием прокси была сопоставима со скоростью доступа без прокси. После такой настройки скорость открытия страниц станет даже выше за счет кэширования часто используемых страниц. Если программа-редиректор умеет обрабатывать запросы параллельно, то необходимо изменить еще один параметр:

url_rewrite_concurrency 0

По умолчанию это значение равно нулю, если параметр закомментирован. Следующий параметр, который может быть полезен:

redirector_bypass off

Если все экземпляры редиректора заняты, то squid может завершить свою работу с ошибкой. Этот параметр позволяет обрабатывать адреса без использования редиректора, если невозможно запустить еще один экземпляр редиректора. Запрос просто будет пущен напрямую.
После этого можно перезапустить squid:

service squid restart

Теперь можно использовать прокси-сервер, но нам нужно еще настроить прозрачное проксирование. Для этого надо включить соответствующие правила iptables для перенаправления пакетов. На сетевом интерфейсе eth0 будет подключение к Интернету, а на интерфейсе eth1 будет подключение к внутренней локальной сети:

iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.1:3128
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

Как загружать правила iptables — вопрос вашего выбора, можете это делать так, как вам будет удобно. Если прозрачное проксирование не нужно, то можно настройку правил пропустить.

sarg

Осталось осуществить анализ логов прокси-сервера squid при помощи анализатора логов sarg (Squid Analysis Report Generator).
Самое первое, что надо сделать — отредактировать файл /etc/sarg/sarg.conf, изменив строчку

output_dir /var/lib/sarg

Здесь можно написать, допустим, /var/www/sarg. Это та директория, в которую будут помещаться сгенерированные файлы анализатора, которые можно будет просматривать в браузере. Директория, естественно, должна существовать. Сама генерация будет запускаться раз в сутки при помощи планировщика cron, поскольку sarg при установке помещает свой скрипт в директорию /etc/cron.daily/. Естественно, для просмотра файлов должен быть установлен и настроен веб-сервер.
Необходимо добавить директорию в конфигурационный файл apache

Alias /sarg /var/lib/sarg

    Options Indexes, FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all

В том же самом файле настроек sarg (/etc/sarg/sarg.conf) необходимо сменить кодировку генерируемых страниц:

charset Latin1

меняем на

charset utf8

Для проверки можно запустить генерацию страниц вручную для проверки работопособности командой

sarg-reports today

Теперь всё должно работать. Трафик кэшируется, фильтруется и вы можете просматривать результат анализа логов прокси-сервера в браузере по адресу http://<ваш-прокси-сервер>/sarg.

[wysija_form id=»2″]

Похожие посты: