Эта тема собирает вместе ежедневные обязанности администратора, которые держат систему в безопасном состоянии. Вы научитесь находить файлы с опасными правами SUID/SGID, грамотно раздавать административные полномочия через sudo вместо раздачи пароля root, ограничивать аппетиты пользователей лимитами, а главное - видеть, кто реально сейчас в системе, какие порты открыты и какие процессы за ними стоят. Это не разовая настройка, а навык регулярного аудита.
Как это работает
Биты SUID и SGID - это механизм повышения прав на время запуска программы. Когда на исполняемом файле стоит SUID, процесс выполняется с правами ВЛАДЕЛЬЦА файла, а не того, кто его запустил. Классический пример - passwd: обычный пользователь меняет свой пароль, но запись идёт в /etc/shadow, владелец которого root. SGID работает так же, но для группы. Опасность в том, что любая уязвимость в SUID-root программе превращается в полный захват системы, поэтому таких файлов должно быть как можно меньше, и их список надо знать наизусть.
sudo решает другую задачу: дать пользователю конкретные права root без выдачи пароля root. Логика описана в /etc/sudoers, который НИКОГДА не редактируют напрямую - только через visudo. Эта обёртка проверяет синтаксис перед сохранением, иначе одна опечатка заблокирует sudo для всех. Команда su - это переключение на другого пользователя целиком (нужен его пароль), su - root даёт полноценную root-сессию с её окружением. sudo точнее: каждое действие логируется в journald и отдельно в /var/log/auth.log (Debian) или /var/log/secure (RHEL).
Лимиты ограничивают ресурсы одного пользователя или сессии: число открытых файлов, процессов, размер core-дампа, объём памяти. Команда ulimit меняет лимиты текущей оболочки (мягкий лимит можно поднимать до жёсткого потолка), а постоянные правила задаются в /etc/security/limits.conf через PAM-модуль pam_limits. В мире systemd те же ограничения для сервисов задаются директивами LimitNOFILE и подобными в unit-файлах - это важно помнить в 2026.
Наконец, аудит присутствия и сети. Кто залогинен прямо сейчас показывают who и w. История входов лежит в бинарных журналах: last читает /var/log/wtmp (успешные входы), lastb читает /var/log/btmp (НЕудачные попытки - первый признак перебора пароля). Открытые сокеты смотрят через ss, а кто именно держит файл или порт - через lsof и fuser.
Команды и примеры
Поиск SUID/SGID файлов по всей системе:
Код: Выделить всё
# SUID (бит 4000) и SGID (бит 2000) одной командой
find / -type f -perm /6000 -exec ls -l {} \; 2>/dev/null
# Только SUID
find / -perm -4000 -type f 2>/dev/null
# Только SGID
find / -perm -2000 -type f 2>/dev/null
Правка sudoers и проверка прав:
Код: Выделить всё
visudo # правка основного файла
visudo -f /etc/sudoers.d/devops # отдельный файл (правильный способ)
# Пример строки: пользователю anna только systemctl без пароля
anna ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
sudo -l # показать, что мне разрешено
sudo -u www-data id # выполнить от другого пользователя
Код: Выделить всё
ulimit -a # все текущие лимиты
ulimit -n # мягкий лимит на открытые файлы
ulimit -Hn # жёсткий (Hard) потолок
ulimit -n 8192 # поднять в текущей сессии
# Постоянно в /etc/security/limits.conf:
# user type item value
@dev soft nofile 4096
@dev hard nofile 8192
* hard nproc 2048
Код: Выделить всё
who # кто залогинен (терминал, время, источник)
w # то же + что выполняет + load average
last # успешные входы из wtmp
last -n 10 anna # последние 10 входов пользователя anna
lastb # НЕудачные попытки (нужен root)
last reboot # история перезагрузок
Код: Выделить всё
ss -tulpn # TCP/UDP слушающие сокеты с процессами
ss -tan state established # активные TCP-соединения
lsof -i :443 # кто держит порт 443
lsof -u anna # все открытые файлы пользователя anna
lsof /var/log/syslog # кто держит конкретный файл
fuser -v 8080/tcp # процесс на порту 8080
fuser -k /mnt/usb # убить процессы, мешающие размонтировать
Код: Выделить всё
nmap -sT localhost # TCP connect скан
nmap -sV -p 1-1024 192.168.1.10 # с определением версий служб
Частые грабли
- Редактирование /etc/sudoers напрямую в обычном редакторе. Опечатка ломает sudo целиком, и без второго root-доступа систему уже не починить. Только visudo.
- netstat больше нет по умолчанию в современных дистрибутивах - привыкайте к ss. Если очень надо, netstat живёт в пакете net-tools.
- ulimit меняет лимит ТОЛЬКО текущей оболочки и её потомков. Поднять жёсткий лимит выше потолка может только root.
- Изменения в limits.conf применяются при НОВОМ входе через PAM, а не к уже запущенным сессиям и не к systemd-сервисам (для них - LimitNOFILE в unit).
- Запуск ss или lsof без sudo прячет процессы чужих пользователей - PID и имя программы будут пустыми.
- lastb по умолчанию пуст: файл /var/log/btmp создаётся не всегда, и читать его может только root.
- nmap по внешнему адресу чужой сети без разрешения - это уже не аудит, а потенциально незаконное сканирование.
- Найдите все SUID-файлы в системе и сравните список с эталонным набором (passwd, sudo, su, mount). Запишите, нет ли лишнего.
- Создайте файл /etc/sudoers.d/lab через visudo -f, разрешив тестовому пользователю выполнять только systemctl status nginx без пароля. Проверьте через sudo -l от его имени.
- В limits.conf задайте этому пользователю hard nofile 1024, перелогиньтесь под ним и убедитесь через ulimit -Hn.
- Запустите ss -tulpn и сопоставьте каждый слушающий порт с процессом. Найдите, кто держит порт 22.
- Сделайте несколько входов под неверным паролем, затем посмотрите их в lastb (от root).
- Через lsof -i найдите процесс, держащий сетевое соединение, и определите его PID и пользователя.
- Чем отличается поведение find -perm -4000 от find -perm /4000?
- Почему sudoers редактируют только через visudo и что именно проверяет эта команда?
- Какой журнал читает lastb и о какой угрозе сигнализируют записи в нём?
- В чём разница между мягким и жёстким лимитом ulimit и кто может поднять жёсткий?
- Какой командой увидеть, какой процесс и под каким пользователем слушает конкретный TCP-порт?
- Почему правка /etc/security/limits.conf не влияет на лимиты systemd-сервиса?
