Установка и настройка SARG для анализа логов SQUID на CentOS

Приложение SARG для представления статистики посещений сайтов в графическом интерфейсе требует веб-сервера. В данной инструкции мы установим и настроим как сам SARG, так и веб-сервер на основе NGINX. Прокси-сервер SQUID устанавливается по инструкции Установка и настройка Squid на CentOS.

Установка и запуск SARG

Установка

В отличие от Debian / Ubuntu, в репозиториях CentOS программное обеспечение SARG отсутствует — установку будет производить из исходников.

Устанавливаем пакеты необходимые для сборки пакета из исходников:

yum install gcc

Скачиваем последнюю версию исходников:

wget https://sourceforge.net/projects/sarg/files/latest/download -O sarg.tar.gz

Распаковываем скачанный архив:

tar zxvf sarg.tar.gz

И переходим в распакованный каталог:

Конфигурируем исходные файлы:

. и устанавливаем его:

Настройка и запуск

Открываем конфигурационный файл sarg:

Снимаем комментарии для следующих настроек:

.
access_log /var/log/squid/access.log
.
output_dir /usr/share/nginx/html/squid-reports
.
date_format e
.
overwrite_report yes
filename.n+1
.

• access_log — путь до логов squid. Если мы не меняли настройки для самого прокси-сервера, то задаем значение/var/log/squid/access.log.
• output_dir — каталог, в котором будут находиться html-отчеты. Это должен быть каталог, из которого веб-сервер будет читать файлы портала. Так как в нашем примере мы будет использовать NGINX, мы указали путь, начинающийся с /usr/share/nginx/html, так как именно в этой директории по умолчанию находятся файлы NGINX.
• date_format — формат даты. В данном примере мы выбрали европейский.
• overwrite_report — перезаписывать отчеты, которые уже были сформированы ранее.
• filename.n+1 — при формировании отчета за один и тот же день, прибавлять к названию файла 1.

Запускаем формирование отчета:

Система проверить корректность настройки в конфигурационном файле SARG и сформирует html-отчет в папке, указанной в опции output_dir (в нашем примере, /usr/share/nginx/html/squid-reports).

Веб-сервер

Как говорилось ранее, для просмотра отчетов в графическом интерфейсе нам нужен веб-сервер. Для его развертывания, сначала ставим репозиторий EPEL:

yum install epel-release

После ставим nginx:

yum install nginx

Разрешаем автозапуск nginx и стартуем сервис:

systemctl enable nginx

systemctl start nginx

Открываем 80 порт в брандмауэре:

firewall-cmd —permanent —add-port=80/tcp

При необходимости просмотра статистики по https также добавим правило:

firewall-cmd —permanent —add-port=443/tcp

Открываем браузер и переходим по адресу http:// /squid-reports/ — должна открыться стартовая страница со списком дат:

Чтобы просмотреть список посещенных сайтов и израсходованного трафика, переходим к нужной нам дате и выберем пользователя, для которого нужно получить статистику. Идентификация пользователей в sarg зависит от идентификации в squid — если проверка не выполняется, то в качестве идентификаторов будут фигурировать IP-адреса.

Автоматическое формирование отчетов

Для формирования новых отчетов необходимо каждый раз запускать команду sarg -x. Чтобы автоматизировать процесс, добавим задание в планировщик Linux.

Открываем на редактирование cron:

0 0 * * * /usr/local/bin/sarg -x

* в данном примере мы будем запускать формирование отчета каждый день в 00:00.

Немного об альтернативе

Помимо SARG, для SQUID существуют другие анализаторы логов. Они имеют схожие принципы работы — консольный запуск анализа и формирования html-отчетов, и предоставление доступа к статистики посредством веб-интерфейса.

Наиболее популярные альтернативы SARG:

1. Lightsquid. Легкий парсер логов, использующий для анализа журналов скрипты, написанные на perl. Также

