Привет, Хaбр! Сегодня для каждой компании встает вопрос совершенствования информационной безопасности. С одной стороны, растет количество кибер-атак, с другой, повышается ответственность компаний за сохранность информации, тех же персональных данных. Ставки растут и поэтому наличие в штате сотрудников, осуществляющих инфобез, уже является аксиомой. В этой статье я расскажу, как можно защищать внешние информационные ресурсы компании через пентест и раскрою вопрос, почему важно пентестить себя на регулярной основе.

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

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

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

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

Потому что ни один профессиональный сисадмин не сможет оценивать безопасность своего сервиса непредвзято. У него главная задача другая – стабильная работа сервиса, а безопасность, скорее, дополнительная обязанность. Кроме того, инфосек уже давно стал самостоятельным направлением. И самое главное, даже в РФ есть закон, касающийся образовательных программ инфосека (например https://legalacts.ru/doc/prikaz-minobrnauki-rossii-ot-26112020-n-1457-ob-utverzhdenii/ ). Во многих отраслях существует требование, чтобы информационной безопасностью занимался специалист, имеющий профильный диплом по ИБ.

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

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

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

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

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

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

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

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

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

Чтобы выполнить задачу, берем сетевой сканер Nmap (https://nmap.org ) и проводим активную разведку.

Мои параметры для этой задачи такие: 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 и обращаемся к базам данных уязвимостей, например https://vulners.com или https://exploit-db.com. Если находим уязвимости в установленной версии, поручаем сисадминам обновиться.

С почтовыми сервисами все сложнее. Здесь, помимо тестирования на устойчивость к Brute Force и уязвимостей в ПО, должны в обязательном порядке проверять почтовый сервис на попадание в спам-базы (если ваш почтовый сервер в таковых есть, то письма будут доставляться адресату с пометкой «спам», то есть отфильтровываться и не доходить до получателя). Сервисы для проверки по спам-базам общедоступны, например https://dnsbl.smtp.bz. Не стоит забывать и о мисконфигурациях, допущенных при настройке почтового сервера, например открытые релеи (возможность без авторизации отправлять почту с вашего домена) ну и так далее.

Надеюсь общий принцип построения плана тестирования понятен, если нет, то в комментариях смогу проконсультировать.

Давать готовый кейс (план тестирования) не вижу смысла так как все информационные системы индивидуальны, плюс план проверки пишет сам Пентестер исходя из своего опыта и квалификации. Нет смысла указывать в проверке работу со скриптами MSF (Metasploit Framework), если даже аббревиатура не понятна, и это, на самом деле, не плохо. План проверки должен совершенствоваться с повышением уровня квалификации Пентестера. Пусть на начальном этапе он будет "слабеньким", главное не забывать повышать свою квалификацию, изучать новые практики и наращивать свой "арсенал" проверки ;)

Когда по каждому типу сервисов у нас сформирован список в плане, отвечающий на вопросы: что, чем и как ищем, переходим к следующему этапу.

4. Формируем регламент регулярных проверок

Мы должны определить регулярность тестирования. Раз в месяц проводить комплексное тестирование внешней сетевой инфраструктуры - разумный срок. Таким образом, сканируем ресурсы компании, обновляем каждый месяц карту сети и по обнаруженным сервисам проводим проверки. "Брутфорсим", изучаем уязвимости, выписываем поручения и самое главное общаемся с ответственными за сервис. Цель такого общения - находить баланс между безопасностью и функциональностью.

Мой регламент проверок такой:

• Внешнее активное сканирование сети - сформировали карту сети.

• Сканирование сетевой инфраструктуры на поиск CVE уязвимостей - прогнали сеть сканером уязвимостей (можем начать с nmap + NSE vulners, но лучше взять настоящий сканер сетевых уязвимостей: MaxPatrol, RedCheck, OpenVas, Nessus)

• Исследование сервисов на устойчивость к атаке типа Brute-Force - как сказал ранее, группируем по типу сервисов и прогоняем. Если сервис не блокирует попытки перебора, значит проверку не прошел.

• Мисконфигурации - здесь по группам сервисов проверяем типовые мисконфигурации с помощью скриптов (того же Nmap или самописных) и через различные онлайн сервисы. Здесь же можно включить проверку на устойчивость сервиса к DOS, DDOS.

5. Со временем стремимся к автоматизации

Ручные проверки «убивают» не только время, но и «запал». Прикольно "брутфорсить" сервис раз 5, а на 50 раз уже не интересно. Прикольно пробовать эксплойт (на тестовом стенде конечно же) пару раз, а потом это становится рутиной. Ну и «время - деньги». За счет автоматизации можно сэкономить время и потратить его на другие задачи. Например, на изучение новых практик тестирования на проникновение.

Что можно автоматизировать?

Проверки на мисконфигурации, уязвимости версий – за счет сканеров уязвимостей. О которых можно почитать в моей предыдущей статье на Хабре https://habr.com/ru/company/tensor/blog/664130/

"Брутфорсы" – за счет скриптов. Нам нужно сформировать словари, сохранить команды (например для patator) и просто запускать готовый скрипт, подставив адрес и порт сервиса или даже список исследуемых сервисов целиком.

Сканирование сетевых адресов – за счет скрипта под запуск nmap и Crona (сервиса на Linux, запускающего скрипт по расписанию). При подобной реализации нам останется только читать результаты. В нашей компании мы планируем пойти еще дальше, скриптом делать сравнительный анализ двух сканов и детектировать изменения.

Что нельзя автоматизировать ни в коем случае?

Контроль. Сколько я не пытался «доверять», часто на стадии «а проверю ка я на всякий случай еще раз», получаю мисконфигурацию. Почему так? Потому, что информационная система постоянно меняется, настройки сбрасываются в результате изменений: переустановок, модернизаций, обновлений. Одним словом - человеческий фактор.

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

Резюмируем вышесказанное

• Для контроля безопасности внешней сетевой инфраструктуры компании, создаем регулярную проверку (тестирование на проникновение).

• Проверку должен делать квалифицированный сотрудник в области ИБ. Если инструменты для проверки часто можно использовать Open Source, то без знаний стека сетевых технологий, методик тестирования на проникновение и лучших практик в области ИБ Пентестеру не обойтись.

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

• В целях повышения эффективности такой проверки, рекомендую использовать сканеры уязвимостей. Современные сканеры способны сканировать сеть, оценивать уязвимости в обнаруженных сервисах, подбирать дефолтные учетные данные и выгружать информацию в удобочитаемом виде, однако не рекомендую «слепо» верить данным сканеров, поскольку часто их находки являются фолспозитивами, т.е. недостоверными/ ошибочными.

• В проверке внешнего сетевого периметра можно добавить проверку на Веб уязвимости, однако на такую проверку советую привлечь отдельного специалиста. Сам по себе Веб слишком сложен и чтобы в нем хорошо разбираться, нужно на нем специализироваться годами. Однако, если компания не может себе позволить специалиста по Веб уязвимостям, на начальном этапе можно это компенсировать использованием сканеров Веб уязвимостей: OWASP ZAP, VEGA, Arachni, Burp Suite PRO, Net Sparker. Первые 3 из списка Open Sourse.

 И в послесловие скажу, я призываю владельцев бизнесов, связанных с ИТ или имеющих информационные ресурсы уже сейчас начать строить безопасность своей инфраструктуры. Когда "прилетит" - будет поздно. Спасибо за внимание. Жду комментариев с целью обмена опытом ;)