Security (Русский)

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

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

Принципы

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

Пароли

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавьте в файл следующие строки:

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

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

Процессор

Микрокод

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

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

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

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

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

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

Многопоточность

Одновременная многопоточность (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 (, ) — безопасный аналог функции malloc() из стандартной библиотеки glibc. Изначально проект разрабатывался для внедрения в библиотеки Bionic (Android) и musl (GraphenOS), однако имеется и встроенная поддержка обычных 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-репозитории проекта.

Данные

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• /var

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

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

Например:

# chmod 700 /boot /etc/{iptables,arptables}

Umask по умолчанию имеет значение , его можно изменить для безопасности новых файлов. В руководстве по безопасности RHEL5 рекомендуется значение umask как обеспечивающее максимальный уровень безопасности, поскольку любые создаваемые файлы будут доступны на чтение только владельцу. В статье Umask#Set the mask value описано, как изменить значение umask.

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

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

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

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

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

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

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

Добавьте следующую строку в файл , чтобы установить паузу в 4 секунды после неудачной попытки входа:

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

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

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

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

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

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

Настройки модуля находятся в файле . Параметры для настройки блокировок:

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

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

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

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

* soft nproc 100
* hard nproc 200

Текущее число потков для каждого пользователя можно узнать командой . Это позволит определить целесообразные значения пределов.

Запуск Xorg без root

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

В статье Xorg#Использование Xorg без прав суперпользователя описано, как запустить Xorg без прав root. В качестве альтернативы можно вместо Xorg использовать Wayland.

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

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

sudo вместо su

Причины, по которым лучше вместо su использовать для привилегированного доступа sudo, перечислены в статье su. Например:

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

# visudo

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

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

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

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

См. Sudo#Editing files. Используйте ограниченные версии редакторов и rnano, которые можно безопасно запускать с правами root.

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

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

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

PAM-модуль позволяет настроить доступ к su только для пользователей из группы . См. su#su and 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

Подробнее см. .

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

Мандатное управление доступом (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 подразумевает сравнение действий программ со списками разрешённого поведения.

Ядро

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

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

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

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

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

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

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

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)

Ограничение доступа к логам ядра

Логи ядра содержат ценную информацию (например, критичные для системы адреса памяти), с помощью которой атакующий может создать эксплойт. Флаг запрещает доступ к логам для процессов без capability (которая по умолчанию есть только у процессов, запущенных от root).

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

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

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

Если установить в значение 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_* смотрите в документации ядра.

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

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

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

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

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

hidepid

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

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

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

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

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

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

[Service]
SupplementaryGroups=proc

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

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

Отключение kexec

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

Lockdown-режим

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

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

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

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

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

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

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

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

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

Примечание:

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

См. также .

Linux Kernel Runtime Guard (LKRG)

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

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

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

Firejail

Firejail — удобный инструмент для запуска приложений и серверов в песочнице. Рекомендован для браузеров и подключённых к сети приложений, а также любых серверов.

bubblewrap

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

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-адресов.

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

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

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

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

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

# ss -lpntu

Подробнее см. .

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

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

SSH

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

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

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

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

DNS

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

Прокси

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

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

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

См. TLS#Trust management.

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

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

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

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

Блокировка BIOS

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

Загрузчики

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

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

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

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

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

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

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

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

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

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

Пакеты

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

Атака на пакетный менеджер возможна при неправильной работе с подписями пакетов, хотя и менеджеры, подсистема подписей которых в порядке, тоже не являются абсолютно безопасными. 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 Security Team.

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

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

Иногда имеет смысл пересобрать пакет, чтобы удалить из него нежелательную функциональность и уменьшить поверхность атаки. Например, пакет можно пересобрать без , чтобы избежать 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
• privacytools.io Privacy Resources
• Red Hat Enterprise Linux 7 Security Guide
• Securing Debian Manual
• The paranoid #! Security Guide