История про логи

#security #russian

Я рассказал эту историю на Kaspersky Security Day, но, думаю, её стоит повторить и в этом блоге.

Однажды, больше 10 лет назад, я консультировал крупную (реально, очень крупную, Fortune 100) компанию по поводу их инсталляции файрвола и обработки логов. В их HQ был десяток–полтора задублированных enforcement points, каждая из которых защищала один гигабитный канал (гигабитные интерфейсы в ту пору не встречались в каждом втором десктопе, найти из можно было только в ядре сети). Эти enforcement points отправляли логи в несколько систем управления. Из систем управления их экспортировали раз в неделю и аналитик отсматривал их.

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

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

Выглядело это примерно так:

Src_IP;Dst_IP;Src_Port;Dst_Port;Action
1.2.3.4;5.6.7.8;32101;80;drop
1.9.10.11;5.6.7.8;32102;80;drop
1.9.10.12;5.6.13.15;35467;22;drop
Dst_IP;Src_IP;Dst_Port;Src_Port;Action
5.6.7.9;1.2.3.4;80;34223;drop
5.6.6.6;1.2.3.4;80;65334;drop

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

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

Скрипт я написал, но потом мне показалось, что раз уж я всё равно занялся парсингом логов, можно и поискать Top 20 IP адресов, попытки подключения с них, подозрительные промежутки времени и тому подобное. Когда я это написал, оказалось, что результаты работы моего скрипта не похожи на результаты, получаемые аналитиком вручную. И не то, что расхождение в трех–пяти позициях, что можно было бы объяснить человеческой ошибкой — нет, расхождение было почти всегда стопроцентным.

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

Оказалось, что для решения задачи нужно было ответить на два вопроса. Первый — если у вас есть 15 точек, каждая из которых контроллирует 1Gbps канал связи (от сети на несколько десятков тысяч хостов до Интернета, например), то сколько пакетов в секунду вы будете блокировать и логировать? Второй — какое максимальное число строк в таблице позволял иметь Microsoft Excel версий до 2007?

Ответ на первый вопрос был “несколько сотен в сумме, несколько десятков на enforcement point”, на второй — 65000. Иначе говоря, в Excel для анализа попадали записи лога за первые несколько минут ночи понедельника. На этих данных строились отчёты. Каждую неделю. 52 раза в год. Эти отчеты проверялись аудиторами. Несколько лет подряд. Никто не замечал ничего необычного.

Почитайте в Википедии, что такое security theater.