🛡️ КАК НЕ ДОПУСТИТЬ ЭСКАЛАЦИЮ ПРИВИЛЕГИЙ LINUX // БЕЗОПАСНОСТЬ ROOT, SUDO, USERS

[D2]

О ЧЕМ РЕЧЬ​

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

Начнем с разграничения пользователей, предоставления каждому только необходимых возможностей, авторизацию с помощью обычной флешки, шифрования домашних каталогов пользователей, рассмотрим возможность полной блокировки root, строгой изоляции прав sudo, разберемся с патчами безопасности от Whonix и закончим отключением битов SUID/SGID.

Данная статья ориентирована на Debian Linux (и, соответственно, дистрибутивы на его основе), однако все приведенные примеры подходят практически для всех дистрибутивов Linux (за исключением главы о патчах Whonix). Не стеcняйcя задавать вопросы, если есть интерес или проблема, я постараюсь ответить, но лучше писать их в этой теме, а не в пм, чтобы другие могли видеть решение или ответ.

---

:zns3: ВВЕДЕНИЕ​

Эскалация или повышение привилегий это когда атакующие получают более высокие привилегии пользователя, к которому они смогли получить первоначальный доступ. Этот этап наступает после того, как атакующий получил доступ к учетной записи. Основная задача на этом этапе сохранить доступ и перемещаться по системе или сети, оставаясь незамеченным. Чтобы добиться такой свободы и не быть обнаруженным, атакующему необходимо провести эскалацию, используя ошибки, недостатки конфигурации, слабые места в приложениях или операционной системе. В результате этого атакующий может получить полный доступ к системе/сети, а также к подключенным дополнительным системам и устройствам.

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

---

СОЗДАНИЕ И РАЗГРАНИЧЕНИЕ ПОЛЬЗОВАТЕЛЕЙ​

В большинстве случаев заражение стандартной учетной записи считается катастрофическим, поскольку атакующий:

1. Имеет полный доступ ко всем файлам, доступным данному пользователю.
2. Может просматривать все клавиатурные вводы и перехватывать сеансы входа в систему.
3. Может выводить на экран ложную информацию.
4. Может выполнять вредоносные действия.

Если существует только одна учетная запись пользователя (не считая root) с привилегиями sudo, атакующий имеет огромную поверхность атаки, начиная от снифферов и заканчивая эксплойтами для установленного ПО. Однако если для разделения используется несколько пользователей или, что еще лучше, виртуальные машины, последствия могут быть не столь катастрофическими.

Обоснование такого строгого подхода, который неизбежно скажется на удобстве использования как домашних ПК, так и серверов:

• Без доступа sudo атакующим гораздо сложнее вырваться за пределы строго ограниченных прав пользователей или виртуальных машин.
• Зараженная ОС может привести к аппаратному заражению (т.е. даже переустановка ОС не поможет). Во многих случаях для атаки на оборудование требуется доступ root/sudo, например, для выполнения команды flash.
• Защита различных частей системы или информации, если пользователь заражен без sudo доступа, который предназначался для браузера, то атакующему будет сложнее получить доступ к пользователю, где хранится рабочая или личная информация.

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

Если проверить историю шелла, то в случае, если пользователи не разделены по задачам, и для администрирования системы использовался пользователь, который также предназначен для повседневной деятельности, соответственно находится в группе риска, можно обнаружить длинные команды, содержащие пароли. Linux собирает историю всех выполненных команд в файле ~/.bash_history.

Если домашний компьютер или сервер активно используется и его история не очищается, то велика вероятность найти в этом файле что-нибудь интересное. Если в системе присутствуют альтернативные оболочки типа Zsh или Fish, то у них тоже есть история. Их нужно либо автоматически очищать, например, с помощью задачи cron, либо строго разделить пользователей по задачам.

Bash: Скопировать в буфер обмена

cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_history

Рассмотрим примерное распределение пользователей для типичного домашнего ПК (подробнее об их правах в разделе sudo):

• ivan - повседневный стандартный пользователь, который обычно имеет доступ sudo, мы его заберем у него позже.
• unsafe - запускать что-то недоверенное, например, qtox =) (это просто для примера, для этого нужно использовать виртуальные машины или, желательно, дедик)
• person - в домашней директории, храниться личная информация, пароли и закладки браузера.
• work - для работы, где будут находиться файлы, закладки браузера, пароли и т.д., отделенные от остальной системы.
• devel - пользователь, который будет выполнять обновления, установку программного обеспечения, настройку и т.д.
• admin - будет иметь привилегии sudo для серьезного администрирования системы.

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

Создадим пользователя admin и предоставим ему привилегии sudo:

Bash: Скопировать в буфер обмена

sudo adduser admin
sudo adduser admin sudo

Затем переключимся на пользователя admin и отберем доступ к sudo у пользователя по умолчанию (в моем примере ivan):

Bash: Скопировать в буфер обмена
sudo delgroup ivan sudo

Можно создать пользователя с домашней папкой, расположение которой будет отличаться от стандартного (/home/user), теоретически это может защитить от некачественных вредоносных скриптов, настроенных на /home, но не защитит от продвинутого ПО или атакующих, также этот вариант интересен тем, что пользователя можно разместить на внешнем носителе:

Bash: Скопировать в буфер обмена
sudo adduser --home /var/work work

Если есть необходимость создания временной учетной записи, например для программиста, то можно установить срок действия ее функционирования, чтобы исключить вектор атаки бывших сотрудников. Для этого необходимо задать срок действия (не обязательно использовать все параметры, можно использовать только необходимые):

Bash: Скопировать в буфер обмена

