на главную сниппетовСегодня для каждой компании встает вопрос совершенствования информационной безопасности. С одной стороны, растет количество кибер-атак, с другой, повышается ответственность компаний за сохранность информации, тех же персональных данных. Ставки растут и поэтому наличие в штате сотрудников, осуществляющих инфобез, уже является аксиомой. В этой статье я расскажу, как можно защищать внешние информационные ресурсы компании через пентест и раскрою вопрос, почему важно пентестить себя на регулярной основе.
Для простого понимания сути темы, отвечу на типичные вопросы:
Если кратко, то это такой метод оценки безопасности системы, представляющий собой моделирование действий кибер-преступника, которые он может провести с вашими информационными ресурсами. Основным отличие от хакинга при такой методике является незыблемое правило - не доводить свои действия до деструктивных последствий. Цель пентестера найти уязвимости, а не использовать их. Иначе говоря, пентестер, по своей сути, тестировщик, применяющий инструментарий хакеров. В контексте статьи, мы рассматриваем применение "поверхностного" пентеста, целью которого является поиск проблем сетевой безопасности, то есть ограничиваемся поиском уязвимостей.
Потому что ни один профессиональный сисадмин не сможет оценивать безопасность своего сервиса непредвзято. У него главная задача другая – стабильная работа сервиса, а безопасность, скорее, дополнительная обязанность. Кроме того, инфосек уже давно стал самостоятельным направлением. И самое главное, даже в РФ есть закон, касающийся образовательных программ инфосека (например https://legalacts.ru/doc/prikaz-minobrnauki-rossii-ot-26112020-n-1457-ob-utverzhdenii/ ). Во многих отраслях существует требование, чтобы информационной безопасностью занимался специалист, имеющий профильный диплом по ИБ.
Этот подход пришел с "запада" и в отечественном сегменте активно развивается. Суть в том, что у компании в штате есть целый отдел ИБ, который регулярно контролирует и защищает информационный периметр (Blue team). Команда атакующих же (Red team) часто работает на аутсорсинге и периодически осуществляет проверку реагирования команды защищающихся на кибер-угрозы. Подход хорош, но финансово затратен. Требует квалифицированных кадров, большого штата ИБ и, в целом, «зрелости» информационной безопасности в компании. Подход, который я предлагаю, относительно экономичен и нацелен на начало становления самостоятельной структуры ИБ в компании. При небольших бюджетах и "слабом" финансировании предлагаю развивать ИБ по предложенному мною "сценарию".
В каждой компании, в которой процессы ИБ в стадии становления, за безопасность информационных сервисов отвечают, как правило, сисадмины. Как ранее было сказано, специалист, занимающийся настройкой и контролем функционала сервиса, между безопасностью и функционалом скорее выберет второе. Чтобы был постоянный, а не периодический контроль за безопасностью внешнего периметра сети, привлекаем специалиста ИБ, имеющего компетенции в области тестирования на проникновение. Пентестер на регулярной основе будет тестировать внешние активы компании и искать уязвимости, о которых будет писать отчет и направлять поручения сисадминам на исправления уязвимостей, предлагая пути решения проблем безопасности. Такой подход показал себя эффективным, поскольку позволяет на регулярной основе искать и устранять самые явные уязвимости, на которые рассчитывают большая часть кибер-преступников. Отменять общепринятый периодический пентест со стороны сторонних команд при этом конечно же не стоит, ведь профессиональные команды Red Team способны найти больше сложно-реализуемых уязвимостей, но такая услуга стоит в разы дороже "штатного" пентестера и к ней прибегают в основном, когда нужно получить компании новую лицензию или аттестат.
Нам понадобится любой внешний сервер (можно, но не нужно домашний ПК). Я бы рекомендовал арендовать VPS с установленным дистрибутивом Linux: Kali, Parrot OS. Хватит 2-4 ядра на процессоре, 4-8 гб. оперативной памяти ну и места на жестком диске от 30 гб. Важно иметь статический IP адрес, чтобы его можно было добавить в белый список, дабы администраторы не заблокировали вас, как злоумышленника. Почему важно иметь отдельный сервер от своей инфраструктуры? В первую очередь для "чистых" результатов. Сетевые правила для внутренней машины могут быть иными, нежели для внешней и вы будете видеть больше, чем "внешний нарушитель", а это не правильно. Опять же, идеологически мы действуем как "внешний нарушитель", соответственно и "атаковать" должны извне.
В первую очередь, Пентестер должен получить сведения о внешнем сегменте сети компании. Сперва опытный хакер проводит разведку (пассивную/активную) с помощью 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 для удобства последующего их тестирования. Когда карта внешней сети создана, все активы в ней заполнены, переходим к следующему этапу.
План - это документ, в котором нужно на основе обнаруженных сервисов указать инструменты для проверки (имеется ввиду программы, алгоритмы), которые применяем к тем или иным сервисам. Соответственно указываем команды и краткое описание. План важно сформировать, поскольку инструментов пентеста в настоявшее время великое множество и как ими пользоваться можно забыть. Открывать каждый раз мануалы для этого долго и не продуктивно.
Во время анализа сервисов и формирования плана работы с ними, важно понимать, какие атаки на эти сервисы применимы. Разберем парочку примеров.
Мы обнаружили, что сотрудники компании использует для удаленного подключения 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), если даже аббревиатура не понятна, и это, на самом деле, не плохо. План проверки должен совершенствоваться с повышением уровня квалификации Пентестера. Пусть на начальном этапе он будет "слабеньким", главное не забывать повышать свою квалификацию, изучать новые практики и наращивать свой "арсенал" проверки ;)
Когда по каждому типу сервисов у нас сформирован список в плане, отвечающий на вопросы: что, чем и как ищем, переходим к следующему этапу.
Мы должны определить регулярность тестирования. Раз в месяц проводить комплексное тестирование внешней сетевой инфраструктуры - разумный срок. Таким образом, сканируем ресурсы компании, обновляем каждый месяц карту сети и по обнаруженным сервисам проводим проверки. "Брутфорсим", изучаем уязвимости, выписываем поручения и самое главное общаемся с ответственными за сервис. Цель такого общения - находить баланс между безопасностью и функциональностью.
Мой регламент проверок такой:
Внешнее активное сканирование сети - сформировали карту сети.
Сканирование сетевой инфраструктуры на поиск CVE уязвимостей - прогнали сеть сканером уязвимостей (можем начать с nmap + NSE vulners, но лучше взять настоящий сканер сетевых уязвимостей: MaxPatrol, RedCheck, OpenVas, Nessus)
Исследование сервисов на устойчивость к атаке типа Brute-Force - как сказал ранее, группируем по типу сервисов и прогоняем. Если сервис не блокирует попытки перебора, значит проверку не прошел.
Мисконфигурации - здесь по группам сервисов проверяем типовые мисконфигурации с помощью скриптов (того же Nmap или самописных) и через различные онлайн сервисы. Здесь же можно включить проверку на устойчивость сервиса к DOS, DDOS.
Ручные проверки «убивают» не только время, но и «запал». Прикольно "брутфорсить" сервис раз 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.
И в послесловие скажу, я призываю владельцев бизнесов, связанных с ИТ или имеющих информационные ресурсы уже сейчас начать строить безопасность своей инфраструктуры. Когда "прилетит" - будет поздно.
на главную сниппетов