2. Free-SA. Изначально, планировался как замена другим устаревающим анализаторам логов прокси-сервера, но сам проект уже давно не обновлялся. Имеет интерфейс, схожий с sarg.

3. SAMS. В большей степени, это приложение для управления прокси-сервером SQUID, однако в нем предусмотрена также функция сбора статистики посещений сайтов. Подробнее об установке в инструкции Установка и настройка SAMS2 на CentOS.

4. Calamaris. Еще один парсер журналов с хорошей статистикой по нагрузке на прокси.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• SARG — анализируем логи прокси-севера Squid

SARG — анализируем логи прокси-севера Squid

Одним из насущных вопросов для системного администратора является получение статистики использования интернета в организации. Располагая такими данными всегда можно ответить на вопрос руководства «куда ушел весь интернет», обосновать необходимость расширения канала, своевременно выявлять и пресекать нежелательный трафик. Сегодня мы рассмотрим такое решение для нашего роутера на платформе Ubuntu Server.

Основной интересующий нас тип траффика — HTTP, который составляет львиную долю входящего интернет-трафика в организации и наиболее интересен, так как позволяет судить об активности и предпочтениях пользователей (а также о том, как они проводят рабочее время). Все необходимые нам данные имеются в логах прокси-сервера Squid, но не будем же мы просматривать их вручную! Необходим инструмент, позволяющий анализировать и предоставлять отчеты на основе этих логов. Одним из таких инструментов является SARG — Squid Analysis Report Generator, что и отражено в его названии.

Приступим. Прежде чем браться за установку SARG необходимо подготовить сервер, данная утилита выдает отчеты в формате HTML и для работы с ними потребуется установленный веб-сервер. Если вы не собираетесь использовать роутер в качестве полноценного веб-сервера, то будет вполне достаточно легкого сервера lighttpd:

Сервер начинает работать сразу после установки, для проверки наберите в браузере адрес сервера и вы увидите стандартную страницу. По умолчанию lighttpd принимает соединения на всех интерфейсах, что нас никоим образом не устраивает, ограничим его работу внутренней сетью. Открываем конфигурационный файл /etc/lighttpd/lighttpd.conf, находим и приводим к следующему виду опцию:

где 10.0.0.1 — внутренний адрес роутера, также не забудьте раскомментировать эту строку и перезагрузить веб-сервер:

Настройка анализатора логов довольно проста и сводится к выбору языка, кодировки и формата отчета, а также пути для его размещения. Все изменения вносим в файл /etc/sarg/sarg.conf:

Также находим и комментируем строку:

Теперь можем проверить работу анализатора:

После того как утилита закончит работу набираем в браузере http://10.0.0.1/squid-reports, вы должны увидеть следующую страницу:

По умолчанию SARG формирует отчет за весь доступный период, отчет содержит детализацию по пользователям (адресам) и посещенным ими сайтам, использованию трафика и кэша, загрузкам. Отдельно можно просмотреть наиболее посещаемые сайты, данный отчет сортирует сайты не по трафику, а по количеству посещений.

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

Можно также просмотреть график потребления трафика и статистику работы по датам и времени.

Если есть желание, можете настроить отображение отчетов по собственному вкусу, конфигурация SARG использует для задания параметров вывода отчетов стандартные HTML теги и неплохо документирована. Если вы владеете HTML на базовом уровне, эта операция не должна вызвать у вас затруднений.

Анализатор настроен и работает, это хорошо. Но запускать его каждый раз вручную не очень интересно, поэтому настроим систему на получение ежедневных, еженедельных и ежемесячных отчетов. Для этого откроем файл /etc/sarg/sarg-reports.conf и укажем путь для размещения отчетов, а также адрес и ссылку для логотипа.

Учтите, что изображение логотипа должно находиться в пределах корневой папки веб-сервера (/var/www) и пути указываются от корня веб-сервера, а не файловой системы.

Теперь зададим расписание для формирования отчетов, которое необходимо добавить в /etc/crontab

