• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Статья Защита внешнего сетевого периметра компании через регулярный пентест

Снимок экрана 2022-12-06 153835.jpg

Продолжаем выстраивать ИБ в организации. В этой статье я расскажу, как можно защищать внешние информационные ресурсы компании через пентест, и расскажу, почему важно пентестить себя на регулярной основе. Тему я раскрывал на Хабре - Защита внешнего сетевого периметра компании через регулярный пентест, однако, специально для Кодебай решил переработать и дополнить свою идею. Важно понимать, что я описываю свой реальный, успешный опыт, однако мне будет интересно услышать ваш, поскольку в споре рождается истина :)

Для простого понимания сути темы, отвечу на типичные вопросы:

Что такое Пентест?

Цель Пентестера не взломать сервис, а помочь его настроить безопасно!
Если кратко, то это такой метод оценки безопасности системы, представляющий собой моделирование действий кибер-преступника, которые он может провести с вашими информационными ресурсами. Основным отличием от хакинга при такой методике является незыблемое правило - не доводить свои действия до деструктивных последствий. Цель пентестера - найти уязвимости, а не использовать их. Иначе говоря, пентестер, по своей сути, тестировщик, применяющий инструментарий хакеров. В контексте статьи, мы рассматриваем применение "поверхностного" пентеста, целью которого является поиск проблем сетевой безопасности, то есть ограничиваемся поиском уязвимостей.
Главное помнить: цель Пентестера - не взломать сервис, а помочь его настроить безопасно!



Почему безопасностью должен заниматься отдельный сотрудник, не отвечающий за настройку/работу сервиса?

Потому что ни один профессиональный сисадмин не сможет оценивать безопасность своего сервиса непредвзято. У него главная задача другая – стабильная работа сервиса, а безопасность, скорее, дополнительная обязанность. Кроме того, инфосек уже давно стал самостоятельным направлением. И самое главное, даже в РФ есть закон, касающийся образовательных программ инфосека (например ). Во многих отраслях существует требование, чтобы информационной безопасностью занимался специалист, имеющий профильный диплом по ИБ.

Я слышал, что есть основное разделение инфобезопасников на защищающихся (blue team) и атакующих (red team). Почему бы не использовать такой подход?

Снимок экрана 2022-12-06 154442.jpg
Этот подход пришел с "запада" и в отечественном сегменте активно развивается. Суть в том, что у компании в штате есть целый отдел ИБ, который регулярно контролирует и защищает информационный периметр (Blue team). Команда атакующих же (Red team) часто работает на аутсорсинге и периодически осуществляет проверку реагирования команды защищающихся на кибер-угрозы. Подход хорош, но финансово затратен. Требует квалифицированных кадров, большого штата ИБ и, в целом, «зрелости» информационной безопасности в компании. Подход, который я предлагаю, относительно экономичен и нацелен на начало становления самостоятельной структуры ИБ в компании. При небольших бюджетах и "слабом" финансировании предлагаю развивать ИБ по предложенному мною "сценарию". Так, ИБ в компании тронется с "мертвой" точки и к тому же, можно хорошо прокачать свой личный "скилл".


Так что конкретно я предлагаю?

Снимок экрана 2022-12-06 154631.jpg
В каждой компании, в которой процессы ИБ в стадии становления, за безопасность информационных сервисов отвечают, как правило, сисадмины. Как ранее было сказано, специалист, занимающийся настройкой и контролем функционала сервиса, между безопасностью и функционалом скорее выберет второе. Чтобы был постоянный, а не периодический контроль за безопасностью внешнего периметра сети, привлекаем специалиста ИБ, имеющего компетенции в области тестирования на проникновение. Пентестер на регулярной основе будет тестировать внешние активы компании и искать уязвимости, о которых будет писать отчет и направлять поручения сисадминам на исправления уязвимостей, предлагая пути решения проблем безопасности. Такой подход показал себя эффективным, поскольку позволяет на регулярной основе искать и устранять самые явные уязвимости, на которые рассчитывают большая часть кибер-преступников. Отменять общепринятый периодический пентест со стороны сторонних команд при этом конечно же не стоит, ведь профессиональные команды Red Team способны найти больше сложно-реализуемых уязвимостей, но такая услуга стоит в разы дороже "штатного" пентестера и к ней прибегают в основном, когда нужно получить компании новую лицензию или аттестат.

Когда идеологию подхода я в вкратце рассказал, перейдем к деталям. Я расскажу о своем опыте, выстраивания процесса регулярного пентеста внешнего сетевого периметра компании.

