Security (Русский)

Состояние перевода: На этой странице представлен перевод статьи Security. Дата последней синхронизации: 14 марта 2023. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Ссылки по теме

• Arch Security Team
• Основные рекомендации
• PAM (Русский)
• Capabilities (Русский)
• Список приложений/Безопасность
• Arch package guidelines/Security

В данной статье собраны рекомендации и лучшие практики по повышению защищённости операционной системы Arch Linux.

Принципы

• Систему можно "защитить" до такой степени, что с ней будет невозможно работать. Необходимо найти баланс между защищённостью и удобством.
• Существует множество атак и угроз, но следует понимать, что наибольшей уязвимостью всегда был — и будет — сам пользователь.
• Принцип минимальных привилегий: каждый элемент системы должен иметь доступ только к тому, что необходимо ему для работы, и ни к чему более.
• Безопасность должна быть организована в виде многослойной системы. Когда один из слоёв защиты прорван, следующий остановит атаку.
• Будьте немного параноиком. Будьте подозрительны. Если что-то выглядит слишком хорошо, чтобы быть правдой, то, скорее всего, так оно и есть.
• Обеспечить стопроцентную защищённость можно только одним способом: отключить машину от всех сетей, запереть её в сейфе, залить бетоном и никогда не использовать.
• Приготовьтесь к неудаче. Создайте план действий на тот случай, если ваши защитные мероприятия не помогут и атакующий преодолеет защиту.

Пароли

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

Надёжность пароля

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

Ненадёжными считаются пароли:

• Основанные на личной информации (кличка домашнего питомца, дата рождения, любимая видеоигра).
• Слова с заменой букв (например, k1araj0hns0n), уязвимые для атаки словарём.
• Слова или часто употребляемые строки, к которым в начале и/или в конце добавлены числа, символы или буквы (например, DG091101%).
• Распространённые фразы или короткие строки из словарных слов (например, photocopyhauntbranchexpose), в том числе и с заменой символов (вроде Ph0toc0pyh4uN7br@nch3xp*se).
• Любой из наиболее распространённых паролей.

Лучше всего для пароля подойдёт длинная (чем длиннее — тем лучше) последовательность символов, созданная с помощью надёжного источника случайности. Очень важно, чтобы пароль был длинным. Слабые алгоритмы хэширования позволяют взломать восьмизначный пароль по его хэш-сумме всего за несколько часов.

Утилиты вроде pwgen или apg^AUR помогают генерировать случайные пароли. К сожалению, такие пароли сложно запомнить. Одна из часто используемых техник запоминания заключается в том, что генерируется длинный пароль и записывается на бумагу, после чего пользователь запоминает минимальное безопасное количество символов. Со временем количество используемых символов из длинного пароля должно увеличиваться. Наконец, когда весь пароль сохранится на уровне "мышечной памяти", бумажку с паролем можно выбросить. Данная техника довольно непроста в использовании, но зато она гарантирует, что пароль не находится в каком-нибудь словаре и его нельзя будет угадать "умной" bruteforce-атакой, комбинирующей слова и замену символов.

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

Часто используется другой подход, с придумыванием мнемонической фразы, в которой каждое слово соответствует символу или группе символов пароля. Например, строке “the girl is walking down the rainy street” может соответствовать t6!WdtR5 или, чуть сложнее, — t&6!RrlW@dtR,57. Такой подход проще, но имейте в виду, что некоторые буквы в начале фраз встречаются чаще других.

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

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

В качестве пароля можно использовать длинную последовательность несвязанных слов. При достаточной длине фразы набранная на количестве слов энтропия компенсирует нехватку энтропии от использования "словарных" слов. Комикс xkcd наглядно раскрывает плюсы и минусы такого подхода, с учётом, что набор слов ограничен. Если набор слов, используемый для генерации пароля, достаточно велик (несколько тысяч) и в пароле 5-7 или больше слов, то этот метод предлагает достаточно неплохую энтропию, даже если атакующий знает используемый набор слов и их количество в парольной фразе. Подробнее см. Diceware.

Смотрите также The passphrase FAQ и Сложность пароля.

Хранение паролей

Следующий шаг после выбора надёжного пароля — убедиться, что он хранится в безопасном месте. Здесь необходимо подумать о таких вещах, как кейлогеры (программные и аппаратные), скринлогеры, социальная инженерия и даже банальное подглядывание. Старайтесь не использовать неуникальные пароли (т.е. такие, которые вы используете где-то ещё) на серверах, в безопасности которых не уверены — это позволит минимизировать потери в случае утечки. Менеджеры паролей позволяют хранить большое количество сложных паролей. После копирования пароля из менеджера в приложение убедитесь, что буфер обмена очищен; кроме того, пароли не должны сохраняться в каких либо лог-файлах. Так, не стоит копировать пароли напрямую в команды терминала, потому что тогда они могут отобразиться в файлах вроде .bash_history. Имейте в виду, что менеджеры паролей, реализованные в виде браузерных расширений, могут быть уязвимы к атакам по сторонним каналам. Использование отдельных приложений-менеджеров может смягчить эту проблему.

Разумеется, не стоит выбирать простые пароли лишь по той причине, что их проще запомнить. Вместо большого количества простых, похожих друг на друга паролей лучше создать зашифрованную базу данных надёжных паролей, которая будет защищена ключом шифрования и одним сложным мастер-паролем. Хранение паролей в виде записей на бумажном носителе — также достаточно эффективный подход [1], поскольку уязвимости в программном обеспечении больше не будут играть никакой роли; однако взамен потребуется обеспечить безопасность физического носителя в реальном мире.

Наконец, важным преимуществом сильного пароля является то, что его нельзя восстановить на основе информации из сторонних источников.

