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

[IvanVasilyevich]

О ЧЕМ РЕЧЬ​

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

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

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

---

ВВЕДЕНИЕ​

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

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

---

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

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

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

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

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

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

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

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

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

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:

sudo adduser admin
sudo adduser admin sudo

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

sudo delgroup ivan sudo

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

sudo adduser --home /var/work work

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

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 для создания списка разрешенных или запрещенных пользователей, обеспечивающего доступ к критическим сервисам только для определенных лиц.

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

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

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

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), его можно скачать с этого сайта, нам нужен только пакет libpam-usb оттуда. Для Arch/Manjaro доступен PKGBUILD.

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

sudo apt install gir1.2-udisks-2.0

После загрузки установим его с помощью команды:

sudo dpkg -i libpam-usb_версия_amd64.deb

Настроить pam_usb можно следующим образом. Подключим флешку или карту памяти и выполним следующую команду (где название "myusb" может быть любым) для добавления нового устройства в качестве метода аутентификации, после чего должно быть предложено выбрать устройство:

sudo pamusb-conf --add-device myusb

Please select the device you wish to add.
* Using "Verbatim STORE N GO (Verbatim_STORE_N_GO_07A10D0894492625-0:0)" (only option)
Which volume would you like to use for storing data ?
0) /dev/sdb2 (UUID: A842-0654)
1) /dev/sdb1 (UUID: CAAF-0882)
[0-1]: 0
Name            : myusb
Vendor          : Verbatim
Model           : STORE N GO
Serial          : Verbatim_STORE_N_GO_07A10D0894492625-0:0
UUID            : A842-0654
Save to /etc/pamusb.conf ?
[Y/n] Y
Done.

Затем необходимо добавить пользователя в конфигурацию pam_usb (где admin имя учетной записи):

sudo pamusb-conf --add-user admin

Which device would you like to use for authentication ?
* Using "myusb" (only option)
User            : admin
Device          : myusb
Save to /etc/security/pam_usb.conf ?
[Y/n] Y
Done.

В любой момент можно запустить pamusb-check, чтобы убедиться, что все работает правильно. Этот инструмент имитирует запрос на аутентификацию (требуется подключение накопителя).

sudo pamusb-check admin

* Authentication request for user "admin" (pamusb-check)
* Device "myusb" is connected (good).
* Performing one time pad verification...
* Verification match, updating one time pads...
* Access granted.

На данном этапе мы определили устройство, которое будет использоваться в качестве аутентификатора для пользователя admin. Однако общесистемная библиотека PAM не знает о pam_usb. Чтобы добавить pam_usb в процесс системной аутентификации, необходимо отредактировать файл /etc/pam.d/common-auth (в Fedora этот файл может называться /etc/pam/system-auth) и добавить в него строку:

auth sufficient pam_usb.so

Где sufficient означает, что если pam_usb разрешает аутентификацию, то пароль запрашиваться не будет. В случае неудачи аутентификации в качестве запасного варианта будет использоваться аутентификация на основе пароля. Проверим:

su admin

* pam_usb
* Authentication request for user "admin" (su)
* Device "myusb" is connected (good).
* Performing one time pad verification...
* Regenerating new pads...
* Access granted.

Опционально можно настроить pam_usb на блокировку экрана при извлечении флешки и разблокировке при ее подключении, инструкцию можно найти здесь.

ШИФРОВАНИЕ ДОМАШНИХ КАТАЛОГОВ ПОЛЬЗОВАТЕЛЕЙ​

Интересным решением также может стать шифрование домашних каталогов пользователя (/home/user), это дополнительная защита каталога конкретного пользователя от других, после ограничения доступа.

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

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

Сначала установим утилиты шифрования:

sudo apt install ecryptfs-utils cryptsetup

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

Выполним следующую команду для шифрования домашнего каталога ivan:

sudo ecryptfs-migrate-home -u ivan

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

1) Вы должны немедленно войти в систему под другой учетной записью пользователя до перезагрузки!
2) Была сделана копия исходного домашнего каталога. Вы можете восстановить каталог резервной копии, если потеряете доступ к своим файлам.
3) Вы должны сгенерировать и записать фразу восстановления.
4) Вы также должны зашифровать раздел подкачки.

Обязательно нужно выйти и снова войти в зашифрованную учетную запись, это необходимо делать для каждого зашифрованного пользователя. После входа в систему должно появиться окно, в котором необходимо нажать кнопку "Run this action now" для создания парольной фразы восстановления. Она необходима на случай, если пароль учетной записи будет забыт. Эту фразу можно будет в любой момент посмотреть командой (войдя в систему под нужным пользователем):

ecryptfs-unwrap-passphrase

Раздел подкачки также может быть зашифрован, это полезно для того, чтобы важные данные в разделе подкачки не хранились в открытом виде на диске (однако зашифрованный раздел подкачки может плохо работать в спящем режиме):

sudo ecryptfs-setup-swap

После проверки можно скопировать или удалить резервную копию, которая будет создана в /home, она будет состоять из имени пользователя и случайной комбинации символов:

sudo rm -rf /home/ivan.7VfGt7OZ

Если данные домашнего каталога были слишком критичны, их можно затереть с помощью команды shred, чтобы избежать восстановления:

sudo shred -vzuf -n5 /home/user.7VfGt7OZ[/SIZE][/SIZE][/SIZE][/SIZE]
 
[SIZE=5][SIZE=5][SIZE=5][SIZE=5]# -v дает подробный вывод
# -z заменяет последний проход нулями, чтобы скрыть факт уничтожения
# -u удаляет файл после уничтожения
# -f получает права на запись, если они отсутствуют
# -n изменяет количество проходов

