← Cloudflare Fundamentals / fundamentals / reference

Политика сканирования и тестирования на проникновение

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

Любое сканирование или тестирование должно ограничиваться следующим:

• IP-адреса, принадлежащие клиенту
• Назначенные публичные IP-адреса Cloudflare
• Зарегистрированные DNS-записи клиента

Такие цели, как *.cloudflare.com или на другие ресурсы, принадлежащие Cloudflare, разрешены только в рамках публичной программы Cloudflare Bug Bounty. См. Дополнительные ресурсы раздел для получения дополнительной информации.

• Троттлинг: Сканирование следует ограничивать разумной скоростью, чтобы избежать сбоев и обеспечить стабильную работу системы.
• Область действия и цель: Сканирование должно выявлять наличие уязвимостей, не пытаясь активно эксплуатировать обнаруженные слабые места.
• Исключения: Рекомендуется исключить /cdn-cgi/ конечные точки из сканирований, чтобы избежать ложных срабатываний или нерелевантных результатов.
• Проверки соответствия требованиям: Клиенты могут проводить Сканирования на соответствие PCI или убедитесь, что известные уязвимости были устранены.

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

1. Разверните Cloudflare Managed Ruleset и включить все правила в наборе правил, задав Статус набора правил к Включено.

2. Разверните Cloudflare OWASP Core Ruleset и задайте следующие конфигурация набора правил:

   • Paranoia Level: PL4
   • Пороговое значение оценки: Высокий: от 25 и выше

3. Создание пользовательского правила на основе WAF attack score чтобы блокировать запросы, считающиеся атакой (оценка атаки WAF от 1 до 20). См. WAF attack score документацию с примером.

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

5. На тарифах Pro и Business без Bot Management включение Super Bot Fight Mode.
   Клиентам с доступом к Bot Management следует убедиться, что Bot Management включён (по умолчанию включено для зон, имеющих на это право).

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

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

После завершения теста рекомендуется проверить уровень защищённости и внести необходимые изменения на основе полученных результатов.

• Cloudflare anycast-сеть будет сообщать о портах, отличных от 80 и 443 как открытые из-за общей инфраструктуры и особенностей работы прокси Cloudflare. Такой результат сканирования ожидаем и не указывает на наличие уязвимости.

• Такие инструменты, как Netcat, могут выводить нестандартные порты HTTP как открытые. Однако эти порты открыты исключительно в целях маршрутизации Cloudflare и не обязательно означают, что через них можно установить соединение с origin-сервером клиента.

• Известные ложные срабатывания: Любые результаты, связанные с Уязвимость ROBOT являются ложными срабатываниями, если ресурсы клиента находятся за Cloudflare.

Правила обязательного уведомления и перечень необходимых сведений см. в Имитация тестовых DDoS-атак. Клиентам также рекомендуется ознакомиться с Рекомендации по защите от DDoS-атак.

• Клиенты могут скачать последний Penetration Test Report Cloudflare через панель управления.
• Сведения о публичной программе Bug Bounty Cloudflare см. на HackerOne ↗.