Если вы используете одну и ту же кодовую фразу для шифрования диска и в качестве пароля входа (удобно при автомонтировании зашифрованного раздела или каталога при входе в систему), убедитесь, что файл /etc/shadow либо находится на зашифрованном разделе, либо использует надёжный алгоритм хэширования паролей (yescrypt/bcrypt/argon2 или sha512 с PBKDF2, но не md5; подробнее см. SHA password hashes).

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

Безопасное управление версиями базы данных представляет собой довольно сложный процесс. Если вы решите пойти этим путём, то необходимо будет обновлять мастер-пароль во всех версиях базы. Чаще всего явные признаки утечки мастер-пароля отсутствуют, поэтому для снижения рисков стоит производить смену пароля регулярно. Если возникло подозрение, что кто-то получил несанкционированный доступ к одной из старых версий базы данных, необходимо как можно быстрее сменить все пароли, которые в ней хранились. "Как можно быстрее" в данном случае означает "быстрее, чем злоумышленник подберёт мастер-пароль методом грубой силы". Время подбора пароля можно приблизительно оценить, исходя из его энтропии.

Хэш-суммы паролей

Хэшированные пароли в Arch Linux хранятся в файле /etc/shadow, который доступен на чтение только суперпользователю. Остальные параметры пользовательских аккаунтов находятся доступном для всех файле /etc/passwd (подробнее см. Пользователи и группы#База данных пользователей). Также см. раздел #Ограничение root.

Задать пароль можно командой passwd, которая вычислит его хэш-сумму с помощью функции crypt и затем сохранит в файл /etc/shadow. См. также SHA password hashes. Пароли солятся, чтобы защитить их от взлома с помощью радужных таблиц.

См. также статью о хранении паролей в Linux.

Требования к паролю с pam_pwquality

pam_pwquality предоставляет защиту от перебора по словарю и помогает настроить политики паролей для всей системы. Модуль основан на pam_cracklib и поддерживает настройки последнего для обратной совместимости.

Установите пакет libpwquality.

Важно: На суперпользователя ограничения политик по умолчанию не действуют.

Примечание:

• Суперпользователь может задавать пароли для обычных пользователей, не укладывающиеся в разрешённую политику. Это удобно при создании временных паролей.
• Текущие рекомендации по поводу паролей (например, от NIST) не советуют использовать в паролях спецсимволы, так как они часто приводят к предсказуемым вариациям в пароле.

Например, вы хотите установить следующую политику:

• запрашивать пароль 2 дополнительных раза в случае ошибки (параметр retry);
• длина пароля не менее 10 символов (параметр minlen);
• новый пароль должен отличаться от старого не менее чем шестью символами (параметр difok);
• не менее 1 цифры (параметр dcredit);
• не менее 1 буквы в верхнем регистре (параметр ucredit);
• не менее 1 буквы в нижнем регистре (параметр lcredit);
• не менее 1 другого символа (параметр ocredit);
• не содержит слов "myservice" и "mydomain";
• работает в том числе и для пользователя root.

Добавьте в файл /etc/pam.d/passwd следующие строки:

#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow

Строка password required pam_unix.so use_authtok является указанием модулю pam_unix не запрашивать пароль, а использовать тот, который будет предоставлен модулем pam_pwquality.

Подробнее см. pam_pwquality(8) и pam_unix(8).

Процессор

Микрокод

В статье Микрокод описано, как установить обновления безопасности для микрокода вашего процессора.

Аппаратные уязвимости

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

Проверить наличие в вашей системе известных уязвимостей можно командой:

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

В большинстве случаев для защиты достаточно своевременно обновлять ядро и микрокод процессора.

Одновременная многопоточность (hyper-threading)

Примечание: Эти параметры нужны в основном для гипервизоров. Их использование в обычной системе не даёт почти никаких преимуществ с точки зрения безопасности.

Одновременная многопоточность (Simultaneous multithreading, SMT), для процессоров Intel также известная как гиперпоточность (hyper-threading), может стать причиной уязвимостей L1 Terminal Fault и Microarchitectural Data Sampling. Ядро Linux и микрокоды предоставляют обновления для защиты от известных уязвимостей, но для некоторых процессоров её лучше отключить, если на машине работают виртуализированные гостевые системы.

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

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

Память

Безопасный malloc

hardened_malloc (hardened_malloc^AUR, hardened-malloc-git^AUR) — безопасный аналог функции malloc() из стандартной библиотеки glibc. Изначально проект разрабатывался для внедрения в библиотеки Bionic (Android) и musl (GrapheneOS), однако имеется и встроенная поддержка обычных Linux-дистрибутивов для архитектуры x86_64.

Поскольку функция hardened_malloc до сих пор не добавлена в glibc (любая поддержка и запросы на слияние приветствуются), использовать её можно с помощью переменной окружения LD_PRELOAD. Тесты показали, что с некоторыми приложениями могут возникнуть проблемы, если задать эту переменную глобально в файле /etc/ld.so.preload. Кроме того, поскольку hardened_malloc может снизить производительность, окончательное решение о его использовании лучше принимать исходя из конкретной ситуации, принимая во внимание реальную поверхность атаки.

Проверить работу улучшенной функции можно либо с помощью сценария-обёртки hardened-malloc-preload, либо запустив программу с явно заданной переменной окружения LD_PRELOAD:

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

Работа с hardened_malloc в Firejail описана в соответствующей статье, а список возможных настроек функции вы найдёте в Github-репозитории проекта.

Данные

Шифрование неактивных данных

Шифрование неактивных данных (Data-at-rest encryption), в том числе полное шифрование диска с использованием надёжного пароля, представляет собой единственный способ защитить данные от физического восстановления. Пока компьютер выключен или зашифрованный диск размонтирован, данные находятся в полной безопасности.

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

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

Также можно зашифровать носитель хранящимся в TPM ключом, но имейте в виду, что в нём находили уязвимости, а ключ можно извлечь с помощью атаки bus sniffing.

Шифрование файлов

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

Есть несколько способов шифрования файлов:

• Некоторые инструменты архивирования и сжатия также поддерживают шифрование. Например: p7zip (флаг -p), zip (флаг -e).
• Можно использовать GnuPG для шифрования файлов.
• age — простой и удобный в использовании инструмент шифрования. Также он позволяет задать несколько получателей и использовать ключи SSH для шифрования, что удобно для безопасного обмена файлами.

Файловые системы

В настоящее время ядро самостоятельно предотвращает связанные с жёсткими и символическими ссылками проблемы безопасности, если включены переключатели sysctl fs.protected_hardlinks и fs.protected_symlinks. По этой причине нет особого смысла выносить отдельно каталоги, доступные на запись для всех.

Отделять файловые системы с такими каталогами имеет смысл только в том случае, если вы желаете ограничить "ущерб" от исчерпания свободного места на диске. Однако имейте в виду, что заполнение файловых систем /var или /tmp приведёт к аварийному завершению служб. Более гибкий подход заключается в выделении квот, причём в некоторые файловые системы эта возможность встроена по умолчанию (например, в Btrfs есть квоты на подтома).

Параметры монтирования

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

Наиболее полезные параметры монтирования:

• nodev: символьные и специальные блочные устройства не будут распознаваться.
• nosuid: биты setuid и setgid в правах доступа к файлам будут игнорироваться.
• noexec: запуск исполняемых файлов будет запрещён.
  • Установка noexec для /home приведёт к невозможности запуска скриптов и проблемам с Wine*, Steam, PyCharm, .NET и т.д.
  • Для некоторых пакетов (например, при сборке nvidia-dkms) может быть необходим параметр exec для /var.

Примечание: При запуске исполняемых файлов Windows в Wine флаг exec не требуется. Этот флаг необходим только если сам Wine установлен в каталог /home.

Файловые системы, которые используются только для хранения данных, должны всегда монтироваться с параметрами nodev, nosuid и noexec.

Примеры файловых систем, для которых это имеет смысл:

• /var
• /home
• /dev/shm
• /tmp
• /boot

Совет: При использовании автомонтирования GPT-разделов ESP и XBOOTLDR всегда монтируются с опциями noexec,nosuid,nodev.

Права доступа к файлам

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

# chmod go-rwx /путь/к/файлу

Важно: Не применяйте это сразу ко всем файлам подряд. Изменяйте права по одному файлу за раз и проверяйте, что ничего не сломалось и зависящие от него программы продолжают нормально работать. Иногда может понадобиться предоставить доступ группе; в таком случае удалите g из команды перед её выполнением. Если вы уже удалили права на чтение файла для группы, то вернуть их можно с помощью команды chmod g+r /путь/к/файлу.

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

• /boot: в этом каталоге находятся файл ядра vmlinuz и образ initramfs.
• /etc/nftables.conf: настройки nftables, применимые к nftables и iptables-nft.
• /etc/iptables: настройки более старого iptables, применимые к iptables.

Значение umask по умолчанию — 0022; его можно изменить для повышения безопасности новых файлов. В руководстве по безопасности RHEL5 рекомендуется значение umask 0077 как обеспечивающее максимальный уровень безопасности, поскольку любые создаваемые файлы будут доступны на чтение только владельцу. В разделе umask (Русский)#Установка значения маски описано, как изменить значение umask.

Файлы SUID и SGID

Важно знать о любых файлах с битами Setuid или Setgid. Примеры таких файлов, которые находятся в /usr/bin и владельцем которых является root:

• gpasswd
• pkexec
• sudo
• su
• passwd
• firejail

Если в таких файлах будут найдены уязвимости, они могут быть использованы для несанкционированного повышения привилегий; см. Wikipedia:Setuid#Security impact.[2][3][4]

Файлы, которые имеют бит SUID, но владельцем которых является не root, или файлы с битом SGID "обычно" имеют меньший риск для безопасности, но уязвимости в них всё равно могут нанести ущерб. Защититься от этого можно, если вместо Setuid и Setgid использовать привилегии.

Для поиска файлов в /usr/bin с битами SUID или SGID можно использовать команду:

$ find /usr/bin -perm "/u=s,g=s"

Резервное копирование

Регулярно создавайте резервные копии важных данных. Регулярно проверяйте целостность резервных копий. Регулярно проверяйте, что резервные копии всё ещё пригодны для восстановления данных.

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

Статус SSD "frozen"

Смотрите Твердотельные накопители#Перевод SSD в состояние "frozen" после возвращения из ждущего режима.

Настройки пользователя

Не используйте root-аккаунт для повседневных нужд

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

Пауза после неудачной попытки входа

Добавьте следующую строку в файл /etc/pam.d/system-login, чтобы установить паузу в 4 секунды после неудачной попытки входа:

/etc/pam.d/system-login

auth optional pam_faildelay.so delay=4000000

Здесь 4000000 — длительность паузы в микросекундах.

Блокировка из-за неудачных попыток входа

Согласно настройкам pambase по умолчанию, pam_faillock.so блокирует пользователя на 10 минут после трёх неудачных попыток входа в течение последней четверти часа (см. FS#67644). Блокируется только аутентификация по паролю (например, login и sudo), вход через SSH по открытому ключу останется доступным. Чтобы предотвратить полный отказ в обслуживании, для суперпользователя такого рода блокировки по умолчанию отключены.

Чтобы разблокировать пользователя, выполните:

$ faillock --user пользователь --reset

Механизм блокировки подразумевает наличие "пользовательского" файла в каталоге /run/faillock/. Если файл удалить или очистить, то пользователь будет разблокирован. Каталог принадлежит суперпользователю, а файлы — обычным пользователям, поэтому команда faillock просто удаляет содержимое файла, для чего права root не требуются.

Настройки модуля pam_faillock.so находятся в файле /etc/security/faillock.conf. Параметры для настройки блокировок:

• unlock_time — продолжительность блокировки (в секундах, по умолчанию 10 минут).
• fail_interval — период, в течение которого неудачные попытки входа вызовут блокировку (в секундах, по умолчанию 15 минут).
• deny — количество неудачных попыток, необходимое для блокировки (по умолчанию — 3).

Совет: Основной целью блокировки является замедление атак методом перебора, чтобы они стали невыполнимыми. Следовательно, если блокировки из-за неправильного ввода паролей становятся слишком частыми, увеличение количества попыток может быть предпочтительнее, чем уменьшение времени блокировки.

Примечание: deny = 0 отключит механизм блокировок.

По умолчанию все блокировки теряются после перезагрузки. Если у атакующего есть возможность перезагружать машину, будет более безопасно сохранять блокировки. Для этого в файле /etc/security/faillock.conf измените параметр dir на /var/lib/faillock.

Изменения вступают в силу сразу, перезагрузка не требуется. В руководстве faillock.conf(5) вы найдёте другие полезные опции: включение блокировки для root-аккаунта, отключение в случае централизованного входа (например, для LDAP) и т.д.

Ограничение на количество процессов

В системах с большим количеством пользователей (в том числе и недоверенных) важно ограничить число процессов, которое пользователь может запускать параллельно. Это помогает защититься от fork-бомб и других DoS-атак. Количество процессов, запускаемых пользователем или группой, определяется в файле /etc/security/limits.conf. Изначально в нём нет ничего, кроме комментариев. Добавьте следующие строки, чтобы ограничить количество процессов значением 100, кроме случаев, когда пользователь выполнил команду prlimit, чтобы повысить свой предел до 200 на время текущего сеанса.

* soft nproc 100
* hard nproc 200

Текущее число запущенных у каждого пользователя потоков можно узнать командой ps --no-headers -Leo user | sort | uniq --count. Это позволит определить целесообразные значения пределов.

Использование Wayland

По возможности используйте Wayland вместо Xorg. Архитектура Xorg считается устаревшей и небезопасной. Например, неактивные приложения имеют возможность перехватывать все нажатия клавиш.

Если же вы вынуждены использовать Xorg, то рекомендуется запускать его без прав суперпользователя. В Wayland слой совместимости Xwayland изначально не использует root.

Ограничение root

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

sudo вместо su

Рекомендуется использовать sudo вместо su по нескольким причинам:

• sudo ведёт лог привилегированных команд, запускаемых обычными пользователями;
• не нужно выдавать пароль от root каждому пользователю;
• поскольку полноценный root-терминал не создаётся, sudo не позволит пользователю случайно запустить команду с правами root, если в этом нет необходимости, что соответствует принципу минимальных привилегий.
• можно разрешить использование отдельной программы отдельному пользователю вместо предоставления полного root-доступа для запуска этой же команды. Например, выдать пользователю alice доступ к конкретной программе можно следующим образом:

# visudo

/etc/sudoers

alice ALL = NOPASSWD: /путь/к/программе

Либо же можно дать доступ к отдельной команде для всех пользователей. Настройки для разрешения обычным пользователям монтировать Samba-каталоги на удалённом сервере:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

Теперь все пользователи из группы users смогут запускать команды /sbin/mount.cifs и /sbin/umount.cifs с любой машины (ALL).

Совет: Для команды visudo лучше использовать не vi, а ограниченную версию редактора nano:

/etc/sudoers

Defaults editor=/usr/bin/rnano

Запуск команды с явным указанием переменной окружения EDITOR=nano visudo связан с некоторыми рисками безопасности, поскольку переменной EDITOR можно присвоить абсолютно любое значение.

Редактирование файлов с sudo

См. sudo (Русский)#Редактирование файлов. Используйте ограниченные версии редакторов rvim и rnano, которые можно безопасно запускать с правами root.

Ограничения на вход в root

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

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

PAM-модуль pam_wheel.so позволяет настроить доступ к su только для пользователей из группы wheel. См. su (Русский)#su и wheel.

Запрет на вход по SSH

Даже если вы не собираетесь запрещать локальным пользователям вход в root-аккаунт, имеет смысл всё же запретить вход в root по SSH. Это не позволит полностью скомпроментировать вашу систему удалённо.

Параметры входа в access.conf

Когда кто-то пытается выполнить вход с помощью PAM, файл /etc/security/access.conf просматривается в поисках первой комбинации, совпадающей с параметрами входа. Попытка считается успешной или неудачной в зависимости от настроек для совпавшей комбинации.

+:root:LOCAL
-:root:ALL

Правила могут задаваться для групп и для отдельных пользователей. В примере ниже пользователь archie может выполнять локальный вход, как и пользователи в группах wheel и adm. Все прочие попытки входа отклоняются:

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

Подробнее см. access.conf(5).

Мандатное управление доступом

Мандатное управление доступом (Mandatory access control, MAC) — политика безопасности, которая часто противопоставляется применяемой по умолчанию в большинстве дистрибутивов Linux, в том числе и в Arch, политике избирательного управления доступом (Discretionary access control, DAC). MAC означает, что каждое действие программы, любым образом влияющее на систему, проверяется на соответствие набору правил безопасности, причём обычные пользователи, в отличие от DAC, изменить этот набор правил не могут. Мандатная система управления доступом значительно повышает защищённость системы, хотя многое зависит от конкретной реализации.

MAC на основе путей к файлам

Самая простая форма управления доступом — задание прав доступа на основе путей к файлам. Отрицательным моментом является то, что права доступа не перемещаются вместе с файлом при его перемещении и не исчезают при удалении файла из системы, позитивным — путевой MAC можно реализовать на широком диапазоне существующих файловых систем, чего не скажешь о MAC с использованием меток.

• AppArmor — реализация MAC, развиваемая компанией Canonical. Позиционирует себя как "лёгкая" альтернатива SELinux.
• TOMOYO — ещё одна простая и удобная в использовании система MAC. Минималистичная реализация, требующая очень небольшого количества зависимостей.

MAC на основе меток

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

• В SELinux, проекте АНБ по повышению безопасности Linux, MAC реализован полностью отдельно от пользователей и их ролей. Сверхнадёжная многоуровневая политика MAC обеспечивает удобное управление системой, в том числе и в случае её роста и модификации.

Списки управления доступом

Списки управления доступом (Access Control Lists, ACL) — ещё один способ задания правил непосредственно в файловой системе. Управление доступом с помощью ACL подразумевает сравнение действий программ со списками разрешённого поведения.

Ядро

Безопасное ядро и защита от эксплойтов

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

Следует однако учитывать, что некоторые пакеты отказываются работать с этой версией ядра. Например:

• skypeforlinux-bin^AUR
• throttled

Если ваш драйвер (например, для NVIDIA) не входит в дерево исходников ядра, возможно, придётся переключиться на его DKMS-версию.

Проверка ASLR пространства пользователя

В пакете linux-hardened представлена улучшенная версия Address Space Layout Randomization (ASLR) для процессов в пространстве пользователя. Команда paxtest позволяет оценить уровень энтропии.

64-битные процессы

linux-hardened 5.4.21.a-1-hardened

Anonymous mapping randomization test     : 32 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 40 quality bits (guessed)
Heap randomization test (PIE)            : 40 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 32 quality bits (guessed)
Main executable randomization (PIE)      : 32 quality bits (guessed)
Shared library randomization test        : 32 quality bits (guessed)
VDSO randomization test                  : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)

linux 5.5.5-arch1-1

Anonymous mapping randomization test     : 28 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 28 quality bits (guessed)
Heap randomization test (PIE)            : 28 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 28 quality bits (guessed)
Main executable randomization (PIE)      : 28 quality bits (guessed)
Shared library randomization test        : 28 quality bits (guessed)
VDSO randomization test                  : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)

