Анализ журналов прокси

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

---

select id, from_unixtime(time), r_host, inet_ntoa(r_ip), r_port, sum(sc_bytes) from proxylog where time > (UNIX_TIMESTAMP() - 86400*2) and cs_username like 'ХХХ' group by r_host order by sum(sc_bytes);

---

Используя его, мы можем быть уверенными, что анализ журналов не сможет сделать никто кроме нас. Это по-своему круто и дает нам определенный авторитет.
Но давайте повернемся лицом к коллегам и используем стандартную на сегодня связку Logstash-Elasticsearch-Kibana (ELK в английском просторечии) для анализа журналов. Вероятно, есть более оптимальные решения, но они потребуют больше времени на настройку и тюнинг. Итак…


ELK мне было удобно поставить на Debian. Правильный "Debian way" описан на этой страничке.

Squid:
Журналы Squid падают в Logstash. Способы выбирайте сами, они описаны во многих местах.
Пара особенностей. По подсказке коллеги из головной конторы, в журнал был добавлен заголовок referrer, а по моей инициативе - количество отправленных байт. В результате директива logformat выглядит так:

---

%ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %un %Sh/%<A %mt %>st %{Referer}>h

---

Logstash:
Чтобы падающие сообщения были нормализованы, то есть из потока символов была извлечена информация, используем вот такую конструкцию:

---

…
else if [message] =~ "(squid)" {
mutate { replace => { "type" => "squid-access" } }
grok {
match => ["message", "<14>%{SYSLOGTIMESTAMP}\s+%{SYSLOGHOST:sourcehost}\s+\(%{WORD:syslogprog}\):\s+%{NUMBER:timestamp}\s+%{NUMBER:request_msec}\s+%{IPORHOST:client}\s+%{WORD:cache_result}/%{NUMBER:status}\s+%{NUMBER:size:int}\s+%{WORD:http_type}\s+(%{URIPROTO}://)?(?:%{USER}(?::[^@]*)?@)?(?:%{URIHOST:urihost})?(?:%{URIPATHPARAM})?\s+(%{WORD:username}|-)\s+%{WORD:request_route}/(%{IPORHOST:forwarded_to}|-)\s+%{NOTSPACE:content_type}
\s+%{NUMBER:send_size:int}\s+(%{URI:referer}|-)"]
}
}
…

---

Тут и мне, написавшему этот жуткий regexp, мало что понятно с ходу, но когда будете настраивать logstash разберетесь что к чему - выбора не будет.
ElasticSearch:
Прелесть этой "не базы данных" в том, что все в ней хранится как-то. Поля, индексы, типы - все это появится в момент, когда вы решите заняться оптимизацией или добиться каких-то расширенных возможностей. Что происходит внутри связки ELK нам не важно. На вход мы подаем поток текста, на выходе получаем "кузявые" таблички и графики.
Kibana:
Статей по настройке интерфейса Kibana великое множество. Мне показалось, что эффективнее всего ставить себе какую-то задачу и искать механизм реализации задачи в ограничениях данного нам средства.
В результате для анализа журналов прокси сервера получился такой интерфейс

Панельки пришлось сделать поменьше, чтобы они все помещались на монитор одновременно. Поэтому по всем параметрам показывает TOP5. Чаще всего этого достаточно. Больше чем на 1-2 "нарушителей" в день нет времени.
Схему можно скачать здесь.

Основные способы применения решения рассмотрим в следующий раз.