Иногда бывают ситуации, когда надо перекинуть файлы с одного сервера на другой, но при этом прямого доступа по ssh между этими серверами нет, не настроена аутентификация. Но вы при этом можете подключиться по ssh к каждому из этих серверов. Вариантов решения задачи как минимум два:
1️⃣ Скопировать файлы с одного сервера сначала к себе, а потом от себя на второй сервер. Я летом часто работаю по 4G, мне такой вариант не подходит. Как подвариант этого же варианта, копировать файлы на какой-то промежуточный сервер со скоростным интернетом.
2️⃣ Настроить аутентификацию между двумя серверами. Иногда это не хочется делать, а когда-то и невозможно. Для этого понадобится либо лишние сертификаты создавать, которые могут быть запаролены, либо включать аутентификацию по паролю. Я лично не против последнего, но часто её отключают.
Выйти из этой ситуации можно относительно просто без лишних телодвижений на серверах. На помощь придёт ssh-agent, который входит в состав ssh-client. Отдельно ставить не надо. Если его просто запустить, то он выведет свои переменные в терминал:
Нам нужно их загрузить в оболочку для последующего использования. Сделаем это так:
Проверяем переменные:
Теперь добавим свои ключи из ~/.ssh в ssh-agent:
Посмотреть все добавленные ключи можно командой:
Почти всё готово. Осталось разрешить проброс агента при ssh соединении. Для этого добавляем в конфигурационный файл
Всё, теперь можно подключаться:
Вы должны подключиться к серверу с пробросом агента. Проверьте это, зайдя в
Теперь если вы куда-то будете подключаться по ssh с этого сервера, будет использоваться проброшенный ключ с вашей машины. То есть вы можете выполнить что-то вроде этого:
Данные с сервера 1.2.3.4 будут скопированы на сервер 5.6.7.8 с использованием сертификата с вашей рабочей машины. Прямой аутентификации с 1.2.3.4 на 5.6.7.8 настроено не будет.
Простой трюк, который можно использовать не только для копирования файлов. Подобную цепочку можно делать бесконечно длинной, но нужно понимать, что если вы захотите с сервера 5.6.7.8 подключиться куда-то дальше с этим же сертификатом, вам нужно будет на 1.2.3.4 так же настраивать проброс агента.
Тут важно понимать один момент, связанный с безопасностью. Когда вы подключились к какому-то серверу с пробросом агента, root пользователь этого сервера тоже получает доступ к этому агенту и может его использовать по своему усмотрению. Так что аккуратнее с этим. На чужие сервера на всякий случай так не ходите. И не включайте проброс агента по умолчанию для всех серверов и соединений. Когда он не нужен, отключайте.
#ssh
1️⃣ Скопировать файлы с одного сервера сначала к себе, а потом от себя на второй сервер. Я летом часто работаю по 4G, мне такой вариант не подходит. Как подвариант этого же варианта, копировать файлы на какой-то промежуточный сервер со скоростным интернетом.
2️⃣ Настроить аутентификацию между двумя серверами. Иногда это не хочется делать, а когда-то и невозможно. Для этого понадобится либо лишние сертификаты создавать, которые могут быть запаролены, либо включать аутентификацию по паролю. Я лично не против последнего, но часто её отключают.
Выйти из этой ситуации можно относительно просто без лишних телодвижений на серверах. На помощь придёт ssh-agent, который входит в состав ssh-client. Отдельно ставить не надо. Если его просто запустить, то он выведет свои переменные в терминал:
# ssh-agentSSH_AUTH_SOCK=/tmp/ssh-XXXXXXm7P5A8/agent.259; export SSH_AUTH_SOCK;SSH_AGENT_PID=260; export SSH_AGENT_PID;echo Agent pid 260;Нам нужно их загрузить в оболочку для последующего использования. Сделаем это так:
# eval `ssh-agent`Agent pid 266Проверяем переменные:
# env | grep SSH_SSH_AUTH_SOCK=/tmp/ssh-XXXXXXrrbmpN/agent.265SSH_AGENT_PID=266Теперь добавим свои ключи из ~/.ssh в ssh-agent:
# ssh-addПосмотреть все добавленные ключи можно командой:
# ssh-add -lПочти всё готово. Осталось разрешить проброс агента при ssh соединении. Для этого добавляем в конфигурационный файл
~/.ssh/config параметр для каждого сервера, к которому будем подключаться. Сервер можно указать как по ip адресу, так и по имени, в зависимости от того, как вы будете подключаться:Host 1.2.3.4 ForwardAgent yesHost srv-01 ForwardAgent yesВсё, теперь можно подключаться:
# ssh root@1.2.3.4Вы должны подключиться к серверу с пробросом агента. Проверьте это, зайдя в
/tmp подключенного сервера. Там должен быть сокет агента:root@1.2.3.4# ls /tmp | grep ssh-ssh-vSnzLCX7LWТеперь если вы куда-то будете подключаться по ssh с этого сервера, будет использоваться проброшенный ключ с вашей машины. То есть вы можете выполнить что-то вроде этого:
root@1.2.3.4# rsync -av /var/www/ root@5.6.7.8:/var/www/Данные с сервера 1.2.3.4 будут скопированы на сервер 5.6.7.8 с использованием сертификата с вашей рабочей машины. Прямой аутентификации с 1.2.3.4 на 5.6.7.8 настроено не будет.
Простой трюк, который можно использовать не только для копирования файлов. Подобную цепочку можно делать бесконечно длинной, но нужно понимать, что если вы захотите с сервера 5.6.7.8 подключиться куда-то дальше с этим же сертификатом, вам нужно будет на 1.2.3.4 так же настраивать проброс агента.
Тут важно понимать один момент, связанный с безопасностью. Когда вы подключились к какому-то серверу с пробросом агента, root пользователь этого сервера тоже получает доступ к этому агенту и может его использовать по своему усмотрению. Так что аккуратнее с этим. На чужие сервера на всякий случай так не ходите. И не включайте проброс агента по умолчанию для всех серверов и соединений. Когда он не нужен, отключайте.
#ssh
👍137👎3
Нашёл очень функциональный инструмент для логирования действий пользователей в подключениях по SSH к серверам. Речь пойдёт про open sourse проект sshlog. Выглядит он так, как-будто хотели сделать на его основе коммерческий продукт, но в какой-то момент передумали и забросили. Сделан он добротно и целостно. Расскажу по порядку.
📌 С помощью sshlog можно:
▪️ Логировать все подключения и отключения по SSH.
▪️ Записывать всю активность пользователя в консоли, в том числе вывод.
▪️ Отправлять уведомления по различным каналам связи на события, связанные с SSH: подключение, отключение, запуск команды и т.д.
▪️ Отправлять все записанные события и сессии на Syslog сервер.
▪️ Собирать метрики по количествам подключений, отключений, выполненных команд и т.д.
▪️ Наблюдать за чьей-то сессией и подключаться к ней для просмотра или взаимодействия.
▪️ Расширять функциональность с помощью плагинов.
Сразу скажу важное замечание. Записывать события пользователя root нельзя. Только обычных пользователей, даже если они сделают
Установить sshlog можно из репозитория разработчиков:
Репозиторий для Ubuntu, но для Debian тоже подходит. После установки автоматически создаётся служба systemd. В директории
-
-
В директории
Функциональность sshlog расширяется плагинами. Они все находятся в отдельном разделе с описанием и принципом работы. Все оповещения реализованы в виде плагинов. Есть готовые для email, slack, syslog, webhook. Оповещения отправляются при срабатывании actions. Так же по этим событиям могут выполняться и другие действия, например, запуск какой-то команды.
В общем, продукт функциональный и целостный. Покрывает большой пласт задач по контролю за сессиями пользователей. Удобно всё это разом слать куда-то по syslog в централизованное хранилище. По простоте и удобству, если мне не изменяет память, это лучшее, что я видел. Есть, конечно, Tlog от RedHat, но он более просто выглядит по возможностям и сложнее в настройке по сравнению с sshlog.
В репозитории есть несколько обращений на тему большого потребления CPU при работе. Я лично не сталкивался с этим во время тестов, но имейте ввиду, что такое возможно. Судя по всему есть какой-то неисправленный баг.
⇨ Сайт / Исходники
#ssh #logs #security
📌 С помощью sshlog можно:
▪️ Логировать все подключения и отключения по SSH.
▪️ Записывать всю активность пользователя в консоли, в том числе вывод.
▪️ Отправлять уведомления по различным каналам связи на события, связанные с SSH: подключение, отключение, запуск команды и т.д.
▪️ Отправлять все записанные события и сессии на Syslog сервер.
▪️ Собирать метрики по количествам подключений, отключений, выполненных команд и т.д.
▪️ Наблюдать за чьей-то сессией и подключаться к ней для просмотра или взаимодействия.
▪️ Расширять функциональность с помощью плагинов.
Сразу скажу важное замечание. Записывать события пользователя root нельзя. Только обычных пользователей, даже если они сделают
sudo su. В описании нигде этого не сказано, но я сам на практике убедился. Плюс, увидел такие же комментарии в вопросах репозитория. Установить sshlog можно из репозитория разработчиков:
# curl https://repo.sshlog.com/sshlog-ubuntu/public.gpg | gpg --yes --dearmor -o /usr/share/keyrings/repo-sshlog-ubuntu.gpg# echo "deb [arch=any signed-by=/usr/share/keyrings/repo-sshlog-ubuntu.gpg] https://repo.sshlog.com/sshlog-ubuntu/ stable main" > /etc/apt/sources.list.d/repo-sshlog-ubuntu.list# apt update && apt install sshlogРепозиторий для Ubuntu, но для Debian тоже подходит. После установки автоматически создаётся служба systemd. В директории
/etc/sshlog/conf.d будут 2 файла конфигурации:-
log_all_sessions.yaml - запись ssh сессий в директорию /var/log/sshlog/sessions, каждая сессия в отдельном лог файле, сохраняется в том числе вывод в консоли, а не только введённые команды.-
log_events.yaml - запись событий: подключения, отключения, введённые команды, общий лог для всех.В директории
/etc/sshlog/samples будут примеры некоторых других настроек. Вся конфигурация в формате yaml, читается легко, интуитивно. Возможности программы большие. Можно логировать только какие-то конкретные события. Например, запуск sudo. Либо команды от отдельного пользователя. Это можно настроить либо в событиях, либо в исключениях. Подробно механизм описан отдельно: sshlog config.Функциональность sshlog расширяется плагинами. Они все находятся в отдельном разделе с описанием и принципом работы. Все оповещения реализованы в виде плагинов. Есть готовые для email, slack, syslog, webhook. Оповещения отправляются при срабатывании actions. Так же по этим событиям могут выполняться и другие действия, например, запуск какой-то команды.
В общем, продукт функциональный и целостный. Покрывает большой пласт задач по контролю за сессиями пользователей. Удобно всё это разом слать куда-то по syslog в централизованное хранилище. По простоте и удобству, если мне не изменяет память, это лучшее, что я видел. Есть, конечно, Tlog от RedHat, но он более просто выглядит по возможностям и сложнее в настройке по сравнению с sshlog.
В репозитории есть несколько обращений на тему большого потребления CPU при работе. Я лично не сталкивался с этим во время тестов, но имейте ввиду, что такое возможно. Судя по всему есть какой-то неисправленный баг.
⇨ Сайт / Исходники
#ssh #logs #security
👍93👎2
Я уже как-то рассказывал про утилиту sshfs, которая позволяет монтировать удалённую файловую систему через SSH. То есть просто монтируете сетевой диск, используя только SSH соединение. Это не очень быстро, так как подключение выполняется в пространстве пользователя, да и в целом по SSH не очень быстрые соединения. Но для некоторых задач это бывает удобно. Доступ по SSH есть практически всегда.
Сделал готовую инструкцию, чтобы можно было быстро всё настроить с аутентификацией по ключам и с systemd юнитом для автомонтирования при загрузке.
Ставим sshfs:
Генерируем и копируем на удалённую машину ключ:
Можно подключаться с помощью пароля, но для этого его нужно будет интерактивно вводить вручную. Не получится настроить автомонтирование. Хотя если применить утилиту expect, то и это ограничение можно обойти. Но с сертификатом удобнее и проще.
Всё готово, монтируем д иректорию
Проверяем:
Размонтировать можно вот так:
Создаём службу systemd:
Сохраняем, запускаем, добавляем в автозагрузку:
Если хотим отмонтировать, то просто останавливаем:
Я показал примеры на тестовом сервере, сделав всё от root. Если будете настраивать куда-то на постоянку, то скорее всего будете запускать под каким-то другим пользователем (хотя кого я обманываю). Через параметры
Можно в systemd указать пользователя, под которым всё это будет монтироваться.
Способ подключения дисков через sshfs костыльный, но вполне рабочий. Пользоваться можно. Если есть возможность настроить nfs или smb, с ними будет лучше. Но, например, конкретно для монтирования директории с сертификатами, разницы никакой нет. Сразу подчеркну, что эту задачу можно решать и по-другому. Например, хуками и копированием сертификатов на целевой хост. Решения задачи может быть много. Я показал один из них.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ssh #fileserver
Сделал готовую инструкцию, чтобы можно было быстро всё настроить с аутентификацией по ключам и с systemd юнитом для автомонтирования при загрузке.
Ставим sshfs:
# apt install sshfsГенерируем и копируем на удалённую машину ключ:
# ssh-keygen -t ed25519# ssh-copy-id root@10.20.1.6Можно подключаться с помощью пароля, но для этого его нужно будет интерактивно вводить вручную. Не получится настроить автомонтирование. Хотя если применить утилиту expect, то и это ограничение можно обойти. Но с сертификатом удобнее и проще.
Всё готово, монтируем д иректорию
/etc/letsencrypt с сервера 10.20.1.6 к себе в /mnt/letsencrypt:# sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencryptПроверяем:
# df -h | grep 10.20.1.6root@10.20.1.6:/etc/letsencrypt 20G 1.8G 17G 10% /mnt/letsencryptРазмонтировать можно вот так:
# fusermount -u /mnt/letsencryptСоздаём службу systemd:
# systemctl edit --force --full sshfs.service[Unit]Description=Mount sshfsAfter=network-online.targetWants=network-online.target[Service]Type=oneshotRemainAfterExit=trueExecStart=sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencryptExecStop=fusermount -u /mnt/letsencrypt[Install]WantedBy=multi-user.targetСохраняем, запускаем, добавляем в автозагрузку:
# systemctl start sshfs.service# systemctl enable sshfs.serviceЕсли хотим отмонтировать, то просто останавливаем:
# systemctl stop sshfs.serviceЯ показал примеры на тестовом сервере, сделав всё от root. Если будете настраивать куда-то на постоянку, то скорее всего будете запускать под каким-то другим пользователем (хотя кого я обманываю). Через параметры
User=sftp-userGroup=sftp-userМожно в systemd указать пользователя, под которым всё это будет монтироваться.
Способ подключения дисков через sshfs костыльный, но вполне рабочий. Пользоваться можно. Если есть возможность настроить nfs или smb, с ними будет лучше. Но, например, конкретно для монтирования директории с сертификатами, разницы никакой нет. Сразу подчеркну, что эту задачу можно решать и по-другому. Например, хуками и копированием сертификатов на целевой хост. Решения задачи может быть много. Я показал один из них.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ssh #fileserver
14👍164👎2
В разное время на канале выходили публикации на тему логирования действий пользователя в терминале, в частности при подключениях по SSH. Тема востребованная, актуальная, так что решил все заметки по ней собрать в одном месте. К тому же решения предлагались очень сильно разные. Будет полезно их увидеть и сравнить в одном месте, от самых простых, до больших корпоративных систем.
◽️Snoopy — небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов. Продукт простой в настройке, живой, обновляется. Приехал в базовые репозитории популярных дистрибутивов. Работает сам по себе, без необходимости менять настройки SSH или пользователей.
◽️Log-user-session — программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл. Продукт старый, не поддерживается, но продолжает работать. Подключившись по SSH пользователь никак не закроет log-user-session и не выполнит команду мимо неё. Его просто отключит от сервера.
◽️PROMPT_COMMAND — использование встроенных возможностей оболочки bash. Содержимое переменной PROMPT_COMMAND выполняется после каждой введённой интерактивной команды. Мы просто выполняем команду
◽️Sshlog — работает как отдельная служба, умеет не только логировать действия пользователей по SSH, но и слать уведомления, в том числе на заданные действия, собирать метрики по подключениям, осуществлять внешний доступ к открытым сессиям пользователей. Программа в своё время была сделана добротно и законченно, с сайтом и документацией, но потом разработку как-будто забросили.
◽️Tlog — современная программа от RedHat с полным названием Terminal logger. Поддерживает различные хранилища для логов: текстовые файлы, syslog сервер, журнал systemd или в elasticsearch. Формат - json, то есть удобно делать поиск и выборку. Разработана для интеграции в экосистему Redhat, поддерживает интеграцию с FreeIPA через SSSD. Есть в базовых репозиториях.
◽️Teleport — масштабная система по управлению удалённым доступом к закрытым от внешнего доступа системам. В том числе осуществляет управление SSH соединениями с помощью своего приложения для установления соединений. Умеет записывать сессии не просто на уровне перехвата команд и вывода в консоль с хранением в текстовом виде, но полноценно записывает сессию, которую можно воспроизвести в режиме реального времени.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ssh #logs #подборка
◽️Snoopy — небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов. Продукт простой в настройке, живой, обновляется. Приехал в базовые репозитории популярных дистрибутивов. Работает сам по себе, без необходимости менять настройки SSH или пользователей.
◽️Log-user-session — программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл. Продукт старый, не поддерживается, но продолжает работать. Подключившись по SSH пользователь никак не закроет log-user-session и не выполнит команду мимо неё. Его просто отключит от сервера.
◽️PROMPT_COMMAND — использование встроенных возможностей оболочки bash. Содержимое переменной PROMPT_COMMAND выполняется после каждой введённой интерактивной команды. Мы просто выполняем команду
history 1, которая показывает последнюю введённую команду и куда-то записываем её: в файл или syslog. Решение максимально простое и понятное, но со своими нюансами. Надо промты менять и следить, чтобы обратно не менялись.◽️Sshlog — работает как отдельная служба, умеет не только логировать действия пользователей по SSH, но и слать уведомления, в том числе на заданные действия, собирать метрики по подключениям, осуществлять внешний доступ к открытым сессиям пользователей. Программа в своё время была сделана добротно и законченно, с сайтом и документацией, но потом разработку как-будто забросили.
◽️Tlog — современная программа от RedHat с полным названием Terminal logger. Поддерживает различные хранилища для логов: текстовые файлы, syslog сервер, журнал systemd или в elasticsearch. Формат - json, то есть удобно делать поиск и выборку. Разработана для интеграции в экосистему Redhat, поддерживает интеграцию с FreeIPA через SSSD. Есть в базовых репозиториях.
◽️Teleport — масштабная система по управлению удалённым доступом к закрытым от внешнего доступа системам. В том числе осуществляет управление SSH соединениями с помощью своего приложения для установления соединений. Умеет записывать сессии не просто на уровне перехвата команд и вывода в консоль с хранением в текстовом виде, но полноценно записывает сессию, которую можно воспроизвести в режиме реального времени.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ssh #logs #подборка
1👍101👎2
На прошлой неделе делал подборку инструментов для логирования действий пользователя в консоли. В комментариях справедливо заметили, что всё это умеет делать практически штатный инструмент - auditd. Его всегда рекомендуют включать и настраивать в контексте вопросов безопасности. Например, в руководствах CIS (#cis) о нём всегда упоминают.
Auditd я знаю, иногда настраиваю. Я о нём писал, как об инструменте для контроля за изменениями файлов. С его помощью это сделать относительно просто. Но честно скажу, не очень его люблю. Настройка неинтуитивна, логи перенасыщены информацией, чтобы просто посмотреть лог и что-то там найти, надо вспоминать команды или грепать текстовый лог.
Тем не менее, auditd это линуксовая база, так что знать его полезно. Настроим в нём логирование пользовательских команд. Auditd будет записывать не только запущенную команду, но и реально выполненную, а так же сопутствующую информацию: рабочая директория, файлы, связанные с выполнением, системный вызов, pid, uid, gid, tty и другие вещи.
Устанавливаем auditd:
Создаём правило, добавив в файл
По совету читателя добавил два правила: для пользователя root и для всех остальных. Правила идентичные, пользователя root идентифицировали через euid=0 и auid=0. Нулевые значения соответствуют root.
Применяем правила:
Теперь все команды пользователей записываются в соответствием с правилами. Смотрим команды root:
Вывалится большая портянка. Каждая команда в своём блоке, где будет указано:
◽️Дата и время выполнения
◽️PROCTITLE - выполненная команда
◽️PATH - файлы, связанные с выполнением (какие-нибудь библиотеки, сам исполняемый файл и т.д.)
◽️CWD - рабочая директория
◽️EXECVE - аргументы команды, если есть.
◽️SYSCALL - выполненный системный вызов со всеми свойствами в виде пользователя, pid, самой команды, исполняемого файла и т.д.
Как можно увидеть, информация исчерпывающая. Вроде и хорошо, что так подробно. С точки зрения безопасности полезная информация. Но быстро глянуть, кто тут что запускал, не получится. Например, если пользователь просто запустил mc, то в лог улетит не только эта команда, но и сопутствующие. Mc открывает свой bash и это тоже будет отражено в логе, также он запускает бинарники cons.saver, dircolors. Избыток подробной информации может сбивать с толку и усложнять аудит. С точки зрения безопасности это полезная информация, а с точки зрения посмотреть, кто тут что делал, не очень.
Может помочь команда, которая выведет список всех выполненных исполняемых файлов:
Также неудобно смотреть команды, запущенные через pipe. В auditd они будут отображены по отдельности.
По умолчанию auditd хранит логи в
Либо настроить пересылку логов в syslog. Для локального syslog сервера есть плагин с настройками в файле
Auditd – мощный инструмент для мониторинга событий операционной системы. Он взаимодействует напрямую с ядром, наблюдает за системными вызовами. Всё, что с ними связано, может записывать. Можно создавать отдельные правила для конкретных приложений и наблюдать за ними.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#auditd #ssh #security
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
4👍124👎2
При работе в терминале Linux иногда возникает потребность записать все вводимые команды и результаты вывода этих команд. Речь идёт не о централизованном способе записи всей активности, а разовой задачи, потому что централизованно эти вещи не всегда настроены. Плюс, там есть разные нюансы в работе, из-за которых что-то может не попадать в вывод.
Приведу примеры централизованной записи команд, о которых я рассказывал ранее:
◽️sshlog - запись вводимых команд и вывода, централизованный сбор логов с записями сессий, уведомления о каких-то событиях в консоли и многое другое.
◽️tlog - централизованная система сбора пользовательской активности в консоли от RedHat.
◽️snoopy - небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов.
◽️log-user-session - программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл.
◽️PROMPT_COMMAND - логирование в текстовый файл с помощью встроенной возможности оболочки bash.
Сегодня речь пойдёт о разовой задаче, когда вы подключились к серверу и хотите сохранить свою работу в консоли. Сделать это очень просто с помощью программы script, которая обычно уже присутствует в системе.
После подключения к серверу запустите её и направьте вывод в лог-файл:
Теперь всё, что вы введёте в консоль, будет записано в файл. Для удобства сразу дату туда добавил. Для того, чтобы прекратить запись, достаточно ввести команду
В лог попадёт некоторый "мусор", который затрудняет восприятие вывода. Это связано с тем, что script записывает сырой поток команд, который включает в себя некоторые закодированные ASCII последовательности, например, описывающие цветной вывод или команды терминала, типа возврата каретки и т.д.
Это всё можно разом очистить. Например, так:
На выходе будет чистый терминал практический такой же, как вы его видели, когда работали.
Простое и быстрое решение для разовой задачи по сохранению своей работы в терминале. Рекомендую сохранить и использовать по мере необходимости.
Я иногда включаю запись терминала средствами SSH клиента, но туда тоже всякий мусор попадает, надо обрабатывать. Плюс, не всегда всю сессию надо записывать. А тут в терминале включил запись, когда не надо, отключил. Потом очистил и всё видно в наглядном представлении без лишнего мусора. Можно вывод какой-то команды или набора команд сохранить и потом спокойно посмотреть.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#linux #terminal #ssh
Приведу примеры централизованной записи команд, о которых я рассказывал ранее:
◽️sshlog - запись вводимых команд и вывода, централизованный сбор логов с записями сессий, уведомления о каких-то событиях в консоли и многое другое.
◽️tlog - централизованная система сбора пользовательской активности в консоли от RedHat.
◽️snoopy - небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов.
◽️log-user-session - программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл.
◽️PROMPT_COMMAND - логирование в текстовый файл с помощью встроенной возможности оболочки bash.
Сегодня речь пойдёт о разовой задаче, когда вы подключились к серверу и хотите сохранить свою работу в консоли. Сделать это очень просто с помощью программы script, которая обычно уже присутствует в системе.
После подключения к серверу запустите её и направьте вывод в лог-файл:
# script -q -f ~/terminal_$(date +%F_%T).logТеперь всё, что вы введёте в консоль, будет записано в файл. Для удобства сразу дату туда добавил. Для того, чтобы прекратить запись, достаточно ввести команду
exit в терминале, и script завершит свою работу.В лог попадёт некоторый "мусор", который затрудняет восприятие вывода. Это связано с тем, что script записывает сырой поток команд, который включает в себя некоторые закодированные ASCII последовательности, например, описывающие цветной вывод или команды терминала, типа возврата каретки и т.д.
Это всё можно разом очистить. Например, так:
# sed -i 's/\x1B\[[0-9;?]*[A-Za-z]//g; s/\x1B\][0-9;]*.*(\x07|\x1B\\)//g;' terminal_2025-10-12_22:42:54.log\x1B\[[0-9;?]*[A-Za-z] - убрали управляющие последовательности (цвета, курсор и bracketed paste);\x1B\][0-9;]*.*(\x07|\x1B\\) - убрали OSC-последовательности ESC ] 0; title ESC \ и некоторые другие;\r - убрали возврат каретки (^M);На выходе будет чистый терминал практический такой же, как вы его видели, когда работали.
Простое и быстрое решение для разовой задачи по сохранению своей работы в терминале. Рекомендую сохранить и использовать по мере необходимости.
Я иногда включаю запись терминала средствами SSH клиента, но туда тоже всякий мусор попадает, надо обрабатывать. Плюс, не всегда всю сессию надо записывать. А тут в терминале включил запись, когда не надо, отключил. Потом очистил и всё видно в наглядном представлении без лишнего мусора. Можно вывод какой-то команды или набора команд сохранить и потом спокойно посмотреть.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#linux #terminal #ssh
Please open Telegram to view this post
VIEW IN TELEGRAM
👍122👎3