linux-lts 4.19.101-1-lts

Anonymous mapping randomization test     : 28 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 28 quality bits (guessed)
Heap randomization test (PIE)            : 28 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 28 quality bits (guessed)
Main executable randomization (PIE)      : 28 quality bits (guessed)
Shared library randomization test        : 28 quality bits (guessed)
VDSO randomization test                  : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)

32-битные процессы (для ядра x86_64)

linux-hardened

Anonymous mapping randomization test     : 16 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 22 quality bits (guessed)
Heap randomization test (PIE)            : 27 quality bits (guessed)
Main executable randomization (ET_EXEC)  : No randomization
Main executable randomization (PIE)      : 18 quality bits (guessed)
Shared library randomization test        : 16 quality bits (guessed)
VDSO randomization test                  : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)

linux

Anonymous mapping randomization test     : 8 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 13 quality bits (guessed)
Heap randomization test (PIE)            : 13 quality bits (guessed)
Main executable randomization (ET_EXEC)  : No randomization
Main executable randomization (PIE)      : 8 quality bits (guessed)
Shared library randomization test        : 8 quality bits (guessed)
VDSO randomization test                  : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization

Ограничение доступа к указателям ядра в файловой системе /proc

Если установить параметр kernel.kptr_restrict в значение 1, то адреса символов ядра в файле /proc/kallsyms будут скрыты от обычных пользователей без привилегии CAP_SYSLOG. Это усложнит динамическое разрешение адресов/символов в эксплойтов ядра. В случае предварительно скомпилированного ядра Arch это поможет слабо, поскольку атакующий просто скачает пакет ядра и вручную найдёт нужные адреса, но для пользовательских сборок этот флаг даёт защиту от локальных root-эксплойтов. Учтите, что это "сломает" некоторые команды perf, запускаемые от обычного пользователя (впрочем, для большинства команд perf всё равно нужны права root). Подробнее см. FS#34323.

