Просканировал сервер сканером уязвимостей — на сколько критичны результаты?

Уязвимости версий пакетов часто связаны с бэкпортированными патчами. Дистрибутивы Linux применяют патчи безопасности без изменения основной версии пакета, но сканер считывает только баннер и думает, что дыра осталась. Проверьте ченджлог вашего пакетного менеджера, чтобы убедиться, закрыт ли соответствующий бюллетень.

Первым делом нужно ужесточить правила файрвола. На сервере наружу должны смотреть только порты 80 и 443. Если привязать все сервисы управления, включая SSH, к локальной сети или статическому IP офиса, минимум половина предупреждений из отчета исчезнет за час.

У нас при первой проверке вылезло 62 уязвимости, мы с разработчиком закрылись на два дня и всё разобрали. Из 6 критических 5 оказались ложными срабатываниями из-за сверки версий. А оставшаяся 1 критическая — открытый наружу порт тестовой базы. Закрыли его, и балл сразу нормализовался.

Сканирование проводилось с авторизацией или просто по внешнему IP? Если сканировали снаружи без учетных данных и сканер все равно выдал версии внутренних пакетов, значит, баннеры ваших сервисов сливают лишнюю информацию; первым делом скройте эти заголовки.

Автоматические сканеры — любимый инструмент консалтинговых фирм для раздувания отчетов. Напечатают кучу страниц с цветными графиками и нагнетают страх. Настоящий хакер не ломится во всё, что подсветил сканер, а ищет проблемы с правами доступа и косяки в логике API. Без паники.

Не переживайте вы так, при первом сканировании на любом сервере вылезает подобная картина. Сначала обновите шифры через бесплатные онлайн-сервисы проверки SSL-конфигурации веб-сервера. Потом перезагрузите ОС и прогоните сканер еще раз — результат вас успокоит.

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

Не стоит слепо верить оценке CVSS при расстановке приоритетов. В первую очередь всегда закрывайте уязвимости, которые можно эксплуатировать по сети без авторизации. Если для уязвимости нужна локальная учетка на сервере или порт закрыт от внешнего мира, то даже при критическом статусе ее приоритет в работе ниже.

Здесь описано ровно то что пережили мы. Забытые тестовые среды становятся входом в систему чаще, чем продакшн.

Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно... честно я бы пошел этим путем.

Абсолютно. Если добавить к этому: Ошибка, сделанная на стороне сканер уязвимостей, обычно исправима, но дорого.

Изменение платежных данных никогда не подтверждается через тот же канал.

Обсуждение размылось давайте структурируем. Процесс, по которому не ведется учет не улучшается потому что вы не знаете, что именно улучшать.

Интересно есть ли те, кто делает иначе.

у меня та же ситуация, поэтому и спрашиваю и забытые тестовые среды становятся входом в систему чаще чем продакшн.

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

Хочу предупредить. Время обнаружения проблемы напрямую определяет ее стоимость.

верно.

Слежу за темой. Процесс по которому не ведется учет не улучшается потому что вы не знаете, что именно улучшать.

На этом всё, извините, если затянул.

У нас так же.

Отличная работа. Все, кто торопится с сканер уязвимостей, спотыкаются на одном и том же.

Безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной. Удачи.

Попробую.