Kali Linux: виды проверок информационных систем

→ Часть 1. Kali Linux: политика безопасности, защита компьютеров и сетевых служб
→ Часть 2. Kali Linux: фильтрация трафика с помощью netfilter
→ Часть 3. Kali Linux: мониторинг и логирование
→ Часть 4. Kali Linux: упражнения по защите и мониторингу системы
→ Часть 5. Kali Linux: оценка защищённости систем

Продолжаем публикацию перевода 11-й главы книги «Kali Linux Revealed». Сегодня хотим познакомить вас с разделом 11.2, который посвящён видам мероприятий, направленных на оценку защищённости информационных систем.

11.2. Виды мероприятий по оценке защищённости информационных систем

После того, как ваша ОС готова к работе, пришло время точно определить то, какое именно исследование вы собираетесь провести. В целом, можно выделить четыре вида подобных исследований:

• Оценка уязвимости систем;
• Оценка систем на соответствие стандартам безопасности;
• Традиционное тестирование на проникновение в систему;
• Исследование приложений.

Конкретное задание на исследование системы может включать в себя различные элементы каждого вида. Мы полагаем, что стоит рассказать о них подробнее и раскрыть их связь с Kali Linux и с рабочим окружением.

Прежде чем переходить к описанию конкретных видов мероприятий по оценке защищённости систем, расскажем о том, чем уязвимости отличаются от эксплойтов.

Уязвимость можно определить как дефект информационной системы, воспользовавшись которым можно нарушить её конфиденциальность, целостность или доступность. Существуют различные виды уязвимостей, с которыми можно столкнуться. Вот некоторые из них:

• Уязвимость к включению файлов. Этот класс уязвимостей позволяет злоумышленнику включать локальные или удалённые файлы в процесс выполняемых программой вычислений. Например, у веб-приложения может быть функция «Сообщение дня», которая читает содержимое некоего файла и включает его в веб-страницу для того, чтобы показать пользователям. Если при разработке подобной функции были допущены ошибки, она может позволить злоумышленнику модифицировать выполняемый им запрос к сайту таким образом, чтобы веб-приложение, вместо полезного файла, подключило к странице файл, подготовленный атакующим.
• Возможность SQL-инъекции. Атака уязвимого приложения методом SQL-инъекции представляет собой ситуацию, когда атакующий обходит подсистемы проверки данных, вводимых пользователями. Это позволяет ему вводить собственные SQL-команды, которые будет выполнять атакованная система. Подобное может привести к проблемам в области безопасности.
• Возможность переполнения буфера. Это уязвимость, которая позволяет атакующему обойти подсистемы контроля ввода и записать данные в область памяти, которая соседствует с памятью, выделенной для некоего буфера. В некоторых случаях области памяти рядом с буфером могут быть чрезвычайно важны для обеспечения работоспособности атакуемой программы. При правильной манипуляции данными, хранящимися в этих областях, можно получить контроль над выполнением кода приложения.
• Подверженность системы состоянию гонки. Это уязвимость, эксплуатация которой основана на использовании временных зависимостей в программах. В некоторых случаях рабочий процесс приложения зависит от выполнения неких действий в определённой последовательности. Если изменить эту последовательность событий, программу можно сделать уязвимой.

Эксплойт, с другой стороны, это программа, которая, если её применить, может воспользоваться конкретной уязвимостью, хотя и не все уязвимости можно эксплуатировать таким образом. Так как эксплойт должен изменить выполняющийся процесс, принуждая его к выполнению непредусмотренных действий, создание эксплойтов может оказаться сложной задачей. Более того, в современных вычислительных платформах имеется целый ряд технологий противодействия эксплойтам, усложняющих их разработку. Среди таких технологий — предотвращение выполнения данных (Data Execution Prevention, DEP) и рандомизация размещения адресного пространства (Address Space Layout Randomization, ASLR). Однако, если для некоей уязвимости не удаётся обнаружить общедоступный эксплойт, это ещё не значит, что подобного эксплойта не существует, а также то, что его нельзя создать. Например, многие организации продают специально разработанные эксплойты, которые не попадают в общий доступ. Поэтому все уязвимости следует рассматривать как потенциально подверженные эксплуатации.