Если установить kernel.kptr_restrict в значение 2, то адреса в файле /proc/kallsyms будут скрыты вне зависимости от привилегий.

/etc/sysctl.d/51-kptr-restrict.conf

kernel.kptr_restrict = 1

Примечание: В linux-hardened по умолчанию используется значение kptr_restrict=2.

Защита BPF

BPF — система динамической загрузки байткода в ядро и его исполнения. Используется некоторыми подсистемами ядра, такими как сетевой стек (XDP, tc), трассировка (kprobes, uprobes, tracepoints) и безопасность (seccomp). Также полезна при построении систем продвинутой сетевой безопасности, повышении производительности и динамической трассировке.

Первоначально аббревиатура BPF означала Berkeley Packet Filter, поскольку оригинальный "классический" BPF использовался в инструментах перехвата пакетов в операционной системе BSD. Со временем проект трансформировался в Extended BPF (eBPF), который вскоре снова был переименован обратно в BPF (уже не аббревиатура). Важно не путать BPF с инструментами фильтрации пакетов вроде iptables и netfilter, хотя в принципе BPF может использоваться и для создания таких программ.

Код BPF может как интерпретироваться, так и компилироваться с помощью JIT-компиляции. Ядро Arch собирается с флагом CONFIG_BPF_JIT_ALWAYS_ON, который отключает BPF-интерпретатор, поэтому BPF работает только через JIT-компиляцию. В результате атакующему сложнее использовать BPF для атак на уязвимости типа SPECTRE. Подробнее см. описание патча, в котором был впервые введён флаг CONFIG_BPF_JIT_ALWAYS_ON.

