Пентест

Тестирование на угрозу пентест

Хранить логи на

Классификация firewall’ов и определение политики пентеста


Большинство организаций при определенных обстоятельствах сталкиваются с успешной компрометацией одного или более хостов в своей сети

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

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

  1. Сообщить об инциденте.
  2. Просмотреть политику безопасности организации.
  3. Изолировать скомпрометированную систему(ы) и выполнить шаги по сохранению следов атаки, чтобы могли быть собраны дополнительные доказательства.
  4. Исследовать другие аналогичные хосты (в том же самом диапазоне адресов, имеющие те же или аналогичные пароли, разделяющие отношение доверия и имеющие ту же ОС и приложения) для определения того, не скомпрометировал ли атакующий и другие системы.
  5. Просмотреть соответствующее законодательство.


Проанализировать проникновение, включая:

  1. модификации, сделанные в ПО и конфигурациях;
  2. модификации, сделанные в данных;
  3. инструментальные средства или данные, оставленные нарушителем;
  4. данные из системных логов, определение проникновения и файлы логов firewall.
  5. Выполнить восстановление системы.


Существуют две возможности:


инсталлировать чистые ОС, приложения, необходимые patches и содержимое web-сервера;
восстановить из backup’а (данное действие может быть более рискованным, так как backup мог быть сделан после компрометации и восстановление компрометированного backup может позволить атакующему в дальнейшем получить доступ к системе).
Запретить сервисы, не являющиеся необходимыми.

Применить все patches
Изменить все пароли (даже на нескомпрометированных хостах).
Переконфигурировать элементы сетевой безопасности (например, firewall, роутер, IDS) для обеспечения дополнительной защиты и оповещения.
Заново присоединить систему к сети.
Протестировать систему для гарантирования безопасности.
Выполнить мониторинг системы и сети, чтобы убедиться, что атакующий снова не сможет получить доступ к системе или сети.


Системные администраторы должны рассмотреть следующие параметры при принятии решения о том, следует ли переинсталлировать ОС на скомпрометированной системе или же достаточно восстановить все из backup’а:

  1. Уровень доступа, который получил нарушитель (например, root, user, guest, system).
  2. Тип атакующего (внутренней или внешний).
  3. Цель компрометации (например, изуродовать web-страницу, получить незаконный доступ к репозиторию ПО, платформе для выполнения других атак).
  4. Метод компрометации системы.


Действия атакующего в течение и после компрометации (например, просмотр логов, отчетов об обнаружении проникновения).
Распространение компрометации на сеть (например, количество скомпрометированных хостов).


Результаты консультаций с адвокатами.


Более низкий уровень доступа, полученный нарушителем, и большие знания web-администратора о действиях нарушителя уменьшают риск, существующий при восстановлении из backup’а и выполнении patch для устранения уязвимостей. Если о действиях нарушителя известно мало, то нужно переустановить все ПО на хосте.


Периодическое тестирование безопасности web-сервера является весьма существенным

Без периодического тестирования не может быть уверенности, что текущие меры защиты работают или что patch безопасности, примененные web-администратором, функционирует так, как объявлено.

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

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


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

  1. Идентификация активных хостов в сети.
  2. Идентификация активных сервисов (портов) на хостах и указание, какие из них являются уязвимыми.
  3. Идентификация вредоносных приложений и баннеров.
  4. Идентификация уязвимостей, связанных с обнаруженными ОС и приложениями.
  5. Тестирование согласованности с политиками безопасности.


Следует использовать сканеры уязвимостей для проверки того, что на ОС и приложениях web-сервера установлены последние обновления, относящиеся к безопасности, и последние версии ОС.

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


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

Такое тестирование особенно рекомендуется для сложных или критичных систем.


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


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


Администраторы web-сервера должны тщательно рассмотреть, существует ли необходимость удаленного администрирования и/или модификации содержимого web-сервера. проверить безопасность Большинство безопасных конфигураций запрещает любое удаленное администрирование или модификации содержимого, хотя это может и не являться необходимым абсолютно для всех организаций. Риск от необходимости удаленного администрирования или модификации содержимого зависит от размещения web-сервера в сети.

