Защита от "самого себя": Как обезопасить критичные конфиги в Linux

Проблема: Один rm -rf по ошибке. Одна неудачная правка nginx.conf в 3 часа ночи. И prod лежит. "Админ" надеется на бэкапы (восстановление). "Архитектор" предотвращает саму возможность ошибки.

Вот 3 уровня эшелонированной обороны для ваших самых важных файлов (конфигов, скриптов, сертификатов).

Уровень 1: "Бетонный бункер" (chattr)
Это — ваш immutable (неизменяемый) флаг. Самая сильная защита, даже от root.

⏺ Как включить: sudo chattr +i /etc/nginx/nginx.conf

Теперь этот файл нельзя удалить, изменить, переименовать или даже создать на него ссылку. Совсем.

⏺ Как выключить (для плановых правок): sudo chattr -i /etc/nginx/nginx.conf

#АрхитекторскийЛайфхак: Сделали правки -> немедленно включили защиту обратно! Это лучшая защита от случайного rm или sed -i.

Уровень 2: "Гибкий контроль" (ACL)
Стандартных rwx (владелец/группа/остальные) часто не хватает. ACL (Access Control Lists) дают гранулярный доступ.

Задача: Дать юзеру deploy право только читать конфиг, но не менять.

⏺ Назначаем права: sudo setfacl -m u:deploy:r /etc/nginx/nginx.conf

⏺ Проверяем права: getfacl /etc/nginx/nginx.conf

Это намного чище, чем добавлять deploy в группу root (чего делать нельзя никогда).

Уровень 3: "Умный Sudo" (sudoers)
Никогда не давайте сервисным юзерам и коллегам ALL=(ALL) ALL. Это "ключи от королевства". Давайте только то, что нужно.

Задача: Дать deploy право только перезапускать Nginx, но не редактировать или удалять его файлы.

⏺ Редактируем visudo: deploy ALL=(root) NOPASSWD: /bin/systemctl restart nginx

Теперь deploy может выполнить sudo systemctl restart nginx, но sudo rm /etc/nginx/nginx.conf ему "откажет в доступе".

Итог: sudoers защищает от эскалации привилегий. ACL защищает от случайных правок другими пользователями. chattr защищает от root-ошибок (включая вас самих в 3 часа ночи).

#linux #security #sysadmin #chattr #acl #sudo #bestpractice

🔒 Linux: Как защитить файл от rm -rf (Даже от Root)

Вы думаете, что пользователь root может всё? Ошибаетесь. Есть уровень файловой системы, где права rwx (777) не имеют значения. Это атрибуты ext4/xfs.

Если вы хотите защитить критический конфиг (например, /etc/resolv.conf, который вечно перезаписывается NetworkManager-ом) или логи от хакера — используйте Immutable bit.

1. Делаем файл бессмертным:

sudo chattr +i /etc/critical_config.conf

Теперь попробуйте rm, mv или echo "test" > .... Вы получите: Operation not permitted. Даже под sudo. Даже под root.

2. Как проверить, почему файл не удаляется: Если ls -l показывает, что права есть, а удалить нельзя — смотрите атрибуты:

lsattr /etc/critical_config.conf
# Вывод: ----i---------e---- /etc/critical_config.conf

Видите букву i? Это оно.

3. Как вернуть всё назад:

sudo chattr -i /etc/critical_config.conf

Где применять: Защита скриптов автозагрузки, критических конфигов и бинарников от изменения вирусами-шифровальщиками.

#linux #security #chattr #filesystem #hacks #root

🐧 Linux: Броня для конфигов — делаем файлы бессмертными через `chattr` 🛡

Знакомая боль: ты кропотливо прописал свои DNS в `/etc/resolv.conf`, а после ребута `NetworkManager` или `systemd-resolved` радостно всё затер и вернул дефолт. Или у тебя есть критически важный баш-скрипт, который стажер может случайно удалить командой `rm -rf`.

В Linux есть магия, которая делает файл неизменяемым. Вообще. Даже для пользователя `root`.

Как повесить «броню»:
Используем утилиту chattr (change attribute) с флагом +i (immutable).

# Делаем файл полностью неизменяемым (нельзя удалить, переименовать, записать)
sudo chattr +i /etc/resolv.conf

# Проверяем, повесился ли атрибут (будет буква 'i' в выводе)
lsattr /etc/resolv.conf

Как снять, когда нужно обновить конфиг:

sudo chattr -i /etc/resolv.conf

Это ультимативная защита от «умных» демонов, которые любят переписывать системные файлы без спроса, и отличный слой защиты от вирусов-шифровальщиков на бэкап-серверах.

#linux #chattr #security #hardening #sysadmin #troubleshooting #admin_future