Лучшие практики для обеспечения безопасности вашего сервера

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

· 9 минуты на чтение
Лучшие практики для обеспечения безопасности вашего сервера

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

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

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

Устанавливайте обновления

Эффективность: 🛡️ 🛡️ 🛡️

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

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

Для обновления системы используйте следующие команды:

Для Fedora, CentOS и RHEL:

sudo dnf upgrade

Для Ubuntu и Debian:

sudo apt update && sudo apt upgrade -y

Настройка автоматических обновлений

Для автоматического применения обновлений можно настроить систему на RHEL, CentOS и Fedora с помощью dnf-automatic:

sudo dnf install -y dnf-automatic

Откройте файл конфигурации dnf-automatic для редактирования:

sudo nano /etc/dnf/automatic.conf

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

[commands]
upgrade_type = security          # Устанавливать только обновления безопасности
apply_updates = yes              # Автоматически применять обновления

Активируйте таймер dnf-automatic, чтобы система автоматически проверяла обновления ежедневно:

sudo systemctl enable --now dnf-automatic.timer

Замена стандартного порта SSH

Эффективность: 🛡️ 🛡️

Большинство ботов сканируют только стандартный порт SSH (22). Изменив его, можно снизить вероятность атак ботов, работающих по шаблону.

Firewall

Перед сменой порта убедитесь, что у вас настроен firewall. Например, в CentOS/RHEL используется firewalld. Вам необходимо открыть новый порт для SSH и закрыть старый, иначе сервер станет недоступным.

Пример для firewalld, если выбранный порт — 58291:

firewall-cmd --zone=public --add-port=57622/tcp --permanent
firewall-cmd --reload

Чтобы изменить порт SSH, отредактируйте файл конфигурации /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

В файле найдите строку

#Port 22

Удалите # и замените 22 на новый номер порта, например, 58291.

Выбирайте порт в диапазоне от 1025 до 65535 — это номера, доступные для нестандартных служб. Лучше выбирать пятизначное число, не конфликтующее с другими сервисами (например, 3306 — для MySQL, 80 — для HTTP, 21 — для FTP).

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

sudo sshd -t

Если ошибок не обнаружено, перезапустите SSH:

sudo systemctl restart sshd

Для подключения с использованием нового порта укажите его через флаг -p:

ssh username@remote_host -p 58291
💡
Оставьте старое соединение открытым и попробуйте подключиться через новый порт в отдельной SSH-сессии, чтобы убедиться, что все работает корректно.

Config SSH

Чтобы не запоминать порты и другие параметры подключения ко всем серверам, можно использовать конфигурационный файл ~/.ssh/config на локальной машине. Создайте его, если он отсутствует.

Пример содержимого файла ~/.ssh/config:

Host my_server
    HostName remote_host
    User username
    Port 58291

После этого подключиться к серверу можно с помощью команды:

ssh my_server

Кроме того, в этом файле можно указать дополнительные параметры, такие как разные SSH-ключи для аутентификации или прокси-серверы.

Создание нового пользователя

Эффективность: 🛡️ 🛡️ 🛡️

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

Чтобы создать альтернативного пользователя, выполните команду:

sudo adduser имя_пользователя

После создания пользователя установите для него пароль:

passwd имя_пользователя

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

usermod -aG sudo имя_пользователя
На большинстве систем это группа sudo, но в некоторых дистрибутивах, например, в CentOS и RHEL, используется группа wheel:

После добавления пользователь сможет использовать sudo для выполнения команд от имени root. Вы также можете задать индивидуальные ограничения для каждого пользователя sudo, разрешив выполнять только определенные команды от имени администратора. 

🙅‍♂️ Запрет входа root пользователя

Эффективность: 🛡️ 🛡️ 🛡️ 🛡️ 🛡️

Запрет на вход root-пользователя через SSH — одна из самых эффективных мер безопасности. Если злоумышленник получит доступ к root-аккаунту, он получит полный контроль над сервером. Поэтому рекомендуется разрешать подключение только для обычных пользователей, которые могут выполнять административные задачи через sudo.

Если же root-доступ по SSH все же необходим, следует настроить вход только по SSH-ключам.

Для настройки параметров входа под root откройте конфигурационный файл SSH:

sudo nano /etc/ssh/sshd_config

Найдите параметр PermitRootLogin и установите его значение в зависимости от нужной политики безопасности:

  • Установите PermitRootLogin no, чтобы запретить root-пользователю вход по SSH
  • Если вам необходимо сохранить возможность входа для root, но только по ключам SSH, установите PermitRootLogin prohibit-password.

Сохраните изменения и перезапустите SSH, чтобы они вступили в силу:

systemctl restart sshd

Заблокировать пароль root

Эффективность: 🛡️ 🛡️ 🛡️ 🛡️

Блокировка пароля для root-пользователя — это дополнительная мера безопасности, которая предотвращает переход в root через команду su. При этом root-аккаунт остается активным, и доступ по другим методам, таким как SSH-ключи, возможен. Это обеспечивает безопасное администрирование без использования root-пароля.

Для блокировки пароля выполните следующую команду, находясь под пользователем с правами sudo:

sudo passwd -l root

Чтобы убедиться, что пароль действительно заблокирован, выполните:

sudo passwd -S root

Если статус root отображается как L (Locked), пароль заблокирован успешно. После этого использование команды su для перехода в root станет невозможным, так как пароль для этого аккаунта будет заблокирован.

Если настроена аутентификация по SSH-ключам, вы все еще сможете войти под root через SSH, но не с помощью пароля.
Спонсор поста 3

🔐 Используйте SSH ключ вместо пароля

Эффективность: 🛡️ 🛡️ 🛡️ 🛡️ 🛡️ 🛡️

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

Принцип работы SSH-ключей

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

Схематичный процесс авторизации по SSH ключу

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

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

Настройка сервера для входа по ключу

Чтобы убедиться, что сервер принимает SSH-ключи, проверьте, что в файле конфигурации SSH (/etc/ssh/sshd_config) включена строка:

PubkeyAuthentication yes

Перезапустите SSH после изменений:

sudo systemctl restart sshd

Создание ssh ключей

Чтобы создать SSH-ключи, используйте команду:

ssh-keygen

По умолчанию утилита предложит сохранить ключи в папке ~/.ssh/. Рекомендуется оставить это местоположение, так как многие программы будут автоматически использовать эти ключи. Закрытый ключ сохранится в id_rsa, а открытый ключ в id_rsa.pub. Также можно задать фразу-пароль для дополнительного шифрования закрытого ключа (опционально).

После генерации SSH-ключей у вас будет пара ключей, готовая для использования.

Никогда не передавайте свой закрытый ключ другим лицам или храните его в небезопасном месте.

Загрузка ключа на сервер

Чтобы добавить открытый ключ на сервер, используйте утилиту ssh-copy-id:

ssh-copy-id username@remote_host

При первом подключении к серверу система может запросить подтверждение, введите yes, а затем — пароль пользователя. ssh-copy-id добавит открытый ключ (id_rsa.pub) в файл ~/.ssh/authorized_keys на сервере, чтобы разрешить вход по ключу.

Если требуется указать путь к публичному ключу:

ssh-copy-id -i /path_to_key username@remote_host

Альтернативный метод загрузки ключа вручную

Если ssh-copy-id недоступен, вы можете загрузить ключ вручную:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

При этом также потребуется подтвердить подключение к серверу (введите yes) и пароль пользователя.

После настройки откройте SSH-сессию:

ssh username@remote_host

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

🙅‍♂️ Запрет авторизации по паролю

Эффективность: 🛡️ 🛡️ 🛡️ 🛡️ 🛡️

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

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

Откройте конфигурационный файл SSH для редактирования:

sudo nano /etc/ssh/sshd_config

Найдите строку с параметром PasswordAuthentication и измените его значение с yes на no:

PasswordAuthentication no

Сохраните изменения и перезапустите SSH, чтобы новые настройки вступили в силу:

sudo service ssh restart

Теперь доступ к серверу возможен только с использованием SSH-ключей. 

Ограничить доступ пользователей по ssh

По умолчанию все пользователи системы могут подключаться к серверу по SSH, используя пароль или ключ. Однако это может представлять риск, особенно если вы создаете учетные записи для конкретных задач, таких как FTP или электронная почта. Эти пользователи, подключившись по SSH, могут получить доступ к системным инструментам, компиляторам и скриптовым языкам, таким как Perl или Python, что может представлять угрозу безопасности.

Чтобы разрешить вход по SSH только для выбранных пользователей, добавьте строку AllowUsers в файл конфигурации SSH:

// ... ... ... ... ...

AllowUsers user1, user2

// ... ... ... ... ...

В этом примере доступ по SSH разрешен только пользователям user1 и user2. Все остальные пользователи не смогут подключаться к серверу по SSH.

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

// ... ... ... ... ...

DenyUsers user1, user2, user3

// ... ... ... ... ...

В этом случае доступ будет запрещен для user1, user2 и user3, а остальные пользователи смогут подключаться по SSH.

После внесения изменений сохраните файл и перезапустите SSH для применения новой конфигурации:

sudo systemctl restart sshd

Запрет X11 Forwarding

Эффективность: 🛡️ 🛡️

Опция X11 Forwarding позволяет запускать графические приложения с сервера на удаленном компьютере через SSH. Хотя это может быть полезно для некоторых задач, в руках злоумышленника доступ к графическим приложениям может стать дополнительным риском безопасности. В области кибербезопасности действует простое правило:

если функция не нужна, лучше ее отключить.

Чтобы отключить X11 Forwarding, отредактируйте файл конфигурации SSH:

sudo nano /etc/ssh/sshd_config

Найдите строку:

X11Forwarding yes

и измените ее значение на:

X11Forwarding no

Сохраните изменения и перезапустите SSH, чтобы они вступили в силу:

sudo systemctl restart sshd

Ограничение для попыток ввода пароля

Эффективность: 🛡️ 🛡️

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

Откройте конфигурационный файл SSH для редактирования:

sudo nano /etc/ssh/sshd_config

Найдите строку с параметром MaxAuthTries. Если строка закомментирована (начинается с #), удалите символ #, чтобы включить ее. Затем установите нужное значение — например, 3, чтобы разрешить не более трех попыток:

MaxAuthTries 3

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

Сохраните изменения и перезапустите SSH, чтобы новые настройки вступили в силу:

sudo systemctl restart sshd

Установите таймаут подключения

Эффективность: 🛡️ 🛡️

Длительные неактивные SSH-сессии могут представлять угрозу безопасности, особенно если пользователь оставил рабочее место без блокировки компьютера. Чтобы снизить этот риск, можно установить таймаут для неактивных подключений. Это прерывает сессию при отсутствии активности, автоматически отключая пользователя.

Откройте файл конфигурации SSH для редактирования:

sudo nano /etc/ssh/sshd_config

Найдите параметр ClientAliveInterval. Если строка закомментирована, удалите символ # и установите нужное значение в секундах. Например:

ClientAliveInterval 600

Здесь 600 означает, что сервер будет проверять активность клиента каждые 600 секунд (10 минут).

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

ClientAliveCountMax 3

то сессия прервется после 3 проверок, если не будет активности. В данном случае это 30 минут (10 минут x 3).

Сохраните изменения и перезапустите SSH для их применения:

sudo systemctl restart sshd

Отклонять подключение без пароля

Эффективность: 🛡️ 🛡️

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

Чтобы запретить доступ для пользователей без пароля, отредактируйте файл конфигурации SSH:

sudo nano /etc/ssh/sshd_config

Найдите параметр PermitEmptyPasswords. Если строка закомментирована, удалите символ # и установите значение no:

PermitEmptyPasswords no

Сохраните изменения и перезапустите SSH, чтобы они вступили в силу:

sudo systemctl restart sshd

Бэкапы

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

  • Регулярность: Установите расписание для регулярного создания резервных копий. Например, можно делать ежедневные копии для важных данных и еженедельные полные бэкапы всей системы.
  • Места хранения: Храните резервные копии в нескольких местах, включая как локальное хранилище, так и удаленные серверы или облачные сервисы. Это обеспечит доступ к данным даже при полной потере доступа к серверу.
  • Автоматизация: Используйте инструменты для автоматизации бэкапов, такие как rsync, tar или специализированные программы для резервного копирования. Автоматизация исключает человеческий фактор и снижает риск пропустить резервное копирование.
  • Проверка и тестирование: Регулярно проверяйте резервные копии и тестируйте процесс восстановления, чтобы убедиться, что данные можно успешно восстановить.

Заключение

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

Мой подход к безопасности

Предложенные рекомендации позволяют сформировать свой “рецепт” безопасности, адаптированный под конкретные задачи. Чаще всего я использую следующий набор мер:

  • Смена порта SSH
  • Создание нового пользователя с правами sudo
  • Блокировка входа по паролю для всех пользователей
  • Запрет входа root на сервер
  • Блокировка пароля root
  • Регулярные резервные копии

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

Struchkov Mark
Struchkov Mark
Задавайте вопросы, если что-то осталось не понятным👇