Если нет желания шифровать всего пользователя, то можно создать зашифрованную папку в каталоге пользователя, используя функцию private. При этом будут созданы каталоги ~/.Private и ~/Private, в которых будут храниться зашифрованные и расшифрованные файлы. При входе в систему будет запущен PAM модуль pam_ecryptfs.so, который расшифрует и смонтирует первый каталог во второй. После размонтирования каталог ~/Private будет пуст, а ~/.Private будет содержать файлы.

ecryptfs-setup-private

СИСТЕМЫ MAC: APPARMOR И SELINUX​

Не всем пользователям необходим доступ ко всем системным ресурсам и возможностям, таким как запись, чтение и выполнение доступа к объектам файловой системы. AppArmor представляет собой модули безопасности, через систему MAC. Это важно, поскольку, например, браузер не должен иметь возможности доступа ко всему домашнему каталогу пользователя. Наиболее часто используемыми системами MAC являются SELinux и AppArmor. SELinux гораздо безопаснее AppArmor, поскольку его настройки более детальны, но он очень сложен в изучении и настройке, поэтому выбор, скорее всего, будет сделан в пользу AppArmor.

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

---

ROOT​

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

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

Поскольку в большинстве случаев учетная запись root не используется и достаточно sudo, рациональным решением будет ее полное отключение. Перед отключением root очень важно иметь альтернативную учетную запись с возможностью выполнения команд sudo, которую мы создали ранее.

Полностью ограничить права root не так просто, как кажется, начнем с блокировки пароля. Как только это будет сделано, будет нельзя войти в учетную запись root со старым паролем (чтобы разблокировать нужно просто ввести sudo passwd root и задать пароль):

sudo usermod -L root

По сути, описанный выше метод меняет пароль на случайный, но при этом сохраняет опасность получения пароля с помощью хэша, поэтому во втором способе изменим оболочку root на nologin вместо bash. Это приведет к тому, что при попытке войти в учетную запись root, даже с правильным паролем, она будет автоматически выходить из оболочки (чтобы вернуть обратно, нужно сменить облочку обратно на /usr/bin/bash):

sudo usermod -s /usr/sbin/nologin root

Очень важно, что следующие два примера ниже также ограничат доступ к режиму восстановления, если это важно в твоем случае, то их не следует использовать. Физически их отсутствие можно компенсировать полным шифрованием диска, паролем BIOS и паролем Grub (но вектор атаки через ssh и tty все равно останется).

Перед использованием следующей настройки следует знать, что она может нарушить работу команды adduser, поэтому ее нужно выполнять только после создания пользователей, ее можно отключить и включать при необходимости, для включения нужно заменить 0 на 1. Следующей командой мы обнулим срок действия root, это стоит сделать для того, чтобы в него нельзя было попасть с помощью ssh (ssh -Y root@host):

sudo chage --expiredate -0 root

В качестве дополнительной защиты можно отключить возможность авторизации в консоли tty через root, удалив все строки в файле /etc/securetty, не являющиеся комментариями (т.е. не начинающиеся с символа "#").

---

SUDO​

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

Настройки sudo находятся в файле /etc/sudoers, и для внесения изменений в этот файл лучше не использовать обычный редактор. Это связано с тем, что неправильный синтаксис файла sudoers может нанести вред системе в плане повышения уровня авторизации учетных записей и их действий. Для редактирования файла sudoers существует специальная команда visudo, которая блокирует файл sudoers, сохраняет изменения во временном файле и проверяет синтаксическую правильность файла перед его копированием в /etc/sudoers.

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

Но не стоит наделять описанные действия магическими свойствами и расслабляться, если заражен пользователь с доступом sudo, то злоумышленник будет существенно ограничен правилами конфигурации, но ничто не помешает ему предварительно загрузить свою библиотеку для регистрации нажатий клавиш, установить сниффер или атаковать какую-либо программу (существует огромное количество руткитов, пример).

КОНФИГУРАЦИЯ​

Создадим правило для пользователя devel, мы не давали ему права sudo, так как в этом нет необходимости, следующей строкой мы разрешим devel выполнять обновления и устанавливать программы с правами суперпользователя, точнее мы дадим ему доступ к sudo, но к выборочным командам: apt и параметрам к ним update, upgrade, install, но он, например, не сможет ничего удалять параметрами remove и purge:

devel ALL = (root) /usr/bin/apt install, /usr/bin/apt update, /usr/bin/apt upgrade

# devel - правило применяется только к пользователю devel.
# ALL= - правило применяется ко всем хостам.
# (root) - пользователь может выполнять команды с привилегиями root.
# :/usr/bin/apt install и т.д., список команд, разделенный запятыми.

Например, также создадим группу пользователей, которые будут иметь доступ к командам shutdown и reboot, поскольку у них нет sudo, это будет полезно. Файл sudoers можно организовать более эффективно, сгруппировав элементы с помощью различных псевдонимов (где User_Alias - псевдоним для пользователей, SUSPEND - имя псевдонима, ivan, work, person - пользователи, которые будут в него включены, то же самое с псевдонимом Cmnd_Alias, который предназначен для команд):

User_Alias        SUSPEND = ivan, work, person
Cmnd_Alias        POWER   = /sbin/shutdown -h now, /sbin/halt, /sbin/reboot, /sbin/restart
SUSPEND           ALL     = (root) POWER

