Мониторинг портов — это практика постоянной проверки того, открыты ли определенные сетевые порты на серверах, принимаются ли соединения и правильно ли они отвечают. Он работает на уровне TCP/UDP 4, независимо от протоколов уровня приложений, что делает его необходимым для мониторинга сервисов инфраструктуры, недоступных для проверок HTTP, — баз данных, кэшей, очередей сообщений, почтовых серверов и пользовательских протоколов приложений. Когда критический порт выходит из строя, каждое приложение, зависящее от этого сервиса, выходит из строя. Мониторинг портов обнаруживает эти сбои за считанные секунды, часто до появления каких-либо симптомов, с которыми сталкивается пользователь.
Почему важен мониторинг портов
Инфраструктурные службы невидимы для HTTP-мониторинга
Проверки работоспособности HTTP подтверждают, что веб-серверы отвечают, но рабочие приложения зависят от десятков серверных служб, которые никогда не обслуживают HTTP-трафик. База данных PostgreSQL на порту 5432, кэш Redis на порту 6379 или брокер RabbitMQ на порту 5672 могут выйти из строя автоматически, в то время как веб-сервер продолжает принимать запросы — возвращая ошибки, устаревшие данные или пустые ответы. Мониторинг портов выявляет эти скрытые сбои.
Сбои в работе служб могут быть бесшумными
Процесс службы может завершиться сбоем, не вызывая никаких предупреждений на уровне ОС. Сервер продолжает работать, сеть работает, но порт перестает принимать соединения. Без мониторинга портов эти тихие сбои обнаруживаются только тогда, когда зависимые приложения начинают давать сбой и пользователи сообщают о проблемах.
Для обеспечения безопасности требуется видимость портов
Несанкционированные открытые порты представляют собой уязвимости безопасности. Порт, который не должен быть доступен из Интернета — будь то из-за неправильно настроенного брандмауэра, непреднамеренного запуска службы или взломанной системы — создает поверхность атаки. Регулярный мониторинг портов выявляет эти воздействия.
Критические порты для мониторинга
Серверы баз данных
- PostgreSQL: 5432
- MySQL/MariaDB: 3306
- МонгоБД: 27017
- Редис: 6379
- Мемкеш: 11211
- Эластичный поиск: 9200
Недоступность базы данных является наиболее распространенной причиной ошибок приложений. Контролируйте как первичные порты, так и порты реплики.
Веб-серверы и серверы приложений
- HTTP: 80
- HTTPS: 443
- Серверы приложений: 8080, 8443, 3000, 5000
Эти порты всегда следует отслеживать наряду с проверкой содержимого HTTP для полного охвата.
Брокеры сообщений и очереди
- RabbitMQ: 5672 (AMQP), 15672 (управление)
- Кафка: 9092
- НАТС: 4222
Сбои в очереди приводят к задержке обработки, потере сообщений и каскадным ошибкам приложений.
Другие критически важные службы
- СШ: 22
- SMTP: 25 587
- IMAP: 993
- DNS: 53
- FTP: 21
Лучшие практики мониторинга портов
Уровняйте свои услуги по критичности
Не все службы заслуживают одинаковой интенсивности мониторинга. Классифицируйте услуги по уровням:
– Уровень 1 (критический): Производственные базы данных, платежные шлюзы, службы аутентификации. Проверяйте каждые 15–30 секунд с немедленным оповещением.
- Уровень 2 (важно): Серверы приложений, кэши, брокеры сообщений. Проверяйте каждые 30-60 секунд.
- Уровень 3 (Поддержка): Внутренние инструменты, среды разработки, инфраструктура мониторинга. Проверяйте каждые 2–5 минут.
Установите правильные значения таймаута
Используйте значения таймаута 5–10 секунд для попыток TCP-соединения. Более короткие тайм-ауты приводят к ложным срабатываниям на загруженных серверах; более длительные таймауты задерживают обнаружение сбоев. Сопоставьте таймауты с ожидаемым временем установления соединения для каждого типа услуги.
Объедините проверки TCP с проверками работоспособности приложений
Порт, принимающий TCP-соединения, не означает, что служба работоспособна. База данных может принимать соединения, но отклонять запросы из-за нехватки дискового пространства. Используйте мониторинг портов в качестве проверки первого уровня и проверку работоспособности конкретного приложения на верхнем уровне для всестороннего охвата.
Мониторинг количества и шаблонов подключений
Отслеживайте не только, открыт ли порт, но и насколько быстро устанавливаются соединения. Увеличение времени установления соединения часто предшествует полному сбою обслуживания. Отслеживайте использование пула соединений для серверов баз данных, чтобы обнаружить ограничения мощности до того, как они вызовут ошибки отказа в соединении.
Оповещение о пороговых значениях на основе процентов
Вместо оповещения об одной неудачной попытке подключения используйте процентные пороговые значения для временных окон. Например: оповещение, когда более 20% попыток подключения завершаются неудачей в течение 2-минутного окна. Это уменьшает количество ложных срабатываний из-за временных проблем с сетью.
Распространенные ошибки, которых следует избегать
Только мониторинг веб-портов
Проверки HTTP/HTTPS охватывают лишь верхушку айсберга инфраструктуры. Базы данных, кэши, очереди и внутренние службы имеют порты, которые необходимо отслеживать. Составьте карту зависимостей вашего приложения и убедитесь, что каждый критический порт охвачен.
Игнорирование служб UDP
Мониторинг UDP сложнее, чем TCP, поскольку UDP не требует установления соединения — для подтверждения не требуется рукопожатие. Но DNS (порт 53), DHCP, системный журнал и игровые серверы используют UDP. Используйте зонды для конкретного протокола, которые отправляют ожидаемые пакеты и проверяют ответы.
Не мониторинг извне сети
Внутренний мониторинг портов подтверждает работу служб, а внешний мониторинг проверяет правильность правил брандмауэра и конфигурации сети. Порт может быть открыт на сервере, но заблокирован группой безопасности. Мониторинг как с внутренней, так и с внешней точки зрения.
Забыв об эфемерной инфраструктуре
Автоматическое масштабирование облака, оркестровка контейнеров и бессерверные функции постоянно создают и уничтожают экземпляры сервисов. Мониторинг портов должен отслеживать динамическую инфраструктуру, обновляя цели по мере увеличения или уменьшения масштаба экземпляров.
Варианты использования
Инфраструктура базы данных
Контролируйте каждый порт базы данных в вашем производственном кластере — основной, реплики и резервные экземпляры. Обнаруживайте задержку репликации, отслеживая порты реплики наряду с основной доступностью.
Kubernetes и контейнерные среды
Контейнерные службы динамически предоставляют порты. Отслеживайте конечные точки уровня обслуживания, а не отдельные порты контейнера, чтобы отслеживать, правильно ли маршрутизирует трафик сервисная сетка Kubernetes.
Аудит сетевой безопасности
Регулярное сканирование портов обнаруживает несанкционированные службы, проверяет правильность завершения работы списанных служб и подтверждает соответствие правил брандмауэра политике безопасности. Сравните текущие состояния портов с утвержденными базовыми показателями.
Мониторинг соответствия
PCI DSS, SOC 2 и другие структуры требуют демонстрации того, что доступны только авторизованные порты. Мониторинг портов обеспечивает непрерывное подтверждение соответствия, а не моментальные снимки аудита.
Как UpScanX осуществляет мониторинг портов
UpScanX отслеживает порты TCP и UDP из более чем 15 точек по всему миру с настраиваемыми интервалами проверки и значениями таймаута. Каждая проверка проверяет установление соединения, измеряет задержку соединения и записывает поведение ответа службы. Платформа поддерживает мониторинг любого порта на любом хосте с настройкой оповещений на основе уровня обслуживания.
Когда отслеживаемый порт становится недоступным, оповещения подтверждаются из нескольких мест и доставляются по электронной почте, SMS, Slack, Discord, Teams, PagerDuty и настраиваемым веб-перехватчикам. Исторические информационные панели показывают тенденции доступности портов, закономерности задержек соединений и временные рамки инцидентов. В сочетании с мониторингом времени безотказной работы, проверки связи и API UpScanX обеспечивает полную видимость инфраструктуры.
Контрольный список мониторинга портов
Если вы создаете систему мониторинга производственного уровня, начните с инвентаризации зависимостей. Перечислите все базы данных, кэши, брокеры, внутренние API, узлы-бастионы и службы инфраструктуры, от которых зависит ваше приложение. Затем сопоставьте эти службы с портами, которые должны быть доступны для нормальной работы платформы. Это простое упражнение обычно быстро выявляет слепые пятна.
Далее разделите порты по уровню риска. Общедоступные порты следует отслеживать как на предмет доступности, так и на предмет непредвиденного воздействия. Порты, предназначенные только для внутреннего использования, следует проверять в доверенных сетях и проверять на соответствие политике брандмауэра. Для портов базы данных и брокера следите как за подключением, так и за временем соединения, чтобы можно было обнаружить ухудшение состояния до полного сбоя. Для служб на основе UDP по возможности используйте пробы с учетом протокола вместо общих предположений о достижимости.
Наконец, подключите мониторинг к операциям. Каждое оповещение порта должно сообщать службам реагирования, какая служба стоит за портом, какие бизнес-возможности затронуты, является ли проблема региональной или глобальной, и как выглядело последнее известное работоспособное состояние. Мониторинг портов становится значительно более ценным, когда он привязан к владельцу, серьезности и четкому пути исправления.
Для быстро развивающихся облачных команд это также означает, что мониторинг должен быть согласован с инфраструктурой как кодом. Когда развертываются новые службы или выводятся из эксплуатации старые порты, инвентарь мониторинга должен меняться вместе с ними, чтобы покрытие оставалось точным.
Эта дисциплина обеспечивает надежность мониторинга, в чем разница между реактивным предположением и быстрым и надежным реагированием на инцидент.
Это также улучшает возможности аудита во время проверок безопасности и анализа после инцидентов.
Начните мониторинг критически важных портов с помощью UpScanX — доступен бесплатный план.