Оглавление
С ростом популярности облачных технологий и контейнеров вопрос безопасности Linux-систем становится все более актуальным. Организации стремятся защитить свои инфраструктуры, отслеживать подозрительные действия и вовремя реагировать на возможные угрозы.
Мы продолжаем делиться опытом разработки детектирующей логики и в данном посте рассмотрим используемый нами инструмент Falco. Это open-source решение для мониторинга безопасности, поддерживаемое CNCF (Cloud Native Computing Foundation) и разработанное компанией Sysdig.
Falco предоставляет мощные возможности для мониторинга событий на уровне ядра Linux, детектирования аномалий и предупреждения о возможных инцидентах. Далее разберем, как Falco работает, в чем его преимущества перед аналогами и как его можно использовать для повышения уровня безопасности.
Почему Falco?
Ключевые особенности Falco:
- Перехват событий ядра в реальном времени: Falco отслеживает различные события в операционной системе и позволяет выявлять подозрительную активность на уровне ядра.
- Анализ контейнерных событий: Falco оптимизирован для работы с контейнерами и идеально подходит для мониторинга Kubernetes-среды.
- Гибкость настройки: Falco поддерживает пользовательские правила для мониторинга, что позволяет легко адаптировать его под специфические потребности бизнеса.
- Интеграция с другими решениями: инструмент интегрируется с SIEM-системами и другими платформами мониторинга, что позволяет объединять данные и автоматизировать ответы на инциденты.
Сравнение с другими инструментами безопасности
Одним из наиболее распространенных средств для мониторинга Linux является auditd — встроенная система аудита, позволяющая отслеживать изменения файлов и активность пользователей. Однако auditd имеет свои ограничения:
- Отсутствие встроенной поддержки контейнеров: Auditd предназначен для мониторинга обычных Linux-систем и не имеет оптимизированной поддержки контейнеров, в то время как Falco легко интегрируется с контейнерными средами.
- Сложность настройки: Auditd требует тонкой настройки для эффективного мониторинга, тогда как Falco предоставляет шаблоны правил и гибкую систему конфигурации.
- Простота интеграции с облачными решениями: Falco, как часть экосистемы CNCF, ориентирован на облачные и микросервисные архитектуры, что упрощает его использование в Kubernetes и других контейнерных платформах.
Примеры использования Falco
Рассмотрим сценарии использования Falco в примерах эксплуатации некоторых техник и тактик.
Эксплуатация RCE в контейнере
Одним из ключевых преимуществ использования Falco вместо auditd в Linux-системах стало его умение отслеживать события в контейнерных средах, которые становятся всё более востребованными.
Рассмотрим контейнер с уязвимостью log4shell. О ее частой эксплуатации мы писали в статье Охота на змея: как обнаруживать эксплуатацию уязвимостей из арсенала группировки Shedding Zmiy. Проэксплуатируем данную уязвимость и посмотрим, как она отображается на примере события auditd.
type=SYSCALL msg=audit(1730850669.828:19716): arch=c000003e syscall=59 success=yes exit=0 a0=7311c8001e50 a1=7311c8001e70 a2=7fff98f4ed40 a3=0 items=2 ppid=19576 pid=20250 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sh" exe="/bin/dash" subj=docker-default key="execve"
type=EXECVE msg=audit(1730850669.828:19716): argc=1 a0="/bin/sh"
type=CWD msg=audit(1730850669.828:19716): cwd="/usr/local/tomcat"
type=PROCTITLE msg=audit(1730850669.828:19716): proctitle="/bin/sh"
Видим, что в полученном событии от auditd у нас нет информации о контейнере, и все действия будто воспроизводятся на основной системе.
{
"container.id": "b3993aae4cba",
"container.image": "log4j-shell-poc",
"container.image.id": "aec163acc896ae05dfda423dd8fe0ce9c48cd71c47eb87d78b4fbf3c606148c2",
"container.name": "nice_herschel",
"container.privileged": false,
"evt.type": "execve",
"proc.aexepath[2]": "/usr/bin/containerd-shim-runc-v2",
"proc.aexepath[3]": "/usr/lib/systemd/systemd",
"proc.cmdline": "sh",
"proc.cwd": "/usr/local/tomcat/",
"proc.exe": "/bin/sh",
"proc.exepath": "/bin/dash",
"proc.name": "sh",
"proc.pcmdline": "java -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.endorsed.dirs=/usr/local/tomcat/endorsed -classpath /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat -Dcatalina.home=/usr/local/tomcat -Djava.io.tmpdir=/usr/local/tomcat/temp org.apache.catalina.startup.Bootstrap start",
"proc.pexe": "/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java",
"proc.pexepath": "/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java",
"proc.pid": 19642,
"proc.pname": "java",
"proc.ppid": 19617,
"user.name": "root",
"user.uid": 0
}
В итоге событие Falco предоставляет более обогащенный вывод, показывая, в каком конкретно контейнере воспроизводится запущенный shell. Благодаря этому аналитики могут быстро определить точку входа злоумышленника в инфраструктуру и принять меры.
Обнаружение RCE
Вторым ключевым фактором использования Falco является наличие информации о родительских процессах. Не отходя далеко от log4shell, опишем правило для обнаружения данной эксплуатации RCE.
Вернемся к событию от Falco. Как мы видим, наш shell был запущен от веб-приложения Java, что может говорить нам о потенциальной эксплуатации RCE уязвимости.
- rule: Potential RCE
desc: Potential shell via web server
condition: spawned_process and proc.pname in (nginx, httpd, apache, apache2, java) and proc.name in (ash, bash, csh, ksh, sh, tcsh, zsh, dash)
output: "Potential RCE (%evt.type %user.name %user.uid %user.loginuid %user.loginname %container.id %container.name %container.image %container.image.id %container.privileged %proc.aexepath[2] %proc.aexepath[3] %proc.aexepath[4] %proc.aexepath[5] %proc.apid[2] %proc.apid[3] %proc.apid[4] %proc.apid[5] %proc.duration %proc.sid %proc.tty %proc.cwd %proc.pid %proc.exepath %proc.exe %proc.name %proc.cmdline %proc.ppid %proc.pexepath %proc.pexe %proc.pname %proc.pcmdline)"
priority: WARNING
tags: [eventid_1, proc_execution, rce]
Данное правило для Falco вы можете использовать и расширять для своих систем, чтобы детектировать подобные активности.
Приятный бонус
Помимо информации о процессе-родителе Falco обогащает информацией о предках родительского процесса.
{
"evt.type": "execve",
"proc.aname[2]": "sh",
"proc.aname[3]": "cron",
"proc.aname[4]": "cron",
"proc.aname[5]": "systemd",
"proc.apid[2]": 11356,
"proc.apid[3]": 11355,
"proc.apid[4]": 11314,
"proc.apid[5]": 1,
"proc.cmdline": "touch /tmp/new_script.sh",
"proc.duration": 174693,
"proc.exe": "touch",
"proc.exeline": "touch /tmp/new_script.sh",
"proc.exepath": "/usr/bin/touch",
"proc.name": "touch",
"proc.pcmdline": "sh /opt/worker_script.sh",
"proc.pid": 11358,
"proc.pname": "sh",
"proc.ppid": 11357,
"user.name": "root"
}
В событии мы видим цепочку процессов: touch, создавший файл /tmp/new_script.sh, инициирован bash-скриптом /opt/worker_script.sh, запущенным через cron. Таким образом, данные поля могут помочь в фильтрации событий, чтобы уменьшить нагрузку на SIEM и прочие подобные системы, или упростить задачу при анализе событий для установки вердикта событию.
Выявление атак в окружение процесса, использующих LD_PRELOAD
Ранее в блоге мы описывали атаку Shedding Zmiy, где встречался модифицированный вариант инструмента Facefish, который закреплял свою библиотеку *.so в /etc/ld.so.preload. Помимо закрепления через /etc/ld.so.preload, атакующие также могут использовать окружение процесса и указать библиотеку через переменную LD_PRELOAD.
{
"priority": "Warning",
"rule": "LD_PRELOAD exists",
"tags": [
"eventid_1",
"ld_preload",
"proc_execution"
],
"output_fields": {
"evt.type": "execve",
"proc.cmdline": "ls --color=auto -lah",
"proc.env[LD_PRELOAD]": "/tmp/maldir/mallib.so",
"proc.exe": "ls",
"proc.exeline": "ls --color=auto -lah",
"proc.exepath": "/usr/bin/ls",
"proc.name": "ls",
"proc.pcmdline": "bash",
"proc.pid": 12364,
"proc.pname": "bash",
"proc.ppid": 11777,
"user.name": "root"
}
}
Информация из поля proc.env об окружении процесса позволяет получить нужные нам переменные и детектировать подобную активность.
- rule: LD_PRELOAD exists
desc: Process started with LD_PRELOAD environment variable
condition: evt.type in (execve, execveat) and proc.env[LD_PRELOAD] != ""
enabled: true
output: "Process started with LD_PRELOAD environment variable (%user.name %proc.env[LD_PRELOAD] %proc.pid %proc.exe %proc.exepath %proc.name %proc.cmdline %proc.exeline %proc.ppid %proc.pname %proc.pcmdline %evt.type)"
priority: WARNING
tags: [eventid_1, proc_execution, ld_preload]
Подробнее о данной технике вы можете узнать из статьи https://www.wiz.io/blog/linux-rootkits-explained-part-1-dynamic-linker-hijacking
Отслеживание создания hardlink и symlink для скрытия инструментов
Для скрытия своих действий атакующие часто создают ссылки на утилиты, такие как wget и curl, с целью загрузки дополнительных файлов. При создании жестких ссылок Falco регистрирует информацию о пути в поле evt.abspath, что позволяет нам отслеживать создание таких ссылок.
{
"priority": "Informational",
"rule": "Create hardlink",
"tags": [
"eventid_12",
"hardlink"
],
"output_fields": {
"evt.abspath.dst": "/tmp/hard_wget",
"evt.abspath.src": "/usr/bin/wget",
"evt.args": "res=0 olddir=-100(AT_FDCWD) oldpath=/usr/bin/wget newdir=-100(AT_FDCWD) newpath=/tmp/hard_wget flags=0",
"evt.type": "linkat",
"proc.name": "ln",
"user.name": "root"
}
}
Воспользуемся этимиполями и поставим на мониторинг создание “жестких” ссылок на данные инструменты.
- rule: Create hardlink
desc: Hardlink created
condition: evt.type in (link, linkat) and (evt.abspath.src endswith wget or evt.abspath.src endswith curl)
enabled: true
output: Hardlink created %evt.args %evt.type %proc.name %evt.abspath.src %evt.abspath.dst
priority: INFO
tags: [eventid_12, hardlink]
Помимо использования hardlink, злоумышленники могут применять символьные ссылки (symlink) для запуска нежелательных команд или обхода ограничений. К счастью, Falco позволяет отслеживать значения аргументов системных вызовов (syscall), что делает его мощным инструментом для детектирования подобных манипуляций. Рассмотрим пример создания symlink с использованием Falco.
{
"priority": "Informational",
"rule": "Create symlink",
"tags": [
"eventid_12",
"symlink"
],
"output_fields": {
"evt.abspath.dst": "/tmp/symlink_wget",
"evt.abspath.src": "/tmp/symlink_wget",
"evt.args": "res=0 target=/usr/bin/wget linkdirfd=-100(AT_FDCWD) linkpath=/tmp/symlink_wget",
"evt.type": "symlinkat",
"fs.path.target": "/usr/bin/wget",
"proc.name": "ln"
}
}
Как можно заметить, поля evt.abspath.dst и evt.abspath.src не дают всей необходимой информации, как в случае с hardlink. Но обратите внимание на значение fs.path.target — оно указывает на приложение, к которому привязывается ссылка, что становится важной деталью для обнаружения атак.
Давайте создадим правило Falco, которое будет отслеживать создание symlink, эксплуатирующие инструменты wget и curl.
- rule: Create symlink
desc: Symlink created
condition: evt.type in (symlink, symlinkat) and (fs.path.target endswith wget or fs.path.target endswith curl)
enabled: true
output: Symlink created %fs.path.target %evt.args %evt.type %proc.name %evt.abspath.src %evt.abspath.dst
priority: INFO
tags: [eventid_12, symlink]
Теперь правило будет регистрировать события создания ссылок на wget или curl, что может говорить о потенциально подозрительной активности.
Выявление эксплуатации созданного symlink через запуск процессов
Помимо отслеживания создания ссылок, можно также мониторить процессы, чтобы выявить случаи использования уже созданных symlink. Например, если злоумышленник создаёт ссылку на wget и затем запускает её, мы сможем отследить это по системному вызову execve. Вот как выглядит событие запуска созданной ссылки:
{
"evt.type": "execve",
"proc.cmdline": "symlink_wget google.com",
"proc.exe": "/tmp/symlink_wget",
"proc.exeline": "/tmp/symlink_wget google.com",
"proc.exepath": "/usr/bin/wget",
"proc.name": "symlink_wget",
"proc.pname": "bash",
"user.name": "root"
}
В этом примере путь в proc.exepath указывает на настоящее приложение wget, хотя имя процесса (proc.name) совпадает с именем symlink. Это явное указание на то, что symlink используется для запуска команды через реальное приложение. Зафиксируем это в правиле:
- rule: Potential evasion with symlink
desc: Potential evasion of wget or curl use via symlinks
condition: evt.type in (execve, execveat) and proc.exepath in ("/usr/bin/wget", "/usr/bin/curl") and (proc.name != wget or proc.name != curl)
enabled: true
output: "Process started (%user.name %proc.pid %proc.exe %proc.exepath %proc.name %proc.cmdline %proc.exeline %proc.ppid %proc.pname %proc.pcmdline %evt.type)"
priority: INFO
tags: [eventid_1, proc_execution]
Процесс, удаляющий свой собственный исполняемый файл
Одна из распространённых техник сокрытия вредоносных программ — это удаление исполняемого файла сразу после его запуска. Это позволяет процессу «скрыться» от простого обнаружения, так как файл, который его запустил, отсутствует в файловой системе в прежнем виде. Примером может служить вредоносное ПО BPFDoor.
Суть техники проста: процесс запускается и тут же удаляет свой файл, оставляя метку (deleted) в событиях. После этого он продолжает стабильно работать в оперативной памяти, но если система перезагрузится или процесс завершится, отследить, что было запущено, станет практически невозможно.
{
"priority": "Warning",
"rule": "Self-deleted file",
"tags": [
"deletion",
"eventid_23",
"filesystem"
],
"output_fields": {
"evt.type": "unlinkat",
"fs.path.name": "/tmp/selfdelete_file",
"proc.exepath": "/tmp/selfdelete_file",
"proc.name": "selfdelete_file",
"proc.pname": "bash",
"user.name": "root"
}
}
В этом событии мы видим системный вызов unlinkat, с помощью которого процесс удалил файл, из которого был запущен. Поля proc.exepath (путь до исполняемого файла процесса) и fs.path.name (путь до удаляемого файла) указывают на один и тот же файл, что и дает нам ключ к идентификации такой активности.
Благодаря оператору val(), который позволяет получить значение нужного поля и сравнить его с значением другого, мы можем создать правило для мониторинга подобных событий:
- rule: Self-deleted file
desc: A process deleting its own executable
condition: evt.type in (unlink, unlinkat) and proc.exepath = val(fs.path.name)
enabled: true
output: Detected self-deleted file %evt.type %fs.path.name %proc.name %proc.exepath %proc.pname
priority: WARNING
tags: [eventid_23, filesystem, deletion]
Это правило будет регистрировать события, когда процесс удаляет свой собственный исполняемый файл.
Обнаружение подозрительных доменов
Одной из сильных сторон Falco является возможность резолвить доменные имена, что существенно упрощает мониторинг и детектирование сетевых событий. Это особенно полезно для обнаружения соединений с подозрительными доменами, часто связанными с атаками. Например, популярный инструмент GSocket, используемый злоумышленниками, по умолчанию устанавливает соединение с основным доменом gsocket[.]io.
С помощью Falco мы можем настраивать правила, чтобы отслеживать такие соединения. Вот пример события, которое регистрируется при подключении к gsocket[.]io:
{
"priority": "Warning",
"rule": "Connection with gsocket.io",
"tags": [
"eventid_3",
"network_connection"
],
"output_fields": {
"evt.type": "connect",
"fd.cip": "192.168.132.129",
"fd.cport": 35028,
"fd.is_server": false,
"fd.l4proto": "tcp",
"fd.sip": "185.199.108.153",
"fd.sip.name": "gsocket.io",
"fd.sport": 80,
"proc.cmdline": "wget gsocket.io",
"proc.exe": "wget",
"proc.exeline": "wget gsocket.io",
"proc.exepath": "/usr/bin/wget",
"proc.name": "wget",
"proc.pid": 15758,
"proc.pname": "bash",
"proc.ppid": 11777,
"user.name": "root"
}
}
Здесь мы видим, что в поле fd.sip.name отображается доменное имя, к которому происходит подключение. Это позволяет нам настроить правила для мониторинга сетевых соединений, ориентируясь именно на имена доменов.
Чтобы обнаруживать соединения с gsocket[.]io, мы напишем правило, которое отфильтрует события типа connect и доменному имени fd.sip.name.
- rule: Connection with gsocket.io
desc: Detection outbound connection to gsocket main domain
condition: evt.type = connect and fd.sip.name="gsocket.io"
enabled: true
output: "Outbound TCP connection (%fd.sip.name %user.name %proc.pid %proc.exe %proc.exepath %proc.name %proc.cmdline %proc.exeline %proc.cwd %proc.ppid %proc.pname %fd.cip %fd.cport %fd.sip %fd.sport %fd.is_server %fd.l4proto %evt.type)"
priority: WARNING
tags: [eventid_3, network_connection]
Также, если вы хотите использовать данный способ для детектирования не одного домена, а нескольких, можете использовать листы. Например:
- list: susp_domains
items: [
"gsocket.io",
"thc.org"
]
...
condition: evt.type = connect and fd.sip.name in (susp_domains)
...
Доступ к конфиденциальным файлам
Одной из ключевых целей атакующих, получивших доступ к системе, является сбор конфиденциальной информации. Например, существует вредоносный инструмент SSH-Snake, который нацелен на извлечение данных из файлов bash_history. Эти файлы могут содержать ценные сведения, такие как команды использования SSH, пароли и другие детали, которые атакующий может использовать для дальнейшего проникновения в систему.
Falco позволяет детектировать доступ к файлам с конфиденциальной информацией с помощью шаблонов (wildcard). В отличие от auditd, который требует указания полного пути к каждой директории и файлу, Falco поддерживает использование шаблонов в правилах. Это позволяет гибко настроить мониторинг для нескольких пользователей сразу, отслеживая доступ к конкретным типам файлов, таким как .bash_history.
- rule: Bash history accessed
desc: Potential gather information from bash history
condition: evt.typ in (open, openat) and fd.name glob "/home/*/.bash_history" and proc.name != bash
enabled: true
output: Bash history accessed (%fd.name %fd.nameraw %user.name %user.uid %user.loginuid %user.loginname %proc.pid %proc.exe %proc.exepath %proc.name %proc.cmdline %proc.exeline %proc.cwd %proc.ppid %proc.pname %proc.pcmdline %evt.type)
priority: INFO
tags: [eventid_9, filesystem, reading]
Посмотрим на пример события, сгенерированного Falco при попытке прочитать .bash_history:
{
"priority": "Informational",
"rule": "Bash history accessed",
"tags": [
"eventid_9",
"filesystem",
"reading"
],
"output_fields": {
"evt.type": "openat",
"fd.name": "/home/roger/.bash_history",
"proc.cmdline": "grep -E ^(ssh|scp|rsync) /home/roger/.bash_history",
"proc.cwd": "/home/roger/",
"proc.exe": "grep",
"proc.exeline": "grep -E ^(ssh|scp|rsync) /home/roger/.bash_history",
"proc.exepath": "/usr/bin/grep",
"proc.name": "grep",
"proc.pid": 16640,
"user.name": "root",
"user.uid": 0
}
}
Отслеживание создания исполняемых файлов
Falco позволяет эффективно контролировать создание новых файлов с правами на исполнение с помощью переменной evt.is_open_exec, что делает его полезным инструментом для выявления скрытых исполняемых файлов, которые могут свидетельствовать о подозрительной активности. Этот подход помогает вовремя обнаружить потенциально вредоносные файлы, особенно если они создаются под скрытыми именами (например, с точкой в начале, как .susp_file).
{
"priority": "Informational",
"rule": "Hidden executable created",
"tags": [
"creation",
"eventid_11",
"filesystem"
],
"output_fields": {
"evt.type": "openat",
"evt.is_open_exec": true,
"fd.filename": ".susp_file",
"fd.name": "/opt/app/.susp_file",
"proc.cmdline": "cp /tmp/susp_file /opt/app/.susp_file",
"proc.exe": "cp",
"proc.exeline": "cp /tmp/susp_file /opt/app/.susp_file",
"proc.exepath": "/usr/bin/cp",
"proc.name": "cp",
"proc.pcmdline": "bash",
"proc.pid": 17067,
"proc.pname": "bash",
"proc.ppid": 16633,
"user.name": "root",
"user.uid": 0
}
}
В этом событии Falco регистрирует, что файл .susp_file был создан с правами на исполнение, а также отмечает, что это скрытый файл. Поле evt.is_open_exec указывает, что файл имеет права на выполнение, что может свидетельствовать о потенциальной угрозе.
- rule: Hidden executable created
desc: Detect creation of an executable file with a hidden name
condition: evt.type in (open, openat, creat) and evt.is_open_exec = true and fd.filename startswith "."
enabled: true
output: Hidden executable created (%evt.is_open_exec %fd.name %fd.filename %user.name %user.uid %user.loginuid %user.loginname %proc.pid %proc.exe %proc.exepath %proc.name %proc.cmdline %proc.exeline %proc.cwd %proc.ppid %proc.pname %proc.pcmdline %evt.type)
priority: INFO
tags: [eventid_11, filesystem, creation]
Это правило позволяет детектировать создание любого исполняемого файла с именем, начинающимся с точки, будь то .hidden_script, .malicious_bin или другой скрытый файл. Поле evt.is_open_exec в условии проверяет, что файл имеет права на исполнение, а условие fd.filename startswith "." позволяет отфильтровать скрытые файлы.
Заключение
В современном ландшафте информационной безопасности критически важно иметь инструмент, позволяющий получать расширенную информацию о событиях для создания более точных и эффективных детектов. При этом необходима продуманная фильтрация часто повторяющихся событий, количество которых увеличивается с ростом числа хостов в инфраструктуре. Это помогает снизить нагрузку на системы сбора и корреляции событий, делая анализ данных более управляемым и точным.
Как мы увидели в приведенных примерах, Falco помогает обнаруживать различные техники атакующих и дает расширенные возможности для создания конфига сбора событий:
- Контейнерные среды: Falco дает широкий спектр возможностей для мониторинга безопасности именно в контейнерах. Он предоставляет детальные события о контейнерах и прочих похожих системах, что позволяет использовать его в данной среде.
- Информация о родительских процессах и предках: Falco фиксирует не только основную информацию о процессах, но и включает данные о родительских процессах и даже предках этих родительских процессов. Это позволяет точно проследить происхождение процессов и выявить цепочку команд, которая могла привести к подозрительной активности.
- Информация об окружении процессов: Falco умеет получать информацию об окружение процесса, что дает возможности для новых гипотез детектирования вредоносной активности. Также, помимо всего окружения, есть возможность для извлечения только известной нам переменной, как это было с LD_PRELOAD.
- Широкие возможности для написания гибких правил: Falco поддерживает шаблоны, списки и дополнительные операторы, такие как val(), для гибкой настройки фильтров и написания конфигураций. Эти инструменты упрощают написание правил и позволяют настраивать их под конкретные нужды, выделяя самые важные и значимые события.
- Обнаружение по доменным именам в сетевых событиях: В Falco встроена возможность анализа сетевых событий с использованием доменных имен, что позволяет распознавать обращения к подозрительным доменам. Это особенно полезно, когда у нас есть список с вредоносными доменами, обращения к которым мы бы хотели отслеживать.
Можно сделать вывод, что помимо стандартного auditd, существуют решения, такие как Falco, которые предоставляют более продвинутые возможности для сбора телеметрии и значительно упрощают мониторинг безопасности в Linux-системах. Falco позволяет детализировать события, эффективно фильтровать данные и настраивать гибкие правила, что делает его мощным инструментом для проактивной защиты.
Также гипотезами для детектов новых инструментов, с которыми сталкиваемся, мы делимся в Telegram-канале Четыре луча. Присоединяйтесь к нам.