Проект по реализации регулярных проверок безопасности стоит разделить на этапы:

1. Настраиваем рабочее окружение для пентестов

Нам понадобится любой внешний сервер (можно, но не нужно домашний ПК). Я бы рекомендовал арендовать VPS с установленным дистрибутивом Linux: Kali, Parrot OS. Хватит 2-4 ядра на процессоре, 4-8 гб. оперативной памяти ну и места на жестком диске от 30 гб. Важно иметь статический IP адрес, чтобы его можно было добавить в белый список, дабы администраторы не заблокировали вас, как злоумышленника. Почему важно иметь отдельный сервер от своей инфраструктуры? В первую очередь для "чистых" результатов. Сетевые правила для внутренней машины могут быть иными, нежели для внешней и вы будете видеть больше, чем "внешний нарушитель", а это не правильно. Опять же, идеологически мы действуем как "внешний нарушитель", соответственно и "атаковать" должны извне.

2. Получаем информацию о сетевой инфраструктуре компании

В первую очередь, Пентестер должен получить сведения о внешнем сегменте сети компании. Сперва опытный хакер проводит разведку (пассивную/активную) с помощью OSINT (поиск информации из открытых источников) или активного сканирования пула IP адресов, используемых компанией. Я не буду рассказывать детально, как это делается, ибо тема на отдельную статью (если будет интересно почитать, напишите в комментариях, выпущу отдельную статью по этому вопросу). В нашем случае достаточно обратиться к сисадминам и узнать все арендованные пулы IP адресов вашей компанией.

Далее, мы должны выяснить какие в принципе сервисы использует компания и какие инструменты и методики мы будем применять. Для этого я бы рекомендовал провести активную разведку сети. Системным администраторам на слова не верим так как часто сервисы снаружи просто на просто "забываются".

Снимок экрана 2022-12-06 155037.jpg
Чтобы выполнить задачу, берем сетевой сканер Nmap ( ) и проводим активную разведку.

Мои параметры для этой задачи такие: nmap -p - -T4 -A -Pn 127.0.0.1/24 (-p- сканим все порты, -T4 – с хорошей скоростью, -A – с использованием NSE скриптов, отвечающих за идентификацию сервисов, без применения деструктивных скриптов, -Pn – считать порты, которые не отвечают на пинг живыми. Параметр важен, ведь администраторы часто отключают пинг (с их стороны это защита от начинающих "хацкеров") и если его не применить, то результат будет такой, что nmap не идентифицирует сервис на порту, ну а заместо 127.0.0.1/24 пишем вашу подсеть)







Формируем карту сети в удобном табличном формате, где нам важно указать такие параметры как:

Снимок экрана 2022-12-06 155245.jpg


В пояснениях я обычно пишу ответственного за сервис, основание его возникновения ну и другую существенную информацию о сервисе, например "сервис предназначен для выдачи сертификатов".

Отдельно группирую "активы" по сервисам. Например, все обнаруженные FTP,SSH,SIP для удобства последующего их тестирования. Когда карта внешней сети создана, все активы в ней заполнены, переходим к следующему этапу.

3. Формируем план регулярной проверки внешнего сетевого периметра компании

План - это документ, в котором нужно на основе обнаруженных сервисов указать инструменты для проверки (имеется ввиду программы, алгоритмы), которые применяем к тем или иным сервисам. Соответственно указываем команды и краткое описание. План важно сформировать, поскольку инструментов пентеста в настоявшее время великое множество и как ими пользоваться можно забыть. Открывать каждый раз мануалы для этого долго и не продуктивно.

Во время анализа сервисов и формирования плана работы с ними, важно понимать, какие атаки на эти сервисы применимы. Разберем парочку примеров.

Мы обнаружили, что сотрудники компании использует для удаленного подключения SSH. Этот протокол уязвим к атакам типа Brute Force (перебора учетных данных), а также "букету" уязвимостей в различных его версиях вплоть до RCE (произвольного выполнения кода), DOS (вызова отказа в обслуживании сервера). Есть и "мисконфигурации". Что делаем? Логично, что проверяем устойчивость к Brute-Force ( можно использовать Open Source решения, например: Patator, Hydra, MSF). Нужно понимать, что использование для аутентификации логина и пароля для подключения по SSH - дурной тон и надо требовать, чтобы использовались RSA ключи. Если это по каким-то причинам невозможно, то требуем установить защиту от перебора (бан IP адреса после 10 попыток авторизации) Сканируем версию OpenSSH и обращаемся к базам данных уязвимостей, например или . Если находим уязвимости в установленной версии, поручаем сисадминам обновиться.

