Управление брандмауэром и безопасностью облачного сервера

Каждый сервер KapsuleHost поставляется с управляемым брандмауэром, который по умолчанию блокирует входящий трафик, а также защитой от перебора пароля, веб-приложением-брандмауэром и автоматическим применением патчей безопасности, всё управляется с одной страницы в KPanel.

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

Открытие страницы управления

1. Войдите в KPanel.
2. Нажмите Cloud Servers в левой боковой панели, затем нажмите на ваш сервер.
3. Нажмите Management в кнопках действий в верхней части страницы.

Прямой адрес: /cloud-servers/<server-id>/management. Страница описывает себя как "Firewall, OS patches, fail2ban, and ModSecurity. Changes apply over SSH within seconds."

Политика брандмауэра по умолчанию

Раздел Firewall (UFW) указывает политику в одной строке: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."

На практике это означает:

• Ничто не может достичь ваш сервер из интернета, если это не разрешено правилом.
• Порт 22 всегда открыт, поэтому изменение брандмауэра никогда вас не заблокирует.
• Порты, которые нужны вашему стеку приложений, такие как 80 и 443 для веб-приложения, открываются автоматически.
• Исходящий трафик с сервера не ограничивается.

Без пользовательских правил раздел показывает "No custom rules. Defaults: SSH + app-stack ports." Это здоровое состояние, а не недостающая конфигурация.

Добавление пользовательского правила

Добавьте правило, когда вы запускаете что-то на порту, который не охватывает политика по умолчанию: приложение Node на 3000, базу данных, которая вам нужна прямо на 5432, игровой или медиа-сервер на UDP-порту.

1. Откройте раздел Firewall (UFW).
2. Введите номер Port в первое поле. Допустимые значения: от 1 до 65535.
3. Выберите TCP или UDP.
4. Выберите Allow или Deny.
5. Нажмите Add.

Правило появляется в списке с бейджем ALLOW или DENY и портом и протоколом, например 3000/tcp. Оно передаётся на сервер через соединение управления в течение нескольких секунд.

Чтобы удалить правило, нажмите X в конце его строки. Удаление правила Allow закроет порт снова сразу.

App Stacks

Раздел App stack сообщает платформе, какой тип приложения запущен на этом сервере, чтобы предустановка защиты могла быть к нему подобрана. Установка приложения через панель устанавливает это для вас.

Признанные стеки: WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web и No app stack. Раздел объясняет себя как: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."

Стек влияет на то, какие порты открываются автоматически и как настраиваются остальные защиты, наиболее заметно в fail2ban.

fail2ban

fail2ban наблюдает попытки аутентификации и блокирует адреса, которые постоянно ошибаются. Он включен по умолчанию, и страница описывает его как: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too."

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

ModSecurity, веб-приложение-брандмауэр

ModSecurity проверяет HTTP-запросы против OWASP Core Rule Set и отмечает те, которые выглядят как атаки. На сервере KapsuleHost он запускается в режиме обнаружения: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."

Режим обнаружения является правильной начальной точкой. Core Rule Set подробный, и на реальном приложении некоторые легитимные запросы будут совпадать с правилом. Запустите его в режиме обнаружения некоторое время, прочитайте логи, выясните, какие правила ваш трафик срабатывает, и только потом переключитесь на блокирование внутри сервера.

Автоматическое применение патчей ОС

Обновления безопасности применяются для вас автоматически. Раздел объясняет подстраховку: "Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot."

Два параметра находятся под переключателем:

• Allow automatic reboot when a kernel update needs it (only during quiet hours below). Обновления ядра вступают в силу только после перезагрузки. Если вы отключите это, патчи ядра будут установлены, но не активны, пока вы не перезагрузитесь сами.
• Quiet window (UTC), час начала и окончания. Перезагрузки происходят только внутри неё. Установите её на самые спокойные часы для вашей аудитории и помните, что поле указано в UTC, а не в вашем местном времени.

История патчей и запуск патча сейчас

Раздел Patch history перечисляет каждый запуск со статусом RUNNING, SUCCESS, ROLLED_BACK, FAILED или SKIPPED, количество обновлённых пакетов, была ли перезагрузка сервера и время, когда он начался.

Чтобы применить патч сразу же, а не ждать по расписанию, нажмите Run patch now. Подтверждение читается: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."

Запись ROLLED_BACK означает, что подстраховка сработала: сервер не вернулся чисто после перезагрузки, поэтому снимок перед патчем был восстановлен. См. Cloud Server Snapshots для того, как работают эти снимки.

Разумная базовая линия

Для большинства серверов это вся конфигурация безопасности:

Последняя строка не находится на этой странице, но имеет большее значение, чем всё остальное вместе взятое. См. Connecting to Your Cloud Server With SSH.

Troubleshooting

"Could not load management config." Панель не смогла прочитать настройки для этого сервера. Перезагрузите и проверьте, что сервер существует и provisioned.

"Port must be 1-65535." Поле порта принимает целое число в этом диапазоне. Диапазоны и названия сервисов не принимаются здесь.

Мое правило сохранено, но ничего не изменилось. Ищите баннер "Live apply unavailable". Если он отображается, изменение сохранено, но ещё не применено к серверу.

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

Запуск патча показывает FAILED. Прочитайте сообщение об ошибке в строке. Полный диск является наиболее частой причиной. Освободите немного места и нажмите Run patch now.

Легитимный трафик начал блокироваться. Если вы переключили ModSecurity в режим блокирования, верните его в режим обнаружения, прочитайте логи и определите правило перед повторной попыткой.

Если правило брандмауэра отказывается применяться или вы заблокированы из сервиса, который вы разрешили, отправьте письмо на support@kapsulehost.com с названием сервера, портом и тем, что вы ожидаете до него достичь.