Squid парсер логов: Доработка парсера логов Squid для корректного просмотра посещенных HTTPS ресурсов
Инструкция по настройке анализатора логов Squid
Анализ логов прокси-сервера Squid достаточно трудоемок, поэтому существует отдельная группа программ для выполнения этой задачи. Одной из таких программ является LightSquid.
Предварительно нужно установить сам Squid. Установить его можно согласно нижеприведенной инструкции. Также для публикации отчетов должен быть настроен любой из веб-серверов, например Apache. Ссылка на инструкцию.
Теперь установим LightSquid. Введите для систем на базе Debian.
apt-get install lightsquid
Или для Centos:
yum install lightsquid
Сначала создадим папку для публикации lightsquid.
mkdir /var/www/lightsquid
Теперь добавим в файл конфигурации apache2 /etc/apache2/apache2.conf описание этой папки:
AddHandler cgi-script .cgi AllowOverride All
Перезапускаем Apache:
systemctl restart apache2
Теперь настраиваем сам LightSquid. Его настройки хранятся в /etc/lightsquid/lightsquid.cfg. Откроем этот файл любым редактором текстов и проверим что параметр logpath указывает на папку с логами Squid.
$logpath=/var/log/squid
Теперь перейдем в каталог /usr/share/lightsquid и запустим проверку конфигурации check-setup.pl.
cd /usr/share/lightsquid
./check-setup.pl
Если ошибок нет запускаем LightParser — скрипт разбора логов.
./lightparser.pl
Добавляем запуск парсера в расписание cron для того, чтобы анализ запускался с определенным интервалом (в примере 15 минут).
crontab -e
*/15 * * * * /usr/local/www/lightsquid/lightparser.pl
Проверить что отчеты построены можно набрав в браузере https://185.125.46.34.
Откроется папка reports внутри которой будут отчеты.
Поделиться в соцсетях:
Спасибо за Вашу оценку!
К сожалению, проголосовать не получилось. Попробуйте позже
Анализируем трафик Squid с помощью Sarg
# Заголовок
title «Squid — Анализ использования интернета»
# Кодировка отчета
charset UTF-8
# Путь к логам SQUID’а.
access_log /var/log/squid/access.log
# Путь хранения временных файлов
temporary_dir /tmp
# Путь размещения отчётов
output_dir /var/www/sarg
# Путь к исключаемым из отчета пользователей
exclude_users /etc/sarg/exclude_users
# Путь к исключаемым из отчета хостов
exclude_hosts /etc/sarg/exclude_hosts
# Путь к исключаемым HTTP-кодам
exclude_codes /etc/sarg/exclude_codes
# Путь к подключаемому CSS-файлу
external_css_file /sarg/default.css
# Перезаписываем отчёты
overwrite_report yes
# Очищаем временную папку
remove_temp_files yes
# Формат даты в отчете: e (European=dd/mm/yy), u (American=mm/dd/yy), w (Weekly=yy.ww)
date_format e
# Преображать IP адреса в DNS имена
resolve_ip yes
# Использование IP адреса вместо идентификаторов пользователей
user_ip yes
# Параметры сортировки (A — По порядку, D — В обратном порядке)
index_sort_order D
# Если нет USERID в access.log (ignore — игнор, ip — записать ip, everybody — вместо userid «everybody»)
records_without_userid ip
# Сортировка ТОП-пользователей (USER CONNECT BYTES TIME)
topuser_sort_field CONNECT reverse
# Сортировка пользовательского отчета (USER CONNECT BYTES TIME)
user_sort_field CONNECT reverse
# Кол-во сайтов в ТОП
topsites_num 50
# Параметры сортировки (CONNECT / BYTES)(A — По порядку, D — В обратном порядке)
topsites_sort_order CONNECT D
# ТОП пользователей
topuser_num 0
# Список формируемых отчетов
report_type topusers topsites sites_users users_sites date_time denied auth_failures site_user_time_date downloads
# Отображаем только название домена
long_url no
# Неограниченное количество отчетов
lastlog 0
# Создаем индексную странцу при создании отчета
index yes
# Тип генерируемого индекса
index_tree file
# Запятую вместо десятичной точки
use_comma yes
# При формировании и сортировке ориентир на полученные байты
date_time_by bytes
# Детальная статистика по завершении создания отчета
show_read_statistics yes
# Параметры выводимых в отчёте сравнительной активности пользователей
topuser_fields NUM DATE_TIME USERID CONNECT BYTES %BYTES IN-CACHE-OUT USED_TIME MILISEC %TIME TOTAL AVERAGE
# Параметры выводимых в отчёте индивидуальной активности
user_report_fields CONNECT BYTES %BYTES IN-CACHE-OUT USED_TIME MILISEC %TIME TOTAL AVERAGE
# Расширения скачиваемых файлов
download_suffix «zip,arj,bzip,gz,ace,doc,iso,adt,bin,cab,com,dot,drv$,lha,lzh,mdb,mso,ppt,rtf,src,shs,sys,exe,dll,mp3,avi,mpg,mpeg»
🧴 Мониторинг журналов доступа Squid с помощью Graylog — Information Security Squad
Добро пожаловать в наш учебник о том, как отслеживать журналы доступа Squid с помощью сервера Graylog.
Graylog — это ведущий инструмент управления журналами с открытым исходным кодом, который обеспечивает сбор, хранение, анализ и обогащение машинных данных в режиме реального времени.
Узнайте, как установить Graylog 3 на CentOS 7, перейдя по ссылке ниже.
? Установка Graylog 3.0 на CentOS 7
Мониторинг журналов доступа Squid с сервером Graylog
Итак, после настройки сервера Graylog следующим шагом будет получение журналов с различных конечных точек для анализа.
Это руководство посвящено мониторингу журналов прокси-серверов Squid Pfsense в Graylog.
Pfsense настроен для пересылки журналов доступа Squid на центральный сервер Rsyslog, работающий в Ubuntu 18.04.
Вы также можете пересылать логи доступа Squid прямо на ваш сервер Graylog
Вы можете проверить нашу ссылку ниже о том, как настроить Rsyslog в качестве центрального сервера журналов в Ubuntu 18.04.
Централизованный мониторинг сервера RSYSLOG
Создание журналов входов в Squid на Graylog
Чтобы получить данные на сервер Graylog, вам необходимо настроить входы сообщений Graylog так, чтобы они принимали данные, отправляемые с различных конечных точек.
В этом руководстве мы собираемся настроить Graylog для получения данных Squid через UDP-порт Syslog 5140.
Обязательно используйте порты> 1024, чтобы избежать проблем с разрешениями для привилегированных портов (<1024).
Поэтому войдите на ваш сервер Graylog и перейдите к System > Inputs..
На странице конфигурации входов выберите тип входа, в этом руководстве Syslog UDP и нажмите Launch new input.
Откроется мастер настройки Syslog UDP.
Выберите свой node Graylog, задайте имя входа (заголовок), установите адрес bind (оставьте значение по умолчанию 0.0.0.0) и порт для прослушивания (5140 в этом случае).
Затем оставьте другие настройки по умолчанию.
Когда вы закончите, нажмите кнопку «save» в нижней части мастера настройки, чтобы сохранить изменения.
Если все в порядке, input Syslog UDP начнет работать сразу же, как только вы сохраните его.
Настройка удаленной пересылки журналов
Поскольку в этой демонстрации журналы доступа Squid хранятся на центральном сервере журналов Ubuntu 18.04, мы продолжим настройку rsyslog для пересылки журналов на сервер Graylog.
Настроить пересылку Rsyslog
На нашем центральном сервере журналов журналы доступа Squid хранятся в /var/log/remotelogs/pfsense/squid/access.logs.
Следовательно, чтобы настроить Rsyslog для пересылки этих журналов, создайте новый файл конфигурации, как показано ниже;
vim /etc/rsyslog.d/60-squid.conf
$ModLoad imfile
$InputFileName /var/log/remotelogs/pfsense/squid/access.log
$InputFileTag squid-access
$InputFileStateFile stat-squid-access
$InputFileSeverity info
$InputFileFacility local7
$InputRunFileMonitor
local7.* @192.168.43.98:5140;RSYSLOG_SyslogProtocol23Format
Проверьте Rsyslog на наличие неправильной конфигурации;
rsyslogd -N1
Перезапустите Rsyslog
systemctl restart rsyslog
Чтобы убедиться, что журналы попадают на сервер Graylog, вы можете использовать команду tcpdump.
tcpdump -i enp0s8 src 192.168.43.142 and "udp port 5140"
Просмотр журналов доступа Squid на сервере Graylog
Чтобы убедиться, что журналы поступают на определенный вход Graylog, нажмите show received messaged
Когда вы нажимаете на show received messaged , вы перенаправляетесь на панель поиска Graylog, где вы можете просматривать свои сообщения.
Итак, Вы получили свои журналы доступа Squid на сервере Graylog, однако журналы не были правильно проанализированы просто потому, что эти журналы не соответствуют правилам, определенным в RFC системного журнала.
Поэтому вам нужно определить Extractors, чтобы инструктировать узлы Graylog о том, как извлекать данные из любого текста в полученных сообщениях журнала Squid.
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 будет подключение к Интернету, а на интерфейсе eth2 будет подключение к внутренней локальной сети:
iptables -t nat -A PREROUTING -i eth2 -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″]
- Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)
- Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
- Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
- Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
- Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
- Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
- Нажмите, чтобы поделиться в Skype (Открывается в новом окне)
IT Crowd | Graylog2: сбор логов из Squid3 и анализ данных в Grafana
В статье возможность сбора логов Squid в системе Graylog2 а так-же их анализ в Grafana.
Конфигурация выполняется в ОС Debian 9.5
Установка Graylog2 рассмотрена в материале Установка Graylog2 в Debian
Установка Squid рассмотрена в материале Настраиваем Прокси-сервер для HTTP, HTTPS, SOCKS5
Установка Grafana рассмотрена в материале Icinga2 + Influx + Grafana
Настраиваем Squid сервер для отправки логов на Graylog.
Устанавливаем rsyslog:
apt update
apt upgrade
apt install rsyslog
Редактируем файл конфигурации:
нано /etc/rsyslog.conf
Указываем папку с дополнительными конфигурациями — раскоментируем строку:
$ IncludeConfig /etc/rsyslog.d/*.conf
Создайте дополнительную логику для отсылки файла Squid на сервере Graylog:
нано / etc / rsyslog.d / 60-squid.conf
Добавляем в файл с указанием IP-адреса Graylog сервера, а так же проверяем путь до log-файла, если он не стандартный:
nano /etc/rsyslog.d/60-squid.conf
# Загрузить модули
module (load = "imfile")
#
# Модули ввода rsyslog
input (type = "imfile"
File = "/ var /log/squid/access.log "
StateFile =" / var / spool / rsyslog / squidstatefile "
Tag =" squid-access "
Severity =" info "
Facility =" local7 "
ruleset =" SquidForward ")
#
# rsyslog RuleSets
набор правил (name = "SquidForward") {
action (type = "omfwd"
Target = "IP-адрес сервера Graylog"
Port = "19302"
Protocol = "tcp"
template = "RSYSLOG_SyslogProtocol23Format ")
}
Перезапускаем rsyslog:
перезапуск службы rsyslog
Подготовка Graylog к приему логов с Squid.
Для этого необходимо установить дополнение из магазина Graylog доступный для загрузки тут.
Далее установим загруженное дополнение — в меню выбираем Systems - Content packs
, выбрать Import content pack
где и загрузить файл JSON
. После чего там же, в Пакеты содержимого
, появится новый пункт Бревна кальмаров
, который необходимо выбрать и нажать Применить содержимое
.
Далее в меню выбрать Системы - Входы
, убедитесь, что соединение работает и нажимает Показать полученные сообщения
, где будут входящие сообщения.Для удобства ввода сообщений в верхней части есть кнопка включения автообновления.
Настройка Elasticsearch.
В конце конфигурационного файла укажем новое значение для количества условий запроса, так как стандартное, в 1000 условий, может быть недостаточно:
нано /etc/elasticsearch/elasticsearch.yml
index.query.bool.max_clause_count: 10240
Перезапускаем Elasticsearch
перезапуск службы elasticsearch
Что делать, если Grafana и Graylog находятся на разных серверах.
1. Изменить настройки для доступа с других устройств.
нано /etc/elasticsearch/elasticsearch.yml
В разделе Сеть
указать:
network.host: IP-Адрес сервеа Elasticsearch \ Graylog
http.port: 9200
2. Для успешной работы Graylog необходимо ввести в конфигурацию выше и порт доступа к Elasticsearch:
нано / etc / graylog / server / server.конф
elasticsearch_hosts = http: // IP-адрес: 9200
Перезапускаем Graylog и Elasticsearch:
перезапуск службы elasticsearch
перезапуск службы graylog-server
Настройка Grafana.
Настройка доступа к Elasticsearch:
Для этого открываем веб-интерфейс Grafana, выбираем Конфигурация - Источники данных
и нажимаем Добавляем источник данных
.
Вводим имя соединения в поле Имя
;
В поле Тип
выбираем Elasticsearch
;
В поле URL
вводим адрес сервера Elasticsearch
;
В поле Имя поля времени
вводим: отметка времени
;
В поле Версия
выбираем 5.х
;
Нажимаем Сохранить и проверить
. Если все верно то ошибок быть не должно.
Создаем приборную панель в Grafana.
Готовый Dashboard доступен на сайте Grafana.
Перед его добавлением установим необходимые дополнения для Grafana:
Плагины
grafana-cli установить briangann-datatable-panel
плагины grafana-cli установить grafana-piechart-panel
плагины grafana-cli установить grafana-worldmap-panel
Перезапустим сервер Grafana:
сервис графана-сервер перезапуск
Добавить json
файл панели в Grafana
Выбираем Приборные панели
- Управление, нажимаем
и импортируем загруженный файл, № Импорт
- Выгрузка.json File
В поле Имя
указываем желаемое имя панели;
В поле Squid-Graylog (выберите источник данных Elasticsearch)
указываем созданное выше соединение с базой Elasticsearch.
И нажимаем кнопку Импорт
.
Если у вас имеется доступ через Интернет, прокси Squid то данные наполнятся быстро и панель показывать статистику:
.
Squid логи [Enchanted Technology]
Формат лога
Разберемся с форматом ‘по умолчанию’
#logformat squid% ts.% 03tu% 6tr%> a% Ss /% 03Hs%Знак % означат что далее следует литерал а не терминальный символ
% ts.% 03tu : точка - это терминальный символ разделяющий значения, а число 03 аргумент (т.е. до точности 3х знаков) для tu
ts : секунд с начала эпохи - Количество секунд от 00:00 1970.01.01
tu : субсекундное время (миллисекунды) - доли секунды
% 6tr : Time Response - время отклика, миллисекунд
%> a : адрес источника запроса
% Ss /% 03Hs :
Ss : статус запроса Squid
Статус запроса в squid
Код Описание TCP_HIT Объект в кеше TCP_MISS Объекта нет в кеше TCP_DENIED Доступ запрещен для этого запроса TCP_REFRESH_HIT Запрошенный объект был в кеше, но устарел.IMS-запрос для этого объекта вернул "304 не изменен", т.е. обновления не потребовалось TCP_REF_FAIL_HIT Запрошенный объект был в кеше, но устарел. IMS-запрос завершен неудачно и будет загружен устаревший объект из кеша TCP_REFRESH_MISS Запрошенный объект был в кеше, но устарел. IMS-запрос загрузил в кеш обновленный объект TCP_CLIENT_REFRESH_MISS Клиент выдал прагму «no-cache» или некоторую аналогичную команду управления кешем вместе с запросом.Таким образом, кеш должен повторно загрузить объект .
TCP_IMS_HIT Клиент использовал IMS-запрос для объекта, который был найден в кеше TCP_SWAPFAIL_MISS Объект в кеше, но доступа к нему нет TCP_NEGATIVE_HIT Запрос для негативно кешированных объектов типа «404 не найден», для которого кэш считает, что знает, что он недоступен.Также обратитесь к объяснениям для negative_ttl в вашем файле squid.conf TCP_MEM_HIT Объект был взят из оперативной памяти TCP_OFFLINE_HIT Запрошенный объект был получен из кеша в автономном режиме. В автономном режиме ни один объект не проверяется, см. offline_mode в файле squid.conf UDP_HIT
UDP_MISS
UDP_DENIEDпо аналогии с TCP UDP_INVALID Неверный запрос UDP_MISS_NOFETCH Во время запуска «-Y» или во время частых сбоев кэш в режиме только попаданий будет возвращать либо UDP_HIT, либо этот код.Таким образом, соседи будут получать только обращения НЕТ Обнаружены ошибки и запросы cachemgr Hs : Код статуса HTTP - Статус коды HTTP протокола
%
: передано байт (В ответ, включая HTTP-заголовок) % rm : Метод запроса - метод запроса (POST, GET…)
% un : Имя пользователя
% Ш /% :
Sh : Статус иерархии кальмаров
Коды иерархий в Squid
Код Описание DIRECT Объект был получен напрямую от сервера FIREWALL_IP_DIRECT Squid пересылает запрос непосредственно на исходный сервер, поскольку IP-адрес исходного сервера находится внутри вашего брандмауэра FIRST_PARENT_MISS Squid перенаправляет запрос в родительский кеш с самым быстрым взвешенным временем приема-передачи FIRST_UP_PARENT Squid перенаправляет запрос первому доступному родительскому элементу в вашем списке LOCAL_IP_DIRECT Squid перенаправляет запрос непосредственно на исходный сервер, поскольку IP-адрес исходного сервера соответствует вашему списку local_ip SIBLING_HIT Squid перенаправляет запрос в кэш-память, которая отправила нам ответ UDP_HIT NO_DIRECT_FAIL Squid не может переслать запрос из-за ограничений брандмауэра, а родительские кеши недоступны PARENT_HIT Squid перенаправляет запрос в родительский кеш, который отправил нам ответ UDP_HIT SINGLE_PARENT Запрос перенаправляется в единственный родительский кэш, подходящий для этого запроса.Также требует включения single_parent_bypass SOURCE_FASTEST Squid перенаправляет запрос на исходный сервер, потому что его ответ source_ping пришел первым PARENT_UDP_HIT_OBJ Squid получил объект в ответе UDP_HIT_OBJ из родительского кеша SIBLING_UDP_HIT_OBJ Squid получил объект в ответе UDP_HIT_OBJ из кэша-брата DEFAULT_PARENT Squid перенаправил запрос родительскому объекту по умолчанию, не отправляя сначала никаких запросов ICP ROUNDROBIN_PARENT Squid перенаправил запрос родительскому циклу с наименьшим количеством использований, не отправляя сначала запросы ICP CLOSEST_PARENT_MISS Squid перенаправил запрос родительскому серверу, ответ ICP_MISS которого имеет наименьшее измеренное RTT, на исходный сервер.Это появляется только при включенном query_icmp в файле конфигурации CLOSEST_DIRECT Squid перенаправил запрос непосредственно на исходный сервер, потому что Squid измеряет более низкий RTT для источника, чем любой из его родительских кешей НЕТ Squid вообще не пересылает запрос NO_PARENT_DIRECT Объект был получен напрямую с сервера, т.к. нет парента для данного URL CLOSEST_PARENT Выбор парента основан на нашем собственном измерении RTT CACHE_DIGEST_HIT Сосед был выбран, потому-что дайджест кеша сообщил о хите. Эта опция была заменена, чтобы различать родительских ов и sibling-ов CD_PARENT_HIT Парент был выбран, потому-что кеш-дайджест предсказал хит CD_SIBLING_HIT Сиблинг был выбран, потому-что кеш-дайджест предсказал хит NO_CACHE_DIGEST_DIRECT CARP Сосед был выбран по CARP ANY_PARENT часть src / peer_select.c: hier_strings [] НЕВЕРНЫЙ КОД часть src / peer_select.c: hier_strings [] Почти каждому из них может предшествовать 'TIMEOUT_', если 2-х секундное (по умолчанию) ожидание ICP-ответов от всех соседей оканчивается таймаутом. См. также конфигурационную опцию icp_query_timeout
: IP адрес запрашиваемого сервера
Создание собственного формата
Первое что хотелось бы сделать - это привычный формат времени
% tl - Местное время, по умолчанию получим запись вот такого вида% d /% b /% Y:% H:% M:% S% z07 августа 2009 г .: 16: 06: 04 +0400% tg - время по Гринвичу, покажет мировое время
07 августа 2009 г .: 12: 06: 04 +0000Модифицируем в % {% Y.% m.% d /% H:% M:% S} tl и получим
2009.08.07 / 16:26: 55Разделение логов
При необходимости можно легко разделять логи для разных acl
access_log <файл> [<имя формата журнала> [acl acl ...]]Пример разделения логов с локального хоста и из локальной сети
access_log /var/log/squid/access.log mylogformat localhost access_log /var/log/squid/access_parsing.log mylogformat localnetЧтобы логировать полый адрес URL
strip_query_terms off.
Разбор лога squid через LightSquid
Итак нам необходимо разобрать бревно кальмаров .
Будем делать это через LightSquidСтавим на Apache .
==========================sudo cp / etc / apache2 / sites-available / default / etc / apache2 / sites-available / monitorСудо нано / и т.д. / apache2 / сайты-доступные / мониторServerAdmin веб-мастер @ localhost Монитор ServerName ServerAlias www.монитор DocumentRoot / var / www / monitor <Каталог /> Параметры FollowSymLinks AllowOverride Нет <Каталог / var / www / monitor /> Параметры Индексы FollowSymLinks MultiViews AllowOverride Нет Заказать разрешить, запретить разрешить от всех <Каталог "/ var / www / monitor /"> AddHandler cgi-скрипт.cgi AllowOverride All ScriptAlias / cgi-bin / / usr / lib / cgi-bin / <Каталог "/ usr / lib / cgi-bin"> AllowOverride Нет Параметры + ExecCGI -MultiViews + SymLinksIfOwnerMatch Заказать разрешить, запретить Разрешить от всех ErrorLog $ {APACHE_LOG_DIR} /error.log # Возможные значения: отладка, информация, уведомление, предупреждение, ошибка, крит, # alert, emerg.LogLevel предупреждать CustomLog $ {APACHE_LOG_DIR} /access.log вместе Псевдоним / doc / "/ usr / share / doc /" <Каталог "/ usr / share / doc /"> Параметры Индексы MultiViews FollowSymLinks AllowOverride Нет Заказать отказать, разрешить Запретить всем Разрешить от 127.0.0.0/255.0.0.0 :: 1/128 sudo a2ensite мониторсудо нано / и т.д. / хосты127.0.1.3 монитор www.monitorСоздаем папку
sudo mkdir / var / www / monitorПрименяем конфигурацию Apache
sudo service apache2 перезагрузитьКачаем сам LightSquid http://lightsquid.sourceforge.net/
Распаковываем и перемещаем в папку с сайтом
tar xfv lightsquid-1.8.tgz sudo mv lightsquid-1.8 / * / вар / www / монитор /Даем права пользователю www-data
sudo chown -Rv www-data / var / www / monitor /Делаем исполняемыми скриптами LightSquid
sudo chmod + x / var / www / monitor / *.cgi sudo chmod + x /var/www/monitor/*.plПравим конфигурацию LightSquid
sudo nano /var/www/monitor/lightsquid.cfg# путь к дополнительным файлам `cfg` $ cfgpath = "/ var / www / monitor"; # путь к папке `tpl` $ tplpath = "/ var / www / monitor / tpl"; # путь к папке `lang` $ langpath = "/ var / www / monitor / lang"; # путь к папке `report` $ reportpath = "/ var / www / monitor / report"; # путь к доступу.журнал $ logpath = "/ var / log / squid"; # путь к папке ʻip2name` $ ip2namepath = "/ var / www / monitor / ip2name"; #language # см. папку `lang` (доступно: bg, eng, fr, hu, it, pt_br, ru, sp) $ lang = "ru";Проверяем конфигурацию LightSquid
sudo /var/www/monitor/check-setup.plLightSquid Config Checker, (c) 2005-9 Сергей Ерохин GNU GPL Путь к логу: / var / log / squid путь к отчету: / var / www / monitor / report Язык: / var / www / monitor / lang / ru Шаблон: / var / www / monitor / tpl / base Ip2Name: / var / www / monitor / ip2name / ip2name.просто нет: GD.PM обнаружен, установите или установите $ graphreport = 0, чтобы отключитьНет поддержки графиков. Будем ставить
sudo perl -MCPAN -e оболочка cpan [1]> установить GD cpan [2]> выйтиЕсли вылетает с ошибкой.
** НЕПРАВИЛЬНАЯ ОШИБКА ** Не удалось найти gdlib-config в пути поиска. Пожалуйста, установите libgd 2.0.28 или выше. Если вы все равно хотите попытаться скомпилировать, перезапустите этот скрипт с параметром --ignore_missing_gd.Предупреждение: не удалось выполнить команду [/ usr / bin / perl Makefile.PL INSTALLDIRS = site] 'YAML' не установлен, постоянное состояние не сохраняется LDS / GD-2.49.tar.gz / usr / bin / perl Makefile.PL INSTALLDIRS = site - НЕ ОК Запуск make test У Make были проблемы, не буду тестировать Запускаем make install У Make были проблемы, не устанавливается Ошибка при выполнении этой команды: LDS / GD-2.49.tar.gz: writemakefile NO '/ usr / bin / perl Makefile.PL INSTALLDIRS = site' вернул статус 512Фиксим
sudo apt-get -y установить libgd2-xpm-dev build-essentialновой Пытаемся ставить по.В результате пишет.
Добавление информации об установке в /usr/local/lib/perl/5.12.4/perllocal.pod LDS / GD-2.49.tar.gz / usr / bin / make install - ОК cpan [2]> выйтиЕще раз проверяем нашу конфигурацию
sudo /var/www/monitor/check-setup.plLightSquid Config Checker, (c) 2005-9 Сергей Ерохин GNU GPL Путь к логу: / var / log / squid путь к отчету: / var / www / monitor / report Язык: / var / www / monitor / lang / ru Шаблон: / var / www / monitor / tpl / base Ip2Name: / var / www / monitor / ip2name / ip2name.просто все проверки пройдены, теперь попробуйте получить доступ к cgi-части в браузереПроверям работу сайта http: //www.monitor/
Запускаем парсер логов
sudo /var/www/monitor/lightparser.plСмотрим что получилось в браузере http: //www.monitor/
Прописываем автоматический разбор логов SQID каждый день в 23.00
sudo EDITOR = nano crontab -e00 23 * * * / var / www / monitor / lightparser.pl # Парсим логи сквидаНу и далее можно редактировать на свой вкус и запросы.
Мой мир
Вконтакте
Одноклассники
.
🦑 Тестирование конфигурационного файла Squid на наличие синтаксических ошибок - Information Security Squad
Я установил прокси-сервер Squid на Ubuntu.
Как мне убедиться, что в моем файле squid.conf нет синтаксических ошибок, и проверить этот файл конфигурации на наличие ошибок?
Где бы вы ни ставили или обновляли прокси-сервер Squid, вы должны убедиться, что ваш файл squid.conf не содержит ошибок.
Это простая задача.
Чтобы проверить файл кальмара.conf на наличие синтаксических ошибок и предупреждений, введите следующие команды.
Проверка файла конфигурации прокси-сервера Squid на наличие ошибок
Откройте окно терминала и введите следующую команду для удаленного входа на сервер Linux и Unix с помощью команды ssh:
$ ssh mitya @ itsecforu
Теперь выполните следующую команду от имени пользователя root:
# squid -k parse
## или используя полный путь ##
$ sudo / usr / sbin / squid3 -k parse
## Отфильтруем с grep / egrep ##
# squid -k parse | grep 'error'
# squid -k parse | egrep 'foo | бар'Пример сеанса:
2020.08.08 08: 16: 42 | Запуск: инициализация схем аутентификации... 2020.08.08 08: 16: 42 | Запуск: инициализированная схема аутентификации 'базовая' 2020.08.08 08: 16: 42 | Запуск: инициализированная схема аутентификации 'дайджест' 2020.08.08 08: 16: 42 | Запуск: инициализированная схема аутентификации 'согласовать' 2020.08.08 08: 16: 42 | Запуск: инициализированная схема аутентификации 'ntlm' 2020.08.08 08: 16: 42 | Запуск: инициализированная аутентификация. 2020.08.08 08: 16: 42 | Файл конфигурации обработки: /etc/squid/squid.conf (глубина 0) 2020.08.08 08: 16: 42 | Обработка: acl mylan src 10.8.0.0 / 24 2020.08.08 08: 16: 42 | Обработка: acl mylan src 172.16.0.0/24 2020.08.08 08: 16: 42 | Обработка: acl SSL_ports порт 443 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports порт 80 # http 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports port 21 # ftp 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports порт 443 # https 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports port 70 # gopher 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports port 210 # wais 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports port 1025-65535 # незарегистрированные порты 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports port 280 # http-mgmt 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports порт 488 # gss-http 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports port 591 # filemaker 2020.08.08 08: 16: 42 | Обработка: acl Safe_ports port 777 # многоязычный http 2020.08.08 08: 16: 42 | Обработка: acl CONNECT метод CONNECT 2020.08.08 08: 16: 42 | Обработка: http_access deny! Safe_ports 2020.08.08 08: 16: 42 | Обработка: http_access deny CONNECT! SSL_ports 2020.08.08 08: 16: 42 | Обработка: http_access разрешить localhost manager 2020.08.08 08: 16: 42 | Обработка: http_access deny manager 2020.08.08 08: 16: 42 | Обработка: http_access разрешить localhost 2020.08.08 08: 16: 42 | Обработка: http_access allow mylan 2020.08.08 08: 16: 42 | Обработка: http_access deny all 2020.08.08 08: 16: 42 | Обработка: http_port 10.суслик: 1440 0% 1440 2020.08.08 08: 16: 42 | Обработка: шаблон_обновления -i (/ cgi-bin / | \?) 0 0% 0 2020.08.08 08: 16: 42 | Обработка: refresh_pattern (Release | Packages (.gz) *) $ 0 20% 2880 2020.08.08 08: 16: 42 | Обработка: refresh_pattern. 0 20% 4320 2020.08.08 08: 16: 42 | Обработка: forwarded_for удаление 2020.08.08 08: 16: 42 | Обработка: через выкл. 2020.08.08 08: 16: 42 | Обработка: forwarded_for off 2020.08.08 08: 16: 42 | Обработка: follow_x_forwarded_for отклонить все 2020.08.08 08: 16: 42 | Обработка: request_header_access X-Forwarded-For deny all 2020.08.08 08: 16: 42 | Обработка: forwarded_for удаление 2020.08.08 08: 16: 42 | Обработка: dns_nameservers 10.8.0.1 2020.08.08 08: 16: 42 | ВНИМАНИЕ! HTTP требует использования Via 2020.08.08 08: 16: 42 | Инициализация https: // контекста проксиПример сообщения об ошибке при проверке файла конфигурации Squid на наличие синтаксических ошибок
# squid -k parse
Вывод:
2020.08.08 08: 21: 07 | Обработка: viaproxy off 2020/08/08 08: 21: 07 | /etc/squid/squid.conf:40 нераспознанный: 'viaproxy'Отредактируйте файл конфигурации и исправьте эту ошибку:
# vim +40 / etc / squid / squid.конф
Найдите эту ошибку:
viaproxy off
Замените на:
через офф
Сохраните и закройте файл.
Теперь проверьте еще раз:
# squid -k parse
Теперь мы можем перезагрузить наш прокси-сервер squid без перезапуска демона squid следующим образом:
# squid -k перенастроить
Как проверить синтаксис файла конфигурации squid
Всегда полезно запускать команды «squid -k parse» и «squid -k debug» для проверки синтаксической конфигурации любого раз, когда вы меняете конфигурацию прокси-сервера.
Обратите внимание, что Squid отказывает запускаться, если обнаружил ошибку.
Если ошибка существует, Squid не будет работать до тех пор, пока системный администратор не исправит синтаксические ошибки.
Другие полезные параметры прокси Squid
Синтаксис:
# squid -k команда
или
$ sudo squid -k команда
Где команда может быть любая команда из следующих:
- перенастроить: Посылает Squid сигнал HUP для повторного чтения его файлов конфигурации.
- rotate: ротировать файлы журнала.
- shutdown: отправляет Squid сигнал TERM, чтобы ненадолго дождаться завершения текущих соединений, а затем завершить работу сервера. Время ожидания включается в файл shutdown_lifetime в файле squid.conf.
- restart: перезапустить сервер
- прерывание: отправляет сигнал INT серверу Squid. Он немедленно отключается, не дожидаясь текущих подключений.
- kill: убить прокси-сервер, отправив сигнал KILL.
- debug: запустить squid в режиме полной отладки.
- проверка: отправляет сигнал «ZERO» серверу Squid. Команда просто проверяет, действительно ли сервер / процесс запущен на вашем Linux / Unix / BSD.
- parse: анализирует файл squid.conf на наличие синтаксических ошибок.
Заключение
Вы узнали, как проанализировать конфигурацию прокси-сервера Squid, затем отправить сигнал в последнюю копию и выходить из командной строки.
Это полезно для проверки синтаксических ошибок в squid.conf и других файлах.
.