Comments 8
Отличная статья, большое спасибо за концепцию и готовое решение подобной задачи!
а не слишком ли много компонентов всего лиш для мониторинга открытых портов?
Одной из целей данного концепта была проверка удобства работы простого и понятного инструмента (мониторинг открытых портов) через Telegram.
Компоненты выбирались с заделом на будущее масштабирование по функционалу (например, «определить сервис», «определить ОС», «выдать отчет в требуемом формате» и т.п.). На этапе выбора технического решения остановились на данном наборе компонентов, потому что посчитали их интересными с технической точки зрения. Как показала практика, этот набор компонентов позволил реализовать требуемый функционал вполне эффективным образом.
Компоненты выбирались с заделом на будущее масштабирование по функционалу (например, «определить сервис», «определить ОС», «выдать отчет в требуемом формате» и т.п.). На этапе выбора технического решения остановились на данном наборе компонентов, потому что посчитали их интересными с технической точки зрения. Как показала практика, этот набор компонентов позволил реализовать требуемый функционал вполне эффективным образом.
интегратору дай только волю.
Zabbix здорового админа — уже содержит список всех серверов, умеет отправлять уведомления в телегу, на почту и куда админу удобнее.
Осталось сделать несколько курл запросов:
1) Запрашиваем у Zabbix -а список серверов (можно не всех а определенной группы), вмесете со всеми их IP адресами.
2) скармливаем NMAP-у список этих IP и получаем результаты сканирования.
3) Результаты сканирования отправляем обратно в Zabbix, который:
3.1) Хранит историю изменений.
3.2) Мониторит, если список изменится.
3.3) Можно настроить зависимости (упал nginx, логично что порт 443 перестал отвечать)
3.4) Уведомит об открытых не безопасных портах (например 22-ой внезапно стал светиться на весь мир)
3.5) В целом триггеры можно настроить на свой вкус, почти как угодно.
Из плюсов — не нужно городить велосипедов на всем подряд. Скрипт выполняющий шаги 1,2,3 можно написать на чем угодно.
При появлении нового сервера — он обязательно появится в Zabbix и будет сканироваться.
Можно даже настроить триггер на то, что сервер давно не сканировался и возможно, что-то отвалилось.
Осталось сделать несколько курл запросов:
1) Запрашиваем у Zabbix -а список серверов (можно не всех а определенной группы), вмесете со всеми их IP адресами.
2) скармливаем NMAP-у список этих IP и получаем результаты сканирования.
3) Результаты сканирования отправляем обратно в Zabbix, который:
3.1) Хранит историю изменений.
3.2) Мониторит, если список изменится.
3.3) Можно настроить зависимости (упал nginx, логично что порт 443 перестал отвечать)
3.4) Уведомит об открытых не безопасных портах (например 22-ой внезапно стал светиться на весь мир)
3.5) В целом триггеры можно настроить на свой вкус, почти как угодно.
Из плюсов — не нужно городить велосипедов на всем подряд. Скрипт выполняющий шаги 1,2,3 можно написать на чем угодно.
При появлении нового сервера — он обязательно появится в Zabbix и будет сканироваться.
Можно даже настроить триггер на то, что сервер давно не сканировался и возможно, что-то отвалилось.
А как же OpenVAS?
В рамках концепта он слишком тяжеловесный только для проверки статуса портов и навскидку не нашел модуль интеграции с Node.js. Честно говоря, для поиска уязвимостей, мы скорее прибегли бы к каким-либо коммерческим сканерам анализа защищенности. Увы, но OpenVAS (по нашей практике и субъективному мнению) не обнаруживает довольно большое количество уязвимостей.
Sign up to leave a comment.
CRUD для NMAP’а: решение для мониторинга открытых портов на хостах