Защита Linux-сервера: практический контрольный список

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

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

1. SSH — важнейшая отдельная настройка

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

Проверьте:

• Вход по паролю отключён, используются только ключи. Одно это изменение останавливает подавляющее большинство попыток.
• Прямой вход под root не используется — работайте под обычной учётной записью и sudo.
• Блокировка неудачных попыток включена (fail2ban или аналог).
• Кто вообще имеет доступ — пройдите по всем учётным записям и авторизованным ключам. Удалите те, что больше не нужны.

2. Брандмауэр — закрыто всё, кроме нужного

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

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

3. Обновления и патчи

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

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

4. Сертификаты и HTTPS

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

5. Резервные копии — и проверка восстановления

Три вопроса, на которые должен быть конкретный ответ:

1. Насколько свежа самая новая копия?
2. Где она находится — вне сервера? Копия на той же машине не поможет, если машина исчезнет.
3. Когда вы в последний раз пробовали восстановление?

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

6. Журналы и мониторинг

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

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

7. Кто и что работает на сервере

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

8. Документация

Запишите, где находится сервер, что на нём работает, у кого есть доступ и как действовать при сбое. Это та часть, ценность которой проявляется в день, когда прежний администратор недоступен, — а этот день рано или поздно всегда наступает.

Что делать, если список породил больше вопросов, чем ответов

В этом и смысл списка. Если на несколько пунктов вы не смогли ответить, состояние сервера, вероятно, стоит пересмотреть.

Мы просмотрим Linux-сервер, конкретно скажем, что в порядке, а что нет, и предложим, что исправить — в том числе если вывод будет, что больших работ не требуется. Подробнее о том, что входит в текущее администрирование, мы писали в статье Обслуживание Linux-сервера: что входит в договор.