В ядре есть встроенные возможности для JIT-скомпилированного BPF, которые защищают от некоторых JIT-spraying атак ценой снижения производительности и невозможности выполнять трассировку и отладку BPF-программ. Они включаются флагом net.core.bpf_jit_harden, который устанавливается в значение 1 для защиты непривилегированного кода или в значение 2, если необходимо защитить весь код.

Настройки net.core.bpf_* смотрите в документации ядра.

Совет:

• В ядре linux-hardened по умолчанию установлено значение net.core.bpf_jit_harden=2.
• По умолчанию программы BPF могут запускать даже обычные пользователи. Чтобы изменить это поведение, установите kernel.unprivileged_bpf_disabled=1[5].

Зона доступа ptrace

Системный вызов ptrace(2) позволяет одному процессу ("трассировщику") наблюдать за выполнением другого процесса, управлять им, а также получить доступ к его памяти и регистрам. Вызов ptrace обычно используется в программах-отладчиках вроде gdb, strace, perf или reptyr. Тем не менее, вредоносные программы с помощью данного системного вызова также могут получать доступ к данным и перехватывать управление процессами.

В Arch по умолчанию включён модуль Yama LSM, в котором задан параметр ядра kernel.yama.ptrace_scope. Параметр установлен в значение 1 (restricted), что не даёт трассировщику выполнять вызов ptrace вне определённой зоны доступа. Исключение составляют только трассировщики, запущенные в привилегированном режиме или с capability CAP_SYS_PTRACE. Это значительно повышает защищённость системы по сравнению с обычными настройками. Без данного модуля по сути нет никакого барьера между процессами, запущенными одним пользователем, поскольку не создаются дополнительные слои безопасности вроде pid_namespaces(7).

