Подсматриваем за Linux-инфраструктурой и выявляем атаки / Антон Жаболенко, Лиана Остапчук

• Антон Жабаенко, руководитель информационной безопасности Валберис, и Лиана, отвечающая за мониторинг информационной безопасности, обсуждают выявление атак в Linux-инфраструктуре.  

• Начинают с прикладного примера: криптобиржа N трагически взломана.  

• Лиана предлагает искать план реагирования на инциденты ИБ.  

• Если плана нет, нужно сформировать список вопросов для расследования.  

• Вопросы касаются проникновения злоумышленников, повышения привилегий и оставленных следов.  

• Логи важны для расследования инцидентов, но часто их недостаточно.  

• Мониторинг должен собирать телеметрию по запросу, таймеру и событиям.  

• Мониторинг не должен мешать работе прода.  

• Вопрос о возможности использования существующих IT-мониторингов для сбора логов.  

• Забикс не подходит, так как требует написания собственного мониторинга.  

• Рассматриваются стандарты и сборщики логов, такие как NIST и SIEM.  

• Ускорение - агент, который собирает телеметрию и логи.  

• Позволяет писать SQL-подобные запросы для получения информации о системе.  

• Собирает 154 вида телеметрии и логов, что достаточно для выявления инцидентов.  

• Пример запроса для получения информации о пользователях с расширенными привилегиями.  

• Ускорение может собирать информацию по наступлению событий.  

• Подсистема EPF и аудит ядра позволяют подписываться на события и потребляют меньше ресурсов.  

• EPG нестабилен на продовых нагрузках и менее производителен, чем парсинг логов.  

• Подсистема аудита работает стабильно и пригодна для прода.  

• Рекомендуется использовать мониторинг потребления ресурсов агентом с помощью Zabbix.  

• OSCORE стабильно работает на продовых серверах.  

• Мониторинг потребления ресурсов агентом с помощью Zabbix показывает стабильное потребление.  

• Встроенные механизмы ограничения ресурсов, такие как watchdog, помогают контролировать потребление.  

• Проблема с буфером аудита в Linux: тротлинг при недостаточном вычитывании событий.  

• Решение: увеличение размера буфера, балансировка между полнотой логов и производительностью, более частые запросы к таблице событий.  

• Проблема с использованием VPN-сервера: конфликт доступа к сокетам, решение: отказ от использования таблицы роудс.  

• OSCORE может потреблять избыточное количество памяти и операций чтения/записи с диска.  

• Решение: ограничение буфера для локальных событий, увеличение частоты отправки логов, оптимизация запросов.  

• Сложные запросы могут потреблять много ресурсов и попадать в черный список.  

• Решение: упрощение запросов, увеличение лимитов watchdog, отключение watchdog.  

• Отключение лимитов помогает избежать проблем с ресурсоемкими запросами.  

• Запросы могут казаться простыми, но на самом деле требуют значительных ресурсов CPU.  

• Таблицы формируются на лету, что требует ресурсов CPU.  

• События накапливаются на локальном хосте и отправляются в систему сбора логов.  

• Редкая отправка событий может привести к расхождению времени доставки и времени события.  

• Это может повлиять на координационную логику и выявление инцидентов.  

• Внимательно изучайте таблицы и поля, которые OSCORE может залогировать.  

• Используйте Vault для хранения секретов, а не OSCORE.  

• OSCORE помогает собирать телеметрию и события в высоконагруженной инфраструктуре.  

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

• OSCORE может помочь в расследовании атак, выявляя подозрительные процессы и соединения.  

• OSCORE полезен для команд эксплуатации, помогая расследовать инфраструктурные инциденты.  

• Помогает ответить на вопросы о том, кто поставил пакет или запустил процесс, который сломал инфраструктуру.  

• Вопросы о задержке доставки логов и нагрузке на сеть.  

• Вопросы о безопасности системы сбора логов и мерах по снижению вероятности компрометации.  

• Вопросы о производительности модулей OSCORE и их подписке на системные вызовы.  

• Возможность сбора системной информации с хостов.  

• Доступ к информации через отдельную таблицу системы инфо.  

• Проект по обмену информацией со смежной командой.  

• Агент Squirrel управляется центральным сервером.  

• Локальные изменения конфигурации агента обновляются с сервера.  

• Агент автоматически обновляет конфигурацию, предотвращая изменения от администраторов.  

• Squirrel поставляется с динамическим конфигом через систему централизованного управления.  

• Возможность указания частоты обновления конфигурации через флаги.  

• Управление рисками и защита от инсайдеров через телепорт.  

• Призыв к выбору лучшего вопроса.  

• Благодарность участникам за внимание.  

• Обещание дальнейших интересных докладов.