Теперь поговорим о различных видах мероприятий по оценке защищённости систем.

11.2.1. Оценка уязвимости систем

Напомним, что уязвимостью считается дефект информационной системы, который может быть каким-то образом использован для нарушения её конфиденциальности, целостности или доступности. При проведении оценки уязвимости систем вашей целью является создание перечня уязвимостей, обнаруженных в целевом окружении. Понятие «целевое окружение» очень важно при оценке защищённости систем. Вы не должны пересекать оговоренные с клиентом границы. Это означает — проводить работы в пределах целевой сети и не отклоняться от целей исследования. Выход за пределы исследуемого окружения, границы которого согласованы с клиентом, может привести к нарушению работы служб клиента, к потере его доверия, или к судебному иску против вас и вашего работодателя.

Исследование уязвимостей систем, благодаря его простоте, часто выполняется на регулярной основе в достаточно зрелых окружениях. Делается это в рамках демонстрации уровня их защищённости или их соответствия неким стандартам безопасности.

В большинстве случаев автоматические инструменты, вроде тех, что можно найти в группах Vulnerability Analysis и Web Applications на сайте Kali Tools, или в соответствующих разделах меню Applications (Приложения) на рабочем столе Kali, используются для обнаружения работающих в целевом окружении компьютеров, для идентификации служб, прослушивающих некие порты и их анализа. Делается это для сбора как можно большего количества информации о системе. В эту информацию входят сведения об аппаратных платформах и ПО серверов, версиях операционных систем и приложений, и другие сведения.

Затем собранную информацию проверяют на известные сигнатуры уязвимостей. Эти сигнатуры состоят из комбинаций фрагментов данных, которые позволяют распознать известные проблемы в области безопасности. Здесь используется как можно больше сведений, так как чем больше их будет — тем точнее окажется идентификация уязвимости. Существует множество показателей, представляющих интерес при анализе уязвимостей систем. Среди них можно отметить следующие:

• Версия операционной системы. Нередко бывает так, что некое приложение уязвимо в одной версии ОС, но в другой данной уязвимости нет. Именно поэтому сканер попытается определить, как можно точнее, на какой версии операционной системы работает целевое приложение.
• Уровень патча ОС. Часто выходят патчи для операционных систем, при установке которых версия ОС не меняется, хотя при этом известные уязвимости либо исчезают, либо начинают вести себя не так, как раньше.
• Архитектура процессора. Существует множество приложений, доступных для разных процессорных архитектур, таких, как Intel x86 и Intel x64, для различных версий ARM, для UltraSPARC, и так далее. В некоторых случаях уязвимость существует только на конкретной архитектуре, поэтому знание архитектуры процессора может сыграть важную роль при формировании точной сигнатуры уязвимости.
• Версия программного обеспечения. Версия целевого программного обеспечения — один из основных показателей, который нужно получить для идентификации уязвимости.

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

Занимаясь сопоставлением собранных данных с сигнатурами, можно получить разные результаты:

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

Несложно понять, что для обеспечения надёжных результатов сканирования системы чрезвычайно важна точность сигнатур. Чем больше данных удаётся собрать — тем выше качество результатов автоматического сканирования, основанного на сигнатурах. Именно поэтому весьма популярно сканирование с предварительной аутентификацией в системе.

При таком подходе сканирующее ПО использует предоставленные специалисту данные для аутентификации в целевой системе. Это даёт возможности по анализу данных, недоступные в других условиях. Например, при обычном сканировании реально получить лишь информацию о системе, которую можно извлечь из анализа служб, которые доступны извне, и из анализа предоставленного ими функционала. Иногда и такое сканирование позволяет собрать немало данных. Но эти сведения не идут ни в какое сравнение с тем, что можно узнать о системе, войдя в неё и и тщательно проанализировав всё установленное ПО, применённые патчи, исполняющиеся процессы, и так далее. Сбор столь обширных данных о системе полезен для нахождения уязвимостей, которые, в противном случае, могли бы остаться необнаруженными.

