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% z

 07 августа 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.pl
 
LightSquid 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.pl
 
LightSquid 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 -e
 
00 23 * * * / var / www / monitor / lightparser.pl # Парсим логи сквида
 

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

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

.

🦑 Тестирование конфигурационного файла 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 и других файлах.

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Theme: Overlay by Kaira Extra Text
Cape Town, South Africa