«Корпоративные лаборатории» — программа профессиональной подготовки в области информационной безопасности, состоящая из теоретической (курсы-вебинары) и практической подготовки (работа в пентест-лабораториях). В данной статье будет рассмотрено содержание именно практической базы, составляющей порядка 80% от общей программы обучения.
Идеальную непробиваемую защиту построить практически невозможно, поэтому необходимо быть готовым к тому, что в теории компрометация может произойти. При этом, при правильно построенной схеме и отработанных процессах реагирования, часто удается свести ущерб к минимуму.
Для обеспечения надлежащего уровня безопасности инфраструктуры необходим постоянный контроль над ее составляющими. Для этих целей необходимо проводить аудит безопасности систем, изучать логи и журналы событий, получать данные с иных источников мониторинга.
Такая информация позволяет улучшить защиту и модернизировать процессы реагирования, используя данные о произошедшем инциденте. Аудит безопасности систем позволяет:
- Выяснить, кто совершил конкретное действие в системе, установить возможное причастное лицо;
- Установить дату совершения действия;
- Определить затронутые в процессе компрометации ресурсы;
- Выяснить, имеется ли вина конкретного человека, либо это системная (программная) ошибка;
- Выработать меры по восстановлению и предотвращению инцидента в последующем;
- Оценить риски.
Журналирование событий
В первую очередь стоит использовать штатные средства системы, в случае Windows-систем это т.н. журнал безопасности. Журнал безопасности содержит такие события, как успешные и неуспешные попытки входа в систему, а также события, относящиеся к использованию ресурсов, такие как создание, открытие и удаление файлов и других объектов. Администраторы могут выбрать события, которые следует заносить в журнал безопасности. Например, если включен аудит входа в систему, сведения о всех попытках входа в систему заносятся в журнал безопасности.
Основные параметры записей:
- Аудит входов в систему;
- Аудит изменений важных объектов системы: файлы, папки;
- Аудит использования прав Администратора на машине.
Настраивается эти значения в локальных групповых политиках, в конфигурации расширенной политики аудита. Необходимо заметить немаловажный факт, что по умолчанию эти политики выключены. Это сделано из-за некоторых факторов:
- Происходит огромное количество событий (сложных для обработки и анализа);
- Сложного отделения действий пользователей от действий системы и программ.
- Размер журнала по умолчанию недостаточен (20 Мб).
В *nix системах существует утилита auditd.
Начиная с версии 2.6, ядро Linux включает в себя подсистему, специально разработанную для проведения аудита, позволяющую отслеживать такие системные события, как:
- Запуск и завершение работы системы (перезагрузка, остановка);
- Чтение/запись или изменение прав доступа к файлам;
- Инициация сетевого соединения или изменение сетевых настроек;
- Изменение информации о пользователе или группе;
- Изменение даты и времени;
- Запуск и остановка приложений;
- Выполнение системных вызовов.
Как это работает
Ни одно событие в любой операционной системе не может произойти без использования системных вызовов ядра. Запуск нового процесса, открытие файлов и работа с ними, запрос времени или типа ОС, обращение к оборудованию, создание сетевого соединения, вывод информации на экран – все эти операции производятся с помощью обращения к функциям ядра операционной системы, для краткости называемых системными вызовами. Если приложение не прибегает в своей работе к вызовам ядра, оно оказывается замкнутым в самом себе и просто не способно к какому-либо взаимодействию со своим окружением, не говоря уже о пользователе. Следовательно, чтобы отследить любое системное событие, достаточно просто перехватывать все обращения к системным вызовам.
Именно это и делает подсистема аудита. Она устанавливает триггеры «до» и «после» всех функций, ответственных за обработку системных вызовов, и ждет. Когда происходит системный вызов, триггер срабатывает, подсистема аудита получает всю информацию о вызове и его контексте, передает ее демону «auditd» и отдает дальнейшее управление функции, обрабатывающей системный вызов. После ее завершения срабатывает «выходной» триггер, и вся информация о системном вызове вновь поступает к подсистеме аудита и демону auditd.
Естественно, держать все эти триггеры в активном состоянии за все время работы ОС накладно и слишком избыточно (только во время старта приложение может выполнить несколько тысяч системных вызовов и для полного анализа журнала аудита придется потратить уйму времени). Поэтому, по умолчанию, триггеры отключены и могут быть выборочно активированы с помощью правил, которые задают имя системного вызова, статус выполнения, пользователя, от имени которого произошел вызов и т.д.
Анализ журналов
Логичным развитием систем журналирования являются IDS (intrusion detection system), IPS (intrusion prevention system), SIEM (security infromation and event management) системы. Они позволяют в более удобном виде интерпретировать события в системе и снизить нагрузку на ИТ персонал. Они содержат некие наборы паттернов поведения системы и компонентов для детектирования атак. Т.е. по своей сути они собирают некий диапазон событий, по которому могут судить о наличии той или иной разновидности атаки/инцидента. Они могут выдавать информацию как в реальном времени, так и по анализу некоторых событий (в этом случае реакция на аномалию может быть произведена с задержкой). Эти системы собирают данные из нескольких источников, которые подразделяются на следующие виды:
- Сетевые;
- Основанные на протоколе;
- Основанные на прикладном протоколе;
- Узловые;
- Гибридные.
Эти системы могут содержать в себе агенты для сбора, а также модули для работы с различными протоколами и устройствами. В современных реалиях обычно используют связку из нескольких систем для повышения уровня защиты и оперативного реагирования на инциденты: обеспечение безопасности сетевого периметра с использованием Snort, OSSEC и Prelude SIEM.
Целостность
Вопрос доверия приходящим из журналов аудита данных или из специализированных систем стоит особенно высоко в тех системах, которые были скомпрометированы. Многие забывают о том факте, насколько лог-файлы не защищены. Их легко можно изменить, подменить или уничтожить, получив доступ к машине, на которой они находятся. В теории, после компрометации системы, нельзя доверять данным, находящимся на ней, в том числе и лог-файлам. Нет гарантии что они намеренно не изменены злоумышленниками.
Чтобы иметь достоверные данные для анализа, можно использовать схему централизованного хранения журналов событий. Желательно для централизованного хранилища иметь отдельный сервер, на которой не будет установлено и запущено ничего кроме сервиса приема событий. Такой сервис должен уметь только принимать события, и в его функционал изначально не должны быть заложены функции по изменению и удалению данных.
После приема событий в хранилище можно сделать дополнительный шаг — резервное копирование. Также можно подумать о присваивании контрольных сумм файлам бэкапа и хранению их в другом месте (либо немедленной отправке на специальный почтовый ящик). Вариантов такой схемы может быть много, ее применение значительно повышает степень доверия к журналам событий.
Использование систем журналирования и реагирования на инциденты дает ИТ персоналу возможность предотвратить большинство современных атак на инфраструктуру и защитить критичные данные своих систем.
Практическая подготовка в пентест-лабораториях. Часть 1
Практическая подготовка в пентест-лабораториях. Часть 2
Практическая подготовка в пентест-лабораториях. Часть 3
Практическая подготовка в пентест-лабораториях. Часть 4
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий