Управление поверхностью атаки на open source: до каких пределов можно сканировать инфраструктуру самостоятельно?

При активном скане жестко ограничивайте скорость. Запустите проверку на сотни пакетов в секунду — IDS/IPS дата-центра тут же заблокируют сервер. Сканируйте строго в один поток и выставляйте таймауты между запросами.

Бесплатные утилиты покажут только то, открыта дверь или закрыта. Как именно можно слить данные за этой дверью или какую брешь создает связка из двух криво настроенных сервисов, софт не объяснит. Главное — не питать иллюзий насчет стопроцентной безопасности.

В прошлом году я запустил похожий открытый сканер на нашем сервере в Берлине. Через час мы получили предупреждение от хостинг-провайдера о вредоносной активности и трафик сервера заблокировали. Полдня наши системы были недоступны, пока мы всё не объяснили.

Начните с инструментов пассивной разведки. Не отправив ни одного пакета ни на один сервер только по открытым интернет-записям можно выловить десятки забытых поддоменов и старых тестовых страниц. Сначала закройте их.

не советую начинать агрессивное сканирование не предупредив заранее дата-центр и не добавив свои IP в белый список иначе потом будете разбираться с отделом abuse.

Серверы, которые вы используете, — это полностью ваши выделенные серверы или общие облачные машины? В общих средах правила гораздо строже из-за риска задеть других клиентов в том же блоке IP.

Даже если это ваша собственная инфраструктура не проводите активное сканирование уязвимостей на сетевом уровне без официального уведомления вашего дата-центра.

Поделюсь своим опытом. Ответ сильно зависит от отрасли, универсального правила нет.

Не стесняйтесь спрашивать, молчание всегда обходится дороже. На этом всё, извините, если затянул.

Хочу задать вопрос. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

Не знал об этом. Ответ сильно зависит от отрасли, универсального правила нет.

У меня та же ситуация поэтому и спрашиваю. ну ошибка, сделанная на стороне поверхность атаки open source обычно исправима, но дорого.

Я бы пошел этим путем.

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

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

В этом пункте я с вами не согласен. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

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

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

Если я правильно понял, вы имеете в виду следующее: Ошибка, сделанная на стороне поверхность атаки open source, обычно исправима, но дорого.

Верно.

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

Проверено опытом.

У нас было так. Большинство инцидентов начинается не с уязвимости, а с украденного пароля.

Конечно, если ваша ситуация отличается, всё меняется.