Как мониторить TCP-порт (и когда оповещать, что порт открыт)

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

Как на самом деле работает монитор TCP-порта

Монитор TCP-порта открывает сокет к цели на выбранном порту и ждёт завершения трёхстороннего рукопожатия. Если рукопожатие прошло успешно, порт открыт. Если соединение отклонено, порт закрыт. Если соединение истекает по таймауту, что-то между зондом и вашим хостом отбрасывает пакет — обычно это межсетевой экран.

Зонд не использует протоколы поверх сокета. Он не согласовывает TLS, не обменивается баннерами SSH и не выполняет запросы к базе данных. Он только сообщает, отвечает ли порт. Для проверки работоспособности на уровне приложения нужна дополнительная HTTP-проверка или пользовательская проверка.

Когда порт должен быть ОТКРЫТ

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

• Серверы баз данных на порту 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). Если процесс-слушатель падает, все зависимые сервисы выходят из строя, но HTTP-зонд запустить нельзя.
• Релеи SMTP на порту 25 или 587. Проверка SMTP-баннера выявляет падения слушателя, которые внутренние health-эндпоинты пропускают.
• Игровые серверы и другие пользовательские TCP-протоколы, не использующие HTTP.
• Внутренние балансировщики нагрузки, открывающие не-HTTP health-порт для вышестоящих сервисов.
• Конечные точки VPN на портах, работающих и по UDP, и по TCP — например, 443 для OpenVPN-TCP и WireGuard.

Когда порт должен быть ЗАКРЫТ

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

Кто-то временно открывает правило брандмауэра для отладки и забывает откатить его. Сервис Kubernetes случайно получает тип LoadBalancer. Новому экземпляру присваивается неправильная группа безопасности. Изменение в модуле Terraform открывает порт, который должен был оставаться внутренним. В любом из этих случаев инвертированный монитор порта обнаруживает открытие в течение одного интервала проверки.

Наиболее ценные порты для инвертированного мониторинга прямо сейчас

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

• 22 (SSH) на продакшен-серверах приложений. Доступ через бастион — норма, и случайно открытый SSH-порт появляется в логах массового сканирования в течение нескольких часов.
• 3306 (MySQL) и 5432 (Postgres). На публичные порты баз данных приходится значительная доля атак по подбору учётных данных.
• 6379 (Redis). Открытый Redis без аутентификации — одна из самых эксплуатируемых уязвимостей конфигурации в индустрии.
• 27017 (MongoDB). Та же история, что и с Redis. Конфигурация по умолчанию, без аутентификации, публичный порт — равно потеря данных.
• 9200 (Elasticsearch). Открытые кластеры за считанные часы становятся объектами скрейпинга, майнинга и вымогательства.

Пороги оповещений для мониторинга портов

Работоспособность сервиса (порт должен быть ОТКРЫТ) требует того же подхода к порогу, что и HTTP: оповещение после 3 последовательных сбоев, подавление коротких всплесков. Сетевые сбои, закрывающие одну проверку, — это шум.

Безопасность (порт должен быть ЗАКРЫТ) требует обратного. Оповещайте при первом же обнаружении. Случайно открытый порт SSH или Redis — это происшествие пятого уровня тревоги. Боты постоянно сканируют публичный интернет, и промежуток между открытием известного порта и компрометацией измеряется минутами.

Стартовый чек-лист для мониторинга портов безопасности

Для каждого IP-адреса вашей команды, доступного из интернета, настройте инвертированные мониторы на портах 22, 3306, 5432, 6379 и 27017 с интервалом 60 секунд. Направляйте эти оповещения в ваш канал безопасности отдельно от оповещений о работоспособности сервисов. Раз в квартал запускайте реальное сканирование портов против собственных IP в качестве контроля. Затраты невелики, охват широк, а отказы, которые этот подход ловит, катастрофичны.