Логи — это черный ящик информационной системы. Когда что-то идет не так, все надежды на него: что там записалось, как все было на самом деле. В теории звучит красиво. А на практике…
Недавно был случай – назовем клиента «Pypkin Corp», крупное производство, куча компов, серверов. Расследование рядового, на первый взгляд, инцидента превратилось в марафон с препятствиями, где главным врагом был не хакер, а собственная система записи событий. История поучительная, поэтому делюсь (изменив детали, конечно).
«У нас тут что-то странное!»
Стандартная ситуация: система обнаружения вторжений (IDS) заорала – засекла подозрительный трафик с контроллера домена (для малышей-пентестеров и меня из прошлого: сердце сети, где все учетки, пароли, доступы). Если его ломают, то все. Трафик шел на известный IP-адрес командного центра ботнета. Ясно, надо срочно действовать.
Команда наготове, план стандартный: изолировать сервер, слить оперативную память, сделать копию диска и – самое главное – нырнуть в логи. Системные журналы Windows, логи Active Directory, сетевого оборудования, прокси… Все, что могло рассказать нам историю атаки: как зашли, куда пошли дальше. Мы ждали ответов.
А получили ни-... ни-че-го.
Когда логи – враг
Первое, что бросилось в глаза – логи были куцые. Катастрофически. На критически важных серверах, включая тот самый контроллер домена, журналы были настроены так, что перезаписывались каждые несколько часов. То есть, мы видели, что после срабатывания IDS что-то происходило, а вот до – как хакер вообще попал внутрь, пытался ли подобрать пароли, использовал ли уязвимость – стерто.
Дальше – больше. Время на серверах «плясало». Никакой синхронизации времени (NTP). На одном сервере одно, на другом – другое, разница в минуты, а где-то и часы. Пытаешься выстроить цепочку событий: вот тут пользователь залогинился, а потом вот этот процесс запустился… А фиг там! По логам получается, что событие Б произошло раньше события А, хотя по логике должно быть наоборот. Пытаешься понять, что было раньше, курица или яйцо, а в ответ – тишина.
Третий гвоздь в крышку гроба – недостаток деталей. Многие системы писали логи по принципу «чтобы было». Запись «Пользователь вошел в систему» – есть. А откуда вошел (IP-адрес)? Какой программой воспользовался? Тишина. Прокси-сервер писал, что кто-то ходил в интернет. А какой файл скачал? С какого конкретно сайта? Заголовки запроса? Снова мимо. Формальность соблюдена, а практической пользы – ноль.
Контрольный в голову – мы поняли, что этим логам доверять на 100% нельзя. На некоторых важных машинах права на управление журналами были настроены криво. То есть, если хакер получил админа (а с контроллером домена это очень вероятно), он мог спокойно подчистить за собой или даже нарисовать что-то свое. Прямых улик подделки мы не нашли, но сам факт, что это возможно, убивал веру в те крохи информации, что у нас были. Централизованной системы сбора логов (SIEM), которая бы копировала все журналы в защищенное место в реальном времени, у «Pypkin Corp» не было. А зря.
На грани фола
Шли дни. Руководство «Pypkin Corp» нервничало – производство частично стоит, убытки капают. А мы все копаемся. Понимаем, что взлом был, но как? Что украли? Куда еще залезли? Четких ответов нет.
Стандартные методы, которые сильно завязаны на логи, просто не работали. Команда вымоталась. Дико обидно – понимать, что ты можешь не справиться не потому, что хакер гений, а потому что у жертвы элементарно бардак с записями.
План Б
Стало ясно: на эти логи полагаться – себе дороже. И что мы делаем?
Копаем глубже в системы. Вместо того чтобы просто читать логи, мы начали потрошить полные копии дисков и дампы памяти с подозрительных машин. И вот там уже начали всплывать интересные вещи: остатки вредоносных программ, следы утилит, которыми хакеры перемещались по сети (типа PsExec), временные файлы, записи в реестре – все то, чего в стандартных логах и близко не было. Анализ памяти помог увидеть, что творилось в системе в момент «фотографирования».
Смотрим на сеть. К счастью, на границе сети у «Pypkin Corp» стояла система записи сетевого трафика (PCAP). Хоть и не весь трафик писался, но кое-что нашлось. Подтвердили связь с командным центром, нашли еще пару подозрительных соединений наружу – возможно, докачивали инструменты или вытаскивали данные.
Сверяемся с «внешним миром». Начали активно пробивать найденные IP-адреса, хэши файлов по базам данных угроз (Threat Intelligence). Это дало подсказки: что за вирус, на что способен, кто примерно за этим стоит.
Говорим с людьми. Как ни странно, иногда помогает. Поговорили с админами, с пользователями. Конечно, люди многое забывают или не замечают. Но иногда случайная фраза типа: «Ой, да вроде на прошлой неделе антивирус ругался, но потом затих» или «Приходило какое‑то письмо странное, я удалил» — может натолкнуть на след.
Анализируем настройки. Проверили конфигурации систем, групповые политики, права доступа. Это помогло понять, где были слабые места, как хакер мог повысить себе права и гулять по сети, даже не оставляя явных записей в журналах.
Прозрение
Собрав все эти кусочки — данные с дисков, обрывки сетевого трафика, информацию из баз угроз, слова людей — мы наконец‑то смогли восстановить картину. Началось все банально: фишинговое письмо, сотрудник кликнул. Дальше хакеры использовали дыру в каком‑то приложении на сервере (которое, конечно же, почти ничего не логировало), получили права повыше и уже оттуда добрались до контроллера домена. Связь с командным центром была лишь верхушкой айсберга. Главная цель была украсть чертежи и производственные секреты (?).
В итоге мы, конечно, справились: угрозу вычистили, дыры залатали, рекомендации выдали. Но какой ценой! Времени и сил ушло втрое больше, чем могло бы. Нервов — немерено.
Для «Pypkin Corp» это был дорогой урок. Целостность данных (Data Integrity), когда мы говорим о логах, — это не галочка в отчете какая‑то, а вопрос выживания.
Так что делать-то? Кратко и по делу:
Решите, ЧТО писать: Мало просто включить логи. Поймите, какие события реально важны для поиска проблем: входы-выходы, смена паролей, ошибки входа, установка софта, кто куда по сети полез с важных серверов, кто поменял настройки, кто полез в папку с секретными документами. Список должен быть осмысленным.
Пишите ПОДРОБНО: Чтобы в логе было все нужное: точное время (до секунды!), IP-адреса (кто и куда), имена пользователей, названия программ, результат операции (успех/неуспех).
Собирайте в ОДНО место и ЗАЩИЩАЙТЕ: Ставьте SIEM или что-то похожее. Это и анализировать проще, и хакеру сложнее будет замести следы на исходной машине. Храните логи достаточно долго (сколько требует закон или здравый смысл).
Время – ДЕНЬГИ (и улики!): Настройте синхронизацию времени (NTP) ВЕЗДЕ. Без этого половина логов – бесполезный мусор.
Проверяйте РЕГУЛЯРНО: Настроить один раз и забыть – плохая идея. Периодически смотрите: а логи вообще пишутся? А то, что нужно? А они не битые? А доступ к ним защищен?
Не доводите до такого. Проверьте свои логи сегодня, чтобы завтра не пришлось кусать локти (потому что хакеры украли деньги и теперь вам нечем оплатить доставку из «Вкусно и точка»).