Хорошо проведённое исследование уязвимостей даёт отчёт о потенциальных проблемах и показатели, которые можно использовать для анализа изменения ситуации во времени. Это — довольно простое исследование, но даже учитывая это, многие организации регулярно проводят автоматическое сканирование уязвимостей. Делается это обычно в часы минимальной нагрузки на системы, так как сканирование может потребовать немалых сетевых и серверных ресурсов и помешать обычной работе организации.

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

▍Многопоточное сканирование

Большинство сканеров уязвимостей поддерживают настройку количества потоков, выделяемых на выполнение задачи сканирования. Речь идёт о том, сколько проверок будет выполняться одновременно. Увеличение числа потоков сканирования приводит к росту нагрузки на компьютер исследователя, на сеть, на целевые системы. Заманчиво ускорить сканирование за счёт увеличения числа потоков, но важно помнить о том, что это может привести к существенному росту нагрузки на системы.

Когда проверка завершена, обнаруженные уязвимости обычно связывают со стандартными идентификаторами, такими, как номера CVE, EDB-ID, или коды классификации уязвимостей, принятые у поставщиков инструментов сканирования. Эта информация, вместе со сведениями об оценке уязвимостей по методике CVSS, используется для определения уровня риска. Все эти сведения, с учётом ложноположительных и ложноотрицательных сообщений об уязвимостей, дают общее представление об уязвимостях, которые нужно учитывать, анализируя результаты сканирования.

Так как автоматизированные средства используют для выявления уязвимостей базы данных сигнатур, малейшее отклонение от известной сигнатуры может изменить результат, и, соответственно, обоснованность сообщений об обнаруженных уязвимостях.

Ложноположительные результаты указывают на то, чего нет, а ложноотрицательные, наоборот, скрывают существующие проблемы. Поэтому качество и возможности автоматических сканеров уязвимости напрямую зависят от применяемых ими баз данных сигнатур. Как правило, поставщики подобного ПО предлагают разные версии своих программ. Одни их них — бесплатные, снабжённые урезанными базами данных, предназначены для домашних пользователей. Другие — достаточно дорогие, с полноценными базами, обычно ориентированы на корпоративный сектор.

Ещё одна проблема, которая часто возникает при сканировании на наличие уязвимостей, заключается в пригодности к использованию предложенных рейтингов риска. Эти рейтинги определяют на универсальной основе, принимая во внимание множество различных факторов, таких, как уровень привилегий, тип программного обеспечения, возможность реализации уязвимости до или после аутентификации. Подобные рейтинги нельзя использовать бездумно, так как их ценность зависит от особенностей исследуемой системы. Качественно оценить уровень риска можно только пользуясь теми рейтингами, которые основаны на анализе подробной информации о системе и обнаруженных в ней уязвимостях.

Не существует единого общепринятого соглашения о рейтингах рисков, однако, можно порекомендовать взять за основу оценки рисков в исследуемой среде стандарт NIST SP 800-30. NIST SP определяет реальный риск обнаруженной уязвимости как комбинацию возможности осуществления угрозы и уровня воздействия на организацию при осуществлении угрозы.

▍11.2.1.1. Возможность осуществления угрозы

В соответствии с NIST, возможность осуществления угрозы основана на вероятности того, что источник угрозы, потенциальный противник, способен к эксплуатации конкретной уязвимости. При этом возможности осуществления угрозы присваивается один из возможных рейтингов: низкий, средний или высокий.

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

▍11.2.1.2. Уровень воздействия на организацию при осуществлении угрозы

Уровень воздействия на организацию при осуществлении угрозы определяют, оценивая размер ущерба, который может причинить использование анализируемой уязвимости.

• Высокий уровень. Использование уязвимости может привести к существенным финансовым потерям, может серьёзно повредить миссии или репутации организации, может закончится серьёзным материальным ущербом или человеческими жертвами.
• Средний уровень. Использование уязвимости может привести к финансовым потерям, повредить миссии или репутации компании, или, в случае с человеческими ресурсами компании, привести к травмам.
• Низкий уровень. Использование уязвимости может привести к некоторым финансовым потерям или воздействию на миссию или репутацию компании.

▍11.2.1.3. Определение уровня риска

