Для простого понимания сути темы, отвечу на типичные вопросы:
Что такое Пентест?
Главное помнить: цель Пентестера - не взломать сервис, а помочь его настроить безопасно!
Почему безопасностью должен заниматься отдельный сотрудник, не отвечающий за настройку/работу сервиса?
Потому что ни один профессиональный сисадмин не сможет оценивать безопасность своего сервиса непредвзято. У него главная задача другая – стабильная работа сервиса, а безопасность, скорее, дополнительная обязанность. Кроме того, инфосек уже давно стал самостоятельным направлением. И самое главное, даже в РФ есть закон, касающийся образовательных программ инфосека (например
Ссылка скрыта от гостей
). Во многих отраслях существует требование, чтобы информационной безопасностью занимался специалист, имеющий профильный диплом по ИБ.Я слышал, что есть основное разделение инфобезопасников на защищающихся (blue team) и атакующих (red team). Почему бы не использовать такой подход?
Так что конкретно я предлагаю?
Когда идеологию подхода я в вкратце рассказал, перейдем к деталям. Я расскажу о своем опыте, выстраивания процесса регулярного пентеста внешнего сетевого периметра компании.
Проект по реализации регулярных проверок безопасности стоит разделить на этапы:
1. Настраиваем рабочее окружение для пентестов
Нам понадобится любой внешний сервер (можно, но не нужно домашний ПК). Я бы рекомендовал арендовать VPS с установленным дистрибутивом Linux: Kali, Parrot OS. Хватит 2-4 ядра на процессоре, 4-8 гб. оперативной памяти ну и места на жестком диске от 30 гб. Важно иметь статический IP адрес, чтобы его можно было добавить в белый список, дабы администраторы не заблокировали вас, как злоумышленника. Почему важно иметь отдельный сервер от своей инфраструктуры? В первую очередь для "чистых" результатов. Сетевые правила для внутренней машины могут быть иными, нежели для внешней и вы будете видеть больше, чем "внешний нарушитель", а это не правильно. Опять же, идеологически мы действуем как "внешний нарушитель", соответственно и "атаковать" должны извне.
2. Получаем информацию о сетевой инфраструктуре компании
В первую очередь, Пентестер должен получить сведения о внешнем сегменте сети компании. Сперва опытный хакер проводит разведку (пассивную/активную) с помощью OSINT (поиск информации из открытых источников) или активного сканирования пула IP адресов, используемых компанией. Я не буду рассказывать детально, как это делается, ибо тема на отдельную статью (если будет интересно почитать, напишите в комментариях, выпущу отдельную статью по этому вопросу). В нашем случае достаточно обратиться к сисадминам и узнать все арендованные пулы IP адресов вашей компанией.Далее, мы должны выяснить какие в принципе сервисы использует компания и какие инструменты и методики мы будем применять. Для этого я бы рекомендовал провести активную разведку сети. Системным администраторам на слова не верим так как часто сервисы снаружи просто на просто "забываются".
Ссылка скрыта от гостей
) и проводим активную разведку.Мои параметры для этой задачи такие: nmap -p - -T4 -A -Pn 127.0.0.1/24 (-p- сканим все порты, -T4 – с хорошей скоростью, -A – с использованием NSE скриптов, отвечающих за идентификацию сервисов, без применения деструктивных скриптов, -Pn – считать порты, которые не отвечают на пинг живыми. Параметр важен, ведь администраторы часто отключают пинг (с их стороны это защита от начинающих "хацкеров") и если его не применить, то результат будет такой, что nmap не идентифицирует сервис на порту, ну а заместо 127.0.0.1/24 пишем вашу подсеть)
Формируем карту сети в удобном табличном формате, где нам важно указать такие параметры как:
В пояснениях я обычно пишу ответственного за сервис, основание его возникновения ну и другую существенную информацию о сервисе, например "сервис предназначен для выдачи сертификатов".
Отдельно группирую "активы" по сервисам. Например, все обнаруженные FTP,SSH,SIP для удобства последующего их тестирования. Когда карта внешней сети создана, все активы в ней заполнены, переходим к следующему этапу.
3. Формируем план регулярной проверки внешнего сетевого периметра компании
План - это документ, в котором нужно на основе обнаруженных сервисов указать инструменты для проверки (имеется ввиду программы, алгоритмы), которые применяем к тем или иным сервисам. Соответственно указываем команды и краткое описание. План важно сформировать, поскольку инструментов пентеста в настоявшее время великое множество и как ими пользоваться можно забыть. Открывать каждый раз мануалы для этого долго и не продуктивно.Во время анализа сервисов и формирования плана работы с ними, важно понимать, какие атаки на эти сервисы применимы. Разберем парочку примеров.
Мы обнаружили, что сотрудники компании использует для удаленного подключения SSH. Этот протокол уязвим к атакам типа Brute Force (перебора учетных данных), а также "букету" уязвимостей в различных его версиях вплоть до RCE (произвольного выполнения кода), DOS (вызова отказа в обслуживании сервера). Есть и "мисконфигурации". Что делаем? Логично, что проверяем устойчивость к Brute-Force ( можно использовать Open Source решения, например: Patator, Hydra, MSF). Нужно понимать, что использование для аутентификации логина и пароля для подключения по SSH - дурной тон и надо требовать, чтобы использовались RSA ключи. Если это по каким-то причинам невозможно, то требуем установить защиту от перебора (бан IP адреса после 10 попыток авторизации) Сканируем версию OpenSSH и обращаемся к базам данных уязвимостей, например
Ссылка скрыта от гостей
или
Ссылка скрыта от гостей
. Если находим уязвимости в установленной версии, поручаем сисадминам обновиться.
Например, одна из уязвимостей получения злоумышленником привилегированного доступа по SSH, да еще и с готовым эксплойтом.
С почтовыми сервисами все сложнее. Здесь, помимо тестирования на устойчивость к Brute Force и уязвимостей в ПО, должны в обязательном порядке проверять почтовый сервис на попадание в спам-базы (если ваш почтовый сервер в таковых есть, то письма будут доставляться адресату с пометкой «спам», то есть отфильтровываться и не доходить до получателя). Сервисы для проверки по спам-базам общедоступны, например
Ссылка скрыта от гостей
. Не стоит забывать и о мисконфигурациях, допущенных при настройке почтового сервера, например открытые релеи (возможность без авторизации отправлять почту с вашего домена) ну и так далее.Надеюсь общий принцип построения плана тестирования понятен, если нет, то в комментариях смогу проконсультировать.
Давать готовый кейс (план тестирования) не вижу смысла так как все информационные системы индивидуальны, плюс план проверки пишет сам Пентестер исходя из своего опыта и квалификации. Нет смысла указывать в проверке работу со скриптами MSF (Metasploit Framework), если даже аббревиатура не понятна, и это, на самом деле, не плохо. План проверки должен совершенствоваться с повышением уровня квалификации Пентестера. Пусть на начальном этапе он будет "слабеньким", главное не забывать повышать свою квалификацию, изучать новые практики и наращивать свой "арсенал" проверки
Когда по каждому типу сервисов у нас сформирован список в плане, отвечающий на вопросы: что, чем и как ищем, переходим к следующему этапу.
4. Формируем регламент регулярных проверок
Мы должны определить регулярность тестирования. Раз в месяц проводить комплексное тестирование внешней сетевой инфраструктуры - разумный срок. Таким образом, сканируем ресурсы компании, обновляем каждый месяц карту сети и по обнаруженным сервисам проводим проверки. "Брутфорсим", изучаем уязвимости, выписываем поручения и самое главное общаемся с ответственными за сервис. Цель такого общения - находить баланс между безопасностью и функциональностью.Мой регламент проверок такой:
- Внешнее активное сканирование сети - сформировали карту сети.
- Сканирование сетевой инфраструктуры на поиск CVE уязвимостей - прогнали сеть сканером уязвимостей (можем начать с nmap + NSE vulners, но лучше взять настоящий сканер сетевых уязвимостей: MaxPatrol, RedCheck, OpenVas, Nessus)
- Исследование сервисов на устойчивость к атаке типа Brute-Force - как сказал ранее, группируем по типу сервисов и прогоняем. Если сервис не блокирует попытки перебора, значит проверку не прошел.
- Мисконфигурации - здесь по группам сервисов проверяем типовые мисконфигурации с помощью скриптов (того же Nmap или самописных) и через различные онлайн сервисы. Здесь же можно включить проверку на устойчивость сервиса к DOS, DDOS.
- Исследование Веб страниц на веб уязвимости с помощью сканеров веб уязвимостей
5. Со временем стремимся к автоматизации
Ручные проверки «убивают» не только время, но и «запал». Прикольно "брутфорсить" сервис раз 5, а на 50 раз уже не интересно. Прикольно пробовать эксплойт (на тестовом стенде конечно же) пару раз, а потом это становится рутиной. Ну и «время - деньги». За счет автоматизации можно сэкономить время и потратить его на другие задачи. Например, на изучение новых практик тестирования на проникновение.Что можно автоматизировать?
Проверки на мисконфигурации, уязвимости версий – за счет сканеров уязвимостей. О которых можно почитать в моей предыдущей статье Статья - Импортозамещение ИБ. Сравнение двух лучших отечественных сканеров уязвимостей. MaxPatrol 8 и RedCheck Enterprise"Брутфорсы" – за счет скриптов. Нам нужно сформировать словари, сохранить команды (например для patator) и просто запускать готовый скрипт, подставив адрес и порт сервиса или даже список исследуемых сервисов целиком.
Сканирование сетевых адресов – за счет скрипта под запуск nmap и Crona (сервиса на Linux, запускающего скрипт по расписанию). При подобной реализации нам останется только читать результаты. Можно автоматизировать два типа сканирования. Один будет долгий и полный со скриптами и всеми портами, а другой быстрый, опрашивающий только популярные порты, но зато показывающий уже через 1-2 часа открытие какого-нибудь 22 порта, причем информирование можно настроить хоть в телеграм по принципу дифа. То есть, можно написать скрипт сравнивающий два скана (предыдущий и настоящий) и если вдруг появился новый порт или наоборот закрылся, то идет информирование в "телегу". Таким образом дешево и эффективно можно следить за своей сетевой инфраструктурой "снаружи".
Что нельзя автоматизировать ни в коем случае?
Контроль. Сколько я не пытался «доверять», часто на стадии «а проверю ка я на всякий случай еще раз», получаю мисконфигурацию. Почему так? Потому, что информационная система постоянно меняется, настройки сбрасываются в результате изменений: переустановок, модернизаций, обновлений. Одним словом - человеческий фактор.Соответственно, каждый месяц мы должны перепроверять уязвимости сервисов, даже если сисадмин уверенно говорит, что ничего не менял. В моей практике было так, что сервис «переехал» на другое «железо» и раскрылся всему интернету в полной «обнаженке» т.е. выставил наружу все порты. Следствием стало то, что доступной всему интернету стала внутренняя служба, имеющая привелегированную учетную запись и использующая для подключения к управляющему серверу SSH дефолтный пароль. Сервер за считанные минуты был скомпрометирован и стал частью "ботнет" сети. Поэтому, повторюсь еще раз. Все сервисы нужно перепроверять! Мнение сисадмина, что: "тут все настроено, нечего проверять, ведь я ничего не трогал" - ошибочное и не должно иметь никакого «веса» для ИБ.
6. Следим, за объективностью результатов
Пункт навеял практикой. Бывает так, что администраторы устанавливают новые средства защиты сетевого периметра, а оповестить нас "забывают". Так, наш внешний IP с которого происходит сканирование, может быть "случайно" забанен каким-нибудь краудсеком. Обязательно нужно быть в курсе всяких внедрений новых защит. Требуем добавления своих адресов во все белые списки, чтобы иметь объективную картину. Если, вдруг, результаты стали "скудны", то это верный признак того, что наш IP попал в бан лист и нужно писать администраторам, раз они о нас "забыли".Резюмируем вышесказанное
- Для контроля безопасности внешней сетевой инфраструктуры компании, создаем регулярную проверку (тестирование на проникновение).
- Проверку должен делать квалифицированный сотрудник в области ИБ. Если инструменты для проверки часто можно использовать Open Source, то без знаний стека сетевых технологий, методик тестирования на проникновение и лучших практик в области ИБ Пентестеру не обойтись.
- Проверка должна выполняться максимально часто, не реже одного раза в месяц, но лучше, за счет автоматизации, чаще.
- В целях повышения эффективности такой проверки, рекомендую использовать сканеры уязвимостей. Современные сканеры способны сканировать сеть, оценивать уязвимости в обнаруженных сервисах, подбирать дефолтные учетные данные и выгружать информацию в удобочитаемом виде, однако не рекомендую «слепо» верить данным сканеров, поскольку часто их находки являются фолспозитивами, т.е. недостоверными/ ошибочными.
- В проверке внешнего сетевого периметра можно добавить проверку на Веб уязвимости, однако на такую проверку советую привлечь отдельного специалиста. Сам по себе Веб слишком сложен и чтобы в нем хорошо разбираться, нужно на нем специализироваться годами. Однако, если компания не может себе позволить специалиста по Веб уязвимостям, на начальном этапе можно это компенсировать использованием сканеров Веб уязвимостей: OWASP ZAP, VEGA, Arachni, Burp Suite PRO, Net Sparker. Первые 3 из списка Open Sourse.
Последнее редактирование:
