На прошлой неделе делал подборку инструментов для логирования действий пользователя в консоли. В комментариях справедливо заметили, что всё это умеет делать практически штатный инструмент - auditd. Его всегда рекомендуют включать и настраивать в контексте вопросов безопасности. Например, в руководствах CIS (#cis) о нём всегда упоминают.

Auditd я знаю, иногда настраиваю. Я о нём писал, как об инструменте для контроля за изменениями файлов. С его помощью это сделать относительно просто. Но честно скажу, не очень его люблю. Настройка неинтуитивна, логи перенасыщены информацией, чтобы просто посмотреть лог и что-то там найти, надо вспоминать команды или грепать текстовый лог.

Тем не менее, auditd это линуксовая база, так что знать его полезно. Настроим в нём логирование пользовательских команд. Auditd будет записывать не только запущенную команду, но и реально выполненную, а так же сопутствующую информацию: рабочая директория, файлы, связанные с выполнением, системный вызов, pid, uid, gid, tty и другие вещи.

Устанавливаем auditd:

# apt install auditd

Создаём правило, добавив в файл /etc/audit/rules.d/audit.rules несколько новых строк:

-a always,exit -F arch=b64 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution
-a always,exit -F arch=b32 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution

-a always,exit -F arch=b64 -F auid!=-1 -S execve -S execveat -k generic_command_execution                                             
-a always,exit -F arch=b32 -F auid!=-1 -S execve -S execveat -k generic_command_execution

По совету читателя добавил два правила: для пользователя root и для всех остальных. Правила идентичные, пользователя root идентифицировали через euid=0 и auid=0. Нулевые значения соответствуют root.

Применяем правила:

# auditctl -R /etc/audit/rules.d/audit.rules

Теперь все команды пользователей записываются в соответствием с правилами. Смотрим команды root:

# ausearch -k root_auth_command_execution

Вывалится большая портянка. Каждая команда в своём блоке, где будет указано:

◽️Дата и время выполнения
◽️PROCTITLE - выполненная команда
◽️PATH - файлы, связанные с выполнением (какие-нибудь библиотеки, сам исполняемый файл и т.д.)
◽️CWD - рабочая директория
◽️EXECVE - аргументы команды, если есть.
◽️SYSCALL - выполненный системный вызов со всеми свойствами в виде пользователя, pid, самой команды, исполняемого файла и т.д.

Как можно увидеть, информация исчерпывающая. Вроде и хорошо, что так подробно. С точки зрения безопасности полезная информация. Но быстро глянуть, кто тут что запускал, не получится. Например, если пользователь просто запустил mc, то в лог улетит не только эта команда, но и сопутствующие. Mc открывает свой bash и это тоже будет отражено в логе, также он запускает бинарники cons.saver, dircolors. Избыток подробной информации может сбивать с толку и усложнять аудит. С точки зрения безопасности это полезная информация, а с точки зрения посмотреть, кто тут что делал, не очень.

Может помочь команда, которая выведет список всех выполненных исполняемых файлов:

# aureport -x -i

Также неудобно смотреть команды, запущенные через pipe. В auditd они будут отображены по отдельности.

По умолчанию auditd хранит логи в /var/log/audit/audit.log. Читать их или грепать напрямую неудобно. Там всё сплошным потоком, без дат. Можно через ausearch или aureport выгружать их в файлы:

# aureport -x -i > /var/log/audit_exec_summary.log

Либо настроить пересылку логов в syslog. Для локального syslog сервера есть плагин с настройками в файле /etc/audit/plugins.d/syslog.conf. С локального можно на внешний пересылать.

Auditd – мощный инструмент для мониторинга событий операционной системы. Он взаимодействует напрямую с ядром, наблюдает за системными вызовами. Всё, что с ними связано, может записывать. Можно создавать отдельные правила для конкретных приложений и наблюдать за ними.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#auditd #ssh #security

В комментариях к статье с настройкой OpenVPN читатель задал странный вопрос. Он обратил внимание, что в логах подключения клиента к серверу фигурирует пароль от закрытого ключа CA:

Mon Jun 16 16:25:21 2025 VERIFY OK: depth=0, CN=пароль_на_ca.key

Я сначала призадумался, прикинул, что такого не может быть. Сколько использую OpenVPN, никогда такого не видел. Следующим комментарием автор сам же и ответил на свой вопрос. Он по ошибке загнал пароль от CA в CN сертификата сервера, когда его создавал. А там должно быть имя сервера, CN = Common Name. Пароль надо вводить уже в самом конце, когда подписываешь сертификат.

Интересная ситуация, поэтому решил сделать по мотивам заметку. Такие ошибки на самом деле не редкость. Расскажу, на мой взгляд, одну из самых популярных ситуаций, когда невольно раскрывается важный пароль. Я и сам на такое натыкался, и от других видел не раз.

Когда торопишься и логинишься по SSH к серверу, особенно если не к своему и первый раз это делаешь, учётные данные ещё не сохранены, то можно в окно приветствия вместо логина сразу же вставить из буфера пароль. Тут же становится понятно, что ты ошибся, и со второй попытки ты всё делаешь правильно.

Но при этом твой введённый пароль вместо логина улетает в открытом виде в лог auth.log или какой-то другой и остаётся там. А если настроено какое-то хранилище логов, то он улетает дальше туда. Если так ошиблись, то сразу же зайдите в логи и подчистите за собой. А если это невозможно, то меняйте пароль, если есть вероятность, что логи может посмотреть кто-то, кому этот пароль знать не положено.

Ещё часто пароли светятся вот в таких конструкциях:

# mysqldump --opt -v --no-create-db db01 -u'root' -p'pass01' > ~/db01.sql'

Если вводите что-то подобное в консоль, то не указывайте пароль явно. Оставьте только ключ -p, тогда пароль у вас спросят интерактивно и он не попадёт в history. Ну а если попал, то удалите его после себя. Либо при запуске команды поставьте перед ней пробел. Но это не обязательно спасёт от сохранения команды. Данная возможность может быть отключена.

Палили так свои пароли? Я и по ssh, и в консоли палил. Благо это было не особо критично, так как чаще всего работаю со своими серверами я один, и чтобы всё это прочитать потом, надо быть рутом. А root это я и есть. Но о таких вещах стоит всегда помнить и следить за собой.

#security

Я уже когда-то давно упоминал про любопытный сайт, где простыми словами описываются различные уязвимости веб приложений:

⇨ Hacksplaining ⇨ Lesson Library

На текущий момент сайт доступен только через VPN. Не знаю, кто и за что блокирует, но не суть. Там есть раздел, где наглядно описаны и на примерах показаны уязвимости и как их эксплуатируют. К некоторым реализованы интерактивные действия, где вы сами поучаствуете во взломе. Сделано необычно и интересно, всё описано простыми словами.

Даётся минимум теории по выполненным шагам. Но в целом всё понятно. Как говорится, вместо тысячи слов. Проще один раз сделать самому и всё понять. Посмотрите на описание SQL Injection, и сразу поймёте о чём я говорю. Также рекомендую как минимум посмотреть наиболее популярные уязвимости:

▪️Cross-Site Scripting
▪️Command Execution
▪️Directory Traversal
▪️File Upload Vulnerabilities

Из последних нововведений - описание нескольких примеров уязвимостей искусственного интеллекта, доступного публично. Из него, оказывается, можно вытянуть информацию, которая не должна быть доступна широкому кругу лиц. Я об этих вещах раньше не слышал и даже не задумывался. Например, из модели можно вытянуть реальные данные, на которых она обучалась, или заставить её выполнить код из загруженного документа. Это при условии, что её заранее не защитили от этих вещей.

Ресурс будет в первую очередь интересен разработчикам, так как там наглядно показано, как не надо писать код или настраивать ИИ. Админам и девопсам будет просто полезно посмотреть, как обычно ломают веб ресурсы, ИИ, и за какие промахи можно бить по рукам разработчиков. Да и просто интересно ознакомиться для общего образования. Платить не надо, всё бесплатно.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#security #обучение

Недавно из комментариев узнал про систему RuSIEM. Она относится к классу продуктов SIEM (Security Information and Event Management). Я в целом далёк от темы безопасности и связанным с этим софтом, так как это отдельное направление в IT. Эта система привлекла меня тем, что у неё есть полностью бесплатная версия RvSIEM, которая занимается только сбором и обработкой логов, анализируя их на наличие содержимого, связанного с защитой и безопасностью.

Решение полностью российское, соответственно документация, весь интерфейс, все встроенные фильтры и отчёты полностью на русском, что упрощает эксплуатацию. Я немного разобрался с RvSIEM: развернул, посмотрел, что умеет и как работает. На первый взгляд неплохая система. Кратко расскажу, что конкретно она делает.

RvSIEM умеет принимать логи из различных систем: веб сервера, операционные системы (в том числе Windows), СУБД, почтовые сервера, шлюзы, сетевые устройства и т.д. Она их автоматически парсит, если используются стандартные шаблоны логов этих приложений и собирает по ним аналитику. Например, вычленяет из них IP адреса источников, информацию об учётных данных, если речь идёт о логине, статусы и критичности событий из логов приложений и т.д.

Всё это стекается в общее хранилище на базе Elasticsearch и ClickHouse, там анализируется и строятся отчёты. Например, можно вывести сквозной список всех IP адресов, с которых были подключения, которые не относятся к IP адресам РФ. Можно сделать отдельный отчёт по логинам RDP или в админку самой RvSIEM. Причём отчёты можно выгружать в различных форматах: PDF, DOCX, XSLX, CSV.

Есть стандартные преднастроенные фильтры и отчёты. Можно писать свои. То же самое и к парсерам относится. Используются grok фильтры для парсинга, как в Logstash. С ними нетрудно разобраться и распарсить свой формат логов. Я в своё время это освоил, когда надо было. Управление всё через веб интерфейс, в консоль ходить не обязательно.

Рассказываю, как я всё это установил. Пошёл на сайт и в разделе скачать оставил заявку. На следующий день мне прислали на почту мою учётную запись в ЛК с документацией всей системы RuSIEM. Там есть все ссылки и инструкции на загрузку. Используется общий установщик, а конкретно установку RvSIEM выбираешь при его запуске.

С установкой проблем не возникло, там всё просто. Инструкция на русском, сделал по ней. Хотя по сути там нужно просто скачать скрипт и запустить его. Дальше установщик всё делает сам. Он работает на базе ролей Ansible. Никаких лицензий потом получать не надо.

Дам одну существенную рекомендацию по настройкам Elasticsearch. Он по умолчанию съедает всю оперативную память и его прибивает OOM Killer. У меня было 4GB памяти, сделал 8GB, не помогло, сделал 12GB - тоже не помогло. Elasticsearch регулярно падал, хотя в тестовой системе нагрузки никакой не было. Мне это надоело и я в файл /etc/elasticsearch/jvm.options.d/rusiem.jvm.options добавил настройки:

-Xms4g
-Xmx4g

Они ограничивают потребление в 4GB, что для небольшой нагрузки достаточно. После этого система стала стабильно работать.

RvSIEM умеет собирать логи разными способами. В основном это syslog, NetFlow и свой агент, в том числе для Windows. То есть настройка простая. Например, в Angie можно напрямую отправить логи в RvSIEM в формате syslog:

access_log syslog:server=10.20.1.9:5014,facility=local7,tag=angie,severity=info
error_log syslog:server=10.20.1.9:5014,facility=local7,tag=angie,severity=info

Основное ограничение бесплатной версии - 500 EPS (events per second). Не знаю, что тут конкретно имеется ввиду. Наверное, суммарное количество строк логов в секунду.

Для бесплатной системы функциональность более чем. Не знаю, есть ли у кого-то что-то лучше. Да и в целом мне понравилась система. Довольно быстро разобрался, развернул, посмотрел, как работает. Особых проблем не возникло. Попробуйте, если вам нужен такого рода продукт.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#logs #security #отечественное

Думаю, многие из вас знают или слышали о бесплатном продукте Suricata – это система обнаружения вторжений (IDS) и система предотвращения вторжений (IPS) с открытым исходным кодом. Её обычно используют в программных шлюзах и анализаторах трафика. Например, в IPFire, OPNsense, PfSense, Arkime и т.д.

На базе Suricata построен известный продукт SELKS, который является отличным дополнением к бесплатному же Wazuh - это SIEM система (Security Information and Event Management). Получается хорошая связка:

◽️SELKS мониторит сетевой трафик в режиме реального времени, выявляет угрозы на уровне сети и пытается их предотвратить.
◽️Wazuh ставит агенты на конечные системы, собирает данные об ОС, софте, уязвимостях, о событиях из логов, об изменениях с уровня файловой системы и т.д.

Вместе эта бесплатная парочка закрывают базовые потребности малого и среднего бизнеса. Хотя не уверен, что малому это в принципе нужно, но тем не менее. Это хорошая рабочая связка.

В январе этого года SELKS прекратил своё развитие в том виде, как он был. Его переименовали в Clear NDR – Community и немного пересобрали. Заменили Elastic Stack (Elasticsearch, Logstash, Kibana) на OpenSearch и Fluentd. Также изменили веб интерфейс с Kibana на тот, что есть в Enterprise-версии. Но при этом версия осталась бесплатной с той же функциональностью. Разработчики обещают более активное развитие, так как теперь у
Community и Enterprise версии общая кодовая база и одинаковый веб интерфейс.

Для Clear NDR - Community пока нет собранного ISO файла, как это было у SELKS. Его можно было развернуть с помощью установщика, как отдельную, новую систему. Clear NDR ставится поверх уже установленной с помощью утилиты stamusctl и работает на базе Docker.

Установка Clear NDR - Community:

# wget https://dl.clearndr.io/stamusctl-linux-amd64
# chmod +x ./stamusctl-linux-amd64
# mv ./stamusctl-linux-amd64 /usr/local/bin/stamusctl

У меня напрямую не скачался бинарник на сервере. Не знаю почему, не стал разбираться. Скачал через браузер даже без VPN и закинул на сервер вручную.

# mkdir /opt/ClearNDR && cd /opt/ClearNDR
# stamusctl compose init

Выбираем сетевой интерфейс, на котором будем слушать трафик. Запускаем сервис:

# stamusctl compose up -d

Можно идти в веб интерфейс по HTTPS и настраивать систему. Учётка по умолчанию - selks-user / selks-user.

К сожалению, на Clear NDR нельзя напрямую подать NetFlow трафик для простого и удобного анализа, поэтому если сервер с ней не является шлюзом, то нужно будет каким-то образом реализовывать подачу нужного трафика на сетевой интерфейс сервера с Clear NDR. В зависимости от топологии сети, задача может решаться по-разному.

Для ручных проверок готовых дампов трафика в формате pcap, можно сделать вот так:

# stamusctl compose readpcap fulltraf.pcap

Система при запуске заберёт себе и проанализирует весь трафик из файла.

Проверить работу можно с помощью набора проверок отсюда: https://github.com/3CORESec/testmynids.org

Отдельно отмечу, что в составе Clear NDR есть полнофункциональный Arkime.

⇨ 🌐 Сайт / Исходники

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#security #gateway