Данное расписание означает, что каждый час с 9:00 до 18:00 (рабочий день организации) запускается скрипт формирования ежедневной статистики, каждый день в 22:00 формируется статистка за день, в 22:30 Воскресенья — статистка за неделю и первого числа каждого месяца в 23:30 статистика за месяц.

Настройка squid или как не купить платное решение

Часто в организациях используем разного рода прокси, прокси как составляющая программного шлюза или самостоятельный классический вариант squid + анализатор логов и т.п.

Мы пытались внедрить решение от Ideco и ИКС, в итоге остановились на squid. Под катом история пути и техническая информация по настройке старого доброго кальмара.

Начну пожалуй с того, что конечно странно на habr в 2018 году видеть статью про настройку squid, но тем не менее, даже в нынешние время платные продукты могут уступать по некоторым пунктам open source софту который так или иначе лежат в основе платного продукта с красивым интерфейсом.

Всё началось с того, что руководство дало ясно понять что мы можем позволить себе купить интернет биллинг.

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

В сети компании насчитывается свыше 550 компьютеров. Большинству из них нужен доступ к внутренним ресурсам.

Все разворачивалось в виртуальной среде, сервер виртуализации Hyper-v core — Неверный выбор, о причинах изложу в конце статьи.

Немного о выборе конкурсантов, UserGate помню его из времен начала работы в IT, по старой памяти приложение windows — по умолчанию не подходит.

Интернет Контроль Сервер (ИКС)- дело дошло до тестов. Удалось корректно загрузить из 10 только 2 раза, отмечая его отличную нестабильность пошли дальше. К стати, не могу не отметить юмор разработчиков, кто в курсе тот поймет! Продукт развивается, может быть уже проблем нет, но и задача решена.

Ideco — мне понравилось, отличное решение, но в функционал включен не только интернет биллинг, это полноценный шлюз со всеми плюшками, для нас лишнее. Но тем не менее он прошел полный тест, возникло 2 непреодолимых препятствия:

1. Невозможно дать доступ к определенным ресурсам всей сети или всем пользователям домена — по умолчанию не считая таких пользователей за пользователя которого нужно лицензировать.

1.1 — Из пункта 1 вытекает немалая цена, т.к. у нас в компании довольно много компьютеров которым необходимо подключение к внутренним web сервисам и не нужен доступ в интернет, покупать лицензии для использования внутренних ресурсов мы не планировали, также не планировали разводить зоопарк серверов раздающих интернет.

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

Кстати, шлюз ideco доступен в бесплатной версии до 40 пользователей и без привязки к AD. Также появился IDECO SELECTA, или я не заметил его выпуска или он был выпущен уже после всех тестов.

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

Начнем с того, что корректных и полных мануалов в сети нет, есть некоторые части, но все инструкции сводились на нет новыми релизами сквида.

Мы используем ubuntu server, следовательно следующая информация актуальна для этой ОС и с другими ОС может серьёзно различаться.

Все в командной строке нужно делать из под sudo, далее дописывать перед каждой командой sudo не буду.

Настройка OS ubuntu server 16.04:

Т.к. мы используем Hyper-v виртуализацию то мы установили необходимые пакеты.

Качаем с оф сайта сквид, в данном посте разбираем версию 3.5.26, для других версии возможно будет неактуально. UPD в докере настроил 3.5.28 полет нормальный.

Распаковываем в home или любой другой каталог.

Указываем какие пакеты нам нужны, можете ненужное удалить или что-то добавить. Кому-то покажется что тут куча лишнего. Список взять из установленной версии сквида и добавлены дополнительные пакеты.

—with-openssl=/usr/lib/ssl/ — указываем путь до openssl, указан дефолтный путь в ubuntu server.
—disable-ipv6 — выключаем ipv6 — о причинах читайте ниже.
—enable-ssl-crtd — это для связки генерации ssl сертификатов для bump.

Возможно будут зависимости, нужно их установить.

По умолчанию все устанавливается в /etc/squid/

