Безопасность в Linux: основы защиты твоей системы

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

Первый шаг: понять свои риски и ценности

Прежде чем что-то защищать, нужно понять, что именно вы защищаете и от кого. Для домашнего сервера с фоточками котиков уровень паранойи будет один, для продакшн-сервера с критическими данными — совершенно другой. В моей практике был случай, когда небольшой стартап, увлеченный модными докерами и микросервисами, забыл про элементарную вещь: кто имеет доступ к их серверам. В итоге, банальная утечка SSH-ключа одного из разработчиков привела к тому, что на серверах неделю крутился майнер. Убытки были не только финансовые от простоя, но и репутационные. Поэтому первое правило: инвентаризация. Что у вас есть? Какие данные? Кто к ним имеет доступ? Ответьте на эти вопросы честно.

Фундамент безопасности: нерушимые правила

Представьте вашу систему как дом. Фундамент — это набор базовых правил, без которых всё остальное просто бессмысленно.

Обновления: ваш ежедневный щит

Я знаю, как хочется отложить обновление системы «на потом». Особенно когда у вас крутится что-то важное и страшно что-то сломать. Но поверьте, большинство атак используют уже известные уязвимости, для которых патчи давно выпущены. Регулярные обновления — это ваша прививка от большинства болячек. Я всегда настаиваю на автоматических обновлениях для патчей безопасности, но с осторожностью для минорных и мажорных версий. Для серверов, особенно тех, что смотрят в интернет, я использую unattended-upgrades. Но есть нюанс: всегда проверяйте логи после обновления. Однажды на Debian 11 после обновления ядра у нас отвалился сетевой драйвер на одной специфической сетевой карте Broadcom. Никто не заметил, пока не пошли жалобы на недоступность. Лайфхак: держите всегда под рукой предыдущую версию ядра, чтобы можно было откатиться, если что-то пошло не так. И не забывайте про репозитории: в текущих реалиях, когда некоторые привычные источники софта могут быть заблокированы или работать нестабильно, имеет смысл использовать зеркала или проверенные отечественные репозитории, а если что-то не из официальных — тщательно проверять PGP-ключи.

Пользователи и права: меньше — значит безопаснее

Это азбука, но до сих пор вижу, как люди работают под root или дают каждому доступ по sudo. Никогда! Запомните: принцип наименьших привилегий. У каждого пользователя должны быть только те права, которые ему необходимы для работы. Для административных задач используйте sudo, а не прямой вход под root. И обязательно настройте sudoers так, чтобы каждый пользователь мог выполнять только строго определённые команды. В моём опыте, однажды, мы обнаружили, что один из стажёров, получив широкий доступ через sudo, случайно удалил критическую базу данных, пытаясь «почистить» логи. Обошлось бэкапом, но урок был усвоен: доверяй, но проверяй и ограничивай.

Фаервол: ваш личный привратник

Открытые порты — это открытые двери для злоумышленников. Используйте фаервол (ufw для простых задач, iptables или nftables для более сложных конфигураций) и закрывайте всё, что не используется. Помните старую поговорку: «Что не разрешено, то запрещено». Я всегда начинаю с запрета всего входящего трафика, а затем открываю только необходимые порты: 22 для SSH (с ограничениями, о них ниже), 80/443 для веб-сервера и так далее. И да, не забудьте про IPv6: многие настраивают фаервол только для IPv4, а потом удивляются, почему их ломают.

SSH: не просто дверь, а бронированная дверь

SSH — это ваш основной канал управления сервером, ваша святая святых. Его нужно защищать особенно тщательно.

• Аутентификация по ключу, а не по паролю: Это первое и самое важное правило. Отключите парольную аутентификацию в sshd_config. Пароль можно подобрать, ключ — практически нет.
• Смените стандартный порт (22): Это не панацея, но отсекает львиную долю автоматических сканеров и ботов. Выберите любой другой порт, например, 2222 или 22222.
• Отключите вход под root: PermitRootLogin no. Если нужно что-то сделать от root, используйте sudo.
• Используйте Fail2ban: Эта штука автоматически банит IP-адреса, с которых идут попытки подбора паролей или ключей. На моих серверах это одна из первых вещей, которую я ставлю. Он умеет работать не только с SSH, но и с другими сервисами.