sudo chage -M 60 -m 7 -W 7 user

# -M максимальный срок действия в днях
# -m минимальный срок действия в днях
# -W установка предупреждения в днях

Если есть необходимость иметь одинаковые файлы в домашних каталогах всех пользователей, например, конфигурационные файлы, то их можно добавить сюда: /etc/skel

Увеличим число раундов хеширования при хешировании паролей. Чем больше число раундов, тем больше времени потребуется для входа в систему (65536 раундов занимают 1 секунду даже на слабых компьютерах), но это значительно усложнит взлом хэшей паролей. Добавим в конец файла "/etc/pam.d/common-password":

Код: Скопировать в буфер обмена
rounds=65536

К сожалению, очень большой дырой является то, что любое графическое приложение, работающее на системе X11, может видеть, что набирает любой пользователь в любом другом приложении для любого пользователя, это также относится к приложениям, работающим в AppArmor. В Debian уже давно X11 работает без root, но чтобы изолировать графические приложения друг от друга, придётся использовать firejail.

Единственным адекватным решением является использование виртуализации или аналога X11, Wayland, который обеспечивает изоляцию графического интерфейса и поддерживается популярными DE, как Gnome, Kde, Sway (аналог i3wm). Существуют две альтернативы решения этой проблемы, такие как Xpra и Xephyr, но они плохо поддерживают повседневные функции, такие как буфер обмена и имеют проблемы с разрешением экрана.

По умолчанию любая учетная запись пользователя может попытаться использовать su для переключения на пользователя root или любую другую учетную запись. Чтобы избежать этого, можно ограничить использование su только пользователями из группы root/sudo. Добавим строку в файл "/etc/pam.d/su":

Код: Скопировать в буфер обмена
auth required pam_wheel.so

ОГРАНИЧЕНИЕ ДОСТУПА К СЛУЖБАМ С ПОМОЩЬЮ PAM ​

Ограничение привилегий с помощью PAM очень эффективный способ повысить безопасность сервисов и уменьшить поверхность атаки. Для этого необходимо изменить конфигурационные файлы PAM для конкретных сервисов, обычно расположенные в каталоге /etc/pam.d/ Воспользуемся модулем pam_listfile для создания списка разрешенных или запрещенных пользователей, обеспечивающего доступ к критическим сервисам только для определенных лиц.

Это очень важно для серверов, для удобства можно использовать группы:

Bash: Скопировать в буфер обмена

sudo groupadd -r ssh
sudo gpasswd -a user1 ssh
sudo echo 'AllowGroups ssh' >> /etc/ssh/sshd_config

Сначала создадим список контроля доступа, который представляет собой простой список разрешенных или запрещенных пользователей:

Bash: Скопировать в буфер обмена
echo -e "user1\nuser2" | sudo tee /etc/allowed_users

Добавим в начало файла /etc/pam.d/sshd следующую строку для настройки модуля "pam_listfile":

Код: Скопировать в буфер обмена
auth required pam_listfile.so item=user sense=allow file=/etc/allowed_users onerr=fail

Сохраним и закроем файл. Данная конфигурация гарантирует, что только пользователи, перечисленные в файле /etc/allowed_users, смогут получить доступ к службе sshd. Root доступ будет запрещен, если только пользователь root не будет явно добавлен в список разрешенных пользователей.

Это открывает огромные возможности для настройки, например, чтобы ограничить доступ пользователя к ssh по дням недели, добавим строку в "/etc/pam.d/ssh":

Код: Скопировать в буфер обмена
account required pam_time.so

А затем добавим запрет в файл "/etc/security/time.conf" (где Wd это день недели):

Код: Скопировать в буфер обмена
sshd ; *; user ; Wd

АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ С ПОМОЩЬЮ ФЛЕШКИ​

⚠️ Предупреждение.
Для выполнения этого действия требуется пакет, загруженный с Github, что может быть опасно. Перед запуском любого программного обеспечения из подобных источников стоит проводить аудит кода.​

Безопасность учетной записи можно сильно увеличить с помощью аппаратного токена, который обычно используется в качестве дополнения к физической аутентификации при загрузке, входе в систему и расшифровке диска. Он также обладает некоторыми интересными возможностями как смарт карта OpenPGP. Из известных это Yubikey, Libremkey и Nitrokey, которые будет сложно доставить на территорию СНГ, из отечественных аналогов Рутокен (который прошел сертификацию ФСБ =) ), Aladdin и eSmart, JaCarta, которые не вызывают доверия.

В нашем случае мы рассматриваем только авторизацию в учетной записи, поэтому подойдет pam_usb, это PAM модуль, обеспечивающий аппаратную аутентификацию в Linux с помощью обычных USB флешек, SD карт, MMC, хоть SSD/HDD. С его помощью мы можем войти в систему без пароля, просто подключив флешку или карту памяти к компьютеру. Такая аутентификация также работает с терминальными командами, требующими sudo, идеально подходит для учетной записи администратора, которая выполняет системные действия и не будет доступна без вставленной флэшки. Pam_usb работает с любым приложением, поддерживающим PAM, с менеджерами входа (GDM, Lightdm и др.) и su/sudo.

Для аутентификации используется серийный номер флешки/карты памяти/диска, модель и производитель, а также опционально OTP - one time pads. Когда OTP включен (по умолчанию он включен, но его можно отключить), общедоступный файл пользовательского блокнота хранится на накопителе в скрытой папке с именем ".pamusb", а закрытый ключ в скрытой папке с тем же именем, которая хранится в домашнем каталоге пользователя.

Разработчик упаковал его для последней версии Debian (и других на базе Debian или Ubuntu), его можно Скачать