Примечание: Программы, использующие системный вызов ptrace, всё ещё можно будет запускать в привилегированном режиме, например, с помощью sudo.

Если вы не планируете использовать отладчики, то имеет смысл установить kernel.yama.ptrace_scope в значение 2 (ptrace доступен только администраторам) или 3 (полный запрет).

hidepid

Важно:

• Могут возникнуть проблемы с некоторыми приложениями при запуске их в песочнице, а также с Xorg (существует обходное решение).
• При использовании systemd версии > 237.64-1 возникают проблемы с D-Bus, Polkit, PulseAudio и Bluetooth.

В ядре предусмотрена возможность скрыть процессы, обычно отображаемые в файловой системе /proc, от непривилегированных пользователей. Для этого необходимо смонтировать данную ФС с флагами hidepid= и gid=. Подробнее см. документацию ядра.

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

Группа proc, предоставляемая пакетом filesystem, представляет собой "белый список" пользователей, которые могут видеть информацию о процессах других пользователей. Если необходимо предоставить какому-то пользователю или службе доступ в каталоги /proc/<pid>, то добавьте его в эту группу.

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

/etc/fstab

proc	/proc	proc	nosuid,nodev,noexec,hidepid=2,gid=proc	0	0

Для корректной работы сеансов необходимо добавить исключение в настройки systemd-logind:

/etc/systemd/system/systemd-logind.service.d/hidepid.conf

[Service]
SupplementaryGroups=proc

Ограничение загрузки модулей

В базовом ядре Arch включён флаг CONFIG_MODULE_SIG_ALL, что подразумевает обязательное наличие подписи у модулей, входящих в пакет linux. Это даёт возможность ограничить загрузку модулей, чтобы загружались только те из них, у которых имеется действительная подпись, то есть модули, не входящие в дерево исходников ядра, например, скомпилированные локально или входящие в сторонние пакеты вроде virtualbox-host-modules-arch, загружаться не будут.

Ограничение включается параметром ядра module.sig_enforce=1. Подробнее см. документацию ядра.

Отключение kexec

Kexec позволяет "подменить" работающее в настоящий момент ядро.

/etc/sysctl.d/51-kexec-restrict.conf

kernel.kexec_load_disabled = 1

Совет: В ядре linux-hardened kexec по умолчанию отключён.

Lockdown-режим

С версии 5.4 в ядро добавлен режим lockdown, который позволяет создать дополнительный барьер безопасности между ядром и суперпользователем. При этом некоторые приложения, полагающиеся на низкоуровневый доступ к аппаратуре или ядру, могут перестать работать.

Для работы в lockdown-режиме необходимо выбрать его тип и инициализировать модули LSM.

Все официально поддерживаемые ядра инициализируют LSM-модули, но сам режим не включают.

Совет: Командой cat /sys/kernel/security/lsm можно вывести список активных LSM-модулей.

Существует два типа lockdown-режима:

• integrity: отключены возможности, которые позволяют пользователю модифицировать запущенное ядро (kexec, bpf).
• confidentiality: также отключены возможности, которые позволяют пользователю извлечь из ядра конфиденциальную информацию.

Рекомендуется использовать integrity, если ваша модель угроз не диктует иное.

Для включения lockdown-режима во время выполнения (runtime) выполните:

# echo режим > /sys/kernel/security/lockdown

Чтобы ядро запускалось в lockdown-режиме при загрузке, используйте параметр ядра lockdown=режим.

Примечание:

• Отключить lockdown-режим во время выполнения невозможно.
• В lockdown-режиме не работает гибернация.

См. также kernel_lockdown(7).

Linux Kernel Runtime Guard (LKRG)

LKRG (lkrg-dkms^AUR) — модуль для проверки целостности ядра и обнаружения попыток эксплуатации уязвимостей.

Запуск приложений в песочнице

См. также статью Песочница в Википедии.

Примечание: Опция работы с namespace для пользователей (CONFIG_USER_NS) в настоящее время включена в ядрах linux, linux-lts, linux-zen и linux-hardened. Её отсутствие может повлиять на доступность для приложений некоторой функциональности песочниц.