Например, если web-сервер расположен внешне относительно firewall’а или фильтрующего роутера, то никакого удаленного администрирования или модификации содержимого не должно выполняться. Удаленное администрирование или модификация содержимого могут выполняться относительно безопасно из внутренней сети, когда web-сервер расположен позади firewall’а.

Удаленное администрирование или модификация содержимого не должны допускаться с хоста, расположенного вне сети организации.
Используется механизм сильной аутентификации (например, криптография с открытым ключом, двухфакторная аутентификация или аналогичные по силе механизмы).
Существует ограничение на хосты, которые могут быть использованы для удаленного администрирования или модификации содержимого на web-сервере.
Ограничение по IP-адресу (не по имени хоста).
Ограничение для хостов, находящихся во внутренней сети.
Используются безопасные протоколы (например, SSH, TLS/SSL), а не протоколы, не обеспечивающие конфиденциальность, целостность и аутентификацию (Telnet, FTP, HTTP, NFS). безопасность серверов баз данных От протоколов требуется, чтобы они обеспечивали шифрование как паролей, так и данных.
Реализация концепции минимальных привилегий для удаленного администрирования и модификации содержимого (например, минимизировать права доступа для аккаунтов удаленного администрирования и модификации).
Изменены все аккаунты по умолчанию или пароли для утилит или приложений удаленного администрирования.
Не монтируется никаких файлов, разделяемых во внутренней сети, к web-серверу, и наоборот.

Список действий для безопасного администрирования web-сервера

  1. Использовать Combined Log Format для хранения Transfer Log или вручную сконфигурировать информацию, описанную в Combined Log Format, чтобы стандартизовать формат Transfer Log.
  2. Если Combined Log Format недоступен, то использовать Referrer Log или Agent Log.
  3. Установить разные имена лог-файлов для разных виртуальных web-сайтов, которые могут быть реализованы как часть одного физического web-сервера.
  4. Использовать Remote User Identity, как описано в RFC 1413.
  5. Хранить логи на отдельном (syslog) хосте.
  6. Архивировать логи в соответствии с организационными требованиями.
  7. Просматривать логи ежедневно или еженедельно (при существовании требования более длительного их хранения).
  8. Использовать автоматизированные средства анализа лог-файла.


Выполнение backup’ов web-сервера

  1. Создать политику выполнения backup’а web-сервера.
  2. Выполнять backup web-сервера инкрементально ежедневно или еженедельно.
  3. Выполнять полный backup web-сервера еженедельно или ежемесячно.
  4. Периодически архивировать backup’ы.
  5. Поддерживать аутентичную копию web-сайта(ов).


Восстановление после компрометации.

  1. Сделать отчет об инциденте.
  2. Свериться с политикой безопасности организации.
  3. Изолировать скомпрометированную систему(ы) или выполнить шаги по сбору дополнительных доказательств осуществления атаки.
  4. Исследовать другие аналогичные хосты для определения, не скомпрометировал ли атакующий и другие системы.
  5. Проконсультироваться с законодательными актами.
  6. Заново подсоединить систему к сети.
  7. Протестировать систему для гарантирования безопасности.
  8. Просмотреть систему и сеть для нахождения следов того, что атакующий снова пытался получить доступ к системе или сети.
  9. Периодически сканировать уязвимости на web-сервере и в соответствующей сети.
  10. Периодически обновлять сканер уязвимостей, используемый для тестирования.
  11. Устранять все недостатки, обнаруженные сканером уязвимостей.
  12. Удаленное администрирование и модификация содержимого.
  13. Использовать сильный механизм аутентификации.
  14. Ограничить хосты, которые могут использоваться для удаленного администрирования и модификации содержимого (например, попытаться минимизировать права доступа для удаленного администрирования и модификации содержимого).
  15. Изменить все аккаунты и пароли по умолчанию для утилит и приложений удаленного администрирования.
  16. Не допускать удаленное администрирование из Интернета через firewall.
  17. Не иметь никаких разделяемых файлов из внутренней сети с web-сервером.

Похожие статьи Pentest