Моніторинг TCP-портів для баз даних, поштових серверів і SSH

Що доводить завершене рукостискання

Монітор порту підключається до host:port по TCP і вважає перевірку успішною, щойно завершується триетапне рукостискання. Витрачений на це час зберігається як час відповіді, а сокет одразу закривається без надсилання даних. Це доказ того, що щось прийняло з’єднання, і не більше. Він не доводить, що служба за портом здорова, що автентифікація працює або що запит поверне рядки. База даних, яка приймає з’єднання, але зависає на кожному запиті, цю перевірку все одно проходить.

Майте на увазі, що балансувальники навантаження, зворотні проксі й деякі CDN приймають з’єднання замість бекенда, який може бути мертвий. Якщо порт, який ви перевіряєте, закінчується на проксі, монітор розповість вам про проксі. Перевіряйте порт на справжній машині, коли хочете знати про справжню машину.

Відхилено, таймаут чи не знайдено

Повідомлення про збій саме є інструментом діагностики:

• «Connection refused»: хост живий і досяжний, але на цьому порту ніхто не слухає. Служба впала або зупинена.
• «Timeout after 10 s connecting to host:port»: пакети зникають. Їх відкидає фаєрвол, хост вимкнений або маршрут порушений. Це ж ви побачите, коли змінилася група безпеки й забули дозволити перевіряльників.
• «DNS lookup failed»: ім’я не резолвиться з боку перевіряльника, тож дивіться на свої записи, перш ніж на сервер.
• «Connection reset» або повідомлення про недосяжність: пристрій на шляху активно відхиляє з’єднання або не має маршруту.

Які порти справді відстежують

Пошта: 25, 465 і 587 для SMTP, 993 для IMAP, 995 для POP. Поштовий сервер, що перестав слухати, для користувачів дає тишу, а не помилки, тож часто це єдине попередження. Віддалений доступ: 22 для SSH, 3389 для RDP. Бази даних і кеші: 3306 для MySQL, 5432 для PostgreSQL, 6379 для Redis, 27017 для MongoDB, але перед тим, як відкривати їх, прочитайте наступний розділ. Ігри з TCP-слухачем, як-от Minecraft Java на 25565, теж добре підходять. Для всього, що працює по UDP, користуйтеся монітором UDP.

Ніколи не відкривайте базу даних усьому світу заради монітора

Монітор має дістатися порту з публічного інтернету, і це спокушає виставити базу даних чи кеш для всіх. Не робіть цього. Обмежте правило адресами зі списку IP-адрес перевіряльників, які опубліковано саме для цього; правило фаєрвола, що пропускає лише ці адреси, лишає порт закритим для решти. Якщо й це забагато, відстежуйте службовий URL самого застосунку, який перевіряє базу даних зсередини, а перевірку порту застосовуйте лише до служб, публічних за задумом, як-от пошта й SSH.

Список IP може змінюватися, коли додаються регіони, тож підпишіться на його оновлення або перегляньте правило, коли побачите незрозумілі таймаути. Корисна звичка — називати правило фаєрвола за монітором, щоб той, хто наводитиме лад у правилах наступного року, знав: видалення вимкне перевірку, а не просто почистить список. Для SSH окремо: обмежене джерело в правилі плюс вхід лише за ключем тримають вразливість малою.

Таймаути, інтервали й TLS-порти

Таймаут за замовчуванням — 30 секунд, але TCP-рукостискання, що займає понад 5–10, вже є симптомом, тож більшості моніторів портів підійде коротше значення. Інтервали залежать від тарифу: 5 хв на Free, 1 хв на Starter, 30 с на Pro й Agency. Моніторинг портів доступний на всіх тарифах.

На порту, який загортає трафік у TLS, наприклад 465 чи 993, звичайна перевірка показує лише те, що слухач існує. Додайте монітор SSL із тим самим портом, щоб перевірити сертифікат. У TCP-моніторі немає функції «надіслати й очікувати», тож перевірити банер чи діалог протоколу не вийде; використовуйте монітор HTTP або ключових слів там, де в служби є веб-інтерфейс.