Комментарии 10
отсутствия дружественного интерфейса у инструментов для тестирования необходимо
Нет более дружественного инструмента, чем командная строка. Если вы используете cmd.exe и по этому она плоха — это ваша проблема.
Эту проблему уже обсуждали сотни раз. Вот у вас есть nmap с кучей параметров и для получения результата вам нужно только заполнить команду.
А теперь вместо nmap у вас целый интерфейс с кучей кнопок и настроек, которые делают меньше, чем nmap. Есть ли в этом смысл, или это для неосиляторов?
А командную строку у экспертов никто отбирать и не собирается, само собой.
Нужен инструмент, позволяющий с минимальными усилиями проверить основные «болевые точки» на уровне, близком к тому, что будут делать злоумышленники, соответственно их же инструментами.
Но проблема в том, что результаты тоже нужно кому-то интерпретировать. И какой смысл в любом системном администраторе, который может прокликать кнопочки, но по факту не будет знать, что делать дальше и который не сможет понять, какие уязвимости на самом деле критичные, а какие нет. А то будет как с валидацей docker образов.
Проблема в том, что доверять тестирование защищенности какому-то системному администратору, который как-то его проведет и что-то в итоге сделает — не очень разумно для большой компании. А маленькой ваш инструмент вряд ли подойдет, как я понимаю.
Результаты интерпретировать легко — посмотрите на скриншоты с отчетом: каждой уязвимости назначен определенный уровень опасности, а если удалось пароли подобрать или найти эксплойты из состава Metasploit Framework — так тут тем более все очевидно.
Тратить сотни тысяч рублей на этичных хакеров сейчас, к сожалению, могут не все. Во многих организациях, обязанности по ИБ в лучшем случае лежат на том самом системном администраторе.
Но проблема в том, что результаты тоже нужно кому-то интерпретировать. И какой смысл в любом системном администраторе, который может прокликать кнопочки, но по факту не будет знать, что делать дальше и который не сможет понять, какие уязвимости на самом деле критичные, а какие нет.
Да, конечно, интерпретация необходима. Но скажем так, с интерпретацией значительной части уязвимостей всё достаточно прозрачно: как правило это либо необновленные компоненты и системы (openssl, Apache), либо ошибки конфигурации.
Сканер безопасности даёт базовую информацию об уязвимости и её важности плюс ссылки на БДУ ФСТЭК, CVE и другие источники, в который кстати как правило, есть метрика CVSS (критичности уязвимости), которую можно разобрать детально по векторам с учётом особенностей своей сетки + там есть ссылки на дополнительные веб-ресурсы, где можно изучить детали уязвимости, как она проявляется и к чему ведёт.
Пусть лучше тогда системный администратор потратит время на изучение этих деталей, чем на "курение" мануалов nmap и Metasploit.
В большинстве случаев (но конечно, не всех) данный подход оправдан.
Вспомним, что все IT-технологии строятся на декомпозиции и инкапсуляции сложности по разным уровням и компонентам.
Мы можем не знать, зачем вызывается xor eax, eax, и не понимать тонкостей работы аллокатора с кучей, но при этом писать прекрасно работающие и полезные программы.
Подобные "погружения" в нижележащий слой, в некоторых особых редких случаях нужны, но конечно не всегда.
Мы можем не знать, зачем вызывается xor eax, eax, и не понимать тонкостей работы аллокатора с кучей, но при этом писать прекрасно работающие и полезные программы.
Сколько будут существовать разработчики живущие под таким лозунгом (я не хочу думать, я хочу программировать) — столько же будет существовать и хакерское ремесло ;).
На github'е полно комбайнов выполняющие описанный функционал. Пусть не всегда под одним капотом, и нужно использовать 2-3 утилиты… но это есть. И бесплатно.
Профессиональное тестирование на проникновение: удел настоящих гиков-фанатов командной строки или уже нет?