Как только выяснены возможность осуществления угрозы и уровень её воздействия на организацию, можно оценить уровень риска (низкий, средний, или высокий), который выражается в виде функции от двух найденных показателей. Показатель уровня риска позволяет сформировать план действий для тех, кто ответственен за защиту и поддержку анализируемой системы.

• Высокий уровень. Имеется серьёзная потребность в принятии дополнительных мер для защиты от уязвимости. В некоторых случаях можно позволить, чтобы система продолжала работать, но нужно подготовить план по её защите, который должен быть реализован как можно скорее.
• Средний уровень. Есть потребность в принятии дополнительных мер для защиты от уязвимости. План по реализации необходимых мер по защите должен быть выполнен в пределах разумного периода времени.
• Низкий уровень. Владелец системы определит самостоятельно, реализовывать ли дополнительные меры по защите от уязвимости, либо принять обнаруженный риск и оставить систему неизменной.

▍11.2.1.4. Итоговые мероприятия

Показатель риска обнаруженной уязвимости формирует множество факторов, поэтому рейтинги, полученные из систем автоматического сканирования следует рассматривать лишь как отправную точку в определении реального риска.

По результатам оценки уязвимостей составляют отчёты. Такие отчёты, созданные со знанием дела и профессионально проанализированные, закладывают базу для других исследований, таких, как оценка систем на соответствие стандартам безопасности. Важно извлечь из результатов оценки уязвимостей всё, что можно.

Kali — это отличная платформа для проведения оценки уязвимостей, ОС для этого не нуждается в особой настройке. В разделах меню Applications (Приложения) можно найти множество инструментов для анализа уязвимостей. В частности, речь идёт о разделах Information Gathering (Сбор информации), Vulnerability Analysis (Анализ уязвимостей), и Web Application Analysis (Анализе веб-приложения). Узнать подробности об использовании Kali Linux для анализа уязвимостей можно на сайте Kali Linux Tools, на сайте официальной документации Kali Linux, и ознакомившись с бесплатным курсом Metasploit Unleashed.

11.2.2. Оценка систем на соответствие стандартам безопасности

Следующий по сложности вид исследований — это оценка систем на соответствие стандартам безопасности. Подобные испытания систем распространены сильнее всего, так как они основаны на проверке требований, предписываемых государственными и индустриальными стандартами, распространяющимися на организации.

Существует множество специализированных стандартов безопасности, однако, чаще всего встречается Payment Card Industry Data Security Standard (PCI DSS). Этот стандарт разработан компаниями, выпускающими платёжные карты. Ему должны соответствовать организации, обрабатывающие карточные платежи. Если говорить о других распространённых стандартах, можно отметить такие, как Defense Information Systems Agency Security Technical Implementation Guides (DISA STIG), Federal Risk and Authorization Management Program (FedRAMP), Federal Information Security Management Act (FISMA), и другие.

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

Оценка системы на соответствие стандартам обычно начинается с анализа уязвимостей. В случае с процедурой проведения аудита на соответствие стандарту PCI, оценка уязвимостей, если она проведена соответствующим образом, может удовлетворить нескольким основным требованиям стандарта. Среди них — требование 2: «Не использовать пароли и другие системные параметры, заданные производителем по умолчанию». Анализ системы на соответствие этому требованию можно провести с помощью инструментов из категории меню Password Attack (Взлом паролей). Далее, это требование 11: «Регулярно выполнять тестирование систем и процессов обеспечения безопасности». Соответствующую проверку можно провести с помощью инструментов из категории Database Assessment (Исследование баз данных). Некоторые требования нельзя проверить с помощью обычных инструментов сканирования на уязвимости. Среди них — требование 9: «Ограничить физический доступ к данным держателей карт», и 12: « Разработать и поддерживать политику информационной безопасности для всего персонала организации». Для проверки таких требований нужны дополнительные усилия.