Вспоминаю случай, когда один мой коллега, переехав на новую квартиру, забыл сменить IP-адрес в AllowUsers или AllowGroups в sshd_config. Естественно, после перезагрузки SSH, он не смог зайти. Пришлось ехать в дата-центр и восстанавливать через KVM. Мелочь, а нервов попортило.

Логи и мониторинг: глаза и уши вашей системы

Без логов вы слепы. journalctl, syslog-ng или rsyslog — ваш лучший друг. Настройте централизованный сбор логов, если у вас несколько машин. Используйте системы мониторинга (Prometheus, Zabbix, Grafana), которые будут не только собирать метрики, но и сигнализировать о подозрительной активности: необычный трафик, внезапное появление новых процессов, изменения в файлах. Для аудита системных вызовов и попыток доступа к файлам используйте auditd. Это сложно, но очень мощно.

Продвинутые меры: для тех, кто хочет большего

SELinux/AppArmor: смириться и полюбить

Эти штуки — это ваш личный телохранитель, который строго следит за тем, что каждое приложение может делать. Многие их отключают, потому что они «мешают» и «сложные». Да, они сложные. Да, поначалу будут сыпать ошибками. Но это мощнейший инструмент. В моем опыте, SELinux на CentOS спасал от компрометации веб-сервера, когда уязвимость в PHP-приложении позволяла запустить шелл. SELinux не дал шеллу выйти за пределы Apache и получить доступ к другим файлам. Разбираться с ними долго, но оно того стоит. Начните с режима permissive, который только логирует нарушения, а не блокирует их, и постепенно ужесточайте правила.

Шифрование дисков: LUKS — ваш несгораемый сейф

Если кто-то получит физический доступ к вашему серверу или ноутбуку, шифрование диска — это последняя линия обороны. LUKS (Linux Unified Key Setup) позволяет зашифровать весь диск или отдельные разделы. Это критически важно для ноутбуков, которые могут быть потеряны или украдены, и для серверов, где хранятся очень чувствительные данные. Единственный минус: если вы забыли пароль, данные потеряны. И да, при каждой перезагрузке нужно вводить пароль (если только у вас нет TPM или вы не настроили автоматическую разблокировку через сеть, что уже отдельная история и не всегда безопасна).

Резервное копирование: спасательный круг

Это не совсем про «защиту от взлома», но про «защиту от потери данных». А потеря данных в результате атаки — это тоже часть безопасности. Резервные копии должны быть:

• Регулярными: Не раз в год, а ежедневно или чаще, в зависимости от частоты изменений данных.
• Проверяемыми: Мало сделать бэкап, нужно убедиться, что из него можно восстановиться. Регулярно тестируйте восстановление.
• Оффлайн/Оффсайт: Копия должна храниться отдельно от основной системы, желательно на другом физическом носителе и в другом географическом месте. Отличные инструменты для этого — rsync, BorgBackup (с шифрованием и дедупликацией).

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

Целостность системы и supply chain security

В мире, где «свои» пакеты могут быть скомпрометированы, а «чужие» просто недоступны, важно проверять, что вы устанавливаете.

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

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

Типичные ошибки: наступать на грабли больно

Я видел их все. И сам наступал на некоторые из них, каюсь.

• Игнорирование предупреждений: «Да ладно, это просто какая-то ошибка в логах, ничего страшного.» Нет, страшно.
• Копипаст бездумный: Найти команду на форуме и выполнить её с правами root, не понимая, что она делает. Это как играть в русскую рулетку.
• Дефолтные пароли и настройки: Админ/админ, root/toor. Серьезно?
• Открытые порты: Зачем вам открытый MySQL в интернет?
• Отсутствие мониторинга: Узнать об инциденте от клиента — это фиаско.
• Отсутствие плана реагирования на инциденты: Что делать, если вас взломали? Паника?

И главный лайфхак: никогда не останавливайтесь в обучении. Мир безопасности меняется каждый день. Читайте профильные ресурсы, участвуйте в сообществах. Защита — это не одноразовая акция, а постоянный процесс.