Wflogs wordpress что это

Help Documentation

Free Support

Upgrade Now to Access Premium Support

Wordfence Web Application Firewall (WAF)

The Wordfence Web Application Firewall is a PHP based, application level firewall that filters out malicious requests to your site.

What it Protects Against

The Wordfence Web Application Firewall (WAF) protects against a number of common web-based attacks as well as a large amount of attacks specifically targeted at WordPress and WordPress themes and plugins. It is set up to run at the beginning of WordPress’ initialization to filter any attacks before plugins or themes can run any potentially vulnerable code. Some of the more general types of attacks we protect against are:

SQL Injection Unsanitized SQL code that can compromise a database system.
Cross Site Scripting (XSS) Unsanitized HTML or JavaScript code used to hijack a user or administrator’s browser session and perform actions as the user.
Malicious File Upload Unsanitized files containing malicious code that can be uploaded to and executed by the web server.
Directory Traversal Unsanitized path names that can be used to trick the web server into serving files containing credentials or other potentially sensitive information.
Local File Inclusion Unsanitized path/file names that can be used to execute potentially malicious code available to the web server’s file system.
External Entity Expansion (XXE) A “feature” of XML that can be used to trick the web server into serving files containing credentials or other potentially sensitive information.

Firewall rules

The Wordfence firewall also has a number of rules that match known attacks commonly seen and exploited in the wild. The patterns for these attacks are specific and require minimal processing in determining if the request matches. The firewall also uses a number of generic rules that use pattern matching to determine if a request appears to be malicious. These are designed to prevent hackers from exploiting “0-day” vulnerabilities for known types of attacks.

Wordfence will automatically update the firewall rules from our servers in our network operations center without you having to update Wordfence. As new threats emerge, the firewall uses rules to protect you that are updated in real-time for premium members. Premium users receive an additional layer of protection. When we add new rules, our servers will then “ping” your site to prompt Wordfence to download the latest rules, so that you are automatically protected from attackers as new threats emerge. Users of the free version of Wordfence receive the community version of the rules 30 days later.

Firewall Status

Status Circles

The firewall status circles indicate to what degree you are currently protected. If the circles are gray, it means that the firewall is in “Learning Mode” or “Disabled”. Hovering your mouse pointer over a status circle will generate a tooltip informing you what needs to be done to reach a 100% rating. To reach a 100% rating on all firewall status circles then the following conditions must be met:

  • Enable Rate Limiting and Advanced Blocking. This option is enabled by default. You can find it in the “Rate Limiting” section on the “Firewall Options” page.
  • Enable all Firewall rules. All firewall rules are enabled by default. If you have previously disabled some firewall rules, visit the “Rules” section on the “Firewall Options” page to re-enable them.
  • Optimize the Wordfence Firewall. This improves the security and performance of your firewall. Learn how
  • Enable Brute Force Protection. This feature protects your WordPress login form from unauthorized login attempts. It is enabled by default.
  • Enable Premium Firewall Rules. Upgrade to a premium license key to get instant protection against threats the moment they are discovered.
  • Enable Real-Time IP Blocklist. With the Wordfence premium “Real-Time IP Blocklist”, IP addresses that are currently attacking other WordPress sites will be automatically blocked from your sending any requests to your site.
  • Repair the Wordfence Firewall configuration. If this message appears, you may need to fix permissions on the firewall’s files. You can also try using the link to rebuild the firewall files that appears at the top of WordPress admin pages. Learn more

Users of the free version can reach a maximum rating of 64% (as displayed on the “Dashboard” page) and 55% (as displayed on the “Firewall” page).

Firewall Mode

The Firewall can be “Enabled”, “Disabled” or in “Learning mode”. If your status circles are grayed out, it means the firewall is disabled or in “Learning mode”. Learn more.

Firewall Optimization

As soon as you have installed Wordfence on your site, the firewall is activated. At this point, the firewall exists inside of your WordPress installation and will protect you against exploits. To make the firewall even more efficient and effective, we encourage you to optimize the firewall. You will be prompted to do this via the Wordfence plugin user interface. In most cases, optimizing the firewall involves clicking through a short configuration procedure.

The “Protection Level” shows whether the default “Basic WordPress Protection” is enabled, which can protect against many attacks, or if “Extended Protection” is enabled. To enable Extended Protection you have to go through the firewall optimization procedure described above. Extended Protection allows the firewall to run before WordPress even starts, protecting against additional attacks. Both protection levels are available in the free and premium versions. [More about Firewall Optimization]

Читайте также:  Как запустить картридж без чипа hp

Allowlisted URLs and False Positives

The firewall uses pattern-matching to identify malicious requests. Sometimes, non-malicious content in the request may accidentally match one of the rules and trigger the firewall to block the request. This is considered a false positive. Wordfence provides a way to exclude this particular URL and parameter from the firewall rules, so they can be allowlisted. You can create allowlisted rules automatically while the firewall is in “Learning Mode”. You can also create allowlisted rules manually via the firewall options, via a button on the “Live Traffic” page, or via the firewall block page if you are viewing the block page as an administrator.

Visits blocked by the firewall will display “403 Forbidden” and “A potentially unsafe operation has been detected in your request to this site”. If you get this message when you are logged in as an administrator, you can directly choose to allowlist any action where you are blocked. If you get the message when you are not logged in you should login to your site. You can then either:

  • Locate the request that was blocked in “Live Traffic” and add it to the allowlist from there.
  • Enable Learning Mode temporarily, repeat the action that was previously blocked, and then re-enable the firewall.

Background requests sent from your browser may show a message that says “Background Request Blocked” if they are blocked by the firewall. These messages are only displayed for the site’s administrator. They can be added to the allowlist by clicking the button in the message if you know that they are safe.

Disabling the Firewall

Open the “Firewall” > “Firewall Options” page, set the “Web Application Firewall Status” to “Disabled” and click the “Save Changes” button.

If you are having technical problems and you cannot set the “Web Application Firewall Status” to “Disabled”, you can instead set a constant. If you have the “Protection Level” set to “Basic WordPress Protection”, you can add this code to your WordPress “wp-config.php” file, just below the line about “WP_DEBUG”. If you have the “Protection Level” set to “Extended Protection”, the code should be added to the “wordfence-waf.php” file, before the line that begins with “if”:

Files Used by the Firewall

The files in “wp-content/wflogs” directory contain firewall configuration data and information on blocked attacks. The firewall needs these files because it can run before WordPress has loaded. Files included in the “wflogs” directory are:

.htaccess
attack-data.php
config.php
config-livewaf.php
config-synced.php
config-transient.php
GeoLite2-Country.mmdb
ips.php
rules.php
template.php

Some hosts may have additional temporary files in this directory with similar names, and some may also have temporary files with long names containing the letters “nfs”.

Some of these files begin with a line that says:

This prevents anyone from viewing the file contents in a web browser even if the web server does not support “.htaccess” files, while allowing the rest of the contents to be read as data. Much of the data is encoded or in a binary format for various reasons, including performance.

Frequently Asked Questions

Make sure that it’s Wordfence that is locking you out of your site. If you have been locked out by Wordfence, the block page will mention “Wordfence” and state a reason for the block. If you contact Wordfence support, include that reason in your message for faster assistance.

For detailed instructions on determining the cause of a block and how to fix unintended blocking, see the Blocking Troubleshooting page here.

When the Wordfence Firewall is Optimized to have “Extended protection”, the Firewall loads via a file called wordfence-waf.php which is located in the root of your WordPress installation. If this file is deleted, or if the code that loads the file has an incorrect file path, a 500 Internal Server Error can be thrown. The error will typically look like the example below, though the file path “/var/www/html/” will usually be different on your site.

PHP Fatal error: Unknown: Failed opening required ‘/var/www/html/wordfence-waf.php’ (include_path=’.:/usr/share/php’) in Unknown on line 0

This error can happen if

1. The wordfence-waf.php file has been deleted. This could have been done by accident, either manually or by some automated process on the server.
2. You or your web host have recently moved the site. This would have caused the file path structure on the site to change, which means that Wordfence can not find the wordfence-waf.php file.

The Wordfence Firewall can block background requests that use AJAX, showing a message that says “Background Request Blocked”. This can prevent certain types of attacks, but some plugins and themes may cause this message as well, even when their requests are safe. It is most likely to occur when adding custom HTML or javascript code in fields that are separate from the WordPress core.

As the admin of the site, you can choose to allowlist these blocked requests by clicking the button to add the blocked request to the allowlist, if you were simply working on the site when they occur. The message is only shown for logged-in admins of the site, so regular visitors, subscribers, authors, editors, or other types of users on your site will not see them.

Читайте также:  Как называются валы на принтере

If you see this message when clicking a link that was sent to you by another person, or a link from another site that leads to your site, it may not be safe to add it to the allowlist. You can contact us about blocked requests if you are not sure whether they are dangerous or not. Be sure to include a description of what you were working on at the time.

Источник

Папка wp-content

WordPress состоит из 3 папок wp-includes , wp-admin , wp-content и из нескольких файлов рядом с этими папками.

Все файлы и папки, кроме wp-content — это и есть WordPress, движок. Т.е. каталоги: wp-includes и wp-admin — это ядро WordPress, а wp-content — это все остальное — все пользовательские данные.

В директории wp-content хранятся практически все пользовательские файлы, кроме файла конфигурации wp-config.php (это неотъемлемая часть ядра). Здесь находятся плагины, темы, файлы плагинов, тем и содержимого сайта. Тут же принято хранить все файлы связанные с расширением возможностей WordPress.

Исходно в WordPress, wp-content содержит один файл index.php и 3 папки: plugins , themes , languages .

Файл wp-content/index.php

Всегда должен существовать и должен иметь такое содержимое:

Этот файл запрещает видеть список файлов в папке. Если index.php не существует, а ваш веб-сервер позволяет смотреть файлы в директориях, то пройдя по ссылке http://example.com/wp-content , можно увидеть все файлы и папки в этой директории. Это могут использовать хакеры, чтобы получить доступ к файлам ключей, что позволит взломать сайт. Например, если у вас установлен уязвимый плагин, то сайт можно будет легко проверить на наличие этого уязвимого плагина, а дальше атакующий без особого труда сможет сломать сайт.

При обновлении WordPress вручную, никогда не трогайте папку wp-content и ничего в ней. Она к обновлению WordPress никакого отношения не имеет.

Список того, что может находиться в каталоге wp-content :

/mu-plugins — обязательные плагины

В WordPress есть «Обязательные плагины», они находится в директории wp-content/mu-plugins . О них я писал отдельно, обязательно ознакомьтесь!

Коротко об обязательных плагинах: Обязательные к использованию плагины (Must-use plugins), известные также под названием mu-plugins — это плагины, которые устанавливаются в специальную папку mu-plugins в каталоге контента wp-content и активируются автоматически (всегда активны) для сайта и сайтов сети. Эти плагины не видно среди обычных плагинов. В админ-панели они отображаются в верхней информационной строке и их невозможно отключить, кроме как удалить файл плагина из каталога wp-content/mu-plugins .

/plugins — плагины

Плагины находятся в директории wp-content/plugins . Плагин может представлять собой один файл или несколько файлов внутри папки. Любые файлы в директории /plugins сканируются WordPress, чтобы определить, является ли файл файлом плагина. Если файл определяется как плагин, он появляется в админ-панели в разделе «Плагины» и готов к активации.

Для деактивации плагина можно удалить плагин из папки /plugins . Также можно переименовать название папки, в этом случае, WordPress просто не сможет найти файл плагина и деактивирует при попытке подключения. Но имейте ввиду, что плагины лучше удалять из админ-панели, через кнопку Удалить, потому что при удалении срабатывают некоторые функции, которые подчищают данные плагина в базе данных или в файлах.

/themes — темы

Темы хранятся в директории wp-content/themes . Каждая тема должна находиться в собственной папке и содержать правильно оформленный файл style.css , чтобы WordPress распознал ее как тему, пригодную для использования. В директории темы должны находиться как минимум 2 файла: index.php и style.css .

WordPress может хранить в этой директории сколько угодно тем. Вы можете легко посмотреть любую имеющуюся тему или активировать её во вкладке Внешний вид ► Темы в админ-панели.

/uploads — медиафайлы и загрузки

WordPress хранит загруженные файлы в папке wp-content/uploads . Эта директория не существует в дистрибутиве WordPress по умолчанию. Она создается при первой загрузке файла в WordPress. Отдельное создание необходимо, потому что эта папка может быть перемещена в другое место (см. ниже)

По умолчанию WordPress хранит загрузки в папках по годам и месяцам:

Перед тем как можно будет загружать какие-либо изображения или файлы в WordPress, на сервере необходимо разрешить создание папок в директории /wp-content . При загрузке первого изображения WordPress автоматически создает директорию /uploads и необходимые поддиректории в ней. После того как первый файл загружен, верните права для /wp-content обратно, обычно 755. Некоторые серверы сразу позволяют скрипту создавать папки и файлы.

Директория uploads должна иметь все права, чтобы в ней можно было свободно создавать и удалять файлы, обычно это права 777 .

WordPress НЕ умеет распознавать и импортировать в админку изображения загруженные в uploads напрямую (не через админку). И в библиотеке файлов WordPress такие файлы не отображаются — WordPress о них ничего не знает.

uploads в Multisite

В Multisite установке для основного сайта фалы загружаются как обычно. А для всех дополнительных сайтов, создается папка /wp-content/uploads/sites/2 , где 2 — это ID сайта сети.

Так для каждого сайта создается папка с его ID в папке /wp-content/uploads/sites . Далее файлы также располагаются в папках по году и месяцу.

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

До версии WP 3.5 файлы дополнительных сайтов располагались не в /wp-content/uploads/sites , а в /wp-content/blogs.dir .

Так например, директория для сайта с ID 3 выглядит так:

  • WP 3.5 и выше: /wp-content/uploads/sites/3
  • WP 3.4 и ниже: /wp-content/blogs.dir/3
Перемещение папки uploads

Чтобы переместить папку uploads нужно определить константу UPLOADS в wp-config.php так:

Или можно изменить опции: upload_path и upload_url_path в таблице опций (см. update_option()).

Перемещать папку uploads не рекомендуется, об этом я писал в статье: Баг с перемещением папки uploads.

/upgrade — автообновления

Директория wp-content/upgrade создается WordPress автоматически при обновлении WordPress. Эта папка используется для хранения новой версии WordPress, скачанной с WordPress.org. Перед обновлением, WordPress скачивает архив и извлекает его содержимое в эту папку. Чтобы процесс автоматического обновления протекал успешно, рекомендуется не трогать эту папку. Если данная директория удалена, WordPress создаст её при следующем обновлении.

Читайте также:  Linux sending post request

/languages — переводы

Каталог wp-content/languages присутствует только в том случае, если вы устанавливаете не английскую версию WordPress. В нем содержаться все файлы локализации (перевода) WordPress. Такие файлы имеют расширения:

  • .mo — сжатая версия аналогичного .po файла, которая используется при переводе;
  • .po — исходный файл перевода. Этот файл можно использовать для редактирования перевода. После редактирования его нужно скомпилировать в сжатую версию с расширением .mo .

Также в languages могут находиться специальные поддиректории:

/pliugns — содержит переводы плагинов. Файл перевода должен иметь формат: название плагина-локаль.mo , например: akismet-ru_RU.mo . Перед загрузкой своего файла перевода, плагин проверяет наличие файла перевода в этой папке и если он там есть, то используется этот файл перевода, а не родной перевод плагина.

  • /themes — содержит переводы тем. Файл перевода должен иметь формат: название темы-локаль.mo , например: twentyfifteen-ru_RU.mo . Также как и с плагинами — эти файлы имеют больший приоритет перед родными файлами перевода темы.
  • Произвольные директории

    В /wp-content можно создавать любые директории. Некоторые плагины, создают такие папки для хранения файлов. Обычно отдельная папка создается, когда нужно хранить много файлов или когда хранимые файлы как-то отличаются от остальных.

    Например плагин WP Super Cache создает директорию /wp-content/cache для хранения кэшированных страниц сайта. Кэшированная страница — это сгенерированная страница сайта, сохраненная как статический файл HTML. При обращении к такой странице она не генерируется повторно, а отдается статический файл. Это и есть страничный кэш, который уменьшает нагрузку сервера в десятки раз, поскольку страницы не генерируются при каждом просмотре, а создаются только когда кэш перезаписывается.

    Плагин WP Super Cache также добавляет два файла в директорию wp-content: advanced-cache.php (специальный) и wp-cache-config.php. Они нужны для работы WP Super Cache.

    Другой пример, популярный плагин для галерей — NextGen Gallery — создает директорию /wp-content/gallery для хранения изображений, загруженных в галереи. Каждая созданная галерея представляет собой поддиректорию /gallery .

    Еще пример, мой плагин Kama Thumbnail, который также создает папку /wp-content/cache/thumb и записывает в нее созданные файлы миниатюр.

    Специальные файлы

    advanced-cache.php

    Вызывается на самом раннем этапе загрузки WordPress, в файле wp-settings.php , если константа WP_CACHE включена. Вот так выглядит вызов:

    Этот файл используется плагинами страничного кэширования. В нем обычно проверяется наличие подходящего файла кэша и если он есть, то он выводиться на экран и работа скрипта обрывается. Это позволяет не загружать 90% файлов WordPress и отдавать статические HTML файлы.

    object-cache.php

    В отличии от advanced-cache.php , object-cache.php срабатывает всегда, если он существует. Он нужен, чтобы переопределить работу базового кэширования объектов WordPress.

    Вызывается из функции wp_start_object_cache(), которая в свою очередь вызывается из файла wp-settings.php чуть позднее advanced-cache.php .

    На основе этого файла работают такие кэши объектов как: Memcache, Memcached, APC, XCache.

    Вызов выглядит так:

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

    Читайте подробнее про Объектный кэш.

    maintenance.php

    wp-content/maintenance.php отвечает за вывод страницы-заглушки, которая показывается в момент автообновления WoordPress. Такая страница определена по умолчанию и за её вывод отвечает функция wp_maintenance(). Но если создать файл maintenance.php в wp-content , то за вывод страницы-заглушки будет отвечать содержимое этого файла.

    В maintenance.php нужно описать страницу-заглушку по всем правилам HTML.

    Подробнее читайте в описании функции wp_maintenance()

    db-error.php

    Позволяет показать произвольный шаблон страницы ошибки соединения с базой данных.

    Если файл wp-content/db-error.php существует в папке wp-content , тогда вместо дефолтного сообщения WordPress об ошибки соединения с базой данных будет загружен этот файл. В файле нужно создать HTML код страницы об ошибке!

    Страница об ошибке подключения должна устанавливать статус ответа 500, чтобы поисковики не обрабатывали контент.

    Файл db-error.php вызывается функцией dead_db(), а функция в свою очередь вызывается при ошибке подключения к БД.

    Пример такой страницы смотрите здесь.

    sunrise.php

    Загружается только для мультисайтовой сборки, т.е. когда срабатывает условие is_multisite() и при этом определена константа ‘SUNRISE’ (её нужно определить в файле wp-config.php ).

    Файл wp-content/sunrise.php позволяет на раннем этапе изменить логику работы сайта в сети мультисайт. Например, тут можно установить глобальные переменные $current_site ,
    $current_blog определяющие текущий сайт сети. Или можно изменить префикс таблиц БД — переменная $table_prefix .

    Также в файле sunrise.php можно изменить константы отвечающие за то, где находится каталоги MU плагинов или обычных плагинов. см. wp_plugin_directory_constants()
    .

    sunrise.php подключается еще до константы SHORTINIT.

    sunrise.php подключается в файле wp-includes/ms-settings.php, который в свою очередь подключается в основном загрузочном файле wp-settings.php.

    db.php

    Позволяет переписать движок работы с БД. Если файл существует в папке wp-content , то он будет вызван до создания подключения к БД. Далее, если в этом файле определить переменную $wpdb , то именно она будет использоваться, как глобальная переменная для работы с БД.

    Благодаря такой логике, можно, например, расширить базовый класс wpdb<> или полностью его заменить.

    Пример расширения базового класса wpdb<> :

    Переименование или перемещение папки wp-content

    В некоторых случаях, например, для уникализации многих URL на всем сайте или для объединения структуры сайта с другим скриптом, или по каким-то еще причинам, нужно чтобы каталог wp-content назвался по-другому или чтобы он находился в другой директории.

    Переместить или переименовать wp-content очень просто. Для этого нужно открыть конфигурационный файл wp-config.php , который лежит в корне вашего сайта и определить в нем две константы:

    • WP_CONTENT_DIR — путь до каталога контента;
    • WP_CONTENT_URL — URL на каталог контента.

    Данный код переименовывает wp-content в data .

    Источник

    Поделиться с друзьями
    КомпСовет
    Adblock
    detector