Создаем папку внутри /etc/squid для ssl сертификатов:

Создаем сертификат:
Переходим в каталог

Конвертируем сертификат в понятный для браузера формат

Создаем базу сертификатов:

Обращаю Ваше внимание на то, что имя прокси сервера и имя указанное при создании сертификата должно быть одинаковое. Формат squid3.domain.local.

Полученный squid3domainlocal.der через групповые политики или вручную вносим в доверенные центры сертификации. Прокси сервер в браузере указываем не ip а полное имя компьютера, к примеру squid3.domain.local.

Создаем обычного пользователя в домене, пусть будет squid3.

Для прохождения аутентификации через kerberos нам нужен keytab пользователя squid3 для principal HTTP/squid3.DOMAIN.LOCAL@DOMAIN.LOCAL, при стандартном входе в домен через net ads создается keytab /etc/krb5.keytab, но в нем указаны principal не http а host. Что делает невозможным проходить аутентификацию пользователей через web браузер. Если Вы расположили keytab в /etc/krb5.keytab и после вводите в домен саму машину, то keytab просто будет дополнен новыми principal.Но обращаю Ваше внимание на то, что устанавливать пакет samba и вводить машину в домен не нужно, достаточно сгенерированного keytab для пользователя.

Далее идем на домен контроллер и выполняем нехитрую команду:

Переносим полученный файл на прокси сервер и далее помещаем в удобное расположение, я выбираю /etc/krb5.keytab.

Если Вы хотите сделать авторизацию еще и для web сайта, статистика или внутренний портал компании то нужно создать группу и включить туда пользователей proxy и www-data.

Добавляем необходимых пользователей в группу:

Назначаем владельцев на krb5.keytab

Если нет необходимости дополнительным сервисам давать доступ, то группу не создаем, просто выставляем владельцев и права:

Чтение и запись для root, только чтение для allowreadkeytab и без доступа для остальных.

Обращаю Ваше внимание, что ниже squid.conf не будет содержать все acl и все правила, будут лишь по 1 примеру настройки, полная настройка acl и листами доступа к сайтам и т.п. будет слишком объемной. Ниже приведенный конфиг можно рассматривать как требующий доработки под свои нужды.

Переходим к настройке squid:

Тут важный момент, есть сайты которые поднимают соединение непосредственно с «компьютером», и аутентификация пользователя не производится. Как следствие происходит блокировка соединения. Для обхода этой проблемы дается доступ конкретному ip к конкретному сайту.

. Важное примечание . Правило должно быть расположено выше правил с аутентификацией basic, ntlm, kerberos и др.

Acl для определения типа контента:

acl application_mime rep_mime_type application/octet-stream
acl video_mime rep_mime_type «/etc/squid/ban/mime_type_video.txt»

Также фильтровать некоторый контент можно по url, для этого создаем acl:

acl blockextention urlpath_regex -i «/etc/squid/ban/blockextention.txt»

Есть еще любопытный acl allowerrorsert, т.к. мы не разрешаем по умолчанию доступ к сайтам с кривыми сертификатами, я использую allowerrorsert для определения перечня разрешенных сайтов с «кривыми» ssl. Об этом не много ниже.

Также есть возможность управлять доступом к сайтам на основе ssl правил, но на мой взгляд эффективнее управлять через http_access. Вот пример acl для использования в правилах ssl:

Ниже мы еще вернемся к этому типу acl и их применению.

Позволяет видеть в расширенном режиме запросы POST и mime.

Аутентификация и авторизация пользователя в группе active direcory через kerberos:

Тут следует остановиться и разобрать подробнее, children — максимальное количество процессов доступные для запуска, startup количество процессов которые запущены всегда, idle максимальная очередь к помощнику при превышении указанного числа будет запускаться новый процесс помощника.

Небольшое отступление по работе авторизации:

Тут есть особенность, дело в том, что некоторые сайты пытаются подключить вагон разных ресурсов и картинок с других сайтов, собрать кучу статистики и прочее, каждый запрос проходит авторизацию это может вызвать большую очередь к процессу помощника авторизации, можно просто увеличить children, увеличить idle… но это только на первый взгляд, запросов от 1 пользователя может быть несколько десятков тысяч, что за собой несет большую очередь. При появлении большой очереди нагрузка на CPU зашкаливает. В условиях большого количества пк и малой доли пользователей с полноценным доступом в интернет, установленный на пк chrome создавал прям удивительное количество соединений — 500 тыс. запросов на clients1.google.com в сутки. Как следствие были пики очередей.

Подробности решения в конце статьи, где будут описаны некоторые технические моменты решение возникших проблем в процессе отладки.

Поиск пользователя в группе:

Две строки выше выполняю 1 функцию, загружают помощника для поиска пользователя в группе, можете сами выполнить в командной строке /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g internet-allow-all -D DOMAIN.LOCAL жмем enter и набираем имя пользователя, если пользователь будет найден в указанной группе, то ответ будет OK если нет то ERR. Обращаю внимание на то, что указанная группа internet-allow-all создана в AD.

Если Вы обратили внимание, то две строки отличаются, в 1 непонятный набор букв и цифр во второй все ясно… В первой строке указана группа «Пользователи домена», не желая разбираться с кириллицей в конфиге сквида и работе хелпера, я решил сделать так, это единственная группа в AD которая связана с этим сервисом имя которой написано кириллицей. Синтаксис тоже изменен, с g что означает группу на T.

Обещал рассказать почему отключил ipv6, это была длинная история, не шла авторизация у пользователя потому что я не указал в строке external_acl_type. ipv4 т.к. мы не используем ipv6 да и мало кто использует в локальных сетях решено было вообще отключить чтобы избежать подобных проблем. На сёрфинге интернета это тоже никак не отражается.

Группы для ограничения скорости:

internet-allow-speed — Группа созданная в AD.

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

Далее следуют разрешающие и блокирующие правила. Правила работают как обычно по цепочке, все что cверху имеет большее значение.

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

Схема работы следующая, клиент заходит на сайт google.com, клиент устанавливает соеденение ssl с прокси, а прокси в свою очередь с сайтом, прокси поднимает ssl с сайтом и отдельно ssl с клиентом выступая при этом посредником.

эта схема при полном бампе соединения, можно разбирать не полностью, а только для 1 из сторон, я не нашел этому применения, поэтому мы это не используем. К тому же чтобы видеть весь трафик открыто, как http, подходит только эта схема.

настройки помощника который генерирует ssl сертификаты для сайтов:

Cоздаем acl с шагами bump, существует всего 3 шага, sslbump1 смотрит на открытую информацию в сертификате, та которая доступна всем.

sslbump2 создает соединение с сайтом sslbump3 создает соединение с клиентом.

Указываем acl которые будут внесены в исключения при работе с sslbump

В bank.txt и allowsplice.txt находятся имена доменов.

Это правило разрешает принимать сертификаты с ошибкой, т.e. просроченный, самоподписанный, выданных на другой хост и т.п. Мы создавали acl для этого правила выше.

splice — пропустить все последующие действия т.е. не делать bump пропустить как есть.
peek — подсмотреть доступную инфу без полного бампа
terminate — закрыть соединение, не используем, фильтруем через http_access
bump — «влезает» в соединение, делает https видимым как http

Закрываем доступ всем.

Режем скорость, указываем сколько пулов задержки мы используем:

VIP-пользователи, избранные сайты без ограничений по скорости

В нерабочее время — Интернет отключается (до 100КБ/сек.)

Ограничение на закачку — до 10MB загружают весь канал без ограничений, свыше только 100 КБ/С

В синтаксисе лога изменена буква a на большую A, вот тут: %6tr %>A. Это дает возможность в логах видеть имя компьютера вместо его IP адреса, что конечно удобней.

Не много о проблемах и об особенностях которые возникали.