Для серверов также очень важно разделение привилегий, не стоит давать пользователю привилегии, которые ему не нужны, например, как мы можем дать пользователям группы sysadm возможность выполнять команды от имени пользователей www и apache:

User_Alias        SYSADM = adm1, adm2
Runas_Alias       WEB    = www, apache
SYSADM            ALL    = (WEB) ALL

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

sudo chmod o-x $(which команда)

Приведенная выше строка означает, что теперь только root/sudo имеет право выполнять эту команду. Всем остальным будет отказано в доступе.

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

sudo groupadd группа
sudo useradd -G группа имяпользователя

ОПЦИИ​

Теперь ограничим права на выполнение определенной команды, запускать которую смогут только члены этой группы:

sudo chown :группа команда
sudo chmod 754 $(which команда)

Переходя к конфигурации параметров, лучше всего отключить функцию запоминания паролей, поскольку большинство эксплойтов sudo основаны именно на ней. Для этого добавим параметр в файл "/etc/sudoers" :

Defaults timestamp_timeout=0

Бывают случаи, когда атакующие пытаются запустить вредоносную программу с помощью sudo, который разветвит фоновый процесс, и он останется активным в терминале пользователя даже после завершения выполнения программы (CVE-2005-4890). Чтобы избежать этого, можно настроить sudo на выполнение команд только с использованием "psuedo-pty":

Defaults  use_pty

Мы также можем изменить параметр passwd_tries, чтобы указать количество попыток ввода пароля пользователем (по умолчанию 3):

Defaults   passwd_tries=5

Аналогичным образом можно задать таймаут ввода пароля (по умолчанию 5 минут):

Defaults   passwd_timeout=2

ПРИМЕР ГОТОВОЙ КОНФИГУРАЦИИ​

Самое важное мы рассмотрели, теперь можно собирать то, что нужно для конкретных задач. Построим нечто усредненное для обычного пользователя, допустим, мы создали трех пользователей: admin, devel и ivan.

• admin - этого пользователя мы ранее назначили в группу sudo, который по замыслу должен использоваться реже
• devel - будет устанавливать пакеты, обновлять систему, редактировать настройки, использовать journalctl, systemctl, mount, kill, iptables и т.д. с ограниченным доступом, чтобы полный суперпользователь admin нужен был не так часто.
• ivan - повседневный пользователь, который будет использоваться для выполнения повседневных задач, мы разрешим ему перезагружать, выключать систему, и использовать netctl для интернета.

Выглядеть это будет примерно так:

Cmnd_Alias  POWER       =   /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot
Cmnd_Alias  STORAGE     =   /usr/bin/mount -o nosuid\,nodev\,noexec, /usr/bin/umount
Cmnd_Alias  SYSTEMD     =   /usr/bin/journalctl, /usr/bin/systemctl
Cmnd_Alias  KILL        =   /usr/bin/kill, /usr/bin/killall
Cmnd_Alias  APT         =   /usr/bin/apt, /usr/bin/apt-get
Cmnd_Alias  NETWORK     =   /usr/bin/netctl
Cmnd_Alias  FIREWALL    =   /usr/bin/iptables, /usr/bin/ip6tables, /usr/bin/ufw, /usr/bin/gufw
devel       ALL         =   (root) APT, SYSTEMD, PASSWD: KILL, FIREWALL, NOPASSWD: POWER, NETWORK, STORAGE
ivan        ALL         =   NOPASSWD: POWER, NETWORK

Посмотрим, что у нас получилось: Cmnd_Alias - псевдоним, который позволит объединить множество команд в группу, POWER - имя этого псевдонима, далее через "=" идет список команд, который можно ограничить вплоть до параметров, например, разрешить запуск только "apt update", далее перечисляем: пользователь (devel и ivan), ALL означает, что он сможет запускать ее на всех хостах, далее через "=" идет список псевдонимов с командами, "PASSWD:" или "NOPASSWD:" перед псевдонимом или перед командой будет означать, что мы заставим его выполнить команду с запросом пароля или без него.

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

Также может потребоваться установить права на доступ к конфигурационным файлам, чтобы devel мог их редактировать, например (где: /etc/{openvpn,zsh,vim} путь к файлам, через запятую):

sudo chown -R devel:root /etc/{openvpn,zsh,vim}

Чтобы узнать, какими возможностями обладает пользователь, необходимо выполнить команду:

sudo -l

АЛЬТЕРНАТИВА SUDO: DOAS​

Doas является хорошей и безопасной альтернативой sudo, благодаря небольшому коду и отсутствию большинства проблем и ошибок sudo, его можно использовать без строгих правил, однако doas, хотя и полностью готов к использованию, может вызвать проблемы у неопытного пользователя Linux, поэтому стоит дважды подумать, прежде чем уверенно стремится заменять sudo на doas на всех системах.

Doas разработан в OpenBSD по всем известным правилам: минимальная поверхность атаки, понятный код, функциональность под конкретные задачи, полная проверка и перепроверка кода, что, в свою очередь, не только делает код достаточно безопасным, но и облегчает задачу аудита и проверки, а также делает его более привлекательным для улучшения сторонними контрибьютерами. Doas доступен в репозиториях большинства дистрибутивов Linux. Следует отметить, что doas не лучше и не хуже sudo, doas пытается избежать ошибок sudo, но это принципиально другой инструмент. Ответ на вопрос, нужен ли doas, полностью зависит от потребностей и предпочтений вопрошающего.

Вкратце, doas это очень минималистичный инструмент с гораздо меньшей поверхностью атаки, чем sudo, количество строк кода doas составляет около 10% от количества строк sudo. Doas имеет меньшую функциональность, чем sudo, что делает его менее поворотливым и более заблокированным, когда речь идет о настройке чего-то сложного и большого. Если говорить о примерах, то Doas это что-то вроде Openrc вместо огромной Systemd. Doas имеет достаточно простой синтаксис конфигурации, похожий на обычное английское общение, вместо условного: "%sudo ALL=(ALL:ALL) ALL" в Sudo, в Doas: "permit ivan as root".

Установить doas в Debian можно одной командой:

sudo apt install doas

Doas бесполезен из коробки. Попытка использовать его в любом ключе приведет к ошибке:

doas: doas is not enabled, /etc/doas.conf: No such file or directory

Создадим файл /etc/doas.conf (нужно включить root и создать через него, поскольку владельцем должен быть root) и назначим права доступа к конфигурационному файлу, владельцем и группой файла /etc/doas.conf должен быть 0, права доступа к файлу должны быть установлены на 0400 (как у /etc/sudoers):

touch /etc/doas.conf
chown -c root:root /etc/doas.conf
chmod -c 0400 /etc/doas.conf

КОНФИГУРАЦИЯ​

Основной синтаксис файла /etc/doas.conf выглядит следующим образом:

permit|deny [options] identity [as target] [cmd command [args ...]]

Пример конфигурационного файла можно найти здесь: /etc/examples/doas.conf

Doas требует большей настройки, чем sudo, поскольку в большинстве дистрибутивов он не включен по умолчанию, но его конфигурация гораздо проще, чем у sudo. Все, что нужно сделать, это отредактировать файл /etc/doas.conf. Каждое правило занимает новую строку. Список приоритетов конфликтующих правил располагается снизу вверх. Действие определяется последним совпавшим правилом.

Пример, который имитирует поведение sudo:

permit persist ivan as root

Это позволит пользователю ivan выполнять команды от имени root после ввода собственного пароля. Таким образом, ivan косвенно получает привилегии root. В более широком смысле эту команду можно разделить на три компонента:

• permit - это действие, вместо него может быть deny для явного отказа в разрешениях кому-либо. Таким образом, "deny ivan as root" будет означать, что если это правило находится в конце списка, то ivan никогда не сможет вводить команды от имени root, независимо от других правил, которые могут предполагать обратное. Это полезно, например, для того, чтобы разрешить доступ всем членам группы, кроме одного.
• ivan - это индентификатор, которым может быть имя пользователя, группа (с префиксом в виде двоеточия ":sudo") или числовой идентификатор пользователя.
• as root - в данном контексте можно аналогичным образом заменить root на любое имя пользователя, группу и т.д. Это поле также является необязательным, по умолчанию оно используется для всех пользователей, т.е. если бы полная строка была просто "permit ivan", то этот пользователь мог бы выполнить любую команду, как и любой другой пользователь.

ОПЦИИ​

Одна из доступных опций nopass, отключающая запрос пароля пользователя при использовании doas:

permit nopass ivan as root

Это позволит пользователю мгновенно выполнить любую команду от имени root, без необходимости вводить свой пароль. Существует промежуточная опция: "persist", при использовании которой пользователю потребуется ввести пароль только в первый раз, после чего в течение некоторого времени он больше не будет запрашиваться (persist отключен по умолчанию, поскольку он потенциально опасен, на нем основаны многие эксплойты sudo, оригинальный doas на OpenBSD использует api ядра для безопасной установки и сброса таймаутов, этот api специфичен для OpenBSD и не имеет аналогов в других операционных системах. В качестве обходного пути функция persist реализована с использованием timestamp файлов, аналогично sudo).

Две другие опции keepenv и setenv. "keepenv" обеспечивает сохранение переменных окружения при создании окружения для нового процесса. "setenv" предназначена для сохранения или установки переменных, которые будут передаваться команде. Список переменных заключен в фигурные скобки, каждая из которых разделена пробелом. Для установки переменной изуется знак равенства "=", а для сохранения простое перечисление имен переменной. Для отмены действия необходимо поставить перед нужной переменной знак минус "-". Для обозначения переменной среды используется знак доллара "$".

Например, очень важно, что по умолчанию sudo сохраняет некоторые переменные окружения, а doas нет, в частности XAUTHORITY, LANG и LC_ALL. Это означает, что мы не сможем запускать графические приложения под X или получить доступ к локали пользователя без дополнительной настройки. Например, чтобы разрешить членам группы sudo запуск графических приложений и доступ к локали пользователя, используем опцию setenv:

permit setenv { XAUTHORITY LANG LC_ALL } :sudo

Также очень интересная для большинства пользователей форума опция nolog, которая не будет записывать выполнение команды в системный журнал, ее также следует добавить к необходимым значениям после permit, например, отключить ведение журналов для команд обновления:

permit nolog ivan cmd apt apt-get as root

Если необходимо использовать 2 параметра, можно просто чередовать их без запятой:

permit nopass nolog ivan cmd apt apt-get as root

ОГРАНИЧЕНИЕ КОМАНД И АРГУМЕНТОВ​

"Cmd" позволяет ограничить правило, разрешив выполнение только определенной команды, возможно, только с определенными аргументами или подкомандами. Рассмотрим:

permit ivan as root cmd apt-get args update

Основная команда имеет префикс cmd, а все аргументы и подкоманды - префикс args. Если строка заканчивается на args и больше ни на что, то все аргументы будут запрещены. Приведенный пример позволит ivan запустить "apt-get update" от имени root, но, например, "apt-get remove" нет. Любая дополнительная подкоманда, любые дополнительные аргументы или отсутствие аргументов приведут к ошибке "Operation not permitted".

Данный пример демонстрирует сразу несколько таких дополнительных параметров:

permit nopass setenv { -http_proxy APT_CONFIG=/etc/apt/apt.conf.d/50appstream } :updaters cmd apt-get args update

Это позволяет любому члену группы updaters выполнить "apt-get update" без ввода пароля, сбросив при этом переменную http-proxy и установив в переменной APT_CONFIG путь к одному из конфигурационных файлов Apt.

В конце конфигурационного файла обязательно должна быть пустая строка. Проверим, все ли правильно с синтаксисом файла /etc/doas.conf с помощью команды:

doas -C /etc/doas.conf && echo "config valid" || echo "config failed"

НЕБОЛЬШИЕ ХИТРОСТИ​

По умолчанию bash использует автодополнение по tab только для файлов и каталогов, находящихся в текущем или указанном каталоге. Чтобы bash завершал аргументы как если бы они были отдельными командами (также используя настройки автодополнения других команд), можно добавить следующую строку в ".bashrc" в домашнем каталоге пользователя или в общесистемный каталог "/etc/bash.bashrc":

complete -cf doas

Для обеспечения совместимости скриптов sudo с doas, можно создать алиасы:

alias sudo='doas'
alias sudoedit='doas rnano'

Или сделать символическую ссылку:

doas ln -s $(which doas) /usr/bin/sudo

Создадим безопасную среду для редактирования doas.conf, аналогичную visudo для /etc/sudoers. Для этого необходимо создать каталог /root/script/vidoas и добавить в него следующий скрипт, в котором можно заменить nano на удобный текстовый редактор:

#!/bin/bash

DOASDIR="/tmp/doas-$(date +%s)"
mkdir $DOASDIR
chmod 700 $DOASDIR
DOASFILE="$DOASDIR/doas.conf"

cp /etc/doas.conf $DOASFILE
chmod 600 $DOASFILE

nano $DOASFILE
sync

doas -C $DOASFILE && echo "valid config" && cp $DOASFILE /etc/doas.conf && chmod 400 /etc/doas.conf || echo "invalid config"
sync

rm -rf $DOASDIR

Затем нужно создать /usr/local/bin/vidoas и добавить следующее:

#!/bin/sh
if [ "$EUID" -ne 0 ]; then
        doas /root/script/vidoas
else
        /root/script/vidoas
fi

Изменим разрешение обоих файлов:

sudo chmod 700 /root/script/vidoas
sudo chmod 755 /usr/local/bin/vidoas

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

---

ПАТЧИ БЕЗОПАСНОСТИ ОТ WHONIX​

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

Вкратце Security-misc это набор огромного количества патчей Debian, он вдохновлен KSPP Kernel Self-Protection Project, который реализует все рекомендованные KSPP настройки ядра Linux и многое другое, он был создан разработчиками Whonix, в дальнейшем материале будет упоминаться Kicksecure, это разделение от разработчиками, так как Whonix это именно дистрибутив для анонимности, но в нем также есть огромное количество испаравлений безопасности, которые отделены в Kicksecure, по сути, можно сказать, что Whonix основан на Kicksecure, хотя это разделение произошло далеко после создания Whonix, где-то в 2020 году.

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

Спойлер: Полный список исправлений

sysctl

sysctl settings are configured via the /etc/sysctl.d/30_security-misc.conf configuration file.

A kernel pointer points to a specific location in kernel memory. These can be very useful in exploiting the kernel so they are restricted to CAP_SYSLOG.

The kernel logs are restricted to CAP_SYSLOG as they can often leak sensitive information such as kernel pointers.

The ptrace() system call is restricted to CAP_SYS_PTRACE.

eBPF is restricted to CAP_BPF (CAP_SYS_ADMIN on kernel versions prior to 5.8) and JIT hardening techniques such as constant blinding are enabled.

Restricts performance events to CAP_PERFMON (CAP_SYS_ADMIN on kernel versions prior to 5.8).

Restricts loading line disciplines to CAP_SYS_MODULE to prevent unprivileged attackers from loading vulnerable line disciplines with the TIOCSETD ioctl which has been abused in a number of exploits before.

Restricts the userfaultfd() syscall to CAP_SYS_PTRACE as userfaultfd() is often abused to exploit use-after-free flaws.

Kexec is disabled as it can be used to load a malicious kernel and gain arbitrary code execution in kernel mode.

Randomises the addresses for mmap base, heap, stack, and VDSO pages.

Prevents unintentional writes to attacker-controlled files.

Prevents common symlink and hardlink TOCTOU races.

Restricts the SysRq key so it can only be used for shutdowns and the Secure Attention Key.

The kernel is only allowed to swap if it is absolutely necessary. This prevents writing potentially sensitive contents of memory to disk.

TCP timestamps are disabled as it can allow detecting the system time.

mmap ASLR

The bits of entropy used for mmap ASLR are maxed out via /usr/libexec/security-misc/mmap-rnd-bits (set to the values of CONFIG_ARCH_MMAP_RND_BITS_MAX and CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX that the kernel was built with), therefore improving its effectiveness.

Boot parameters

Boot parameters are outlined in configuration files located in the etc/default/grub.d/ directory.

Slab merging is disabled which significantly increases the difficulty of heap exploitation by preventing overwriting objects from merged caches and by making it harder to influence slab cache layout.

Memory zeroing at allocation and free time is enabled to mitigate some use-after-free vulnerabilities and erase sensitive information in memory.

Page allocator freelist randomization is enabled.

Kernel Page Table Isolation is enabled to mitigate Meltdown and increase KASLR effectiveness.

vsyscalls are disabled as they are obsolete, are at fixed addresses and thus, are a potential target for ROP.

The kernel panics on oopses to thwart certain kernel exploits.

Enables randomisation of the kernel stack offset on syscall entries.

All mitigations for known CPU vulnerabilities are enabled and SMT is disabled.

IOMMU is enabled to prevent DMA attacks along with strict enforcement of IOMMU TLB invalidation so devices will never be able to access stale data contents.

Distrust the 'randomly' generated CPU and bootloader seeds.

Disables and blacklists kernel modules

Certain kernel modules are disabled and blacklisted by default to reduce attack surface via the /etc/modprobe.d/30_security-misc.conf configuration file.

Deactivates Netfilter's connection tracking helper - this module increases kernel attack surface by enabling superfluous functionality such as IRC parsing in the kernel. Hence, this feature is disabled.

Bluetooth is disabled to reduce attack surface. Bluetooth has a lengthy history of security concerns.

Thunderbolt and numerous FireWire kernel modules are also disabled as they are often vulnerable to DMA attacks.

The MSR kernel module is disabled to prevent CPU MSRs from being abused to write to arbitrary memory.

Uncommon network protocols are blacklisted. This includes:

DCCP - Datagram Congestion Control Protocol

SCTP - Stream Control Transmission Protocol

RDS - Reliable Datagram Sockets

TIPC - Transparent Inter-process Communication

HDLC - High-Level Data Link Control

AX25 - Amateur X.25

NetRom

X25

ROSE

DECnet

Econet

af_802154 - IEEE 802.15.4

IPX - Internetwork Packet Exchange

AppleTalk

PSNAP - Subnetwork Access Protocol

p8023 - Novell raw IEEE 802.3

p8022 - IEEE 802.2

CAN - Controller Area Network

ATM

Disables a large array of uncommon file systems and network file systems that reduces the attack surface especially against legacy approaches.

The vivid kernel module is only required for testing and has been the cause of multiple vulnerabilities so it is disabled.

Provides some disabling of the interface between the Intel Management Engine (ME) and the OS.

Incorporates much of Ubuntu's default blacklist of modules to be blocked from automatically loading. However, they are still permitted to load.

Blocks automatic loading of the modules needed to use of CD-ROM devices by default. Not completely disabled yet.

Other

A systemd service clears the System.map file on boot as these contain kernel pointers. The file is completely overwritten with zeroes to ensure it cannot be recovered. See:

/etc/kernel/postinst.d/30_remove-system-map

/lib/systemd/system/remove-system-map.service

/usr/libexec/security-misc/remove-system.map

Coredumps are disabled as they may contain important information such as encryption keys or passwords. See:

/etc/security/limits.d/30_security-misc.conf

/etc/sysctl.d/30_security-misc.conf

/lib/systemd/coredump.conf.d/30_security-misc.conf

An initramfs hook sets the sysctl values in /etc/sysctl.conf and /etc/sysctl.d before init is executed so sysctl hardening is enabled as early as possible. This is implemented for initramfs-tools only because this is not needed for dracut because dracut does that by default, at least on systemd enabled systems. Not researched for non-systemd systems by the author of this part of the readme.

Network hardening

TCP syncookies are enabled to prevent SYN flood attacks.

ICMP redirect acceptance, ICMP redirect sending, source routing and IPv6 router advertisements are disabled to prevent man-in-the-middle attacks.

The kernel is configured to ignore all ICMP requests to avoid Smurf attacks, make the device more difficult to enumerate on the network and prevent clock fingerprinting through ICMP timestamps.

RFC1337 is enabled to protect against time-wait assassination attacks by dropping RST packets for sockets in the time-wait state.

Reverse path filtering is enabled to prevent IP spoofing and mitigate vulnerabilities such as CVE-2019-14899.

Entropy collection improvements

The jitterentropy_rng kernel module is loaded as early as possible during boot to gather more entropy via the /usr/lib/modules-load.d/30_security-misc.conf configuration file.

Distrusts the CPU for initial entropy at boot as it is not possible to audit, may contain weaknesses or a backdoor. For references, see: /etc/default/grub.d/40_distrust_cpu.cfg

Gathers more entropy during boot if using the linux-hardened kernel patch.

Restrictive mount options

Not enabled by default yet. In development. Help welcome.


/home, /tmp, /dev/shm and /run are remounted with the nosuid and nodev mount options to prevent execution of setuid or setgid binaries and creation of devices on those filesystems.

Optionally, they can also be mounted with noexec to prevent execution of any binary. To opt-in to applying noexec, execute touch /etc/noexec as root and reboot.

To disable this, execute touch /etc/remount-disable as root.

Alternatively, file /usr/local/etc/remount-disable or /usr/local/etc/noexec could be used.
Root access restrictions

su is restricted to only users within the group sudo which prevents users from using su to gain root access or to switch user accounts - /usr/share/pam-configs/wheel-security-misc (which results in a change in file /etc/pam.d/common-auth).

Add user root to group sudo. This is required due to the above restriction so that logging in from a virtual console is still possible - debian/security-misc.postinst

Abort login for users with locked passwords - /usr/libexec/security-misc/pam-abort-on-locked-password.

Logging into the root account from a virtual, serial, whatnot console is prevented by shipping an existing and empty /etc/securetty file (deletion of /etc/securetty has a different effect).

This package does not yet automatically lock the root account password. It is not clear if this would be sane in such a package although, it is recommended to lock and expire the root account.

In new Kicksecure builds, root account will be locked by package dist-base-files.


However, a locked root password will break rescue and emergency shell. Therefore, this package enables passwordless rescue and emergency shell. This is the same solution that Debian will likely adapt for Debian installer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211

See:

/etc/systemd/system/emergency.service.d/override.conf
/etc/systemd/system/rescue.service.d/override.conf

Adverse security effects can be prevented by setting up BIOS password protection, GRUB password protection and/or full disk encryption.
Console lockdown

This uses pam_access to allow members of group console to use console but restrict everyone else (except members of group console-unrestricted) from using console with ancient, unpopular login methods such as /bin/login over networks as this might be exploitable. (CVE-2001-0797)

This is not enabled by default in this package since this package does not know which users shall be added to group 'console' and thus, would break console.

See:

/usr/share/pam-configs/console-lockdown-security-misc
/etc/security/access-security-misc.conf

Brute force attack protection

User accounts are locked after 50 failed login attempts using pam_faillock.

Informational output during Linux PAM:

Show failed and remaining password attempts.
Document unlock procedure if Linux user account got locked.
Point out that there is no password feedback for su.
Explain locked root account if locked.

See:

/usr/share/pam-configs/tally2-security-misc
/usr/libexec/security-misc/pam-info
/usr/libexec/security-misc/pam-abort-on-locked-password

Access rights restrictions
Strong user account separation

Read, write and execute access for "others" are removed during package installation, upgrade or PAM mkhomedir for all users who have home folders in /home by running, for example:

chmod o-rwx /home/user

This will be done only once per folder in /home so users who wish to relax file permissions are free to do so. This is to protect files in a home folder that were previously created with lax file permissions prior to the installation of this package.

See:

debian/security-misc.postinst
/usr/libexec/security-misc/permission-lockdown
/usr/share/pam-configs/mkhomedir-security-misc

SUID / SGID removal and permission hardening

Not enabled by default yet.

A systemd service removes SUID / SGID bits from non-essential binaries as these are often used in privilege escalation attacks. It is disabled by default for now during testing and can optionally be enabled by running systemctl enable permission-hardening.service as root.


Access rights relaxations

This is not enabled yet because hidepid is not enabled by default.

Calls to pkexec are redirected to lxqt-sudo because pkexec is incompatible with hidepid=2.


Application-specific hardening

Enables "apt-get --error-on=any" which makes apt exit non-zero for transient failures. - /etc/apt/apt.conf.d/40error-on-any.
Enables APT seccomp-BPF sandboxing - /etc/apt/apt.conf.d/40sandbox.
Deactivates previews in Dolphin.
Deactivates previews in Nautilus - /usr/share/glib-2.0/schemas/30_security-misc.gschema.override.
Deactivates thumbnails in Thunar.
Displays domain names in punycode (network.IDN_show_punycode) in Thunderbird to prevent IDN homograph attacks (a form of phishing).
Security and privacy enhancements for gnupg's config file /etc/skel/.gnupg/gpg.conf. See also:


ioerror/torbirdy#11
Opt-in hardening

Some hardening is opt-in as it causes too much breakage to be enabled by default.

An optional systemd service mounts /proc with hidepid=2 at boot to prevent users from seeing another user's processes. This is disabled by default because it is incompatible with pkexec. It can be enabled by executing systemctl enable proc-hidepid.service as root.

A systemd service restricts /proc/cpuinfo, /proc/bus, /proc/scsi and /sys to the root user. This hides a lot of hardware identifiers from unprivileged users and increases security as /sys exposes a lot of information that shouldn't be accessible to unprivileged users. As this will break many things, it is disabled by default and can optionally be enabled by executing systemctl enable hide-hardware-info.service as root.

miscellaneous

hardened malloc compatibility for haveged workaround /lib/systemd/system/haveged.service.d/30_security-misc.conf

set dracut reproducible=yes setting

Мы рассмотрим только те, которые интересуют нас в рамках темы данной статьи.

УСТАНОВКА В DEBIAN LINUX​

Поддерживаются как Debian 11 Bullseye, так и новый Debian 12 Bookworm, а также другие дистрибутивы, основанные на них. Для установки потребуются привилегии root, поэтому можно либо выполнить su от обычного пользователя, если не были применены рекомендации в статье выше, либо перезайти в созданного пользователя admin. Создадим группу console и добавим в нее пользователей, ivan - имя которого нужно изменить на собственного пользователя, при необходимости нужно добавить дополнительных пользователей, как admin (это необходимо для блокировки консоли, подробнее об этом ниже):

sudo addgroup --system console
sudo adduser ivan console
sudo adduser admin console

Перезагружаемся. Теперь загрузим ключ подписи репозитория и добавим его:

wget https://www.kicksecure.com/keys/derivative.asc
sudo cp derivative.asc /usr/share/keyrings/derivative.asc

Добавляем репозиторий, в примере Debian 12 Bookworm, если используется Debian 11 Bullseye, нужно просто заменить название выпуска (bookworm на bullseye):

echo "deb [signed-by=/usr/share/keyrings/derivative.asc] https://deb.kicksecure.com bookworm main contrib non-free" | sudo tee /etc/apt/sources.list.d/derivative.list

Если нет желания возиться с этими командами, можно воспользоваться утилитой extrepo, Kicksecure присутствует в ней:

sudo apt install extrepo
sudo extrepo enable kicksecure

Установим security-misc:

sudo apt update && sudo apt install --no-install-recommends security-misc

