Common Vulnerabilities and Exposures
CVE - база данных общеизвестных уязвимостей информационной безопасности. Каждой уязвимости присваивается идентификационный номер вида CVE-год-номер.
Red Hat CVE Checker
NEW Web site CVE
CVE - база данных общеизвестных уязвимостей информационной безопасности. Каждой уязвимости присваивается идентификационный номер вида CVE-год-номер.
Red Hat CVE Checker
NEW Web site CVE
CVE-2019-14287
Уязвимость CVE-2019-14287 очень интересна в своей природе. Благодаря наличию уязвимости в ОС, злоумышленник может овладеть максимальными привилегиями. Рассмотрим ее.
Для начала настроим разрешенное пользователю user_name для запуска всех прав пользователя, кроме корневых разрешений vim.
~]# visudo
или
~]# vi /etc/sudoers
…
user_name ALL=(ALL, !root) /usr/bin/vim
…
Сохранить.
Выполните:
~]# sudo -u#-1 id -u
или
~]# sudo -u#4294967295 id -u
в случае если после ввода пароля вы стали супер пользователем, сожалею - ваша система уязвима.
Причиной, по которой пользователь овладевает привилегиями- преобразование идентификатора пользователя в имени пользователя -1 (или не действительное значение 4294967295)
Решение:
Уязвимость влияет на все версии Sudo до последней версии 1.8.28. Необходимо повысить версию.
Уязвимость CVE-2019-14287 очень интересна в своей природе. Благодаря наличию уязвимости в ОС, злоумышленник может овладеть максимальными привилегиями. Рассмотрим ее.
Для начала настроим разрешенное пользователю user_name для запуска всех прав пользователя, кроме корневых разрешений vim.
~]# visudo
или
~]# vi /etc/sudoers
…
user_name ALL=(ALL, !root) /usr/bin/vim
…
Сохранить.
Выполните:
~]# sudo -u#-1 id -u
или
~]# sudo -u#4294967295 id -u
в случае если после ввода пароля вы стали супер пользователем, сожалею - ваша система уязвима.
Причиной, по которой пользователь овладевает привилегиями- преобразование идентификатора пользователя в имени пользователя -1 (или не действительное значение 4294967295)
Решение:
Уязвимость влияет на все версии Sudo до последней версии 1.8.28. Необходимо повысить версию.
Cтруктура файловой системы Linux
/ - корень;
Это главный каталог в системе Linux. По сути, это и есть файловая система Linux.
/bin - каталог с бинарными файлами пользователя;
Этот каталог содержит исполняемые файлы. Здесь расположены программы, которые можно использовать в однопользовательском режиме или режиме восстановления.
/sbin - системные исполняемые файлы;
Так же как и /bin, содержит двоичные исполняемые файлы
/etc - каталог с конфигурационными файлами;
В этом каталоге содержатся конфигурационные файлы всех программ, установленных в системе.
/dev - файлы устройств;
Местоположение всех подключенных устройств
/proc - информация о процессах;
Это подсистема, динамически создаваемая ядром ОС.
/var - Переменные файлы;
Название каталога /var говорит само за себя, он должен содержать файлы, которые часто изменяются
/tmp - каталог с временными файлами;
В этом каталоге содержатся временные файлы, созданные системой, любыми программами или пользователями
/usr - Программы пользователя;
Это самый большой каталог с большим количеством функций
/home - раздел для домашних каталогов пользователей;
Тут хранятся домашние каталоги созданных пользователей
/boot - Файлы загрузчика;
Содержит все файлы, связанные с загрузчиком системы
/lib - Системные библиотеки;
Содержит файлы системных библиотек, которые используются исполняемыми файлами в каталогах /bin и /sbin.
/opt - Дополнительные программы;
В этот каталог устанавливаются дополнительные программы
/sys - Информация о системе;
Назначение каталогов Linux из этой папки - получение информации о системе непосредственно от ядра
/ - корень;
Это главный каталог в системе Linux. По сути, это и есть файловая система Linux.
/bin - каталог с бинарными файлами пользователя;
Этот каталог содержит исполняемые файлы. Здесь расположены программы, которые можно использовать в однопользовательском режиме или режиме восстановления.
/sbin - системные исполняемые файлы;
Так же как и /bin, содержит двоичные исполняемые файлы
/etc - каталог с конфигурационными файлами;
В этом каталоге содержатся конфигурационные файлы всех программ, установленных в системе.
/dev - файлы устройств;
Местоположение всех подключенных устройств
/proc - информация о процессах;
Это подсистема, динамически создаваемая ядром ОС.
/var - Переменные файлы;
Название каталога /var говорит само за себя, он должен содержать файлы, которые часто изменяются
/tmp - каталог с временными файлами;
В этом каталоге содержатся временные файлы, созданные системой, любыми программами или пользователями
/usr - Программы пользователя;
Это самый большой каталог с большим количеством функций
/home - раздел для домашних каталогов пользователей;
Тут хранятся домашние каталоги созданных пользователей
/boot - Файлы загрузчика;
Содержит все файлы, связанные с загрузчиком системы
/lib - Системные библиотеки;
Содержит файлы системных библиотек, которые используются исполняемыми файлами в каталогах /bin и /sbin.
/opt - Дополнительные программы;
В этот каталог устанавливаются дополнительные программы
/sys - Информация о системе;
Назначение каталогов Linux из этой папки - получение информации о системе непосредственно от ядра
Что нужно знать о режиме сна и гибернации в Linux?
Режим гибернации при его включении, система Linux записывает свое текущее состояние в файл. Далее при включении все эти данные восстанавливаются и вы продолжаете работу с места остановки.
Режим сна помогает экономить электроэнергию, когда вы не используете свою систему.
В Linux есть 3 режима ожидания:
- Suspend to RAM - ждущий режим, режим используют большинство ноутбуков. В этом режиме питание остается для оперативной памяти,большая часть компонентов отключается.
- Suspend to Disk - в этом режиме состояние ПК сохраняется в файле подкачки, и система полностью выключается.
- Suspend to both - гибридная приостановка, здесь состояние машины сохраняется в swap, но система не выключается
Для отключения описанных выше режимов, необходимо отключить следующие sydtemd:
~]# systemctl mask sleep.target
~]# systemctl mask suspend.target
~]# systemctl mask hibernate.target
~]# systemctl mask hybrid-sleep.target
Выполните перезагрузку ОС
~]# shutdown -r
Режим гибернации при его включении, система Linux записывает свое текущее состояние в файл. Далее при включении все эти данные восстанавливаются и вы продолжаете работу с места остановки.
Режим сна помогает экономить электроэнергию, когда вы не используете свою систему.
В Linux есть 3 режима ожидания:
- Suspend to RAM - ждущий режим, режим используют большинство ноутбуков. В этом режиме питание остается для оперативной памяти,большая часть компонентов отключается.
- Suspend to Disk - в этом режиме состояние ПК сохраняется в файле подкачки, и система полностью выключается.
- Suspend to both - гибридная приостановка, здесь состояние машины сохраняется в swap, но система не выключается
Для отключения описанных выше режимов, необходимо отключить следующие sydtemd:
~]# systemctl mask sleep.target
~]# systemctl mask suspend.target
~]# systemctl mask hibernate.target
~]# systemctl mask hybrid-sleep.target
Выполните перезагрузку ОС
~]# shutdown -r
Управление systemd.
В Linux управлением systemd выполняется утилитой systemctl. Мы прекрасно знаем, как и за что отвечают те или иные команды передаваемые systemd для определенных юнитов, такие как: start, stop, status, mask, unmask. Но на самом деле, функционал достаточно широкий:
• list-units - посмотреть все службы
~]# systemctl list-units
• list-sockets - посмотреть все сокеты служб
~]# systemctl list-sockets
• list-timers - посмотреть список таймеров
~]# systemctl list-timers
• start - запустить службу
~]# systemctl start daemon
• stop - остановить службу
~]# systemctl stop daemon
• reload - перечитать конфигурацию
~]# systemctl reload daemon
• restart - перезапустить службу
~]# systemctl restart daemon
• try-restart - перезапустить службу, только если она запущена
~]# systemctl try-restart daemon
• reload-or-restart - попросить службу обновить свою конфигурацию
~]# systemctl reload-or-restart daemon
• isolate - запустить только одну службу вместе с ее зависимостями
~]# systemctl isolate daemon
• kill - отправить сигнал завершения процессу используется вместе с опциями --signal и --kill-who
~]# systemctl kill daemon
• clean - удалить все данные, которые касаются указанной службы, сюда входит кэш, логи
~]# systemctl clean daemon
• is-active - проверить запущена ли служба
~]# systemctl is-active daemon
• is-failed - проверить не завершилась ли служба с ошибкой
~]# systemctl is-failed daemon
• status - посмотреть состояние и вывод службы
~]# systemctl status daemon
• show - посмотреть параметры управления службой в Linux
~]# systemctl show daemon
• cat - посмотреть содержимое юнит файла в текстовом виде
~]# systemctl cat daemon
• reset-failed - очистить состояние failed для служб, которые завершились с ошибкой
~]# systemctl reset-failed
• list-dependencies - посмотреть зависимости службы
~]# systemctl list-dependencies daemon
• list-unit-files - вывести все установленные файлы служб
~]# systemctl list-unit-files
• enable - добавить службу в автозагрузку
~]# systemctl enable daemon
• disable - удалить службу из автозагрузки
~]# systemctl disable daemon
• is-enabled - проверить есть ли уже служба в автозагрузке
~]# systemctl is-enabled daemon
• reenable - сначала выполнить disable потом enable для службы
~]# systemctl reenable daemon
• list-jobs - все выполняющиеся задачи
~]# systemctl list-jobs
• snapshot - сохранить состояние служб, чтобы потом восстановить
~]# systemctl snapshot daemon
• daemon-reload - обновить конфигурацию юнитов для всех служб
~]# systemctl daemon-reload
• mask - сделать юнит недоступным
~]# systemctl mask daemon
• unmask - сделать юнит доступным
~]# systemctl unmask daemon
• link - добавить юнит файл, который расположен не в стандартной папке для юнитов
~]# systemctl link /home/daemon
• revert - вернуть юнит до состояния по умолчанию
~]# systemctl revert daemon
• edit - отредактировать параметры службы не изменяя основной файл юнита.
~]# systemctl edit daemon
В Linux управлением systemd выполняется утилитой systemctl. Мы прекрасно знаем, как и за что отвечают те или иные команды передаваемые systemd для определенных юнитов, такие как: start, stop, status, mask, unmask. Но на самом деле, функционал достаточно широкий:
• list-units - посмотреть все службы
~]# systemctl list-units
• list-sockets - посмотреть все сокеты служб
~]# systemctl list-sockets
• list-timers - посмотреть список таймеров
~]# systemctl list-timers
• start - запустить службу
~]# systemctl start daemon
• stop - остановить службу
~]# systemctl stop daemon
• reload - перечитать конфигурацию
~]# systemctl reload daemon
• restart - перезапустить службу
~]# systemctl restart daemon
• try-restart - перезапустить службу, только если она запущена
~]# systemctl try-restart daemon
• reload-or-restart - попросить службу обновить свою конфигурацию
~]# systemctl reload-or-restart daemon
• isolate - запустить только одну службу вместе с ее зависимостями
~]# systemctl isolate daemon
• kill - отправить сигнал завершения процессу используется вместе с опциями --signal и --kill-who
~]# systemctl kill daemon
• clean - удалить все данные, которые касаются указанной службы, сюда входит кэш, логи
~]# systemctl clean daemon
• is-active - проверить запущена ли служба
~]# systemctl is-active daemon
• is-failed - проверить не завершилась ли служба с ошибкой
~]# systemctl is-failed daemon
• status - посмотреть состояние и вывод службы
~]# systemctl status daemon
• show - посмотреть параметры управления службой в Linux
~]# systemctl show daemon
• cat - посмотреть содержимое юнит файла в текстовом виде
~]# systemctl cat daemon
• reset-failed - очистить состояние failed для служб, которые завершились с ошибкой
~]# systemctl reset-failed
• list-dependencies - посмотреть зависимости службы
~]# systemctl list-dependencies daemon
• list-unit-files - вывести все установленные файлы служб
~]# systemctl list-unit-files
• enable - добавить службу в автозагрузку
~]# systemctl enable daemon
• disable - удалить службу из автозагрузки
~]# systemctl disable daemon
• is-enabled - проверить есть ли уже служба в автозагрузке
~]# systemctl is-enabled daemon
• reenable - сначала выполнить disable потом enable для службы
~]# systemctl reenable daemon
• list-jobs - все выполняющиеся задачи
~]# systemctl list-jobs
• snapshot - сохранить состояние служб, чтобы потом восстановить
~]# systemctl snapshot daemon
• daemon-reload - обновить конфигурацию юнитов для всех служб
~]# systemctl daemon-reload
• mask - сделать юнит недоступным
~]# systemctl mask daemon
• unmask - сделать юнит доступным
~]# systemctl unmask daemon
• link - добавить юнит файл, который расположен не в стандартной папке для юнитов
~]# systemctl link /home/daemon
• revert - вернуть юнит до состояния по умолчанию
~]# systemctl revert daemon
• edit - отредактировать параметры службы не изменяя основной файл юнита.
~]# systemctl edit daemon
SSH. Как облегчить жизнь?
Создадим наш CA. К примеру это будет ключевая пара, в которой используется схема цифровой подписи типа Ed25519.
~]# ssh-keygen -C CA -t ed25519 -f ca_key
Не забудьте устанавливать пароли
Получаем два файла: ca_key и ca_key.pub. Они и образуют наш CA. Закрытый ключ ca_key перемещаем в необходимый каталог, а открытый ключ ca_key.pub помещаем на удаленном сервере в /etc/ssh/ca_key.pub и выполняем команду доверять всем ключам, подписанным этим CA, добавив в конфигурационный файл сервера /etc/ssh/sshd_config такую строку:
TrustedUserCAKeys /etc/ssh/ca_key.pub
‼️Всегда перезагружайте SSH-сервер после каждого изменения конфигурации
~]# systemctl restart ssh.service
Генерируем пару пользовательских ключей для аутентификации на сервере:
~]# ssh-keygen -t ed25519 -f user
и подписываем открытый ключ пользователя user.pub:
~]# ssh-keygen -s ca_key -I user -n root user.pub
Опция -I — это идентификатор ключа
Опция -n задает принципал
Предположим, у нас есть сервер с тремя непривилегированными пользователями user1, user2 и user3. Каждый пользователь имеет свои, строго ограниченные права доступа к файлам и каталогам.
Любому из этих принципалов может быть предоставлено право авторизоваться на сервере. Для этого создаем на сервере каталог auth_principals:
~]# mkdir /etc/ssh/auth_principals
А в sshd_config вставляем строку
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
В каталоге auth_principals для любого пользователя можно создать файл, где указать тех принципалов, которые уполномочены авторизоваться под именем данного пользователя. Например, разрешим принципалам user1 и user2 авторизоваться в системе от имени пользователя user3:
~]# echo -e 'user1\nuser2' > /etc/ssh/auth_principals/user3
А принципалу user3 от имени пользователей user1 и user2:
~]# echo user3 > /etc/ssh/auth_principals/user1
~]# echo user3 > /etc/ssh/auth_principals/user2
Создадим принципалу user3 сертификат:
~]# ssh-keygen -s ca_key -I user -n user3 -z 102348 -O no-x11-forwarding -O source-address=192.168.145.23,192.168.201.0/24 -V always:2023 user.pub
С помощью опции -O source-address мы разрешили user3 входить в систему только с определенного IP-адреса и/или определенной сети.
С помощью опции -z даем сертификату серийный номер для учета и контроля и возможного отзыва.
Опция -O no-x11-forwarding запрещает x11-forwarding.
Теперь не забудьте поместить все эти ключи и сертификаты на клиентской машине в правильный каталог .ssh и отредактировать config
Создадим наш CA. К примеру это будет ключевая пара, в которой используется схема цифровой подписи типа Ed25519.
~]# ssh-keygen -C CA -t ed25519 -f ca_key
Не забудьте устанавливать пароли
Получаем два файла: ca_key и ca_key.pub. Они и образуют наш CA. Закрытый ключ ca_key перемещаем в необходимый каталог, а открытый ключ ca_key.pub помещаем на удаленном сервере в /etc/ssh/ca_key.pub и выполняем команду доверять всем ключам, подписанным этим CA, добавив в конфигурационный файл сервера /etc/ssh/sshd_config такую строку:
TrustedUserCAKeys /etc/ssh/ca_key.pub
‼️Всегда перезагружайте SSH-сервер после каждого изменения конфигурации
~]# systemctl restart ssh.service
Генерируем пару пользовательских ключей для аутентификации на сервере:
~]# ssh-keygen -t ed25519 -f user
и подписываем открытый ключ пользователя user.pub:
~]# ssh-keygen -s ca_key -I user -n root user.pub
Опция -I — это идентификатор ключа
Опция -n задает принципал
Предположим, у нас есть сервер с тремя непривилегированными пользователями user1, user2 и user3. Каждый пользователь имеет свои, строго ограниченные права доступа к файлам и каталогам.
Любому из этих принципалов может быть предоставлено право авторизоваться на сервере. Для этого создаем на сервере каталог auth_principals:
~]# mkdir /etc/ssh/auth_principals
А в sshd_config вставляем строку
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
В каталоге auth_principals для любого пользователя можно создать файл, где указать тех принципалов, которые уполномочены авторизоваться под именем данного пользователя. Например, разрешим принципалам user1 и user2 авторизоваться в системе от имени пользователя user3:
~]# echo -e 'user1\nuser2' > /etc/ssh/auth_principals/user3
А принципалу user3 от имени пользователей user1 и user2:
~]# echo user3 > /etc/ssh/auth_principals/user1
~]# echo user3 > /etc/ssh/auth_principals/user2
Создадим принципалу user3 сертификат:
~]# ssh-keygen -s ca_key -I user -n user3 -z 102348 -O no-x11-forwarding -O source-address=192.168.145.23,192.168.201.0/24 -V always:2023 user.pub
С помощью опции -O source-address мы разрешили user3 входить в систему только с определенного IP-адреса и/или определенной сети.
С помощью опции -z даем сертификату серийный номер для учета и контроля и возможного отзыва.
Опция -O no-x11-forwarding запрещает x11-forwarding.
Теперь не забудьте поместить все эти ключи и сертификаты на клиентской машине в правильный каталог .ssh и отредактировать config
Под контролем безопасности
В настоящий момент, преобладающее использование ОС - Astra Linux.
Если есть подозрение, что у Вас в системе проникновение, предлагаю проверить, так ли это.
user_list.sh
# Получим список пользователей
if uname -a | grep astra ;
# Это вариант запроса для Astra Linux.
then
getent passwd {1000..60000} >/dev/null 2>&1
# Сравним с выводом через awk
eval getent passwd {$(awk '/^UID_MIN/ {print $2}' /etc/login.defs)..$(awk '/^UID_MAX/ {print $2}' /etc/login.defs)} | cut -d: -f1
fi
# Зачастую мы хотим просто посмотреть реальных пользователей, у которых есть каталоги.
# Исключаем папку lost+found
users=`ls /home -I lost*`
echo $users
Проверим информацию о входах в систему, основные параметры пользователей.
# Список последних загрузок ОС
~]# journalctl --list-boots 2>/dev/null
search_auth.sh
if [ -e /var/log/btmp ]
then
# Неудачные попытки входа в систему
lastb 2>/dev/null
fi
if [ -e /var/log/wtmp ]
then
# Лог логинов и бутов
last -f /var/log/wtmp
fi
Получаем список привилегированных sudo-юзеров
~]# sudo cat /etc/sudoers 2>/dev/null
~]# cat /etc/passwd 2>/dev/null
Юзеры с пустым паролем
~]# sudo cat /etc/shadow | awk -F":" '($2 == "") {print $1}' 2>/dev/null
Иногда можно найти приватные ключи хоста, что потом позволит изучить исходившие от него подключения. Это пригодится при расследовании сложных инцидентов с массовыми подключениями.
Спросим у рута и у всех пользователей, что у них есть на этот счет:
~]# cat /root/.ssh/* 2>/dev/null
~]# for name in $(ls /home) do cat /home/$name/.ssh/* 2>/dev/null done
Если полученные ключи не принадлежат известным системам, это может быть плохой новостью. Также проверим попытки удаленного входа через SSH:
~]# sudo journalctl _SYSTEMD_UNIT=sshd.service | grep "error" 2>/dev/null
Входы в систему по SSH можем посмотреть через lastlog.
~]# sudo journalctl | grep ssh # или sshd
Ищем ошибки аутентификации
~]# sudo journalctl | grep ssh | grep -i -A2 -B2 fail
В настоящий момент, преобладающее использование ОС - Astra Linux.
Если есть подозрение, что у Вас в системе проникновение, предлагаю проверить, так ли это.
user_list.sh
# Получим список пользователей
if uname -a | grep astra ;
# Это вариант запроса для Astra Linux.
then
getent passwd {1000..60000} >/dev/null 2>&1
# Сравним с выводом через awk
eval getent passwd {$(awk '/^UID_MIN/ {print $2}' /etc/login.defs)..$(awk '/^UID_MAX/ {print $2}' /etc/login.defs)} | cut -d: -f1
fi
# Зачастую мы хотим просто посмотреть реальных пользователей, у которых есть каталоги.
# Исключаем папку lost+found
users=`ls /home -I lost*`
echo $users
Проверим информацию о входах в систему, основные параметры пользователей.
# Список последних загрузок ОС
~]# journalctl --list-boots 2>/dev/null
search_auth.sh
if [ -e /var/log/btmp ]
then
# Неудачные попытки входа в систему
lastb 2>/dev/null
fi
if [ -e /var/log/wtmp ]
then
# Лог логинов и бутов
last -f /var/log/wtmp
fi
Получаем список привилегированных sudo-юзеров
~]# sudo cat /etc/sudoers 2>/dev/null
~]# cat /etc/passwd 2>/dev/null
Юзеры с пустым паролем
~]# sudo cat /etc/shadow | awk -F":" '($2 == "") {print $1}' 2>/dev/null
Иногда можно найти приватные ключи хоста, что потом позволит изучить исходившие от него подключения. Это пригодится при расследовании сложных инцидентов с массовыми подключениями.
Спросим у рута и у всех пользователей, что у них есть на этот счет:
~]# cat /root/.ssh/* 2>/dev/null
~]# for name in $(ls /home) do cat /home/$name/.ssh/* 2>/dev/null done
Если полученные ключи не принадлежат известным системам, это может быть плохой новостью. Также проверим попытки удаленного входа через SSH:
~]# sudo journalctl _SYSTEMD_UNIT=sshd.service | grep "error" 2>/dev/null
Входы в систему по SSH можем посмотреть через lastlog.
~]# sudo journalctl | grep ssh # или sshd
Ищем ошибки аутентификации
~]# sudo journalctl | grep ssh | grep -i -A2 -B2 fail
Файловые аномалии при проникновении.
Необходимо выполнить поиск всех файлов, у которых нет владельца или группы, — это характерно при удаленном проникновении на хост и работе через реверс‑шеллы.
При поиске вредоносов рекомендую искать файлы без владельца
~]# find /root /home -nouser 2>/dev/null
или без группы
~]# find /root /home -nogroup 2>/dev/null
Конкурирующая команда для поиска файлов с SUID и GUID
~]# find / -uid 0 \( -perm -4000 -o -perm 2000 \) -print
Поиск файлов с нехарактерных названиями, например начинающихся на точку, две точки или пробел
~]# find / -name " *" -print # find / -name ". *" -print
~]# find / -name ".. *" -print
Поиск больших файлов (больше 10 Мбайт)
~]# find / -size +10M
Поиск процессов, инициированных удаленными файлами
~]# lsof +L1
Необходимо выполнить поиск всех файлов, у которых нет владельца или группы, — это характерно при удаленном проникновении на хост и работе через реверс‑шеллы.
При поиске вредоносов рекомендую искать файлы без владельца
~]# find /root /home -nouser 2>/dev/null
или без группы
~]# find /root /home -nogroup 2>/dev/null
Конкурирующая команда для поиска файлов с SUID и GUID
~]# find / -uid 0 \( -perm -4000 -o -perm 2000 \) -print
Поиск файлов с нехарактерных названиями, например начинающихся на точку, две точки или пробел
~]# find / -name " *" -print # find / -name ". *" -print
~]# find / -name ".. *" -print
Поиск больших файлов (больше 10 Мбайт)
~]# find / -size +10M
Поиск процессов, инициированных удаленными файлами
~]# lsof +L1
Основы аудита Linux.
Аудит в Linux состоит из двух групп компонентов: в пространстве ядра это kauditd, а в пользовательском — auditd
Ядро, принимая системные вызовы из user space, пропускает их через фильтры user, task, filesystem , exclude и exit.
user используется для фильтрации событий
task применяется для системных вызовов fork() и clone().
filesystem используется для исключения событий для конкретной файловой системы.
exclude задает исключения для событий.
exit проходят все системные вызовы.
auditctl - мы можем управлять потоком событий.
ausearch, aureport, aulast просматривем журнал аудита.
Статус работы подсистемы
~]# auditctl -s
Отправьте текстовое сообщение
~]# auditctl -m hello
убедитесь
~]# ausearch -m USER
, что соответствующее событие попало в журнал аудита
Примеры правил находятся /usr/share/audit/sample-rules/.
Примеры типов правил:
Управляющие правила настраивают систему аудита и поведение агента.
Правила файловой системы. Формат правила следующий:
-w path-to-file -p permissions -k keyname
-w указывает на то, что это правило файловой системы.
-p может содержать любые комбинации прав доступа r (чтение), w (запись), x (выполнение) и a (изменение атрибута).
-k задает имя правила.
Правила системных вызовов используются для мониторинга системных вызовов.
-a action,list -S syscall -F field=value -k keyname
-a означает append (добавление) правила в фильтр.
action может быть always (всегда создавать события) или never (никогда не создавать события).
list содержит один из возможных вариантов: task, exit, user, filesystem или exclude.
-S - указывает конкретный syscall (имя или номер); можно в одном правиле указывать сразу несколько syscall, каждый после своего ключа -S.
-F - задает фильтр по полям.
-k - имя правила.
В качестве примера, создадим правило для регистрации изменения файла passwd.
Для начала убедимся, что у нас не применено ни одно правило.
~]# auditctl -l
Если ранее уже были заданы какие‑то правила, то смело удаляем их командой:
~]# auditctl -D
Применим правило:
~]# auditctl -w /etc/passwd -p wa -k passwd
Проверим, что правило активно:
~]# auditctl -l -w /etc/passwd -p wa -k passwd
Проверим, как правило работает.
~]# useradd testuser
Убедимся, что по нашему правилу сгенерировалось событие.
~]# aureport --summary -k
Посмотрим эти события.
~]# ausearch -i -k passwd
Сформируем отчет
~]# aureport
Все возможные типы регистрируемых событий
~]# ausearch -m
Описание всех типов и полей логов
Аудит в Linux состоит из двух групп компонентов: в пространстве ядра это kauditd, а в пользовательском — auditd
Ядро, принимая системные вызовы из user space, пропускает их через фильтры user, task, filesystem , exclude и exit.
user используется для фильтрации событий
task применяется для системных вызовов fork() и clone().
filesystem используется для исключения событий для конкретной файловой системы.
exclude задает исключения для событий.
exit проходят все системные вызовы.
auditctl - мы можем управлять потоком событий.
ausearch, aureport, aulast просматривем журнал аудита.
Статус работы подсистемы
~]# auditctl -s
Отправьте текстовое сообщение
~]# auditctl -m hello
убедитесь
~]# ausearch -m USER
, что соответствующее событие попало в журнал аудита
Примеры правил находятся /usr/share/audit/sample-rules/.
Примеры типов правил:
Управляющие правила настраивают систему аудита и поведение агента.
Правила файловой системы. Формат правила следующий:
-w path-to-file -p permissions -k keyname
-w указывает на то, что это правило файловой системы.
-p может содержать любые комбинации прав доступа r (чтение), w (запись), x (выполнение) и a (изменение атрибута).
-k задает имя правила.
Правила системных вызовов используются для мониторинга системных вызовов.
-a action,list -S syscall -F field=value -k keyname
-a означает append (добавление) правила в фильтр.
action может быть always (всегда создавать события) или never (никогда не создавать события).
list содержит один из возможных вариантов: task, exit, user, filesystem или exclude.
-S - указывает конкретный syscall (имя или номер); можно в одном правиле указывать сразу несколько syscall, каждый после своего ключа -S.
-F - задает фильтр по полям.
-k - имя правила.
В качестве примера, создадим правило для регистрации изменения файла passwd.
Для начала убедимся, что у нас не применено ни одно правило.
~]# auditctl -l
Если ранее уже были заданы какие‑то правила, то смело удаляем их командой:
~]# auditctl -D
Применим правило:
~]# auditctl -w /etc/passwd -p wa -k passwd
Проверим, что правило активно:
~]# auditctl -l -w /etc/passwd -p wa -k passwd
Проверим, как правило работает.
~]# useradd testuser
Убедимся, что по нашему правилу сгенерировалось событие.
~]# aureport --summary -k
Посмотрим эти события.
~]# ausearch -i -k passwd
Сформируем отчет
~]# aureport
Все возможные типы регистрируемых событий
~]# ausearch -m
Описание всех типов и полей логов
Red Hat Customer Portal
RHEL Audit System Reference - Red Hat Customer Portal
The Audit System Reference provides lists of supported Audit event fields and record types in RHEL 7 and RHEL 8.
Воплощение желаний, повышение прав для редактирования файлов
Не однократно Вы могли сталкиваться с просьбой пользователей делегировать без полномочному пользователю права в /etc/sudoers на выполнение команды редактирования.
Вы естественно редактируете файл sudoers
[root@worked ~]# visudo
и прописываете
test ALL=(ALL) NOPASSWD: /usr/bin/vi
Выполним авторизацию под пользователем test:
[root@worked ~]# su test
выполним одну, весьма простую команду
[test@worked root]$ sudo vi -c ':!/bin/sh' /dev/null
sh-5.1#
что произошло?
sh-5.1# id
uid=0(root) gid=0(root) группы=0(root) контекст=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
sh-5.1#
❓❓Я стал root??
Попробуем сменить hostname
sh-5.1# hostnamectl set-hostname xak
sh-5.1#
Выполнилось? А ну, давайте зайдем повторно на сервер (см фото)!!
❗️❗️❗️Поздравляю, Ваша система стала уязвима и пользователь может воплощать свое ХОЧУ!
⚠️Будьте бдительны при воплощении желаний пользователей.
Не однократно Вы могли сталкиваться с просьбой пользователей делегировать без полномочному пользователю права в /etc/sudoers на выполнение команды редактирования.
Вы естественно редактируете файл sudoers
[root@worked ~]# visudo
и прописываете
test ALL=(ALL) NOPASSWD: /usr/bin/vi
Выполним авторизацию под пользователем test:
[root@worked ~]# su test
выполним одну, весьма простую команду
[test@worked root]$ sudo vi -c ':!/bin/sh' /dev/null
sh-5.1#
что произошло?
sh-5.1# id
uid=0(root) gid=0(root) группы=0(root) контекст=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
sh-5.1#
❓❓Я стал root??
Попробуем сменить hostname
sh-5.1# hostnamectl set-hostname xak
sh-5.1#
Выполнилось? А ну, давайте зайдем повторно на сервер (см фото)!!
❗️❗️❗️Поздравляю, Ваша система стала уязвима и пользователь может воплощать свое ХОЧУ!
⚠️Будьте бдительны при воплощении желаний пользователей.
Восстановления файлов в Linux
Многие ошибочно думают, что grep ищет только по содержимому файла. Да же по определению, grep-это утилита командной строки для поиска в текстовых наборах данных строк, соответствующих регулярному выражению. Но это не так)
Утилита способна проводить поиск по всей поверхности диска, есть там файлы или нет. Нужно только знать хотя бы небольшой фрагмент содержимого.
~]# grep --binary-files=text --context=x 'fragment_content' /dev/partition > outFile.txt
Эта команда ищет в разделе /dev/partition строку fragment_content и сохраняет x строк после искомой в текстовый файл outFile.txt. Если указать достаточно большое x и если повезёт, то можно захватить большой кусок файла или весь файл целиком. Ключевым здесь является --binary-files=text, который даёт команду искать среди бинарных данных на диске.
Тем же способом можно извлечь определённую информацию со старых, чужих, выброшенных жёстких дисков.
Желаю удачи!!
Многие ошибочно думают, что grep ищет только по содержимому файла. Да же по определению, grep-это утилита командной строки для поиска в текстовых наборах данных строк, соответствующих регулярному выражению. Но это не так)
Утилита способна проводить поиск по всей поверхности диска, есть там файлы или нет. Нужно только знать хотя бы небольшой фрагмент содержимого.
~]# grep --binary-files=text --context=x 'fragment_content' /dev/partition > outFile.txt
Эта команда ищет в разделе /dev/partition строку fragment_content и сохраняет x строк после искомой в текстовый файл outFile.txt. Если указать достаточно большое x и если повезёт, то можно захватить большой кусок файла или весь файл целиком. Ключевым здесь является --binary-files=text, который даёт команду искать среди бинарных данных на диске.
Тем же способом можно извлечь определённую информацию со старых, чужих, выброшенных жёстких дисков.
Желаю удачи!!
Уязвимость в ядре Linux. Выход из контейнеров Kubernetes.
Уязвимость в ядре Linux, имеющая идентификатор CVE-2022-0185, может использоваться для выхода из контейнеров Kubernetes. CVE-2022-0185 представляет собой переполнения буфера хипа в компоненте ядра File System Context. Уязвимость приводит к out-of-bounds записи, отказу в обслуживании, а в итоге и к выполнению произвольного кода.
В бюллетенях безопасности, отмечалось, что с помощью этого бага локальный пользователь может повысить свои привилегии в системе.
РЕШЕНИЕ:
Red Hat
На неконтейнеризированных развертываниях Red Hat Enterprise Linux 8 вы можете отключить пространства имен пользователей, установив user.max_user_namespaces на 0:
~]# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf ~]# sysctl -p /etc/sysctl.d/userns.conf
UBUNTU
~]# sysctl -w kernel.unprivileged_userns_clone=0
Уязвимость в ядре Linux, имеющая идентификатор CVE-2022-0185, может использоваться для выхода из контейнеров Kubernetes. CVE-2022-0185 представляет собой переполнения буфера хипа в компоненте ядра File System Context. Уязвимость приводит к out-of-bounds записи, отказу в обслуживании, а в итоге и к выполнению произвольного кода.
В бюллетенях безопасности, отмечалось, что с помощью этого бага локальный пользователь может повысить свои привилегии в системе.
РЕШЕНИЕ:
Red Hat
На неконтейнеризированных развертываниях Red Hat Enterprise Linux 8 вы можете отключить пространства имен пользователей, установив user.max_user_namespaces на 0:
~]# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf ~]# sysctl -p /etc/sysctl.d/userns.conf
UBUNTU
~]# sysctl -w kernel.unprivileged_userns_clone=0
Как исправить сломанные пакеты в Linux
Бывает, когда вы пытаетесь запустить какое-либо обновление или попытаться установить новый пакет в свои системы RHEL/CentOS, вы получаете ошибку сломанного пакета. Эта ошибка не позволяет вам продолжить обновление или установку, что приводит к блокировке.
Сломанные пакеты - когда некоторые из пакетов либо не были установлены должным образом, либо были частично установлены по какой-то неожиданной причине.
- Сначала вам нужно проверить все пакеты с информацией о файлах, взятых из метаданных пакета, хранящихся в базе данных rpm,
~]# rpm -Va
- Решение проблемы неработающего пакета - запустить обновление с опцией -b
~]# dnf upgrade -b
- Если вы знаете конкретный сломанный пакет, вы можете попробовать переустановить этот пакет
~]# dnf --refresh reinstall package_name
- Если вы столкнулись с какой-либо ошибкой сломанного пакета при запуске команды yum
~]# yum reinstall \*
Если yum не может восстановить, вы можете пропустить эти пакеты, используя опцию --skip-broken.
Бывает, когда вы пытаетесь запустить какое-либо обновление или попытаться установить новый пакет в свои системы RHEL/CentOS, вы получаете ошибку сломанного пакета. Эта ошибка не позволяет вам продолжить обновление или установку, что приводит к блокировке.
Сломанные пакеты - когда некоторые из пакетов либо не были установлены должным образом, либо были частично установлены по какой-то неожиданной причине.
- Сначала вам нужно проверить все пакеты с информацией о файлах, взятых из метаданных пакета, хранящихся в базе данных rpm,
~]# rpm -Va
- Решение проблемы неработающего пакета - запустить обновление с опцией -b
~]# dnf upgrade -b
- Если вы знаете конкретный сломанный пакет, вы можете попробовать переустановить этот пакет
~]# dnf --refresh reinstall package_name
- Если вы столкнулись с какой-либо ошибкой сломанного пакета при запуске команды yum
~]# yum reinstall \*
Если yum не может восстановить, вы можете пропустить эти пакеты, используя опцию --skip-broken.
Понимание lsof
lsof расшифровывается как “List Open Files”, это инструмент командной строки в Linux, который предоставляет подробный список всех открытых файлов в системе.
Основной синтаксис команды lsof прост
~]# lsof
По умолчанию lsof отобразит список всех открытых файлов для всех процессов, запущенных в системе.
Вывод отобразит:
идентификатор процесса (PID)
идентификатор потока (TID)
имя команды задачи (TASKCMD)
имя пользователя, выполняющего процесс (USER)
файловый дескриптор (FD)
тип файла (TYPE)
устройство (DEVICE)
размер (SIZE/OFF)
имя файла (NAME)
для каждого открытого файла.
Опции:
-c: позволяет отображать только открытые файлы для процессов
~]# lsof -c https
-u: позволяет отображать только открытые файлы для процессов, запущенных под определенным пользователем
~]# lsof -u root
-p: позволяет отображать только открытые файлы для определенного идентификатора процесса
~]# lsof -p 123
-i: позволяет отображать только открытые сетевые файлы
~]# lsof -i
-r: позволяет повторять отображение открытых файлов с заданным интервалом
~]# lsof -r 5
Ситуации когда можно использовать lsof для выявления проблемы:
- Использование дискового пространства
- Зависшие процессы
- Отладка сетевых проблем
- Устранение неполадок с блокировкой файлов
- Мониторинг активности системы
-Обнаружение не известных процессов
lsof расшифровывается как “List Open Files”, это инструмент командной строки в Linux, который предоставляет подробный список всех открытых файлов в системе.
Основной синтаксис команды lsof прост
~]# lsof
По умолчанию lsof отобразит список всех открытых файлов для всех процессов, запущенных в системе.
Вывод отобразит:
идентификатор процесса (PID)
идентификатор потока (TID)
имя команды задачи (TASKCMD)
имя пользователя, выполняющего процесс (USER)
файловый дескриптор (FD)
тип файла (TYPE)
устройство (DEVICE)
размер (SIZE/OFF)
имя файла (NAME)
для каждого открытого файла.
Опции:
-c: позволяет отображать только открытые файлы для процессов
~]# lsof -c https
-u: позволяет отображать только открытые файлы для процессов, запущенных под определенным пользователем
~]# lsof -u root
-p: позволяет отображать только открытые файлы для определенного идентификатора процесса
~]# lsof -p 123
-i: позволяет отображать только открытые сетевые файлы
~]# lsof -i
-r: позволяет повторять отображение открытых файлов с заданным интервалом
~]# lsof -r 5
Ситуации когда можно использовать lsof для выявления проблемы:
- Использование дискового пространства
- Зависшие процессы
- Отладка сетевых проблем
- Устранение неполадок с блокировкой файлов
- Мониторинг активности системы
-Обнаружение не известных процессов
Команды командной строки Linux
Смена разрешения rwx на восьмеричный формат в Linux
~]# stat -c '%n %a' info_file
info_file 755
Безвозвратное удаление файла в Linux
~]# shred -zvu info_file
Проверка правописания слов в Linux
~]# look docum
Поиск описания ключевого слова на странице руководства
~]# man -k https
Список всех команд, встроенных в оболочку.
~]# help
Мгновенный переход в только что созданный каталог
~]# mkdir dir1 && cd $_
~]# mkdir dir1 && cd !$
Мгновенное выполнение нужного элемента истории
~]# !123
Переход в последнюю рабочую директорию
~]# cd -
Смена разрешения rwx на восьмеричный формат в Linux
~]# stat -c '%n %a' info_file
info_file 755
Безвозвратное удаление файла в Linux
~]# shred -zvu info_file
Проверка правописания слов в Linux
~]# look docum
Поиск описания ключевого слова на странице руководства
~]# man -k https
Список всех команд, встроенных в оболочку.
~]# help
Мгновенный переход в только что созданный каталог
~]# mkdir dir1 && cd $_
~]# mkdir dir1 && cd !$
Мгновенное выполнение нужного элемента истории
~]# !123
Переход в последнюю рабочую директорию
~]# cd -
Ключи сервера
Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да - ключ сохраняется в файл ~/.ssh/known_hosts.
Если ключ сервера изменился, то при попытке соединения SSH/PUTTY информирует о подделке ключа «ВНИМАНИЕ-ПОТЕНЦИАЛЬНАЯ БРЕШЬ В БЕЗОПАСНОСТИ»
Обратите внимание, если сервер не трогали, а ssh информирует, значит вы не на тот сервер выполняете авторизацию (например, в сети появился ещё один компьютер с тем же IP) или кто то изменил ключ.
Удалить известный ключ сервера
~]# ssh-keygen -R server
Удалить ещё и ключ IP
~]# ssh-keygen -R 127.0.0.1
Ключ сервера хранится
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
Если вы ВМ клонируете, то ssh-ключи сервера нужно обязательно перегенерировать
Удалить склонированные;
~]$ rm -fr /etc/ssh/ssh_host_*
Перезапустить службу
~]# systemctl restart sshd
Новый ключи сформируются в /etc/ssh/
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key.pub
ssh_host_rsa_key
Если выше перечисленные *.pub не сформировались автоматически, после перезапуска службы или службу нельзя перезапускать, то их можно сформировать вручную
~]# ssh-keygen -f /etc/ssh/ssh_host_ed25519_key -N '' -t ed25519
~]# ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -N '' -t ecdsa
Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да - ключ сохраняется в файл ~/.ssh/known_hosts.
Если ключ сервера изменился, то при попытке соединения SSH/PUTTY информирует о подделке ключа «ВНИМАНИЕ-ПОТЕНЦИАЛЬНАЯ БРЕШЬ В БЕЗОПАСНОСТИ»
Обратите внимание, если сервер не трогали, а ssh информирует, значит вы не на тот сервер выполняете авторизацию (например, в сети появился ещё один компьютер с тем же IP) или кто то изменил ключ.
Удалить известный ключ сервера
~]# ssh-keygen -R server
Удалить ещё и ключ IP
~]# ssh-keygen -R 127.0.0.1
Ключ сервера хранится
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
Если вы ВМ клонируете, то ssh-ключи сервера нужно обязательно перегенерировать
Удалить склонированные;
~]$ rm -fr /etc/ssh/ssh_host_*
Перезапустить службу
~]# systemctl restart sshd
Новый ключи сформируются в /etc/ssh/
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key.pub
ssh_host_rsa_key
Если выше перечисленные *.pub не сформировались автоматически, после перезапуска службы или службу нельзя перезапускать, то их можно сформировать вручную
~]# ssh-keygen -f /etc/ssh/ssh_host_ed25519_key -N '' -t ed25519
~]# ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -N '' -t ecdsa
Боремся с Out of Memory
Out of Memory Killer (OOM Killer) – это механизм ядра Linux, который освобождает оперативную память при ее исчерпании за счет принудительного завершения некоторых запущенных процессов. Если процесс убивается OOM Killer, в логе /var/log/messages регистрируется событие:
~]# cat /var/log/messages | grep "Out of»
Out of Memory: Killed process 123 (name_service) score 904 or sacrifice child
OOM killer убивает процессы сигналом SIGKILL. Чтобы завершить процесс, Linux вызывает функцию out_of_memory и выбирает процесс по правилам, основанным на вычисленной репутацим каждого процесса (oom_score).
Проверить репутацию процесса
~]# cat /proc/123/oom_score
Чем выше репутация процесса, тем больше вероятность того, что именно его завершит OOM Killer.
Когда мы стали понимать принцип работы функции, нам предстоит выставить приоритеты и обеспечить стабильность работы приложения.
Мы можете отключить OOM Killer, но это станет фатальной ошибкой:
~]# cat /proc/sys/vm/panic_on_oom
По умолчанию тут указан 0 - OOM Killer включен
Чтобы отключить его:
~]# sudo echo 1 > /proc/sys/vm/panic_on_oom
Для обеспечения гарантии стабильности работы определенного процесса и уверенности, что данный процесс никогда не будет принудительно завершен, достаточно будет увеличить его репутацию.
Вывести текущую репутацию процесса:
~]# cat /proc/123/oom_score
Репутация процесса имеет значение от -16 до +15, назначим репутацию:
~]# echo -5 > /proc/123/oom_adj
~]# cat /proc/1764/oom_score
Для полного отключения OOM Killer процесса, нужно указать в oom_adj значение -17
Осталось разобраться с основной задачей, что будет если процесс перезапустить и ему привиться новый PID
~]# pgrep -f "/usr/sbin/sshd" | while read PID; do echo -17 > /proc/$PID/oom_adj; done
Но гораздо удобнее задать репутацию в файле сервиса юнита службы systemd:
[Service]
OOMScoreAdjust=-500
Out of Memory Killer (OOM Killer) – это механизм ядра Linux, который освобождает оперативную память при ее исчерпании за счет принудительного завершения некоторых запущенных процессов. Если процесс убивается OOM Killer, в логе /var/log/messages регистрируется событие:
~]# cat /var/log/messages | grep "Out of»
Out of Memory: Killed process 123 (name_service) score 904 or sacrifice child
OOM killer убивает процессы сигналом SIGKILL. Чтобы завершить процесс, Linux вызывает функцию out_of_memory и выбирает процесс по правилам, основанным на вычисленной репутацим каждого процесса (oom_score).
Проверить репутацию процесса
~]# cat /proc/123/oom_score
Чем выше репутация процесса, тем больше вероятность того, что именно его завершит OOM Killer.
Когда мы стали понимать принцип работы функции, нам предстоит выставить приоритеты и обеспечить стабильность работы приложения.
Мы можете отключить OOM Killer, но это станет фатальной ошибкой:
~]# cat /proc/sys/vm/panic_on_oom
По умолчанию тут указан 0 - OOM Killer включен
Чтобы отключить его:
~]# sudo echo 1 > /proc/sys/vm/panic_on_oom
Для обеспечения гарантии стабильности работы определенного процесса и уверенности, что данный процесс никогда не будет принудительно завершен, достаточно будет увеличить его репутацию.
Вывести текущую репутацию процесса:
~]# cat /proc/123/oom_score
Репутация процесса имеет значение от -16 до +15, назначим репутацию:
~]# echo -5 > /proc/123/oom_adj
~]# cat /proc/1764/oom_score
Для полного отключения OOM Killer процесса, нужно указать в oom_adj значение -17
Осталось разобраться с основной задачей, что будет если процесс перезапустить и ему привиться новый PID
~]# pgrep -f "/usr/sbin/sshd" | while read PID; do echo -17 > /proc/$PID/oom_adj; done
Но гораздо удобнее задать репутацию в файле сервиса юнита службы systemd:
[Service]
OOMScoreAdjust=-500
Создаем отказоустойчивый сервис в systemd.
Регулярно сталкиваемся с тем что, сервис падает и мы не успеваем его своевременно поднять. Я против костылей, но описанное ниже решение использует функционал systemd, главное правильно настроить)
Условно, предположим:
Имя сервиса: name_service
Местоположение: /lib/systemd/system/
Выполним редактирование сервиса:
~]# vi /lib/systemd/system/name_service
или
~]# systemctl edit name_service
Наверняка Вы увидите стандартные секции настроек сервиса
[Unit]
…
[Service]
…
[Install]
…
Чтобы сервис перезапустился автоматически, нужно в секцию Unit добавить следующий строки:
StartLimitIntervalSec=500
StartLimitBurst=5
А в секцию Service добавить:
Restart=on-failure
RestartSec=5s
После добавления нужно systemd перечитать конфиги:
~]# systemctl daemon-reload
После применения данных настроек, если сервис вдруг остановится по незапланированным причинам, в течение 5 секунд он будет перезапущен. Попыток рестарта сервиса будет 5 в течение 500 секунд и если все эти попытки закончатся неудачей, дальнейших попыток перезапуска не будет.
Регулярно сталкиваемся с тем что, сервис падает и мы не успеваем его своевременно поднять. Я против костылей, но описанное ниже решение использует функционал systemd, главное правильно настроить)
Условно, предположим:
Имя сервиса: name_service
Местоположение: /lib/systemd/system/
Выполним редактирование сервиса:
~]# vi /lib/systemd/system/name_service
или
~]# systemctl edit name_service
Наверняка Вы увидите стандартные секции настроек сервиса
[Unit]
…
[Service]
…
[Install]
…
Чтобы сервис перезапустился автоматически, нужно в секцию Unit добавить следующий строки:
StartLimitIntervalSec=500
StartLimitBurst=5
А в секцию Service добавить:
Restart=on-failure
RestartSec=5s
После добавления нужно systemd перечитать конфиги:
~]# systemctl daemon-reload
После применения данных настроек, если сервис вдруг остановится по незапланированным причинам, в течение 5 секунд он будет перезапущен. Попыток рестарта сервиса будет 5 в течение 500 секунд и если все эти попытки закончатся неудачей, дальнейших попыток перезапуска не будет.
‼️DANGER. Знать но не использовать
Самая веселая, но печально известная команда:
❗️~]# rm -rf /
В новых дистрибутивах команда не нанесет как такового вреда, поскольку как они предоставляют отказоустойчивость. Но если Вы хотите достичь успеха, то:
❗️~]# rm -rf / --no-preserve-root
или
❗️~]# rm -fr/*
Перезапишите свой раздел
❗️~]# echo “DANGER” > /dev/sda
Переместим в никуда
❗️~]# mv /etc/* /dev/null
Уничтожим улики мусором
❗️~]# dd if=/dev/random of=/dev/sda
А теперь применим бомбу
‼️~]# :(){:|:&};:
❗️Не забудьте, что есть и маскированные команды
Самая веселая, но печально известная команда:
❗️~]# rm -rf /
В новых дистрибутивах команда не нанесет как такового вреда, поскольку как они предоставляют отказоустойчивость. Но если Вы хотите достичь успеха, то:
❗️~]# rm -rf / --no-preserve-root
или
❗️~]# rm -fr/*
Перезапишите свой раздел
❗️~]# echo “DANGER” > /dev/sda
Переместим в никуда
❗️~]# mv /etc/* /dev/null
Уничтожим улики мусором
❗️~]# dd if=/dev/random of=/dev/sda
А теперь применим бомбу
‼️~]# :(){:|:&};:
❗️Не забудьте, что есть и маскированные команды