На первый взгляд может показаться не вполне понятным, как использовать Kali Linux для выполнения некоторых проверок. Однако, Kali отлично подходит для решения подобных задач, причём, не только из-за богатого набора стандартных инструментов, но и потому, что она основана на Debian, что открывает возможность установки множества дополнительных приложений. Искать программы, реализующие необходимый функционал, можно в менеджере пакетов, используя ключевые слова, взятые из используемого стандарта информационной безопасности. Подобный поиск, почти наверняка, завершится выдачей нескольких заслуживающих внимания результатов. В настоящее время многие организации используют Kali Linux как платформу именно для оценки систем на соответствие стандартам безопасности.

11.2.3. Традиционное тестирование на проникновение в систему

В последнее время стало сложно подобрать подходящее определение для «традиционного теста на проникновение». Дело в том, что подобные тесты используются в различных сферах деятельности, как результат, все описывают их по-своему. Путаницы добавляет и то, что «тестированием на проникновение» всё чаще стали называть описанную выше оценку систем на соответствие стандартам безопасности, или даже обычную оценку уязвимостей. В подобных случаях исследование не выходит за рамки неких минимальных требований.

В этом разделе мы не будем касаться споров об особенностях различных видов испытаний систем. Здесь мы расскажем об исследованиях, которые не ограничены некими «минимальными требованиями». Это — исследования, которые задуманы так, чтобы после их проведения можно было бы по-настоящему улучшить общую безопасность организации.

В противоположность видам исследований, которые мы обсудили ранее, традиционные тесты на проникновение не часто начинаются с определения области исследования. Вместо этого для них устанавливают определённые цели. Например: «смоделировать последствия компрометации внутреннего пользователя», или: «выяснить, что случилось бы, если бы организация попала под целенаправленную атаку, выполняемую внешним злоумышленником». Ключевой отличительной чертой подобных исследований является то, что в ходе их выполнения не только находят и оценивают уязвимости, но ещё и используют найденные проблемы для раскрытия наихудших вариантов развития событий.

В ходе тестирования на проникновение не полагаются исключительно на инструменты сканирования систем на уязвимости. Работа продолжается путём исследования находок, путём использования эксплойтов или испытаний для исключения ложноположительных результатов, делается всё возможное для того, чтобы обнаружить скрытые уязвимости, или то, что мы называем ложноотрицательными результатами.

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

Здесь требуется критический анализ целевого окружения, ручной поиск уязвимостей, креативность, способность к нестандартному мышлению. Всё это — подходы к обнаружению дополнительных уязвимостей, которые требуют других инструментов, способных найти уязвимости там, где заканчиваются возможности самых мощных автоматических сканеров. Нередко, после завершения этого шага, весь процесс начинают снова и снова для того, чтобы обеспечить полное и качественное выполнение работы.

Несмотря на сложность и многоплановость традиционного тестирования на проникновение, ход такого исследования можно упорядочить, разбив на несколько шагов. Стоит отметить, что Kali упрощает подбор ПО для каждого из таких шагов. Итак, вот пошаговый план тестирования на проникновение с комментариями об используемых инструментах:

• Сбор информации. На данной фазе усилия пентестера направлены на то, чтобы узнать как можно больше о целевом окружении. Обычно эта деятельность неинвазивна и выглядит как обычная активность пользователей. Эти действия составляют основу для остальных этапов исследования и таким образом они должны привести к сбору как можно более полных данных о системе. Раздел Information Gathering (Сбор информации) меню Applications (Приложения) Kali Linux содержит в себе десятки инструментов, направленных на то, чтобы раскрыть как можно больше информации об исследуемой системе.
• Обнаружение уязвимостей. Этот шаг часто называют «активным сбором информации». Специалист, пытаясь идентифицировать потенциальные уязвимости в целевом окружении, ещё не атакует систему, но уже ведёт себя не так, как обычный пользователь. Именно здесь часто имеет место вышеописанное сканирование систем на уязвимости. На данном шаге исследования будут полезны программы из разделов Vulnerability Analysis (Анализ уязвимостей), Web Application Analysis (Анализ веб-приложений), Database Assessment (Исследование баз данных), и Reverse Engineering (Реверс-инжиниринг).
• Эксплуатация уязвимостей. Имея список обнаруженных потенциальных уязвимостей, на данном шаге исследования специалист пытается воспользоваться ими для того, чтобы найти точку опоры в целевой среде. В этом деле полезны инструменты, которые можно найти в категориях Web Application Analysis (Анализ веб-приложений), Database Assessment (Исследование баз данных), Password Attacks (Взлом паролей), и Exploitation Tools (Средства эксплуатации уязвимостей).
• Проникновение в системы и незаметное извлечение данных. После того, как исследователю удалось закрепиться в системе, нужно двигаться дальше. Как правило, на данном этапе ищут способ повышения привилегий до уровня, соответствующего тому, который необходим для достижения целевых систем, ранее недоступных, и скрытного извлечения их них секретной информации. На этом шаге можно обратиться к таким разделам меню приложений, как Password Attacks (Взлом паролей), Exploitation Tools (Средства эксплуатации уязвимостей), Sniffing & Spoofing (Сниффинг и спуфинг), и Post Exploitation (Действия после эксплуатации уязвимости).
• Подготовка отчётов. После завершения активной фазы исследования, нужно задокументировать произведённые действия и подготовить отчёт. Обычно этот шаг не отличается такой же технической сложностью, как предыдущие. Однако, благодаря качественным отчётам клиент может получить полную отдачу от проделанной работы, поэтому не стоит недооценивать важность этого этапа исследования. Соответствующие инструменты можно найти в разделе Reporting Tools (Средства подготовки отчётов) меню Applications (Приложения).

В большинстве случаев  тесты на проникновение будут устроены совершенно по-разному, так как каждая организация будет подвергаться разным угрозам и иметь различные ресурсы, которые требуется защищать. Kali Linux даёт универсальную базу для решения подобных задач, именно здесь можно воспользоваться множеством возможностей по настройке Kali. Многие организации, которые выполняют такие исследования, поддерживают настроенные под свои нужды версии Kali LInux для внутреннего использования. Это позволяет им ускорить развёртывание систем перед новым исследованием.

Среди часто встречающихся дополнительных настроек Kali Linux можно отметить следующие:

• Предустановка лицензированных коммерческих пакетов. Например, имеется пакет, вроде платного сканера уязвимостей, который планируется использовать в ходе многих сеансов тестирования на проникновение. Для того, чтобы избежать необходимости устанавливать этот пакет на каждой развернутой копии Kali, можно интегрировать его в систему. Как результат, этот пакет окажется установленным при каждом развёртывании Kali.
• Предварительно настроенная виртуальная частная сеть с обратным соединением. Это очень удобная функция для устройств, которые преднамеренно оставляют подключёнными внутри исследуемой сети. Такие устройства позволяют проводить «удалённые внутренние» исследования. Устройство с функцией обратного соединения подключается к компьютеру пентестера, создавая туннель, который можно использовать для подключения к внутренним системам. Дистрибутив Kali Linux ISO of Doom — это пример как раз такой специальной настройки системы.
• Предустановленные инструменты и программы собственной разработки. Многие организации имеют наборы инструментов собственной разработки, необходимые в ходе сеансов тестирования на проникновение, поэтому их предварительная установка при формировании специального образа системы позволяет экономить время.
• Предварительная настройка конфигурации ОС, в том числе — настройка отображение имён хостов на IP-адреса, обоев рабочего стола, настройки прокси-серверов, и так далее. Многие пользователи Kali предпочитают особые настройки системы. Если вы собираетесь регулярно переустанавливать систему, сохранение подобных настроек может иметь смысл.

11.2.4. Исследование приложений

Большинство мероприятий по оценке защищённости систем отличаются достаточно большими масштабами. Особенностью же исследований приложений является тот факт, что изучению подвергается конкретная программа. Подобные исследования становятся всё более распространёнными из-за сложности жизненно важных приложений, используемых компаниями. Многие из таких приложений созданы собственными силами этих компаний. Если нужно, исследование приложений может сопутствовать другим видам исследований. Среди видов приложений, которые могут быть исследованы на предмет безопасности, можно отметить следующие:

• Веб-приложения. Эти приложения часто являются целями злоумышленников, так как они, обычно обладая значительной поверхностью атаки, доступны из интернета. Стандартные тесты нередко позволяют обнаружить базовые проблемы веб-приложений. Однако, более детальное исследование, хотя и может занимать немало времени, позволяет найти скрытые дефекты приложений. Для проведения подобных испытаний можно воспользоваться метапакетом kali-linux-web, который содержит множество полезных инструментов.
• Настольные приложения, распространяемые в виде исполняемых файлов. Серверные приложения — это не единственная цель злоумышленников. Настольные приложения также подвержены атакам. В прошедшие годы многие настольные программы, такие, как средства для чтения PDF-файлов, или видео-приложения, использующие интернет-ресурсы, подвергались множествам атак, что привело к их совершенствованию. Однако, всё ещё существует множество настольных приложений, в которых, при правильном подходе, можно найти массу уязвимостей.
• Мобильные приложения. С ростом популярности мобильных устройств, мобильные приложения становятся постоянными предметами исследований безопасности. Эти приложения очень быстро развиваются и меняются, поэтому в данной сфере методология исследований пока не достигла достаточной зрелости, что ведёт к регулярному, практически еженедельному, появлению новых методик. Инструменты, относящиеся к изучению мобильных приложений, можно найти в разделе меню приложений Kali Linux Reverse Engineering (Реверс-инжиниринг).

Исследование приложений можно проводить самыми разными способами. Например, для идентификации потенциальных проблем можно воспользоваться автоматическим средством, предназначенным для тестирования конкретного приложения. Подобные автоматические средства, основываясь на особенностях работы приложений, пытаются найти в них неизвестные слабости, вместо того, чтобы полагаться на набор заранее заданных сигнатур. Инструменты для анализа программ должны учитывать особенности их поведения. Вот, например, популярный сканер уязвимости веб-приложений Burp Suite. В ходе исследования приложения он находит поля для ввода данных, после чего выполняет различные атаки методом SQL-инъекций, наблюдая в это время за приложением для того, чтобы выявить атаки, которые оказались успешными.

Существуют и более сложные сценарии исследования приложений. Такие исследования могут быть выполнены в интерактивном режиме. При их проведении используют модели чёрного и белого ящиков.

• Исследование методом чёрного ящика. Инструмент (или исследователь) взаимодействует с приложением, не обладая специальными знаниями о нём, или особым доступом к нему, превышающим возможности обычного пользователя. Например, в случае с веб-приложением, исследователь может иметь только доступ к функциям и возможностям, открытым пользователю, который не авторизован в системе. Любая используемая учётная запись будет такой же, которую обычный пользователь может зарегистрировать самостоятельно. Это не даст атакующему возможности анализировать функционал, который доступен только привилегированным пользователям, учётные записи которых необходимо создавать администратору.
• Исследование методом белого ящика. Инструмент (или исследователь) часто имеет полный доступ к исходному коду приложения, административный доступ к платформе, на которой оно выполняется, и так далее. Это гарантирует выполнение полного и тщательного анализа всех возможностей приложения, независимо от того, где именно находится изучаемая функциональность. Минус такого исследования заключается в том, что оно не является имитацией реальных действий злоумышленника.

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

В других случаях может быть применён гибридный подход, когда исследователь не обладает полным доступом к исходному коду приложения для платформы, на которой оно выполняется, но выданная ему учётная запись подготовлена администратором и даёт доступ к как можно большим возможностям приложения.

Kali — это идеальная платформа для всех подходов к исследованию приложений. После установки стандартного дистрибутива здесь можно найти множество сканеров, рассчитанных на конкретные приложения. Тут есть и инструменты для более продвинутых исследований. Среди них — редакторы исходного кода и скриптовые окружения. В деле исследования приложений вам могут оказаться полезными материалы из разделов Web Application и Reverse Engineering сайта Kali Tools.

Итоги

В этом материале мы рассказали о различных видах мероприятий по оценке защищённости информационных систем. Здесь же можно найти ссылки на инструменты, полезные при проведении подобных исследований. В следующий раз поговорим о методике формализации исследований и о типах атак.

Уважаемые читатели! Если вы проводили исследования по оценке защищённости систем или заказывали подобные исследования в специализированных организациях — просим поделиться опытом.

Автор: ru_vds

Источник