БЛОКИРОВКА КОНСОЛИ​

Блокировка консоли позволяет использовать консоль только членам группы console. Всем остальным будет запрещено использовать консоль с помощью старых, непопулярных методов входа, таких как /bin/login, которые могут быть использованы для атаки CVE-2001-0797. При установке мы добавили пользователя ivan и пользователя admin, поэтому проблем с этим не возникнет.

ЗАЩИТА ОТ ПОДБОРА ПАРОЛЕЙ БРУТФОРСОМ​

Security-misc существенно ограничивает подбор паролей пользователей, блокируя учетную запись после 50 неудачных попыток входа с помощью faillock до тех пор, пока она не будет разблокирована вручную командой "sudo faillock --user ivan --reset", для чего придется войти в систему под другим пользователем, например, admin.

ОГРАНИЧЕНИЕ ПРАВ ДОСТУПА​

Security-misc снимает права на чтение, запись и выполнение для других пользователей, имеющих домашние папки в каталоге /home. Это сделано для защиты ранее созданных файлов в домашней папке пользователя, которые до установки были созданы с ослабленными правами доступа к файлам. Проще говоря, пользователь ivan не будет иметь доступа к папке пользователя user.

УКРАЩЕНИЕ SUID/SGID И ПРАВ ДОСТУПА​

Описанные выше улучшения это все, конечно, мило, но наибольший интерес представляет SUID, именно этот товарищ, на пару с SGID часто позволяют пустить пешку в дамки и заполучить заветные повышенные привилегии в системе.

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

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

В идеальном мире не должно быть ни одного двоичного файла SUID, доступного из учетной записи пользователя, поскольку в противном случае открывается огромная поверхность для атак внутри системы (динамический компоновщик, запуск libc, части ядра Linux, включая загрузчик ELF, и т.д.). Поскольку в реальности это сделает невозможным использование системы, можно попробовать воспользоваться этой функцией, которая должна повысить безопасность системы и уменьшить площадь атаки за счет отключения многих исполняемых файлов с поддержкой SUID/SGID и изменения прав доступа.

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

Работает она следующим образом: ищет в папках исполняемые/библиотечные файлы SUID/SGID и отключает все, что не входит в белый список. Но поскольку программы могут быть переустановлены, это приходится делать при каждом запуске системы, на производительности это не сказывается. Стандартный список папок:

/bin/ nosuid
/usr/bin/ nosuid
/usr/local/bin/ nosuid
/sbin/ nosuid
/usr/sbin/ nosuid
/usr/local/sbin/ nosuid
/lib/ nosuid
/lib32/ nosuid
/lib64/ nosuid
/usr/lib/ nosuid
/usr/lib32/ nosuid
/usr/lib64/ nosuid
/usr/local/lib/ nosuid
/usr/local/lib32/ nosuid
/usr/local/lib64/ nosuid

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

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

sudo /usr/libexec/security-misc/permission-hardening

Для полного включения функции необходимо выполнить:

sudo systemctl enable permission-hardening.service
sudo systemctl start permission-hardening.service

Функция вежливо запишет текущее состояние до изменения, посмотреть их можно здесь:

cat /var/lib/permission-hardening/existing_mode/statoverride

А список изменений можно посмотреть здесь:

cat /var/lib/permission-hardening/new_mode/statoverride

Чтобы сравнить их и увидеть изменения, можно выполнить команду:

meld /var/lib/permission-hardening/existing_mode/statoverride /var/lib/permission-hardening/new_mode/statoverride

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

sudo mkdir -p /etc/permission-hardening.d

Затем нужно открыть файл /etc/permission-hardening.d/20_user.conf и указать путь к необходимому бинарнику, вместе с параметров exactwhitelist:

/usr/sbin/exim4 exactwhitelist

И после этого включим его, этой же командой можно включить конкретный двоичный файл на время до перезагрузки:

sudo /usr/libexec/security-misc/permission-hardening-undo /usr/sbin/exim4

Чтобы вернуть все обратно и полностью отключить эту функцию, необходимо выполнить команды:

sudo /usr/libexec/security-misc/permission-hardening-undo all
sudo systemctl stop permission-hardening.service
sudo systemctl mask permission-hardening.service

---

ЗАКЛЮЧЕНИЕ​

Не вдаваясь в подробности темы, у тебя получится настроить систему с достаточной защитой от повышения привилегий. Конечно, остаются параллельные проблемы, такие как уязвимости в приложениях/скриптах, неправильная настройка ОС и приложений, забытые критические данные (пароли, логины, резервные копии и т.д.), уязвимости в ядре ОС. Поэтому следует произвести дополнительные настройки для защиты от первоначального доступа атакующего, проникновений извне, руткитов, а также от прямого вмешательства человека, от перехвата трафика и слежки, запретить вход по паролю через SSH на сервер, удалить ненужные службы, не допускать ошибок конфигурации. И, конечно, регулярно обновлять систему. А чтобы не пропустить новые статьи, можно подписаться на профиль.

---

©
Специально для xss.pro
Автор статьи: IvanVasilyevich​

 

[Dread Pirate Roberts]

всю статью не осилил, проскроллил по диагонали, но в целом статья годная.
спасибо за pam_usb, я не знал такое.

 

[TR77]

очень полезно, спасибо за инфу

 

[nmap]

спасибо за pam_usb, я не знал такое.

Да их самому любые вполне можно писать.

 

[Wadov]

it was interesting but too long for read ))

 

[IvanVasilyevich]

Эффективнее вместе с https://xss.pro/threads/99122/