Начните с портов, к которым напрямую обращаются клиенты: HTTPS на 443, редирект на 80, порты API-шлюза, а также DNS или SMTP, если вы размещаете их самостоятельно. Затем охватите внутренние зависимости, способные обрушить весь стек: базы данных, кэши и очереди сообщений. И наконец, следите за портами управления — SSH, RDP и Docker API, — чтобы убедиться, что они недоступны из интернета.
Расставляйте приоритеты по влиянию, а не по номеру порта
Если мониторить все слушающие сервисы сразу, получится шум из алертов и размытая ответственность. Вместо этого оцените каждый порт по трём вопросам, прежде чем добавлять проверку:
- Влияние на клиентов и выручку. Если порт перестанет отвечать, увидят ли пользователи ошибки, сломается ли оформление заказа, получат ли API-клиенты таймауты?
- Единая точка отказа. Стоит ли за портом одна основная база данных, один брокер или один балансировщик, или трафик автоматически переключается на резерв?
- Риск раскрытия. Станет ли инцидентом безопасности ситуация, когда этот порт окажется доступен из публичного интернета?
Высокая оценка по первым двум вопросам относит порт к уровню доступности. Высокая оценка по третьему — к уровню раскрытия, где условием алерта является состояние «открыт».
Уровень 1: публичные точки входа
Создайте эти проверки первыми, обычно с интервалом 30–60 секунд из нескольких регионов:
- 443 (HTTPS): ваш главный вход. Проверяйте TLS-рукопожатие, а не только TCP-подключение.
- 80 (HTTP): должен отвечать редиректом на 443. Сломанный редирект оставляет ни с чем пользователей, пришедших по старым ссылкам.
- Порты API-шлюза (например, 8443 или выделенный gRPC-порт), к которым напрямую обращаются партнёры и мобильные приложения.
- 53 по TCP и UDP, если вы сами размещаете авторитативный DNS. UDP обслуживает большинство запросов, а TCP — большие ответы и передачу зон, поэтому проверяйте оба.
- 25, 465 или 587, если вы отправляете транзакционные письма через собственные релеи. Если SMTP незаметно откажет, письма для сброса пароля и счета перестанут доходить.
Проверки из нескольких локаций важны, потому что изменение в файрволе или CDN может оставить порт открытым в одном регионе и заблокированным в другом.
Уровень 2: внутренние зависимости
Эти сервисы не должны быть публичными, поэтому проверяйте их изнутри сети или с IP-адреса мониторинга, явно разрешённого в файрволе:
- 5432 (PostgreSQL) и 3306 (MySQL): как основные узлы, так и реплики.
- 6379 (Redis): кэши часто отказывают незаметно, а затем перегружают стоящую за ними базу данных.
- 5672 (RabbitMQ) и 9092 (Kafka): зависший брокер тормозит все асинхронные задачи.
- Листенеры внутренних балансировщиков перед слоями сервисов.
Отслеживайте время подключения, а не только статус «доступен/недоступен». Если порт базы данных принимает соединение за 800 мс вместо 5 мс, это часто указывает на исчерпание пула соединений или перегрузку хоста.
Уровень 3: порты, которые должны оставаться закрытыми
Последний уровень переворачивает логику: алерт срабатывает, когда эти порты доступны из публичного интернета.
| Порт | Сервис | Чем опасна публичная доступность |
|---|---|---|
| 22 | SSH | Постоянная цель брутфорса и credential stuffing |
| 3389 | RDP | Частая точка проникновения программ-вымогателей |
| 2375 / 2376 | Docker API | 2375 работает без аутентификации и даёт контроль над хостом |
| 6443 | Kubernetes API | Доступ следует ограничить разрешёнными диапазонами IP или частной сетью |
| 9200 | Elasticsearch | Распространённый источник утечек данных |
| 27017 | MongoDB | Исторически массово сканировался и очищался, если оставался открытым |
Запускайте эти проверки из внешних локаций каждые 5–15 минут. Так вы поймаете ослабленную security group, неверно настроенный Helm-чарт или забытый отладочный порт.
Как внедрить это с UpScanX
Мониторинг портов UpScanX выполняет проверки TCP и UDP из более чем 15 глобальных локаций, что хорошо подходит для поэтапного внедрения:
- Неделя 1: добавьте проверки уровня 1 с валидацией ответов для конкретного протокола, чтобы алерт срабатывал даже тогда, когда порт принимает соединения, но возвращает некорректные ответы.
- Неделя 2: добавьте проверки уровня 2 везде, где сеть допускает доступ мониторинга, с отслеживанием времени подключения и задержки ответа. Предупреждение выставляйте примерно на 2–3-кратное превышение обычного времени подключения.
- Неделя 3: зафиксируйте базовую конфигурацию для уровня 3 и включите обнаружение изменений состояния портов. Идентификация сервисов с определением версии также сообщит, если порт, на котором должен работать nginx, внезапно определяется как что-то другое.
Направляйте алерты уровня 1 в Slack или Microsoft Teams, где их сразу увидят дежурные инженеры, а алерты о раскрытии уровня 3 отправляйте команде безопасности по Email или через Webhook. О том, что проверять на каждом открытом порту, читайте в нашем чек-листе мониторинга критичных открытых портов.
Ключевые выводы
- Расставляйте приоритеты по влиянию на клиентов, единым точкам отказа и риску раскрытия, а не по номеру порта.
- Сначала мониторьте публичные точки входа, затем внутренние зависимости данных, затем порты управления.
- Отслеживайте задержку подключения, а не только доступность, чтобы рано замечать деградацию.
- Пересматривайте список после крупных изменений инфраструктуры: новые сервисы незаметно добавляют новые порты.