Ця сторінка містить зміни, які я роблю у ванільній установці Arch Linux для забезпечення безпеки, а також деякі інші зміни, які я вважаю корисними. Більшість змін буде працювати на будь-якому дистрибутиві Linux, яка є досить актуальною. Це не одноразове налаштування, але, сподіваюся, певні його частини будуть корисні для кожного, хто хоче отримати більш безпечну систему Linux.
Останнє оновлення: 01/05/2022
З точки зору безпеки, Arch варто враховувати з кількох причин:
Розмір встановленого дистрибутиву: Базова установка відносно мінімальна порівняно з такими дистрибутивами як Fedora або Mint. Це дозволяє мені зосередитися на додаванні тільки того, що я хочу, а не постійно намагатися вилучати зайве і вимикати фонові служби, які мені не потрібні.
Ядро: Розповсюджується загальний міф про те, що ядро Linux є безпечним, або що користувачі можуть довгий час не турбуватися про оновлення безпеки. Нічого з цього навіть далеко не правда. Нові версії Linux виходять майже щотижня, часто містять важливі виправлення безпеки серед багатьох інших змін. Ці релізи зазвичай не вказують явно, які коміти мають безпекові наслідки. Внаслідок цього багато «стабільних» або «LTS» дистрибутивів не знають, які коміти слід повернути назад на свої старі ядра, чи навіть що-небудь потребує повернення взагалі. Якщо проблемі призначений CVE, можливо, ваш дистрибутив його виправить. Можливо, ні. Навіть якщо CVE існує, принаймні в разі Ubuntu і Debian особливо, користувачі часто залишаються з ядрами, які повні відомих дір протягом місяців підряд. Red Hat і подібні "підприємницькі" дистрибутиви також мають таку саму проблему. Крім того, команда з безпеки ядра Linux не запитує CVE для жодних вразливостей, частково через те, що їх просто занадто багато, щоб відстежувати. Культура дочірніх структур, що намагаються вибирати виправлення безпеки в ім'я стабільності не працює. Arch не грає в гру повернення назад, вибираючи замість цього надавати найновіші стабільні ядра незабаром після їх випуску.
The Arch Build System: Довгий час користуючись системою ports у FreeBSD та OpenBSD, користування ABS було приємним. Це полегшує створення/перестворення пакунків. Це полегшує оновлення пакунків. Це показує, як справжньо будуються речі і з якими параметрами. Ця ідея, запозичена з BSD, робить взаємодію з системою пакунків простою і прозорою.
Тепер перейдемо до того, як я укріплюю безпеку.
У цьому розділі містяться кілька порад для розгляду під час створення початкової розмітки диска. Концепції повинні бути застосовні до будь-якого дистрибутиву.
Спочатку розгляньте можливість використання шифрування всього диска разом із логічним об'єднанням томів. Шифрування диска захищає дані у спокої, а LVM дозволяє отримати певну гнучкість, яка може бути дуже корисною. Просте розташування диска може виглядати так:
Розділення логічних томів для різних точок монтування має кілька переваг, зокрема можливість встановлення прапорів монтування на конкретних каталогах. Розгляньте створення окремих логічних томів для /, /var та /home при установці. Для типового настільного комп'ютера, напевно, вам потрібно виділити більшість місця на диску для /home. Для інших двох не потрібно багато, якщо не існує конкретного випадку використання. У цьому прикладі використовуються 25 ГБ та 8 ГБ. Якщо вам потрібно мати велику базу даних у /var або що-небудь інше, вносьте відповідні зміни.
У Linux існує багато каталогів, до яких можна записувати користувачі, кожен з яких надає можливість зловмисникам виконувати свої власні виконувані файли. Після створення файлу fstab додайте прапори noexec та nodev до /var та /home. Це заборонить виконання виконуваних файлів на цих точках монтування, а також запобіже інтерпретації символьних або блочних спеціальних пристроїв на них. Два тимчасові файлові системи (/tmp та /dev/shm) також можна заблокувати за допомогою тих самих прапорів, додавши наступне:
# /etc/fstab [...] tmpfs /tmp tmpfs rw,noexec,nodev,size=1G,mode=1777 0 0 tmpfs /dev/shm tmpfs rw,noexec,nodev,size=1G 0 0
Ви можете змінювати розмір обмеження 1G, як вам зручно.
Після завершення установки та переходу до завершеного встановлення виглядатиме приблизно так:
# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert home lvm -wi-ao---- 189.12g root lvm -wi-ao---- 25.00g var lvm -wi-ao---- 8.00g # mount | egrep '(lvm|/tmp|shm)' | sort /dev/mapper/lvm-home on /home type ext4 (rw,nodev,noexec,relatime) /dev/mapper/lvm-root on / type ext4 (rw,relatime) /dev/mapper/lvm-var on /var type ext4 (rw,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nodev,noexec,size=1048576k) tmpfs on /tmp type tmpfs (rw,nodev,noexec,relatime,size=1048576k)
Ще один каталог, який можна записувати користувачам, - це /run, зокрема каталоги /run/user/$UID, які systemd створює, коли хтось входить в систему, але їхнє тимчасове природу визнають як неприємні та складні. Я досі не знайшов ідеального рішення, яке не порушувало б інші речі. FUSE - ще один спосіб для некореневих користувачів створювати нові точки монтування та виконувати виконувані файли. Якщо функція FUSE не потрібна, модуль ядра можна внести в чорний список.
Зазвичай менеджерам пакунків не потрібна додаткова конфігурація. Pacman, який використовує Arch, не виняток. Моє рекомендація для будь-якого менеджера пакунків - переконатися, що використовуються тільки дзеркала з TLS.
# /etc/pacman.d/mirrorlist Server = https://example.com/[...]/$repo/os/$arch
Перевірте генератор дзеркал, щоб побачити список серверів, здатних працювати з TLS, поруч з вами.
Використання дзеркала HTTPS з Pacman особливо важливе, оскільки він не перевіряє файли бази даних пакунків, і все запускається в системі root. HTTPS не вирішує ці дві проблеми, але воно є маленьким шансом захистити вас від деяких атак, які впливають на ці проблеми.
Додавання вашого сервера до вашого файла /etc/pacman.conf також додасть те, що часткові оновлення не підтримуються.
# /etc/pacman.conf [core] Include = /etc/pacman.d/mirrorlist
Останнім часом я розробив деякі методи, які можна використовувати для вивчення та автоматичного виявлення тих пакунків, які вже не обслуговуються, іноді з загальним кодом, який я намагаюся підтримувати, принаймні в простому стані. Ці інструменти незалежні від Pacman, але вони корисні для будь-якого дистрибутиву. Я думаю, що вони мають значення, тому що я їх написав, але багато інших може не погодитися.
Ядро - це одна з найбільш критичних компонентів вашої системи, тому його потрібно налаштувати з особливою увагою.
Використовуйте стандартні параметри ядра за замовчуванням, якщо немає ніяких вимог. Вони включають ті, що вимагаються для належної роботи UEFI та/або BIOS, такі як quiet і rw.
Рівень важливості (якщо ви користуєтеся SELinux) може бути встановлений за допомогою параметра security. У вас можуть бути різні причини використання одного або іншого рівня, але зазвичай варто вибрати selinux=0, apparmor=0 або не встановлювати нічого взагалі. Ці параметри можна встановити як глобальні параметри ядра або змінити в конфігурації загрузчика ядра.
Увімкнення підтримки сигналізації з помилкою (код 4) для оновлення ядра в ядрі Linux було виправлено в 5.17. До цього часу вона була вимкнена за замовчуванням через зловживання.
# /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="... pstore.print_all=1"
Однак, може бути сенс налаштувати додаткові параметри для захисту системи від деяких загроз. Наприклад, параметр slab_nomerge дозволяє захистити від атаки, коли зловмисники об'єднуються зайняті кеш-пам'ять, щоб зробити їх вразливими на переповнення буфера після їх перевірки на розмір.
# /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="... slab_nomerge"
Використання random.trust_cpu=on ініціалізує генератор випадкових чисел на кожному з ядер CPU, вірячи, що CPU генерують стійкий до атак шум. Це допомагає захистити вас від атак на випадкові числа, які використовуються в криптографії.
# /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="... random.trust_cpu=on"
Ще однією цікавою опцією є kaslr (запуск ядра на випадковій адресі). Це важливий аспект безпеки, оскільки зловмисники не можуть передбачити точку входу в ядро, якщо вона рандомізована. Це ускладнює атаки на віддалену експлуатацію, оскільки потрібно знайти вразливість і потім знайти спосіб її експлуатації.
# /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="... kaslr"
Після внесення цих змін перезавантажте систему або виконайте sudo grub-mkconfig -o /boot/grub/grub.cfg для завантажувального меню, якщо ви використовуєте GRUB. Після перезавантаження перевірте, що параметри було встановлено коректно.
Будь-який комп'ютер, що з'єднується з мережею, повинен використовувати брандмауер, але не завжди так відбувається. Зазвичай брандмауер відкриває всі порти за замовчуванням, тому вам потрібно розглянути налаштування стандартної політики.
Для iptables ви можете виконати наступне, щоб увімкнути всі порти:
# iptables -P INPUT DROP # iptables -P OUTPUT DROP # iptables -P FORWARD DROP # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
З цими правилами буде дуже важко налаштувати правильну роботу серверів, якщо ви використовуєте сервер. Також, це не належить до Arch, оскільки він використовує Uncomplicated Firewall (UFW), що дозволяє встановлювати стандартні правила.
Останній пункт важливий: не забудьте включити брандмауер в автозавантаження після перевірки того, як вони працюють. В іншому випадку ви зможете втратити з'єднання під час наступного перезавантаження системи.
Багато людей використовують sudo, але небагато роблять це безпечно. Деякі дистрибутиви налаштовані так, що дозволяють звичайним користувачам стати root, просто введучи свій власний пароль. Моє стурбовання від будь-якого використання sudo, яке включає введення пароля для підвищення привілеїв, походить з того факту, що X11 дозволяє будь-якому додатку перехоплювати натискання клавіш.
Моя рекомендована настройка sudo дозволяє звичайному користувачеві виконувати деякі адміністративні завдання в системі як root, не вводячи пароль. У моєму випадку такі завдання включають оновлення пакунків та перезавантаження. Як тільки моя система налаштована так, як я хочу, цього дійсно все, що мені потрібно робити як root.
# /etc/sudoers Defaults env_reset Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" Defaults umask=0022 Defaults umask_override root ALL=(ALL:ALL) ALL Cmnd_Alias PACMAN = /usr/bin/pacman -Syu Cmnd_Alias REBOOT = /sbin/reboot "" Cmnd_Alias SHUTDOWN = /sbin/poweroff "" bh ALL=(root) NOPASSWD: PACMAN bh ALL=(root) NOPASSWD: REBOOT bh ALL=(root) NOPASSWD: SHUTDOWN
Така настройка дозволить моєму користувачеві запускати pacman -Syu як root (але не будь-які інші команди pacman), а також дозволить мені перезавантажувати та вимикати комп'ютер.
Для будь-яких інших адміністративних завдань я увійду як root на віртуальну консоль (ctrl + alt + f2) і виконаю їх там. Це трохи незручно, але небезпека перехоплення клавіш X11 реальна. Не вірите мені? Ось невеликий кейлогер, який може зберегти введений пароль sudo для подальшого використання.
Якщо помилка в програмі дозволяє компрометувати процес, злоумисник фактично може робити все, що може ця програма: підключатися до Інтернету, читати файли, записувати файли і так далі. Песочниця - це спосіб обмежити потенційний шкідливий вплив компрометованого процесу.
Firejail - це інструмент, який мені найбільше подобається для цієї задачі. Він легко налаштовується, надає розумні значення за замовчуванням і може бути подальшим зміцненням за допомогою простих файлів конфігурації. Щоб встановити його на Arch, виконайте наступне:
# pacman -S firejail # systemctl enable --now apparmor # apparmor_parser -r /etc/apparmor.d/firejail-default # firecfg # echo XXX > /etc/firejail/firejail.users
Замініть XXX на своє ім'я звичайного користувача, не root.
Після цього firejail створить символічні посилання на всі встановлені додатки, для яких він має профіль. Вони розміщуються в каталозі /usr/local/bin, що означає, що ваша змінна оточення PATH повинна вказувати туди першою. Це можна зробити, експортуючи змінну в оболонці користувача (~/.bashrc або подібний) або в /etc/profile для всіх користувачів.
[...] export PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
Розгляньте можливість виконання firecfg, якщо ви вже встановили всі програми, які вам потрібні. В іншому випадку він повинен бути запущений знову після встановлення будь-яких нових додатків у випадку, якщо Firejail має для них профіль.
Додаткові обмеження можуть бути встановлені за допомогою власних профілів в каталозі користувача ~/.config/firejail. Якщо ви хочете заборонити програвачу музики Clementine перезаписувати теги у вашій музичній колекції, може підійти наступний приклад.
# /home/user/.config/firejail/clementine.profile
whitelist ${HOME}/music
read-only ${HOME}/musiC
include /etc/firejail/clementine.profile
Для перевірки роботи скористайтеся прапорцем --list під час виконання у пісочниці додатка.
$ firejail --list 14609:bh::/usr/bin/firejail /sbin/clementine 17755:bh::/usr/bin/firejail /sbin/firefox
Більше інформації та прикладів можна знайти в розділі створення власних профілів документації. Також перегляньте посібник X11 для деяких порад щодо подальшої ізоляції GUI-додатків.
Bubblewrap - це ще одна опція для розгляду песочення.
Якщо ваша апаратна частина має можливості бездротового зв'язку або блютуз і ви хочете вимкнути їх програмно, rfkill може зробити це. Він включений в пакунок util-linux.
$ rfkill list ID TYPE DEVICE SOFT HARD 0 bluetooth hci0 blocked unblocked 1 wlan phy0 blocked unblocked
Блокування одного або обох пристроїв при запуску можна зробити, активуючи відповідний сервіс:
# systemctl enable --now rfkill-block@all.service
Замініть all на bluetooth або wlan, за бажанням.
Оскільки годинники на більшості комп'ютерів мають тенденцію відхилятися від часу з плином часу, добре було б запустити якийсь NTP клієнт.
Існує різноманітні варіанти. Встановленої в базовій установці Arch (і будь-якої системи на основі systemd) включає systemd-timesyncd, але я не дуже прихильник його. Якщо думка про встановлення ще одного пакунка для завдання, яке технічно можна виконати за допомогою того, що ви вже маєте, викликає вас дрож у коліні, відверніться зараз і використовуйте цей. Я рекомендую використовувати OpenNTPD замість цього. Він легкий і має відмінну безпекову історію.
# pacman -S openntpd # systemctl disable --now systemd-timesyncd # systemctl enable openntpd
Він буде використовувати пул ntp.org за замовчуванням для синхронізації часу. Це "добре", але пул ntp.org включає багато низькоякісних серверів. Деякі з них працюють на віртуальних машинах. Деякі з них вже не працюють і ніколи не були видалені. Колація round-robin DNS навіть може дати вам сервер, який знаходиться від вашого фактичного місцезнаходження на відстані 100 мс або більше. Беручи це до уваги, я рекомендую використовувати деякі відомо-хороші сервери в файлі конфігурації.
server time.apple.com server time.cloudflare.com server pool.ntp.org constraint from "https://example.com"
Якщо наявність назв компаній у файлі конфігурації налякає вас з якоїсь причини, є багато інших варіантів. Я рекомендую пули Apple та Cloudflare тільки тому, що вони мають високоякісні вузли по всьому світу і не ймовірно зникнуть найближчим часом.
Ключове слово servers вказує OpenNTPD використовувати кілька IP-адрес з домену, тоді як server означає, що він використовуватиме лише перший. В цьому випадку він використовуватиме по одному з кожного пула.
Моє єдине рекомендація для PulseAudio (окрім того, щоб уникати його використання) - це увімкнути дві опції в файлі конфігурації:
# /home/user/.config/pulse/daemon.conf avoid-resampling = true flat-volumes = no
Це дозволить уникнути надмірного погіршення якості звуку. Також це запобігає деяким роздратовуючим проблемам з контролем гучності.
Інші опції для розгляду можна знайти у сховищі audiophile-linux.
Цей розділ для випадкових нюансів, які не дуже пасують до інших частин.
Я запускаю свого користувача з umask 77 за замовчуванням, що означає, що будь-які нові створені файли будуть недоступні для читання іншим користувачам. Мій домашній каталог також має режим 700. Якщо процес, що працює в якості іншого користувача без привілеїв, буде скомпрометований, він не зможе прочитати мої файли. Щоб досягти цього, помістіть umask 77 кудись у файл оболонки користувача rc (~/.bashrc або подібний) та виконайте:
# chmod -R go-rwx /home/*
Ніколи не змінюйте значення umask для root. Це призведе до всіляких проблем.
Мені також подобається розміщувати каталог ~/.cache користувача в tmpfs, щоб зменшити записи на диск.
# /etc/fstab [...] tmpfs /home/bh/.cache tmpfs rw,size=250M,noexec,noatime,nodev,uid=bh,gid=bh,mode=700 0 0
Все, що туди потрапляє, все одно є сміттям.
Можливо приховати процеси не-root користувачів один від одного. Це основно корисно в мультикористувацьких системах, але може бути варто робити це також на звичайному настільному комп'ютері. Чим менше інформації атакуючий може дізнатися про вашу конфігурацію, тим краще.
Вихідні DNS-запити можуть бути зашифровані з dnscrypt-proxy. Є інші варіанти, такі як DNS через HTTPS і DNS через TLS, але мені подобається протокол DNSCrypt більше, оскільки він не базується на моделі сертифіката авторитета. dnscrypt-proxy (або unbound) також може бути використаний для фільтрації деяких рекламних оголошень та шкідливих програм через чорні списки.
Наступні не пов'язані з безпекою налаштування sysctl були корисні за моїм досвідом:
# /etc/sysctl.d/98-misc.conf net.ipv4.tcp_congestion_control=bbr vm.swappiness=10
Linux підтримує кілька алгоритмів керування заторами TCP. Алгоритм BBR дає більш стабільну пропускну здатність мережі, ніж типовий, на моєму досвіді, особливо для передачі файлів через Атлантику. Це може допомогти багато, або зовсім не вплинути, в залежності від конкретного використання.
Значення swappiness контролює, наскільки агресивно ядро буде переміщувати сторінки пам'яті на диск. За замовчуванням значення 60 для мене занадто велике, тому я зменшую його до 10, щоб уникнути такого багатого переміщення.
Журнал systemd може стати дуже великим, якщо ви не встановите на нього жодних обмежень. Також можна включити стиснення, щоб більше інформації помістилася в менший файл.
# /etc/systemd/journald.conf.d/99-limit.conf [Journal] Compress=yes SystemMaxUse=100M
Linux Hardening: https://vez.mrsk.me/linux-hardening.html