Прокси сервер выведен в отдельную dmz, файрволом жестко ограничен доступ в dmz и из нее. Т.к. сквид постоянно опрашивает dns и kerberos по udp преимущественно, то он незамедлительно превышал допустимое количество подключений с 1 ip, на сервер AD который находится в другой dmz, соединения сбрасывались. Проблема была неочевидная, хелпер авторизации падал, клиент получал окно аутентификации.

Ошибка выглядит так:

support_krb5.cc(64): pid=36139 :2017/10/24 08:53:51| kerberos_ldap_group: ERROR: Error while initializing credentials from keytab: Cannot contact any KDC for realm ‘DOMAIN.LOCAL’

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

Была еще 1 ошибка:

support_sasl.cc(276): pid=8872 :2017/10/24 06:26:31| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error
support_ldap.cc(957): pid=8872 :2017/10/24 06:26:31| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error

В bind нужно скопировать обратную зону.

UPD — Самое интересное

Возникла проблема с высокой нагрузкой на cpu и io, проц грузил в основном negotiate_kerberos io грузил ext_kerberos_ldap_group_acl, понятное дело что negotiate_kerberos запускал ext_kerberos_ldap_group_acl, нагрузка была не постоянная, два раза в день по 30 минут.

Изменение соотношения количества children и idle нужного результата не дало. В процессе отладки была ясная картина, при любой конфигурации в период пиков запускалось максимальное количество процессов аутентификации. Был проанализирован access.log, как результат анализа было выделено то, что в момент пиковой нагрузки было очень много ssl соединений, это натолкнуло на мысль что проблема кроется не в авторизации а в ssl_bump, для эксперимента был отключен ssl_bump, как результат было полное отсутствие нагрузки на протяжении всего дня. В целом в течении дня работа кальмара и его помощников не вызывала нарекании, но в определенные моменты приходило огромное количество соединений, сухие цифры: от 1 компьютера в единицу времени (5-15 мин) пришло 10000 запросов на ssl соединение которое попадает под правило bump. В другой день тоже самое с другого компьютера на .*whatsapp.net.

В конечном итоге ssl_bump включен, работает без нареканий. Если идет куча запросов на хост который недоступен по таймауту, вот тут возникают пики. На уменьшение очереди в основном повлияло исключение clients1.google.com и clients2.google.com из прокси.

Решать дать доступ к clients1.google.com и clients2.google.com, отключить задание на обновление или исключить эти хосты из прокси решать Вам.

Относительно hyper-v, в целом всё работает стабильно, uptime обычно превышает два месяца, но наступает тот день когда абсолютно на ровном месте без ошибок в логах и какой-либо нагрузки зависают виртуальные машины или выполняется их перезагрузка, но при этом последующая загрузка не приводит загрузке рабочего состояния. Приходится делать сброс и последующая загрузка производится нормально, прошу прощения за тавтологию. При всех равных на указанном сервере крутится две виртуалки ubuntu server 16.04 и у обоих происходит ода и та же проблема с разницей между ними в несколько дней, потом опять uptime не менее 2 месяцев. Для решения этой проблемы переносим сквид в докер, следующую статью оформлю про настройку сквида в докере, в целом мало чем отличается кроме целой кучи зависимостей.

Редактируем и вставляем:

Для его работы нужно установить apache2:

Рассказывать о том, как настаивать его не буду, по ссылкам довольно понятно и доступно. Обращу внимание лишь на одно, пока не будет сгенерирован первый отчет — по web адресу ничего не появится, будет ошибка.

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

И в скрипте который является шаблоном для /usr/bin/squid-analyzer:

Статья писалась с перерывами, периодически дополнялась и корректировалась, надеюсь она будет полезна.

Ниже листинг подчищенного конфига, его следует использовать как образец, не подлежит копипасту, это не даст рабочий экземпляр, нужно создавать файлы которые указаны в acl, заполнять их и т.д.

В процессе отладки очень помог awk, команда которая выводит и группирует столбцы: