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

Понимание ландшафта угроз

Разберём популярные типы угроз, с которыми могут столкнуться администраторы Linux‑серверов. К ним относятся:

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

  • Руткиты и вредоносное ПО. Любой софт, который пытается получить неавторизированный доступ к ресурсам сервера.

  • Атаки типа «отказ в обслуживании» (DoS). Перегрузка ресурсов сервера, из‑за чего зависящие от него сервисы становятся недоступными.

  • Уязвимости нулевого дня. Эксплуатация неизвестных или неисправленных уязвимостей в системе.

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

Управление пользователями и доступом

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

Управление пользователями и разделение привилегий

  • Избегайте прямого доступа под root. Это может сделать сервер более уязвимым. Вместо root‑доступа создайте нового пользователя с привилегиями sudo для административных задач.

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

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

Укрепление SSH

  • Отключите вход под root через SSH. Измените файл /etc/ssh/sshd_config, чтобы запретить вход под root, установив PermitRootLogin no.

  • Включите аутентификацию на основе ключей. Избегайте использования аутентификации на основе паролей для SSH, настроив пары публичных и приватных ключей. Такой подход снижает вероятность успешных брутфорс‑атак.

  • Ограничьте доступ к SSH по IP. Настройте правила файрвола или используйте TCP‑обёртки, чтобы разрешить доступ по SSH только опредёленным IP‑адресам.

Многофакторная аутентификация (MFA)

  • Настройте MFA для SSH. Используйте Google Authenticator, Duo Security или другие нструменты, чтобы включить MFA, добавив ещё один слой безопасности в процесс аутентификации.

  • Установите приложение MFA на свой телефон, затем настройте его на сервере и настройте файл /etc/pam.d/sshd ( Pluggable Authentication Modules — это набор компонентов, предоставляющих программный интерфейс для авторизации пользователей в Linux), чтобы обеспечить MFA для SSH.

Безопасная конфигурация системы

Обновления системы и управление патчами

  • Включите автоматические обновления. Настройте менеджер пакетов для автоматической установки патчей безопасности. Это можно сделать с помощью unattended-upgrades в системах на основе Debian или yum-cron в CentOS/RHEL.

  • Регулярно проверяйте систему на уязвимости. Используйте сканеры уязвимостей вроде Lynis или OpenVAS, чтобы выявить уязвимости в текущей конфигурации.

Настройки безопасности ядра

  • Измените параметры ядра с помощью sysctl, чтобы улучшить безопасность. Например:

    • Отключите IP форвардинг: net.ipv4.ip_forward = 0

    • Запретите запросы ICMP (ping): net.ipv4.icmp_echo_ignore_all = 1

  • Использование модулей безопасности: Linux поддерживает дополнительные модули вроде grsecurity (это проприетарный патч ядра Linux) или SELinux, которые обеспечивают расширенный контроль доступа к чувствительным областям.

Конфигурация сети

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

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

Расширенные механизмы аутентификации и авторизации

Контроль доступа на основе ролей (RBAC)

  • Использование RBAC позволяет определять роли с конкретными привилегиями и назначать пользователям эти роли, минимизируя избыточные разрешения.

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

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

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

  • Аналогично SELinux, AppArmor ограничивает приложения определённым набором ресурсов, блокируя любую попытку доступа к ресурсам вне заданной политики.

Безопасность приложений и баз данных

Безопасность веб-приложений

  • Конфигурация Apache/Nginx. Установите ограничительные разрешения для чувствительных директорий и включите HTTPS по умолчанию. Регулярно обновляйте серверное ПО, чтобы предотвратить уязвимости.

  • Веб-файрвол (WAF). Используйте WAF, например ModSecurity, для фильтрации и мониторинга HTTP-запросов, добавляя слой безопасности для ваших веб-приложений.

Укрепление баз данных

  • Ограничьте IP‑адреса, которые могут получить доступ к вашей базе данных, только доверенными хостами. Это особенно критично, если ваша база данных доступна из интернета.

  • Используйте шифрование на уровне базы данных и рассмотрите полное шифрование диска.

  • Валидируйте все инпуты и используйте связываемые переменные (prepared statements), чтобы предотвратить атаки SQL‑инъекцией.

Аудит, мониторинг и журналирование

Настройка журналирования с Syslog и JournalD

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

  • Настройте logrotate, чтобы управлять и архивировать журналы, в противном случае место на диске может быстро закончиться.

Использование инструментов реального времени

  • Fail2ban мониторит журналы и блокирует IP-адреса после определённого числа неудачных попыток входа, помогая предотвратить брутфорс-атаки.

  • Инструменты обнаружения вторжений вроде Tripwire и OSSEC могут обнаруживать неавторизированные изменения в файлах или необычную активность.

Аудит с помощью Auditd

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

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

Защита данных и шифрование

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

  • Для чувствительных данных рассмотрите полное шифрование диска с помощью LUKS. Это предотвращает доступ к данным, если устройство хранения будет удалено или украдено.

  • Включите HTTPS на всех веб-серверах, чтобы шифровать данные во время передачи. Кроме того, используйте TLS для любых соединений с базой данных.

Мониторинг целостности файлов

  • Advanced Intrusion Detection Environment (AIDE) — это полезный инструмент, который обнаруживает изменения, удаления или добавления файлов. Настройте AIDE, чтобы выполнять ежедневное сканирование и отправлять уведомления при обнаружении неавторизированных изменений.

План реагирования на инциденты и стратегия резервного копирования

Планирование реагирования на инциденты

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

  • Рассмотрите реализацию инструментов систем управления безопасностью и событиями (SIEM) для корреляции событий в реальном времени, что помогает в быстром обнаружении и реагировании.

Автоматическое резервное копирование и восстановление

  • Частота резервного копирования: Настройте регулярное автоматическое резервное копирование с помощью rsync, cron или других подобных инструментов. Храните резервные копии в нескольких местах, включая внешнее или облачное хранилище.

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

Заключение

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

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

Комментарии (12)


  1. unixweb
    08.11.2024 08:07

    Эта статья не туториал, это рекомендации. Туториал когда подробно показывают как что-то сделать.


    1. Shaman_RSHU
      08.11.2024 08:07

      Это вырезано из памятки от ФСТЭК по усилению безопасности Linux. Но как-то все не систематизировано.


  1. pda0
    08.11.2024 08:07

    Запретите запросы ICMP (ping)

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


    1. kenomimi
      08.11.2024 08:07

      От дудоса школьниками защищает. Насколько помню, лоик как раз именно через ICMP работает. Чуток усложняет сканирование сети роботами.


      1. pda0
        08.11.2024 08:07

        От дудоса защищает правило фаервола, ограничивающее частоту приёма эхо-запросов.


    1. j_larkin
      08.11.2024 08:07

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


    1. shanker
      08.11.2024 08:07

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


  1. Revertis
    08.11.2024 08:07

    Избегайте прямого доступа под root. Это может сделать сервер более уязвимым. Вместо root‑доступа создайте нового пользователя с привилегиями sudo для административных задач.

    А как это поможет вообще? Типа атакующему надо будет целое слово sudo добавлять к командам, и он обломается? :)


    1. j_larkin
      08.11.2024 08:07

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


      1. teakettle
        08.11.2024 08:07

        Там было еще про "PasswordAuthentication no" было, в статье почему-то не упомянуто.


  1. mizugoji
    08.11.2024 08:07

    Используйте шифрование на уровне базы данных и рассмотрите полное шифрование диска.

    А что это даст, если сервер всегда онлайн?

    Если злоумышленник проник в линукс систему, то диск уже будет смонтирован и доступен. Не понял зачем нужно шифрование диска.


  1. mizugoji
    08.11.2024 08:07

    Не упомянули про то, что доступ по SSH желателен из локальной сети по внутренним ip адресам. А к этому промежуточному серверу доступ уже через VPN канал. Тогда уже технически невозможно подключиться к SSH без доступа к внутренней сети.

    А по хорошему SSH нужно прятать за HTTPS сервером, чтобы его нельзя было вообще обнаружить никак через сканирование. Проект SSH3 (SSH over HTTP/3) уже реализовал такое.

    Так же имеется черновик для стандартизации нового протокола - Remote terminal over HTTP/3 connections