Важно: Опция работы с namespace для непривилегированных пользователей (CONFIG_USER_NS_UNPRIVILEGED) по умолчанию включена в ядрах linux, linux-lts и linux-zen, что существенно увеличивает поверхность атаки в плане локальной эскалации привилегий (смотрите FS#36969).

Для повышения безопасности вы можете:

• использовать ядро linux-hardened, в котором используется безопасное значение по умолчанию, или
• с помощью sysctl установить параметр kernel.unprivileged_userns_clone в значение 0.

Имейте в виду, что это может нарушить работу некоторых приложений, например Zoom. Также может понадобиться заменить bubblewrap на bubblewrap-suid, если он установлен; смотрите Bubblewrap#Installation.

Firejail

Firejail — удобный инструмент для запуска приложений и серверов в песочнице. Изначально он был создан для браузеров и других интернет-приложений, но сейчас поддерживает большое количество программ. Он устанавливается как suid-программа и создаёт изолированную среду на базе белых и чёрных списков.

bubblewrap

bubblewrap — песочница, разработанная для непривилегированных контейнерных инструментов, таких как Flatpak, причём с потреблением памяти даже меньшим, чем у Firejail. В bubblewrap не хватает некоторых возможностей, вроде списков разрешённых путей к файлам; тем не менее, в нём реализованы bind-монтирование, создание user/IPC/PID/network/cgroup namespaces, а также поддержка как простых, так и сложных песочниц.

Bubblejail основан на bubblewrap и предоставляет модель разрешений, ориентированную на ресурсы, с графическим интерфейсом для их настройки.

chroot

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

Linux containers

Linux Containers — ещё один неплохой способ изоляции приложений, особенно когда вы нуждаетесь в большем разделении, чем предлагается в других программах виртуализации (вроде KVM или VirtualBox). LXC запускается поверх существующего ядра в псевдо-chroot окружении с собственным виртуальным аппаратным обеспечением.

Прочие способы виртуализации

Программы полной виртуализации вроде VirtualBox, KVM, Xen или Qubes OS (основанной на Xen) помогают повысить изолированность и безопасность при запуске небезопасного приложения или при переходе в браузере на подозрительные веб-сайты.

Сеть и межсетевые экраны

Межсетевые экраны

Утилиты iptables и nftables — два фронт-энда для встроенного в ядро Linux межсетевого экрана Netfilter. По умолчанию они не включены. Для защиты работающих в системе служб рекомендуется настроить и запустить межсетевой экран — как правило, в разного рода руководствах нет указаний по защите отдельных служб, зато межсетевой экран предоставляет комплексную и надёжную защиту.

• В статьях iptables и nftables вы найдёте общую информацию о работе межсетевых экранов.
• В статье Настройка межсетевого экрана приведено руководство по настройке экрана iptables.
• В статьях из категории Firewalls можно найти другие способы работы с netfilter.
• В статье Ipset описываются способы блокировки списков IP-адресов.
• opensnitch — межсетевой экран с поддержкой настраиваемых правил по приложениям, портам, хостам и т.д.

Открытые порты

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

Если служба не требует доступа в сеть, то её можно привязать либо к сокету Unix (см. unix(7)), либо к адресу петлевого интерфейса вида localhost (но не к непетлевому адресу 0.0.0.0/0).

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

Вывести список открытых портов можно командой ss -l. Чтобы вывести список процессов и прослушиваемые ими TCP- и UDP-порты, выполните:

# ss -lpntu

Подробнее см. ss(8).

Параметры ядра

Параметры ядра, относящиеся к взаимодействию с сетью, можно настроить утилитой sysctl. Подробнее см. sysctl (Русский)#Защита стека TCP/IP.

SSH

Для защиты от атаки методом "грубой силы" рекомендуется настроить аутентификацию по ключу. В случае OpenSSH см. OpenSSH#Вход только по открытому ключу. Утилиты Fail2ban и Sshguard предлагают дополнительную защиту посредством ведения логов и создания правил межсетевого экрана, но они уязвимы для спуфинга, поскольку атакующий может изменить пакеты таким образом, что они будут выглядеть как посланные администратором (если известен его IP-адрес). От подмены IP-адресов также можно защититься, см. sysctl (Русский)#Reverse path filtering и sysctl (Русский)#Отключение перенаправлений ICMP.

Двухфакторная аутентификация обеспечивает дополнительную безопасность аккаунтов пользователей. В Google Authenticator применяется двухшаговая процедура аутентификации с использованием одноразовых паролей (one-time passcodes, OTP).

Запрет на вход суперпользователя также считается хорошей практикой, по двум причинам: это помогает отслеживать случаи проникновения злоумышленников в систему, а также создает дополнительный барьер перед получением root-доступа. Для OpenSSH см. OpenSSH#Отключение.

Mozilla опубликовала руководство по настройке OpenSSH с подробным логированием и более жёсткими требованиями к шифрованию.

DNS

Стандартная конфигурация DNS работает почти всегда, но имеет некоторые недостатки в плане безопасности. См. Разрешение доменных имён#Приватность и безопасность.

Прокси

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

Например, представьте, что некое приложение (запущенное к тому же с правами root) использует функцию разрешения DNS-имён из стандартной библиотеки glibc. Баг в этой функции автоматически приведет к появлению RCE-уязвимости в приложении. Кэширующий DNS-сервер вроде dnsmasq, работающий как прокси, позволит этого избежать [6].

Управление TLS-сертификатами

См. TLS#Trust management.

Физическая безопасность

Физический доступ к машине как правило означает и root-доступ — при наличии достаточного количества времени и ресурсов. Тем не менее, можно создать ряд барьеров, которые повысят уровень защищённости системы и от таких воздействий.

Установив вредоносное устройство FireWire, Thunderbolt или PCI Express, дающее доступ к памяти, атакующий при следующей загрузке получит полный доступ к системе [7]. В случае Thunderbolt вы можете ограничить прямой доступ к памяти полностью или для конкретных устройств, см. Thunderbolt#User device authorization. В случае Firewire или PCI Express вы мало что можете сделать, как и при модификации собственно аппаратного обеспечения компьютера — например, при записи вредоносной прошивки в контроллер устройства хранения данных. Тем не менее, как правило большинство атакующих не столь изощрённы.

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

Блокировка BIOS

Пароль BIOS не позволит кому-либо загрузиться со съёмного носителя (такая загрузка обычно означает root-доступ к системе). Убедитесь, что ваш носитель — первый в порядке загрузки, и отключите загрузку с других устройства и дисков.

Загрузчики

Очень важно защитить ваш загрузчик. Отсутствие такой защиты позволит обойти любые ограничения входа, например, установив параметр ядра init=/bin/sh, чтобы загрузиться напрямую в оболочку.

Syslinux

Syslinux поддерживает задание пароля. Можно установить либо один глобальный пароль, либо отдельные пароли для пунктов меню.

GRUB

GRUB также поддерживает пароли, подробнее см. GRUB#Защита загрузчика паролем. Также поддерживается шифрование boot-раздела, в результате чего незашифрованными остаются только отдельные участки кода загрузчика. Настройки GRUB, ядро и initramfs будут зашифрованы.

Secure Boot

Secure Boot — функциональность UEFI по проверке файлов во время загрузки системы. Это позволяет предотвратить атаки вида evil maid, например, с подменой файлов на загрузочном разделе. Обычно производители снабжают компьютеры готовыми OEM-ключами, но в режиме Setup Mode пользователь может заменить их на свои и использовать для настройки безопасной загрузки.

Trusted Platform Module (TPM)

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

Загрузочный раздел на съёмном носителе

Довольно популярная идея, смысл которой в том, что система не сможет загрузиться без boot-раздела, который вынесен на съёмный флэш-накопитель. Часто при этом используется полное шифрование диска, а также размещение на загрузочном разделе заголовочных файлов шифрования.

Данный подход можно также совместить с шифрованием /boot-раздела.

Автоматический выход

Если вы используете Bash или Zsh, то переменная TMOUT позволяет настроить автоматический выход из оболочки по истечении определённого периода времени.

Например, настройки для автоматического выхода из виртуальных консолей (но не из эмуляторов терминала в X11):

/etc/profile.d/shell-timeout.sh

TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
	/dev/tty[0-9]*) export TMOUT;;
