Привет %username%,
Сегодня я хотел бы рассказать про достаточно тривиальную задачу сбора логов с децентрализованных Squid proxy серверов и подводные камни с которыми мы столкнулись.
Что имеем:
- Squid-hq
- Squid-br1
- Squid-br2
- Squid-br3
- Squid-br4
- Squid-db
Как видно из списка, в наличии 5 серверов squid proxy в разных удаленых офисах, и 1 база данных для сбора логов. Все OS CentOS 7.3, squid proxy от 3.3.8 до 3.5.26, Squid-db — с установленной mariadb 5.6
Из того что удалось найти это перловые скрипты и схема, собственно их и берем за основу:
- Ставим зависимости на сервера squid proxy:
yum install perl perl-Readonly* perl-URI perl-YAML perl-DBI perl-Carp perl-DBD-mysql
- После чего раскладываем по местам скрипты и конфиг для подключения к базе:
cp log_mysql_daemon.pl /usr/libexec/squid/log_mysql_daemon.pl
Даем права:
chmod +x /usr/libexec/squid/log_mysql_daemon.pl
chown squid:squid /usr/libexec/squid/log_mysql_daemon.pl
- Далее создаем конфиг файл для подключения скрипта к базе:
vi /etc/squid/log_mysql_daemon.conf
host: "<database-ip>"
database: "squid_log"
table: "access_log"
user: "squid"
pass: "<squid-passwd>"
- Создаем базу, импортируем схему и создаем юзера:
mysql -p
create database squid_log;
CREATE USER 'squid'@'%' IDENTIFIED BY '<squid-passwd>';
GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-hq-ip>';
GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-br1-ip>';
GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-br2-ip>';
GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-br3-ip>';
GRANT ALL PRIVILEGES ON squid_log.* TO 'squid'@'<Squid-br4-ip>';
exit
cat log_mysql_daemon-table.sql log_mysql_daemon-views.sql | mysql -p squid_log
-
Переходим на сторонузлаsquid proxy конфига
Добавляем конфигурацию для демона
vi /etc/squid/squid.conf
acl dontLog http_status 403 407
logformat squid_mysql %ts.%03tu %6tr %>a %Ss %03Hs %<st %rm %ru %un %Sh %<A %mt squid-hq
access_log /var/log/squid/access.log squid
access_log daemon:/etc/squid/log_mysql_daemon.conf squid_mysql !dontLog
logfile_daemon /usr/libexec/squid/log_mysql_daemon.pl
Разбираем:
acl dontLog http_status 403 407 — опциональная строка, убирает ошибки из лога идущих в базу данных связаные с эрор кодами 403, 407. База будет расти в геометрической прогресии, а для репортинга не будет нести никакой ценности
logformat squid_mysql %ts.%03tu %6tr %>a %Ss %03Hs %<st %rm %ru %un %Sh %<A %mt squid-hq — задаем формат логу, одно из важных условий для множественных squid серверов последнее значение с названием сервера с которого приходят логи. В оригинальных скриптах функционал отсутствует поэтому подкручиваем эту строку и сам скрипт следующим образом:
в /usr/libexec/squid/log_mysql_daemon.pl в настройку колонок добавляем squid-server
# fields that we should have in the database table
# this list depends on the log format configuration
my @required_fields = qw(
id
time_since_epoch
response_time
client_src_ip_addr
squid_request_status
http_status_code
reply_size
request_method
request_url
username
squid_hier_status
server_ip_addr
mime_type
squid_server
);
access_log /var/log/squid/access.log squid — Оставляем локальные логи для отладок и случаев проблем с базой, у них включен ротейшен поэтому лишним не будет
access_log daemon:/etc/squid/log_mysql_daemon.conf squid_mysql !dontLog — собственно сама строка к конфигурации демона. Обратите внимание что !dontLog отменяет логирование 403,407 только для базы данных, так что в случае отладки можно легко использовать локальные логи
logfile_daemon /usr/libexec/squid/log_mysql_daemon.pl — путь к перловому демону
- Перечитываем конфиги squid proxy
squid reconfigure
squid -k reconfigure
и получаем желаемый результат:
Доступные таблицы и вьюшки:
Заключение:
Как видно, данные теперь находятся централизованно в базе данных и легко доступны для обработки. Далее планируем написать фронтэнд для фильтрации и экспорта данных (репортинга). В целом статья написана и собрана из разных источников, к сожалению нигде не смог найти все вместе, поэтому считаю целесообразым оставить это здесь.
Было ли бы вам интересно почитать продолжения цикла статей про Squid Proxy?
Комментарии (32)
Deq56
08.08.2017 20:38А что мешало сделать несколько табличек в БД, это бы уменьшило в итоге базу и облегчило написание запросов?
к примеру вынести из access_log данные по src_ip, user, url, method и т.д. в отдельные таблички?
Просто при большом кол-во пользователей, БД будет долговато строить отчетыiRandom Автор
08.08.2017 20:51Честно говоря, оптимизацией базы пока не занимались, пользователей много, но долгих запросов пока не наблюдали, за идею спасибо, учтём :)
whitedruid
08.08.2017 22:00Большое спасибо! Сам задумывался над централизацией хранения (для трёх нод всего). Очень бы хотелось узнать про то какие-нибудь современные средства по анализу логов :) (к вопросу о том, что интересует в Squid)
Ещё, извините за полный offtop, задам вопрос ко всем присутствующим (с просьбой о помощи): у всех ли корректно basic-авторизация Squid работает в Microsoft Edge (в Windows 8/10)? Наткнулся на эти «грабли» и никак не могу победить. Chrome, Mozilla — все отлично, а MS IE, Edge — ошибка. В качестве «первого хелпера» — Kerberos-авторизация.iRandom Автор
08.08.2017 22:06Рад что оказалось полезным :)
Хм, ntlm + ldap полет нормальный, странно, а в чем именно проблема? что логи говорят? какая версия squid?
erlioniel
09.08.2017 09:37+1Не используйте базу в качестве централизированного хранилища для логов, выше уже рекомендовали ELK — это действительно стоящий внимания инструмент. В качестве альтернативы можно предложить Graylog — он мне показался более простым для старта, но менее гибким чем ELK.
tbp2k5
09.08.2017 07:59Наверное off-topic, но не поделитесь причиной использования Proxy в ваших офисах?
NB Я знаю Squid и его плюшки (почти 20 лет занимаюсь, среди прочего, одним из наших проксей). Недавно просматривал его статистику за последних несколько месяцев. Через этот сервер ~3500 пользователей тянут в среднем 2Tb в сутки. Сейчас период отпусков/каникул но выборка все равно достаточно репрезентативная. Судя по логам, количество эффективно кешируемого трафика тает на глазах (все в криптованных тоннелях). Собственно тенденция просматривается давно откуда решение убирать прокси. У вас все видимо не так. Мне интересно в чем ваша специфика…iRandom Автор
09.08.2017 08:00Фактически давно отказались от cache функционала — не имеет смысла, поэтому основном назначение распередление доступов в зависимости от AD групп
mihmig
09.08.2017 09:42Как вариант могу предположить, что скоро трафик опять подорожает. Тогда кеширование сможет помочь (но только если кешировать через MITM https трафик. Как раз для корпоративных пользователей внедрение корневого сертификата не представляет проблемы.
tbp2k5
09.08.2017 19:06Не знаю как в ваших краях а у нас линии и так не дешевые. Стоимость гигабитной линии для организаций (уточнение целевого уровня доступности: с резервированием, 2+ аплинка, и т. д.) исчисляется в десятках тысяч евро в год. 10Gb уже сотни тысяч. Но цены помаленьку падают. С другой стороны цены для SOHO раз в 100-150 ниже — вполне могут и вырасти. Тем не менее не думаю что это экономически оправдает прокси…
PS MITM: мне лично сильно не нравятся подобные решения. Все что ухудшает безопасность — плохое решение за которое, рано или поздно, приходиться платить…
mihmig
09.08.2017 09:48acl dontLog http_status 403 407 — опциональная строка, убирает ошибки из лога
Спасибо за опцию, не знал о такой взможности (соответственно и не искал в документации)
Сразу же пришла в голову «уязвимость»:
инсайдер может сливать данные на свой веб-сервер, принимающий файл и отдающий ошибку :)
Как вариант — логировать это в текстовый файл, с анализом аномалий (резкое увеличение размера файла, большой размер запроса/ответа)iRandom Автор
09.08.2017 10:06да, именно поэтому оставил параллельно логирование в локальные файлы, ибо бывает нужен дебаг, ну и не мешает периодически поглядывать в аксес логи, бывали случаи high cpu из-за chrome request > clients*.google.com
smartlight
09.08.2017 10:14+1Что будет если сервак с Mysql приляжет от того что места в /var/lib/mysql закончилось?
Где настройка хотя бы одно слейва?
Будьте готовы резать БД каждый месяцiRandom Автор
09.08.2017 10:19Для этого есть Zabbix который мониторит и базу и место в /var/lib/mysql
А в общем да, опитимизация базы нужна, сделаем — отпишу часть 2ую :)
pessom
09.08.2017 11:56И это в 21 веке?
практичнее использовать rsyslog + graylog.
Доставка логов будет за минимальное время, нагрузка на сервис минимальна и что-то искать значительно проще.iRandom Автор
09.08.2017 12:16Испрользовал эту связку для логирования серверов и нетворк оборудывания, graylog понравился — удобно, конекторы, grok и тд, но были существенные проблемы с производительностью — поэтому с jvm как-то связываться не хотелось, да и иногда велосипед интереснее :)
pessom
09.08.2017 14:00Для jvm нужно помощнее железо и побольше памяти, у себя в легкую просасываем 500 сообщений в секунду.
Никаких проблем с доезжаем логов или производительностью нет.
Doktor3lo
09.08.2017 12:05Мне казалось, хранить логи в БД — не самый лучший вариант. Почему не использовать какое-нибудь специфическое решение. Например, influxdb или graphit с последующим натягиванием какой-нибудь grafana?
На какой объем логов вы рассчитываете?
ckpunT
09.08.2017 22:10Squid, как много в этом слове для it-шника слилось. Хранение логов в реляционной БД — мощно.
Скрипт при отсутствии же связи с БД не дошлет логов и придется ручками перезаливать лог, если это вообще кто-либо будет делать. Как и сообщения rsyslog не всегда доходят до graylog, даже при наличии связи с сервером логов. Прям навеяло, ng_ipacct на freebsd 4.3 с perl-скриптом, который раз в минуту снимал статистику и складывал в mysql.
Если уж логи важны, то стоит локально хранить логи и копировать и(или) реплицировать их на squid_db. Ну или устроить трэш и отправлять логи через MQ (:
Softer
А почему MySQL? Почему не ELK?
iRandom Автор
Как-то взор пал на протоптанную дорогу MySQL, имел опыт ELK в graylog, надо подумать