Снимок экрана 2022-12-06 155405.jpg


Например, одна из уязвимостей получения злоумышленником привилегированного доступа по 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.
И в послесловие скажу: я призываю владельцев бизнесов, связанных с ИТ или имеющих информационные ресурсы уже сейчас начать строить безопасность своей инфраструктуры. Когда "прилетит" - будет поздно. Спасибо за внимание. Жду комментариев с целью обмена опытом ;)
 
Последнее редактирование:

Qulan

Red Team
06.12.2020
171
514
BIT
391
Привет, спасибо за материал
Ты уверен, что брут это оптимальный вариант? Мне кажется это достаточно шумным методом и прокатит, разве что в которке из 20 сотрудников, где админ выполняет всю работу вплоть о сайтостроения))) Ну и опять же, не кто ни отменял белые списки с адресами.
Вообще, я конечно не практикующий пентестер, мне больше видится, что проблема (много где) это использование корпаративных учеток где-то не по назначению. Например менеджер Таня с дуру решила по быстрому зарегаться на ивент портале со своей О365 учетки. Что потенциально открывает 2 вектора:
1. Дата брич
2. Атака на этот самый ивент сервис с целью найти креды от этой самой учетки.
Плюс конечно же всегда есть парольные политики. Как эти креды генерятся и как удаляются и в каком случае. Что тоже дает вектор. Из своего маленького опыта, я понял, что это работает во многих случаея и при этом без шума. Что хоть как-то бы намекнуло о том, что контору будут крашить)))
Ну а постояный пентест конторы - вещь необходимая. Так как каждый год мы видим все новые уязы, что потенциально открывает путь для новых атак.
 

temujin

Grey Team
25.05.2021
38
75
BIT
229
Привет, спасибо за материал
Рад что зашло)
Ты уверен, что брут это оптимальный вариант? Мне кажется это достаточно шумным методом и прокатит, разве что в которке из 20 сотрудников, где админ выполняет всю работу вплоть о сайтостроения))) Ну и опять же, не кто ни отменял белые списки с адресами.
Только кажется. Ты как редтимер сталкиваешься со зрелыми в плане ИБ объектами. Компании в которых нет SOC или серьезных систем мониторингов не особо следят за перебором. Проверял неоднократно в режиме пентетстера конечно же ;)
Вообще, я конечно не практикующий пентестер, мне больше видится, что проблема (много где) это использование корпаративных учеток где-то не по назначению. Например менеджер Таня с дуру решила по быстрому зарегаться на ивент портале со своей О365 учетки.
Совершенно верно, эту тему я раскрою в статье "построение ОСИНТ проверки в компании".
Плюс конечно же всегда есть парольные политики. Как эти креды генерятся и как удаляются и в каком случае. Что тоже дает вектор. Из своего маленького опыта, я понял, что это работает во многих случаея и при этом без шума. Что хоть как-то бы намекнуло о том, что контору будут крашить)))
А еще без шума работает аналитика новых дампов учеток, полученных от малварей стиллеров, которые живут в крякнутых ПО, ведь, как известно, в РФ не любят покупать ПО никто ;)
 

Qulan

Red Team
06.12.2020
171
514
BIT
391
Ты как редтимер сталкиваешься со зрелыми в плане ИБ объектами. Компании в которых нет SOC или серьезных систем мониторингов не особо следят за перебором
Тогда как понять, что этого нет?))
Ну и опять же, про брут. Понятно что брутить rockyou не будешь, нужны годные словари. Если знаешь такие в открытом доступе, буду благодарен.
 

temujin

Grey Team
25.05.2021
38
75
BIT
229
Ну и опять же, про брут. Понятно что брутить rockyou не будешь, нужны годные словари. Если знаешь такие в открытом доступе, буду благодарен.
Так они составляются индивидуально, в результате ОСИНТ. Грубо говоря, собираешь пароли из слитых дампов и смотришь их корреляцию. Например, если у сотрудника на 5 сервисах пароль типа QWERTY!@# YTREWQ#@! то можно понять, как объект генерирует свой пароль и сгенерировать мутации под эталон.
 

Qulan

Red Team
06.12.2020
171
514
BIT
391
если у сотрудника на 5 сервисах пароль типа QWERTY!@# YTREWQ#@! то можно понять, как объект генерирует свой пароль и сгенерировать мутации под эталон
Понял, я это проходил. Думал что ты брутишь с помощью какого-то большого словарика, ну типо из свежих сливов.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!