esac

Если же вы хотите задать таймаут при работе в произвольном сеансе Bash/Zsh, выполните:

$ export TMOUT="$(( 60*10 ))";

Учтите, что команда не сработает, если в оболочке уже выполняется какой-то процесс (например, SSH-сессия или другая оболочка без поддержки переменной TMOUT). Однако если вы используете виртуальную консоль главным образом при перезапуске зависшего GDM/Xorg с правами root, это может оказать весьма удобным.

Защита от мошеннических USB-устройств

Установите USBGuard, который помогает защититься от мошеннических USB-носителей (вроде BadUSB, PoisonTap или LanTurtle) с помощью белых и чёрных списков устройств, составляемых на основе их атрибутов.

Сбор изменяющихся данных

В процессе работы компьютер может быть уязвим для сбора изменяющихся данных^{[устаревшая ссылка 2022-09-23 ⓘ]}. Лучше всего отключать компьютер в те моменты, когда он не нужен, или когда его физическая безопасность под вопросом (например, при прохождении поста службы безопасности в каком-либо учреждении).

Пакеты

Аутентификация

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

Обновления

Важно выполнять обновление системы на регулярной основе.

Отслеживание уязвимостей

Подпишитесь на рассылку Common Vulnerabilities and Exposure (CVE) Security Alert, которая ведётся National Vulnerability Database и находится на странице загрузки NVD. Arch Linux Security Tracker — другой полезный ресурс, в котором объединены Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) и данные о CVE. Утилитой arch-audit можно проверить наличие уязвимостей в работающей системе. Также можно использовать графический трей arch-audit-gtk. См. также Arch Security Team.

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

Пересборка пакетов

Иногда имеет смысл пересобрать пакет, чтобы удалить из него нежелательную функциональность и уменьшить поверхность атаки. Например, пакет bzip2 можно пересобрать без bzip2recover, чтобы избежать CVE-2016-3189. Также при пересборке можно применить различные флаги безопасности, как вручную, так и с помощью программ-обёрток.

Флаг	Назначение
-D_FORTIFY_SOURCE=2	Обнаружение переполнения буфера во время выполнения
-D_GLIBCXX_ASSERTIONS	Проверка границ строк и контейнеров С++ во время выполнения
-fasynchronous-unwind-tables	Повышение надёжности трассировки
-fexceptions	Отключение тредов на основе таблиц
-fpie -Wl,-pie	Полный ASLR для исполняемых файлов
-fpic -shared	Отключение перемещений текста для динамических библиотек
-fplugin=annobin	Генерирование данных о контроле качества защищённости
-fstack-clash-protection	Повышение надёжности обнаружения переполнения стека
-fstack-protector или -fstack-protector-all	Защита от срыва стека
-fstack-protector-strong	Аналогично
-g	Добавление отладочной информации
-grecord-gcc-switches	Сохранение флагов компилятора в отладочной информации
-mcet -fcf-protection	Управление защитой целостности
-O2	Рекомендованный уровень оптимизации
-pipe	Избегать использования временных файлов, ускорение сборки
-Wall	Рекомендованный уровень предупреждений компилятора
-Werror=format-security	Блокировать потенциально небезопасные аргументы форматной строки
-Werror=implicit-function-declaration	Блокировать компиляцию при отсутствии прототипов функций
-Wl,-z,defs	Обнаруживать и блокировать перелинковку
-Wl,-z,now	Отключение "ленивого связывания"
-Wl,-z,relro	После перемещения сегменты доступны только на чтение

• О флагах и их значении

Смотрите также

• Arch Linux Security Tracker
• CentOS Wiki: OS Protection
• Hardening the Linux desktop
• Hardening the Linux server
• Linux Foundation: Linux workstation security checklist
• privacyguides.org Privacy Resources
• Red Hat Enterprise Linux 7 Security Guide
• Securing Debian Manual
• The paranoid #! Security Guide