Regarding translations: My native language is English. Because this is a free and open-source hobby project which generates zero income, and translatable content is likely to change as the features and functionality supported by the project changes, it doesn't make sense for me to spend money for translations. Because I'm the sole author/developer/maintainer for the project and I'm not a ployglot, any translations I produce are very likely to contain errors. Sorry, but realistically, that won't ever change. If you find any such errors/typos/mistakes/etc, your assistance to correct them would be very much appreciated. Pull requests are invited and encouraged. Otherwise, if you find these errors too much to handle, just stick with the original English source. If a translation is irredeemably incomprehensible, let me know which, and I can delete it. If you're not sure how to perform pull requests, ask. I can help.
CIDRAM/СИДРАМ (Бесклассовая Адресация Доступа Менеджер / Classless Inter-Domain Routing Access Manager) это скрипт предназначен для защиты веб-сайтов, путем блокирования запросов, исходящих из IP-адресов рассматривается как источников нежелательного трафика, в том числе (но не ограничивается) трафик с конечными точками доступа нечеловеческих, клоуд/облачные сервисы, спамботы, скребки, и т.д. Она делает это путем вычисления возможной CIDR из IP-адресов, поставляется из входящих запросов, а затем попытка сопоставить эти возможные CIDR с его сигнатур файлы (эти сигнатур файлы содержат списки CIDR из IP-адресов рассматривается как источников нежелательного трафика); Если совпадения найдены, запросы блокируются.
(Видеть: Что такое «CIDR»?).
CIDRAM авторское право 2016 года, а также GNU/GPLv2, созданный Caleb M (Maikuolan).
Это руководство находится в свободном доступе. Вы можете его передавать и/или модифицировать на условиях GNU General Public License, как публикует Фонд свободного программного обеспечения (Free Software Foundation); либо под второй версией лицензии, либо любой другой более поздней версией (по вашему выбору). Пособие публикуется не в целях увеличения прибыли или создания себе рекламы, а лишь в надежде принести пользу, правда, без всякой гарантии. Подробности Вы можете узнать на странице GNU General Public License в разделе LICENSE.txt, а также на страницах:
Этот документ с относящимися к нему пакетом файлов можно бесплатно скачать на страницах:
Во-первых, вам понадобится свежая копия CIDRAM. Вы можете скачать архив последней версии CIDRAM из репозитория CIDRAM/CIDRAM. Чтобы быть конкретным, вам понадобится свежая копия каталога «vault» (все из архива, кроме каталога «vault» и его содержимого, можно безопасно удалить или проигнорировать).
До v3 необходимо было установить CIDRAM где-нибудь в вашем общедоступном root-каталоге, чтобы иметь доступ к фронтенду интерфейсу CIDRAM. Однако, начиная с версии 3, в этом нет необходимости, а для обеспечения максимальной безопасности и предотвращения несанкционированного доступа к CIDRAM и ее файлам рекомендуется вместо этого устанавливать CIDRAM за пределами общедоступного root. Не имеет особого значения, где именно вы решите установить CIDRAM, главное чтобы она была доступна для PHP, где-то достаточно безопасно, и где-то чем вы довольны. Также больше нет необходимости поддерживать имя каталога «vault», поэтому вы можете переименовать «vault» в любое имя, которое вы предпочитаете (но для ради удобства в документации он будет по-прежнему называться каталогом «vault»).
Когда вы будете готовы, загрузите каталог «vault» в выбранное вами место и убедитесь что у него есть разрешения необходимые для того чтобы PHP мог писать в каталог (в зависимости от рассматриваемой системы иногда вам не нужно ничего делать, а иногда вам нужно установить CHMOD 755 в каталог, или если есть проблемы с 755, вы можете попробовать 777, но 777 не рекомендуется из-за меньшей безопасности).
Далее, чтобы CIDRAM могла защитить вашу кодовую базу или CMS, вам необходимо создать «точку входа». Такая точка входа состоит из трех вещей:
- Включение файла «loader.php» в соответствующую точку вашей кодовой базы или CMS.
- Инстанциация CIDRAM core.
- Вызов метода «protect».
Простой пример:
<?php
require_once '/path/to/the/vault/directory/loader.php';
(new \CIDRAM\CIDRAM\Core())->protect();Если вы используете веб-сервер Apache и имеете доступ к php.ini, вы можете использовать директиву auto_prepend_file для запуска CIDRAM всякий раз, когда делается любой запрос PHP. В таком случае наиболее подходящим местом для создания вашей точки входа будет ее собственный файл, и вы должны указать этот файл в директиве auto_prepend_file.
Пример:
auto_prepend_file = "/path/to/your/entrypoint.php"
Или это в файле .htaccess:
php_value auto_prepend_file "/path/to/your/entrypoint.php"
В других случаях наиболее подходящим местом для создания вашей точки входа будет самая ранняя возможная точка в вашей кодовой базе или CMS, чтобы она всегда загружалась всякий раз, когда кто-то обращается к любой странице на всем вашем веб-сайте. Если в вашей кодовой базе используется «начальная загрузка», хорошим примером будет самое начало вашего «начальная загрузочного» файла. Если в вашей кодовой базе есть центральный файл, отвечающий за соединение с вашей базой данных, другим хорошим примером будет самое начало этого центрального файла.
CIDRAM зарегистрирован в Packagist, и так, если Вы знакомы с Composer, Вы можете использовать Composer для инсталляция CIDRAM.
composer require cidram/cidram
CIDRAM зарегистрирован как плагин с базой данных плагинов WordPress, и Вы можете установить CIDRAM непосредственно из панели плагинов. Вы можете установить его так же, как любой другой плагин, и никаких дополнительных шагов не требуется.
Предупреждение: Обновление CIDRAM через панель инструментов плагинов приводит к чистой установке! Если Вы персонализированные свою инсталляция (изменили вашу конфигурацию, установленные модули и т.д.), эти персонализации будут потеряны при обновлении через панель инструментов плагинов! Лог-файлы также будут потеряны! Чтобы сохранить файлы журналов и настройки, обновите страницу с CIDRAM фронтенд.
Настоятельно рекомендуется просмотреть конфигурацию новой установки, чтобы иметь возможность настроить ее в соответствии со своими потребностями. Вы также можете установить дополнительные модули, файлы сигнатур, создать вспомогательные правила, или реализовать другие настройки, чтобы ваша установка наилучшим образом соответствовала вашим потребностям. Я рекомендую использовать фронтенд интерфейс, чтобы делать эти вещи.
CIDRAM должен автоматически блокировать нежелательные запросы на свой веб-сайт, без необходимости ручного помощь, кроме его первоначальной инсталляция.
Вы можете настроить конфигурацию, и настроить какие CIDRы заблокированы, путем изменения файла конфигурации и/или ваши сигнатур файлы.
Если Вы обнаружили ложноположительный, пожалуйста, свяжитесь со мной чтобы сообщить мне об этом. (Видеть: Что такое „ложноположительный“?).
CIDRAM можно обновлять вручную или через фронтенд. CIDRAM также может быть обновлен через Composer или WordPress, если они первоначально установлены с помощью этих средств.
Фронтенд обеспечивает удобный и простой способ для поддержания, управления и обновить инсталляция CIDRAM. Вы можете просматривать, обмениваться и скачать лог-файлы через страницу для лог-файлы, Вы можете изменить конфигурацию с помощью страницы конфигурации, Вы можете устанавливать и удалять компоненты через страницу обновления, и Вы можете загрузить, скачать, и изменять файлы в вашем vault с помощью файл менеджер.
Подобно тому, как вам нужно было создать точку входа, чтобы CIDRAM защищал ваш веб-сайт, вам также потребуется создать точку входа для доступа к фронтенду. Такая точка входа состоит из трех вещей:
- Включение файла «loader.php» в соответствующую точку вашей кодовой базы или CMS.
- Инстанциация CIDRAM front-end/фронтенд.
- Вызов метода «view».
Простой пример:
<?php
require_once '/path/to/the/vault/directory/loader.php';
(new \CIDRAM\CIDRAM\FrontEnd())->view();Класс «FrontEnd» расширяет класс «Core», а это означает, что при желании, вы можете вызвать метод «защиты» перед вызовом метода «просмотра», чтобы заблокировать потенциально нежелательный трафик от доступа к фронтенду. Делать это совершенно необязательно.
Простой пример:
<?php
require_once '/path/to/the/vault/directory/loader.php';
$CIDRAM = new \CIDRAM\CIDRAM\FrontEnd();
$CIDRAM->protect();
$CIDRAM->view();Наиболее подходящим местом для создания точки входа для фронтенда является отдельный выделенный файл. В отличие от вашей ранее созданной точки входа, вы хотите, чтобы ваша фронтенд точка входа была доступна только путем прямого запроса определенного файла, в котором существует точка входа, поэтому в этом случае вы не захотите использовать auto_prepend_file или .htaccess.
После создания фронтенд точки входа используйте браузер для доступа к ней. Вам должна быть представлена страница входа. На странице входа введите имя пользователя и пароль стандартную (admin/password) и нажмите кнопку входа.
Заметка: После того, как Вы вошли в первый раз, в целях предотвращения несанкционированного доступа к фронтенд, Вы должны немедленно изменить имя пользователя и пароль! Это очень важно, потому что это можно загрузить произвольный PHP код на свой веб-сайт через фронтенд.
Кроме того, для обеспечения оптимальной безопасности настоятельно рекомендуется включить «двухфакторную аутентификацию» для всех аккаунтов фронтенд (инструкции приведены ниже).
Инструкции предоставляются на каждой странице в фронтенд, чтобы объяснить правильный способ использовать его и его целевое назначение. Если Вам нужна дополнительная объяснение или любой специальный помощь, обратитесь в поддержки. Дополнительно, есть некоторые видео доступны на YouTube, которые могли бы помочь путем демонстрации.
Возможно сделать фронтенд более безопасным, включив двухфакторную аутентификацию («2FA»). При входе в аккаунт с поддержкой 2FA, электронное письмо отправляется на адрес электронной почты, связанный с этой аккаунтой. Это электронное письмо содержит «код 2FA», который затем должен ввести пользователь в дополнение к имени пользователя и паролю, чтобы иметь возможность войти в систему, используя эту аккаунт. Это означает, что получить пароль аккаунтой будет недостаточно для того, чтобы любой хакер или потенциальный злоумышленник могли войти в эту аккаунт, потому что им также необходимо будет иметь доступ к адресу электронной почты, связанному с этой аккаунтой, чтобы иметь возможность получать и использовать код 2FA, связанный с сеансом, что делает фронтенд более безопасным.
Во-первых, чтобы включить двухфакторную аутентификацию, используя страницу обновлений фронтенда, установите компонент PHPMailer. CIDRAM использует PHPMailer для отправки электронных писем.
После того, как Вы установили PHPMailer, вам нужно будет заполнить директивы конфигурации для PHPMailer через страницу конфигурации CIDRAM или файл конфигурации. Более подробная информация об этих директивах конфигурации содержится в разделе конфигурации этого документа. После того, как Вы заполнили директивы конфигурации PHPMailer, установите enable_two_factor в true. На этом этапе должна быть включена двухфакторная аутентификация.
Затем вам нужно связать адрес электронной почты с аккаунтой, чтобы CIDRAM знал, куда отправлять коды 2FA при входе в эту аккаунт. Для этого используйте адрес электронной почты в качестве имени пользователя для аккаунтой (например, foo@bar.tld), или указать адрес электронной почты как часть имени пользователя так же, как при отправке письма обычно (например, Foo Bar <foo@bar.tld>).
Заметка: Особенно важна защита вашего vault от несанкционированного доступа (например, посредством укрепления безопасности вашего сервера и ужесточение разрешений общего доступа), поскольку несанкционированный доступ к вашему конфигурационному файлу (который хранится в вашем vault), может подвергнуть риску выставлять исходящие настройки SMTP (это включает имя пользователя и пароль SMTP). Вы должны убедиться, что ваше vault правильно защищено, прежде чем включить двухфакторную аутентификацию. Если Вы не можете этого сделать, то, по крайней мере, Вы должны создать новую аккаунт электронной почты, предназначенную для этой цели, чтобы уменьшить риски, связанные с открытыми параметрами SMTP.
Ниже представлен список переменных данных в файле конфигурации config.yml, а также краткое описание их функций.
Конфигурация (v3)
│
├───general
│ stages [string]
│ fields [string]
│ timezone [string]
│ time_offset [int]
│ time_format [string]
│ ipaddr [string]
│ http_response_header_code [int]
│ silent_mode [string]
│ silent_mode_response_header_code [int]
│ lang [string]
│ lang_override [bool]
│ numbers [string]
│ emailaddr [string]
│ emailaddr_display_style [string]
│ ban_override [int]
│ default_dns [string]
│ default_algo [string]
│ statistics [string]
│ force_hostname_lookup [bool]
│ allow_gethostbyaddr_lookup [bool]
│ disabled_channels [string]
│ default_timeout [int]
│ sensitive [string]
│ email_notification_address [string]
│ email_notification_name [string]
│ email_notification_when [string]
├───components
│ ipv4 [string]
│ ipv6 [string]
│ modules [string]
│ imports [string]
│ events [string]
├───logging
│ standard_log [string]
│ apache_style_log [string]
│ serialised_log [string]
│ error_log [string]
│ outbound_request_log [string]
│ report_log [string]
│ truncate [string]
│ log_rotation_limit [int]
│ log_rotation_action [string]
│ log_banned_ips [bool]
│ log_sanitisation [bool]
├───frontend
│ frontend_log [string]
│ signatures_update_event_log [string]
│ max_login_attempts [int]
│ theme [string]
│ magnification [float]
│ custom_header [string]
│ custom_footer [string]
│ remotes [string]
│ enable_two_factor [bool]
├───signatures
│ shorthand [string]
│ default_tracktime [string]
│ infraction_limit [int]
│ tracking_override [bool]
│ conflict_response [int]
├───verification
│ search_engines [string]
│ social_media [string]
│ other [string]
│ adjust [string]
├───recaptcha
│ usemode [int]
│ lockip [bool]
│ lockuser [bool]
│ sitekey [string]
│ secret [string]
│ expiry [float]
│ recaptcha_log [string]
│ signature_limit [int]
│ api [string]
│ show_cookie_warning [bool]
│ show_api_message [bool]
│ nonblocked_status_code [int]
├───hcaptcha
│ usemode [int]
│ lockip [bool]
│ lockuser [bool]
│ sitekey [string]
│ secret [string]
│ expiry [float]
│ hcaptcha_log [string]
│ signature_limit [int]
│ api [string]
│ show_cookie_warning [bool]
│ show_api_message [bool]
│ nonblocked_status_code [int]
├───legal
│ pseudonymise_ip_addresses [bool]
│ privacy_policy [string]
├───template_data
│ theme [string]
│ magnification [float]
│ css_url [string]
│ block_event_title [string]
│ captcha_title [string]
│ custom_header [string]
│ custom_footer [string]
├───rate_limiting
│ max_bandwidth [string]
│ max_requests [int]
│ precision_ipv4 [int]
│ precision_ipv6 [int]
│ allowance_period [string]
│ exceptions [string]
│ segregate [bool]
├───supplementary_cache_options
│ prefix [string]
│ enable_apcu [bool]
│ enable_memcached [bool]
│ enable_redis [bool]
│ enable_pdo [bool]
│ memcached_host [string]
│ memcached_port [int]
│ redis_host [string]
│ redis_port [int]
│ redis_timeout [float]
│ redis_database_number [int]
│ pdo_dsn [string]
│ pdo_username [string]
│ pdo_password [string]
└───bypasses
used [string]Общая конфигурация (любая конфигурация ядра, не относящаяся к другим категориям).
- Элементы управления этапами цепочки выполнения (состояние, регистрация ошибок, и т.д.).
stages
├─Tests ("Выполнить тестов файлов сигнатур")
├─Modules ("Выполнить модули")
├─SearchEngineVerification ("Выполнить проверку поисковой системы")
├─SocialMediaVerification ("Выполнить проверку в социальных сетях")
├─OtherVerification ("Выполнить другую проверку")
├─Aux ("Выполнить вспомогательные правила")
├─Tracking ("Выполнить отслеживание IP")
├─RL ("Выполнить ограничения скорости")
├─CAPTCHA ("Развертывание CAPTCHA (заблокированные запросы)")
├─Reporting ("Выполнить отчетность")
├─Statistics ("Обновить статистику")
├─Webhooks ("Выполнить веб-крючков")
├─PrepareFields ("Подготовить поля для вывода и журналов")
├─Output ("Генерация выводных (заблокированные запросы)")
├─WriteLogs ("Запись в журналы (заблокированные запросы)")
├─Terminate ("Прекращать запрос (заблокированные запросы)")
├─AuxRedirect ("Редирект по вспомогательным правилам")
└─NonBlockedCAPTCHA ("Развертывание CAPTCHA (незаблокированные запросы)")- Элементы управления для полей во время событий блокировки (когда запрос заблокирован).
fields
├─ID ("ИД")
├─ScriptIdent ("Скрипт версия")
├─DateTime ("Дата/Время")
├─IPAddr ("IP-адрес")
├─IPAddrResolved ("IP-адрес (постановили)")
├─Query ("Запрос/Query")
├─Referrer ("Реферер")
├─UA ("Агент пользователя")
├─UALC ("Агент пользователя (в нижнем регистре)")
├─SignatureCount ("Количество сигнатурей")
├─Signatures ("Идентификаторы для сигнатурей")
├─WhyReason ("Почему заблокированные")
├─ReasonMessage ("Почему заблокированные (подробный)")
├─rURI ("Реконструированный URI")
├─Infractions ("Нарушений")
├─ASNLookup ("** Поиск ASN")
├─CCLookup ("** Поиск кода страны")
├─Verified ("Подтвержденная идентичность")
├─Expired ("Истекший")
├─Ignored ("Игнорируется")
├─Request_Method ("Метод запроса")
├─Protocol ("Протокол")
├─SEC_CH_UA_PLATFORM ("!! SEC_CH_UA_PLATFORM")
├─SEC_CH_UA_MOBILE ("!! SEC_CH_UA_MOBILE")
├─SEC_CH_UA ("!! SEC_CH_UA")
├─Hostname ("Имя хоста")
├─CAPTCHA ("Статус CAPTCHA")
├─Inspection ("* Проверка условий")
└─ClientL10NAccepted ("Языковое разрешение")- Предназначен только для отладки вспомогательных правил. Не отображается для заблокированных пользователей.
** Требуется функциональность поиска ASN (например, через модуль IP-API или BGPView).
!! Это подсказка клиенту с низкой энтропией. Это новая экспериментальная веб-технология, которая еще не получила широкой поддержки во всех браузерах и основных клиентах. Видеть: Sec-CH-UA - HTTP | MDN. Хотя клиентские подсказки могут быть полезны для снятия отпечатков пальцев, поскольку они не получили широкой поддержки, их присутствие в запросах не следует предполагать и не полагаться на них (т.е., блокировать по причине их отсутствия – плохая идея).
- Часовой пояс для использования (например, Africa/Cairo, America/New_York, Asia/Tokyo, Australia/Perth, Europe/Berlin, Pacific/Guam, и т.д.). Укажите «SYSTEM», чтобы позволить PHP обрабатывать это автоматически.
timezone
├─SYSTEM ("Использовать часовой пояс по умолчанию.")
├─UTC ("UTC")
└─…Другие- Смещение часового пояса в минут.
- Формат нотации даты, используемый CIDRAM. Дополнительные опции могут быть добавлены по запросу.
time_format
├─{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss} {tz} ("{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss} {tz}")
├─{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss} ("{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss}")
├─{Day}, {dd} {Mon} {yyyy} ("{Day}, {dd} {Mon} {yyyy}")
├─{yyyy}.{mm}.{dd} {hh}:{ii}:{ss} {tz} ("{yyyy}.{mm}.{dd} {hh}:{ii}:{ss} {tz}")
├─{yyyy}.{mm}.{dd} {hh}:{ii}:{ss} ("{yyyy}.{mm}.{dd} {hh}:{ii}:{ss}")
├─{yyyy}.{mm}.{dd} ("{yyyy}.{mm}.{dd}")
├─{yyyy}-{mm}-{dd} {hh}:{ii}:{ss} {tz} ("{yyyy}-{mm}-{dd} {hh}:{ii}:{ss} {tz}")
├─{yyyy}-{mm}-{dd} {hh}:{ii}:{ss} ("{yyyy}-{mm}-{dd} {hh}:{ii}:{ss}")
├─{yyyy}-{mm}-{dd} ("{yyyy}-{mm}-{dd}")
├─{yyyy}/{mm}/{dd} {hh}:{ii}:{ss} {tz} ("{yyyy}/{mm}/{dd} {hh}:{ii}:{ss} {tz}")
├─{yyyy}/{mm}/{dd} {hh}:{ii}:{ss} ("{yyyy}/{mm}/{dd} {hh}:{ii}:{ss}")
├─{yyyy}/{mm}/{dd} ("{yyyy}/{mm}/{dd}")
├─{dd}.{mm}.{yyyy} {hh}:{ii}:{ss} {tz} ("{dd}.{mm}.{yyyy} {hh}:{ii}:{ss} {tz}")
├─{dd}.{mm}.{yyyy} {hh}:{ii}:{ss} ("{dd}.{mm}.{yyyy} {hh}:{ii}:{ss}")
├─{dd}.{mm}.{yyyy} ("{dd}.{mm}.{yyyy}")
├─{dd}-{mm}-{yyyy} {hh}:{ii}:{ss} {tz} ("{dd}-{mm}-{yyyy} {hh}:{ii}:{ss} {tz}")
├─{dd}-{mm}-{yyyy} {hh}:{ii}:{ss} ("{dd}-{mm}-{yyyy} {hh}:{ii}:{ss}")
├─{dd}-{mm}-{yyyy} ("{dd}-{mm}-{yyyy}")
├─{dd}/{mm}/{yyyy} {hh}:{ii}:{ss} {tz} ("{dd}/{mm}/{yyyy} {hh}:{ii}:{ss} {tz}")
├─{dd}/{mm}/{yyyy} {hh}:{ii}:{ss} ("{dd}/{mm}/{yyyy} {hh}:{ii}:{ss}")
├─{dd}/{mm}/{yyyy} ("{dd}/{mm}/{yyyy}")
├─{mm}.{dd}.{yyyy} {hh}:{ii}:{ss} {tz} ("{mm}.{dd}.{yyyy} {hh}:{ii}:{ss} {tz}")
├─{mm}.{dd}.{yyyy} {hh}:{ii}:{ss} ("{mm}.{dd}.{yyyy} {hh}:{ii}:{ss}")
├─{mm}.{dd}.{yyyy} ("{mm}.{dd}.{yyyy}")
├─{mm}-{dd}-{yyyy} {hh}:{ii}:{ss} {tz} ("{mm}-{dd}-{yyyy} {hh}:{ii}:{ss} {tz}")
├─{mm}-{dd}-{yyyy} {hh}:{ii}:{ss} ("{mm}-{dd}-{yyyy} {hh}:{ii}:{ss}")
├─{mm}-{dd}-{yyyy} ("{mm}-{dd}-{yyyy}")
├─{mm}/{dd}/{yyyy} {hh}:{ii}:{ss} {tz} ("{mm}/{dd}/{yyyy} {hh}:{ii}:{ss} {tz}")
├─{mm}/{dd}/{yyyy} {hh}:{ii}:{ss} ("{mm}/{dd}/{yyyy} {hh}:{ii}:{ss}")
├─{mm}/{dd}/{yyyy} ("{mm}/{dd}/{yyyy}")
├─{yy}.{mm}.{dd} {hh}:{ii}:{ss} {tz} ("{yy}.{mm}.{dd} {hh}:{ii}:{ss} {tz}")
├─{yy}.{mm}.{dd} {hh}:{ii}:{ss} ("{yy}.{mm}.{dd} {hh}:{ii}:{ss}")
├─{yy}.{mm}.{dd} ("{yy}.{mm}.{dd}")
├─{yy}-{mm}-{dd} {hh}:{ii}:{ss} {tz} ("{yy}-{mm}-{dd} {hh}:{ii}:{ss} {tz}")
├─{yy}-{mm}-{dd} {hh}:{ii}:{ss} ("{yy}-{mm}-{dd} {hh}:{ii}:{ss}")
├─{yy}-{mm}-{dd} ("{yy}-{mm}-{dd}")
├─{yy}/{mm}/{dd} {hh}:{ii}:{ss} {tz} ("{yy}/{mm}/{dd} {hh}:{ii}:{ss} {tz}")
├─{yy}/{mm}/{dd} {hh}:{ii}:{ss} ("{yy}/{mm}/{dd} {hh}:{ii}:{ss}")
├─{yy}/{mm}/{dd} ("{yy}/{mm}/{dd}")
├─{dd}.{mm}.{yy} {hh}:{ii}:{ss} {tz} ("{dd}.{mm}.{yy} {hh}:{ii}:{ss} {tz}")
├─{dd}.{mm}.{yy} {hh}:{ii}:{ss} ("{dd}.{mm}.{yy} {hh}:{ii}:{ss}")
├─{dd}.{mm}.{yy} ("{dd}.{mm}.{yy}")
├─{dd}-{mm}-{yy} {hh}:{ii}:{ss} {tz} ("{dd}-{mm}-{yy} {hh}:{ii}:{ss} {tz}")
├─{dd}-{mm}-{yy} {hh}:{ii}:{ss} ("{dd}-{mm}-{yy} {hh}:{ii}:{ss}")
├─{dd}-{mm}-{yy} ("{dd}-{mm}-{yy}")
├─{dd}/{mm}/{yy} {hh}:{ii}:{ss} {tz} ("{dd}/{mm}/{yy} {hh}:{ii}:{ss} {tz}")
├─{dd}/{mm}/{yy} {hh}:{ii}:{ss} ("{dd}/{mm}/{yy} {hh}:{ii}:{ss}")
├─{dd}/{mm}/{yy} ("{dd}/{mm}/{yy}")
├─{mm}.{dd}.{yy} {hh}:{ii}:{ss} {tz} ("{mm}.{dd}.{yy} {hh}:{ii}:{ss} {tz}")
├─{mm}.{dd}.{yy} {hh}:{ii}:{ss} ("{mm}.{dd}.{yy} {hh}:{ii}:{ss}")
├─{mm}.{dd}.{yy} ("{mm}.{dd}.{yy}")
├─{mm}-{dd}-{yy} {hh}:{ii}:{ss} {tz} ("{mm}-{dd}-{yy} {hh}:{ii}:{ss} {tz}")
├─{mm}-{dd}-{yy} {hh}:{ii}:{ss} ("{mm}-{dd}-{yy} {hh}:{ii}:{ss}")
├─{mm}-{dd}-{yy} ("{mm}-{dd}-{yy}")
├─{mm}/{dd}/{yy} {hh}:{ii}:{ss} {tz} ("{mm}/{dd}/{yy} {hh}:{ii}:{ss} {tz}")
├─{mm}/{dd}/{yy} {hh}:{ii}:{ss} ("{mm}/{dd}/{yy} {hh}:{ii}:{ss}")
├─{mm}/{dd}/{yy} ("{mm}/{dd}/{yy}")
├─{yyyy}年{m}月{d}日 {hh}時{ii}分{ss}秒 ("{yyyy}年{m}月{d}日 {hh}時{ii}分{ss}秒")
├─{yyyy}年{m}月{d}日 {hh}:{ii}:{ss} {tz} ("{yyyy}年{m}月{d}日 {hh}:{ii}:{ss} {tz}")
├─{yyyy}年{m}月{d}日 ("{yyyy}年{m}月{d}日")
├─{yy}年{m}月{d}日 {hh}時{ii}分{ss}秒 ("{yy}年{m}月{d}日 {hh}時{ii}分{ss}秒")
├─{yy}年{m}月{d}日 {hh}:{ii}:{ss} {tz} ("{yy}年{m}月{d}日 {hh}:{ii}:{ss} {tz}")
├─{yy}年{m}月{d}日 ("{yy}年{m}月{d}日")
├─{yyyy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초 ("{yyyy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초")
├─{yyyy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz} ("{yyyy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz}")
├─{yyyy}년 {m}월 {d}일 ("{yyyy}년 {m}월 {d}일")
├─{yy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초 ("{yy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초")
├─{yy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz} ("{yy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz}")
├─{yy}년 {m}월 {d}일 ("{yy}년 {m}월 {d}일")
├─{yyyy}-{mm}-{dd}T{hh}:{ii}:{ss}{t:z} ("{yyyy}-{mm}-{dd}T{hh}:{ii}:{ss}{t:z}")
├─{d}. {m}. {yyyy} ("{d}. {m}. {yyyy}")
└─…ДругиеЗаполнитель – Объяснение – Пример на основе 2024-04-30T18:27:49+08:00.
{yyyy} – Год – Например, 2024.
{yy} – Сокращенный год – Например, 24.
{Mon} – Сокращенное название месяца (на английском языке) – Например, Apr.
{mm} – Месяц с ведущими нулями – Например, 04.
{m} – Месяц – Например, 4.
{Day} – Сокращенное название дня (на английском языке) – Например, Tue.
{dd} – День с ведущими нулями – Например, 30.
{d} – День – Например, 30.
{hh} – Час с ведущими нулями (используется 24-часовой формат времени) – Например, 18.
{h} – Час (используется 24-часовой формат времени) – Например, 18.
{ii} – Минуты с ведущими нулями – Например, 27.
{i} – Минута – Например, 27.
{ss} – Секунды с ведущими нулями – Например, 49.
{s} – Секунда – Например, 49.
{tz} – Часовой пояс (без двоеточия) – Например, +0800.
{t:z} – Часовой пояс (с двоеточием) – Например, +08:00.
- Место IP-адреса актуального соединения в общем потоке данных (полезно для Cloud-сервиса). Стандарт = REMOTE_ADDR. ВНИМАНИЕ: Изменяйте это значение только в том случае, если Вы уверены в своих действиях!
ipaddr
├─HTTP_INCAP_CLIENT_IP ("HTTP_INCAP_CLIENT_IP (Incapsula)")
├─HTTP_CF_CONNECTING_IP ("HTTP_CF_CONNECTING_IP (Cloudflare)")
├─CF-Connecting-IP ("CF-Connecting-IP (Cloudflare)")
├─HTTP_X_FORWARDED_FOR ("HTTP_X_FORWARDED_FOR (Cloudbric)")
├─X-Forwarded-For ("X-Forwarded-For (Squid)")
├─Forwarded ("Forwarded")
├─REMOTE_ADDR ("REMOTE_ADDR (Стандарт)")
└─…ДругиеСмотрите также:
- Какое сообщение статуса HTTP должно отправлять CIDRAM при блокировке запросов?
http_response_header_code
├─200 (200 OK (Хорошо)): Наименее надежный, но наиболее удобный
│ для пользователя. Автоматизированные
│ запросы, скорее всего, интерпретируют
│ этот ответ как указание на то, что запрос
│ был выполнен успешно.
├─403 (403 Forbidden (Запрещено)): Более надежен, но менее удобен в
│ использовании. Рекомендуется для
│ большинства общих обстоятельств.
├─410 (410 Gone (Удалён)): Может вызвать проблемы при разрешении
│ ложных срабатываний, поскольку некоторые
│ браузеры кэшируют это сообщение о
│ состоянии и не отправляют последующие
│ запросы даже после разблокировки. Может
│ быть наиболее предпочтительным в
│ некоторых контекстах, для определенных
│ видов трафика.
├─418 (418 I'm a teapot (Я чайник)): Отсылает к первоапрельской шутке (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). Очень
│ маловероятно, что это будет понято
│ каким-либо клиентом, ботом, браузером, или
│ кем-либо еще. Предоставляется для
│ развлечения и удобства, но обычно не
│ рекомендуется.
├─451 (451 Unavailable For Legal Reasons (Недоступно По Юридическим Причинам)): Рекомендуется при блокировке
│ преимущественно по юридическим причинам.
│ Не рекомендуется в других контекстах.
└─503 (503 Service Unavailable (Сервис Недоступен)): Самый надежный, но наименее удобный для
пользователя. Рекомендуется при атаке
или при работе с чрезвычайно постоянным
нежелательным трафиком.- Должен CIDRAM молча перенаправить заблокированные попытки доступа вместо отображения страницы «доступ запрещен»? Если да, указать местоположение для перенаправления блокировал попытки доступа. Если нет, оставить эту переменную пустым.
- Какое сообщение статуса HTTP должно отправлять CIDRAM при тихом перенаправлении заблокированных попыток доступа?
silent_mode_response_header_code
├─301 (301 Moved Permanently (Перемещено навсегда)): Сообщает клиенту, что перенаправление
│ является ПОСТОЯННЫМ, и что метод запроса,
│ используемый для перенаправления, МОЖЕТ
│ отличаться от метода запроса,
│ используемого для первоначального
│ запроса.
├─302 (302 Found (Найдено)): Сообщает клиенту, что перенаправление
│ является ВРЕМЕННЫМ, и что метод запроса,
│ используемый для перенаправления, МОЖЕТ
│ отличаться от метода запроса,
│ используемого для первоначального
│ запроса.
├─307 (307 Temporary Redirect (Временное перенаправление)): Сообщает клиенту, что перенаправление
│ является ВРЕМЕННЫМ, и что метод запроса,
│ используемый для перенаправления, НЕ
│ может отличаться от метода запроса,
│ используемого для первоначального
│ запроса.
└─308 (308 Permanent Redirect (Постоянное перенаправление)): Сообщает клиенту, что перенаправление
является ПОСТОЯННЫМ, и что метод запроса,
используемый для перенаправления, НЕ
может отличаться от метода запроса,
используемого для первоначального
запроса.Независимо от того, как мы инструктируем клиента, важно помнить, что в конечном счете мы не имеем никакого контроля над тем, что клиент решит сделать, и нет никакой гарантии, что клиент выполнит наши инструкции.
- Задаёт CIDRAM стандарт языка.
lang
├─af ("Afrikaans")
├─ar ("العربية")
├─bg ("Български")
├─bn ("বাংলা")
├─bs ("Bosanski")
├─ca ("Català")
├─cs ("Čeština")
├─de ("Deutsch")
├─en ("English (AU/GB/NZ)")
├─en-CA ("English (CA)")
├─en-US ("English (US)")
├─es ("Español")
├─fa ("فارسی")
├─fr ("Français")
├─gl ("Galego")
├─gu ("ગુજરાતી")
├─he ("עברית")
├─hi ("हिंदी")
├─hr ("Hrvatski")
├─id ("Bahasa Indonesia")
├─it ("Italiano")
├─ja ("日本語")
├─ko ("한국어")
├─lv ("Latviešu")
├─ml ("മലയാളം")
├─mr ("मराठी")
├─ms ("Bahasa Melayu")
├─nl ("Nederlandse")
├─no ("Norsk")
├─pa ("ਪੰਜਾਬੀ")
├─pl ("Polski")
├─pt-BR ("Português (Brasil)")
├─pt-PT ("Português (Europeu)")
├─ro ("Română")
├─ru ("Русский")
├─sv ("Svenska")
├─sr ("Српски")
├─ta ("தமிழ்")
├─th ("ภาษาไทย")
├─tr ("Türkçe")
├─uk ("Українська")
├─ur ("اردو")
├─vi ("Tiếng Việt")
├─zh-Hans ("中文（简体）")
└─zh-Hant ("中文（傳統）")- Локализовать в соответствии с HTTP_ACCEPT_LANGUAGE, когда это возможно? True = Да [Стандарт]; False = Нет.
- Как Вы предпочитаете номера для отображения? Выберите пример, который выглядит наиболее правильным для вас.
numbers
├─Arabic-1 ("١٢٣٤٥٦٧٫٨٩")
├─Arabic-2 ("١٬٢٣٤٬٥٦٧٫٨٩")
├─Arabic-3 ("۱٬۲۳۴٬۵۶۷٫۸۹")
├─Arabic-4 ("۱۲٬۳۴٬۵۶۷٫۸۹")
├─Armenian ("Ճ̅Ի̅Գ̅ՏՇԿԷ")
├─Base-12 ("4b6547.a8")
├─Base-16 ("12d687.e3")
├─Bengali-1 ("১২,৩৪,৫৬৭.৮৯")
├─Burmese-1 ("၁၂၃၄၅၆၇.၈၉")
├─China-1 ("123,4567.89")
├─Chinese-Simplified ("一百二十三万四千五百六十七点八九")
├─Chinese-Simplified-Financial ("壹佰贰拾叁萬肆仟伍佰陆拾柒点捌玖")
├─Chinese-Traditional ("一百二十三萬四千五百六十七點八九")
├─Chinese-Traditional-Financial ("壹佰貳拾叄萬肆仟伍佰陸拾柒點捌玖")
├─Fullwidth ("１２３４５６７.８９")
├─Geez ("፻፳፫፼፵፭፻፷፯")
├─Hebrew ("א׳׳ב׳קג׳יד׳ךסז")
├─India-1 ("12,34,567.89")
├─India-2 ("१२,३४,५६७.८९")
├─India-3 ("૧૨,૩૪,૫૬૭.૮૯")
├─India-4 ("੧੨,੩੪,੫੬੭.੮੯")
├─India-5 ("೧೨,೩೪,೫೬೭.೮೯")
├─India-6 ("౧౨,౩౪,౫౬౭.౮౯")
├─Japanese ("百万二十万三万四千五百六十七・八九分")
├─Javanese ("꧑꧒꧓꧔꧕꧖꧗.꧘꧙")
├─Khmer-1 ("១.២៣៤.៥៦៧,៨៩")
├─Lao-1 ("໑໒໓໔໕໖໗.໘໙")
├─Latin-1 ("1,234,567.89")
├─Latin-2 ("1 234 567.89")
├─Latin-3 ("1.234.567,89")
├─Latin-4 ("1 234 567,89")
├─Latin-5 ("1,234,567·89")
├─Mayan ("𝋧𝋮𝋦𝋨𝋧.𝋱𝋰")
├─Mongolian ("᠑᠒᠓᠔᠕᠖᠗.᠘᠙")
├─NoSep-1 ("1234567.89")
├─NoSep-2 ("1234567,89")
├─Odia ("୧୨୩୪୫୬୭.୮୯")
├─Roman ("M̅C̅C̅X̅X̅X̅I̅V̅DLXVII")
├─SDN-Dwiggins ("4E6,547;X8")
├─SDN-Pitman ("4↋6,547;↊8")
├─Tamil ("௲௲௨௱௲௩௰௲௪௲௫௱௬௰௭")
├─Thai-1 ("๑,๒๓๔,๕๖๗.๘๙")
├─Thai-2 ("๑๒๓๔๕๖๗.๘๙")
└─Tibetan ("༡༢༣༤༥༦༧.༨༩")- Если Вы хотите, Вы можете предоставить адрес электронной почты здесь чтобы дать пользователям, когда они заблокированы, для их использования в качестве точки контакта за поддержку и/или помощь ибо в случае их блокирования по ошибке. ПРЕДУПРЕЖДЕНИЕ: Любой адрес электронной почты Вы предоставляете здесь наверняка будет найдены по спамботами и скребки во время используется здесь, и так, это настоятельно рекомендуется, если Вы решите добавить адрес электронной почты здесь, что Вы убедитесь что адрес электронной почты что Вы предоставляете здесь одноразовый адрес и/или адрес который Вы не против чтобы быть спамом (другими словами, Вы вероятно не хотите использовать ваши основные личные электронной почты или первичные бизнес электронной почты).
- Как Вы предпочитаете, чтобы адрес электронной почты был представлен пользователям?
emailaddr_display_style
├─default ("Ссылки кликабельны")
└─noclick ("Текст не кликабельны")- Переопределить «http_response_header_code» когда «infraction_limit» превысило? 200 = Не переопределить [Стандарт]. Другие значения совпадают с доступными значениями для «http_response_header_code».
ban_override
├─200 (200 OK (Хорошо)): Наименее надежный, но наиболее удобный
│ для пользователя. Автоматизированные
│ запросы, скорее всего, интерпретируют
│ этот ответ как указание на то, что запрос
│ был выполнен успешно.
├─403 (403 Forbidden (Запрещено)): Более надежен, но менее удобен в
│ использовании. Рекомендуется для
│ большинства общих обстоятельств.
├─410 (410 Gone (Удалён)): Может вызвать проблемы при разрешении
│ ложных срабатываний, поскольку некоторые
│ браузеры кэшируют это сообщение о
│ состоянии и не отправляют последующие
│ запросы даже после разблокировки. Может
│ быть наиболее предпочтительным в
│ некоторых контекстах, для определенных
│ видов трафика.
├─418 (418 I'm a teapot (Я чайник)): Отсылает к первоапрельской шутке (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). Очень
│ маловероятно, что это будет понято
│ каким-либо клиентом, ботом, браузером, или
│ кем-либо еще. Предоставляется для
│ развлечения и удобства, но обычно не
│ рекомендуется.
├─451 (451 Unavailable For Legal Reasons (Недоступно По Юридическим Причинам)): Рекомендуется при блокировке
│ преимущественно по юридическим причинам.
│ Не рекомендуется в других контекстах.
└─503 (503 Service Unavailable (Сервис Недоступен)): Самый надежный, но наименее удобный для
пользователя. Рекомендуется при атаке
или при работе с чрезвычайно постоянным
нежелательным трафиком.- Список DNS-серверов, чтобы использовать для имен хостов поиска. ВНИМАНИЕ: Изменяйте это значение только в том случае, если Вы уверены в своих действиях!
FAQ. Что я могу использовать для «default_dns»?
- Определяет, какой алгоритм использовать для всех будущих паролей и сеансов.
default_algo
├─PASSWORD_DEFAULT ("PASSWORD_DEFAULT")
├─PASSWORD_BCRYPT ("PASSWORD_BCRYPT")
├─PASSWORD_ARGON2I ("PASSWORD_ARGON2I")
└─PASSWORD_ARGON2ID ("PASSWORD_ARGON2ID (PHP >= 7.3.0)")- Определяет, какую статистическую информацию отслеживать.
statistics
├─Blocked-IPv4 ("Запросы блокированный – IPv4")
├─Blocked-IPv6 ("Запросы блокированный – IPv6")
├─Blocked-Other ("Запросы блокированный – Другие")
├─Banned-IPv4 ("Запросы запрещенный – IPv4")
├─Banned-IPv6 ("Запросы запрещенный – IPv6")
├─Passed-IPv4 ("Запросы прошли – IPv4")
├─Passed-IPv6 ("Запросы прошли – IPv6")
├─Passed-Other ("Запросы прошли – Другие")
├─CAPTCHAs-Failed ("Попытки CAPTCHA – Не удалось!")
├─CAPTCHAs-Passed ("Попытки CAPTCHA – Успех!")
├─Reported-IPv4-OK ("Запросы, сообщаются внешним API – IPv4 – ОК")
├─Reported-IPv4-Failed ("Запросы, сообщаются внешним API – IPv4 – Не удалось")
├─Reported-IPv6-OK ("Запросы, сообщаются внешним API – IPv6 – ОК")
└─Reported-IPv6-Failed ("Запросы, сообщаются внешним API – IPv6 – Не удалось")Примечание: Статистику отслеживания для вспомогательных правил можно контролировать на странице вспомогательных правил.
- Поиск имен хостов для всех запросов? True = Да; False = Нет [Стандарт]. Поиск имен хостов обычно выполняется по принципу «по мере необходимости», но может быть принудительно для всех запросов. Это может быть полезно в качестве средства предоставления более подробной информации в логфайлах, но может также иметь слегка отрицательный эффект на производительность.
- Разрешить поиск gethostbyaddr, когда UDP недоступен? True = Да [Стандарт]; False = Нет.
Примечание: Поиск IPv6 может работать некорректно в некоторых 32-разрядных системах.
- Это можно использовать для предотвращения использования CIDRAM определенных каналов при отправке запросов (например, при обновлении, при извлечении метаданных компонента, и т.д.).
disabled_channels
├─GitHub ("GitHub")
├─BitBucket ("BitBucket")
└─GoogleDNS ("GoogleDNS")- Тайм-аут по умолчанию для внешних запросов? Стандарт = 12 секунд.
- Список путей, которые следует рассматривать как конфиденциальные страницы. При необходимости каждый указанный путь будет сверяться с реконструированным URI. Путь, который начинается с косой черты, будет рассматриваться как литерал и сопоставляться с компонентом пути запроса и далее. В качестве альтернативы, путь, который начинается с символа не буквенно-цифрового, и заканчивается тем же символом (или тем же символом плюс необязательный флаг «i»), будет рассматриваться как регулярное выражение. Любой другой путь будет рассматриваться как литерал и может соответствовать любой части URI. Путь, рассматриваемый как конфиденциальная страница, может повлиять на поведение некоторых модулей, но не имеет никакого эффекта в остальном.
- Если вы решили получать уведомления от CIDRAM по электронной почте, например, когда срабатывают определенные вспомогательные правила, здесь вы можете указать адрес получателя этих уведомлений.
- Если вы решили получать уведомления от CIDRAM по электронной почте, например, когда срабатывают определенные вспомогательные правила, здесь вы можете указать имя получателя этих уведомлений.
- Когда отправлять уведомления после их создания.
email_notification_when
├─Immediately ("Сразу.")
├─After24Hours ("Через 24 часа, объединенные вместе (или при ручном запуске, например, через cron).")
└─ManuallyOnly ("Только при ручном запуске (например, через cron).")Конфигурация для активации и деактивации компонентов, используемых CIDRAM. Обычно заполняется страницей обновлений, но также может управляться отсюда для более точного контроля и для пользовательских компонентов, не распознаваемых страницей обновлений.
- Файлы сигнатуры IPv4.
- Файлы сигнатуры IPv6.
- Модули.
- Импортов. Обычно используется для передачи информации о конфигурации компонента в CIDRAM.
- Обработчики событий. Обычно используется для изменения внутреннего поведения CIDRAM или для предоставления дополнительных функционал.
Конфигурация связанная с журнала (что применимо к другим категориям исключено).
- Файл разборчивыми для людей, для регистрации всех заблокированных попыток несанкционированного доступа. Задайте имя файлу, или оставьте пустым чтобы деактивировать опцию.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Apache-стиль файл для регистрации всех заблокированных попыток несанкционированного доступа. Задайте имя файлу, или оставьте пустым чтобы деактивировать опцию.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Сериализованная файл для регистрации всех заблокированных попыток несанкционированного доступа. Задайте имя файлу, или оставьте пустым чтобы деактивировать опцию.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Файл для регистрации обнаруженных нефатальных ошибок. Задайте имя файлу, или оставьте пустым чтобы деактивировать опцию.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Файл для регистрации результатов любых исходящих запросов. Задайте имя файлу, или оставьте пустым чтобы деактивировать опцию.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Файл для регистрации любых отчетов, отправленных во внешние API. Задайте имя файлу, или оставьте пустым чтобы деактивировать опцию.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Усекать лог-файлы, когда они достигают определенного размера? Значение это максимальный размер в Б/КБ/МБ/ГБ/ТБ, до которого файл журнала может увеличиться до усечения. Стандартное значение 0КБ отключает усечение (лог-файлы может расти неограниченно). Примечание: относится к отдельным лог-файлы! Размер файлов журнала не учитывается совместно.
- Лог вращения ограничивает количество журнальных лог-файлов, которые должны существовать в любой момент времени. Когда создаются новые лог-файлы, если общее количество лог-файлов превышает указанный предел, указанное действие будет выполнено. Здесь Вы можете указать желаемый лимит. Значение 0 отключит вращение лог.
- Лог вращения ограничивает количество журнальных лог-файлов, которые должны существовать в любой момент времени. Когда создаются новые лог-файлы, если общее количество лог-файлов превышает указанный предел, указанное действие будет выполнено. Здесь Вы можете указать желаемое действие.
log_rotation_action
├─Delete ("Удалите самые старые лог-файлы, пока лимит больше не будет превышен.")
└─Archive ("Сначала архивируйте, а затем удалите самые старые лог-файлы, пока лимит больше не будет превышен.")- Включить заблокированные запросы от запрещенных IP-адресов в лог-файлы? True = Да [Стандарт]; False = Нет.
- При использовании фронтенд страницы журналов для просмотра данных журнала, CIDRAM подготавливает данные журнала перед их отображением таким образом, чтобы защитить пользователей от атак XSS. Однако эти меры обычно не происходят, когда данные впервые регистрируются. Это необходимо для обеспечения точного сохранения данных журнала, чтобы помочь любому эвристическому анализу, который может потребоваться в будущем. Однако в случае, если пользователь пытается прочитать данные журнала, используя внешние инструменты, которые не подготавливают данные журнала аналогичным образом для защиты пользователей, пользователь может подвергаться атакам XSS. При необходимости Вы можете изменить поведение по умолчанию с помощью этой директивы конфигурации. True = Очистка данных при записи в журнал (данные сохраняются менее точно, но риск XSS ниже). False = Не очищайте данные при записи в журнал (данные сохраняются более точно, но риск XSS выше) [Стандарт].
Конфигурация для фронтенда.
- Файл для запись всех попыток входа в фронтенд. Задайте имя файлу, или оставьте пустым чтобы деактивировать опцию.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Файл для регистрации при обновлении сигнатурей через фронтенд. Задайте имя файлу, или оставьте пустым чтобы деактивировать опцию.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Максимальное количество попыток входа в систему фронтенда. Стандарт = 5.
- Стандартная тема для фронтенда.
theme
├─default ("Default")
├─bluemetal ("Blue Metal")
├─fullmoon ("Full Moon")
├─moss ("Moss")
├─primer ("Primer")
├─primerdark ("Primer Dark")
├─rbi ("Red-Blue Inverted")
├─slate ("Slate")
└─…Другие- Увеличение шрифта. Стандарт = 1.
- Вставляется как HTML в начале всех фронтенд страниц. Это может быть полезно, если вы хотите включить логотип веб-сайта, персонализированный заголовок, скрипты, или подобное на всех таких страницах.
- Вставляется как HTML в конце всех фронтенд страниц. Это может быть полезно, если вы хотите включить юридическое уведомление, контактную ссылку, деловую информацию, или подобное на всех таких страницах.
- Список адресов, используемых системой обновлений для получения метаданных компонентов. Это может потребоваться скорректировать при обновлении до новой основной версии, или при приобретении нового источника обновлений, но в обычных обстоятельствах его следует оставить в покое.
- Эта директива включает/отключает использование 2FA для фронтенд счетов.
Конфигурация для сигнатурей, файлов сигнатурей, модулей и т.д.
- Управляет что делать с запросом, когда есть положительное совпадение с сигнатурю, в которой используются заданные сокращенные слова.
shorthand
├─Attacks ("Атаки")
├─Bogon ("⁰ Bogon/Марсианин IP")
├─Cloud ("Облачный сервис")
├─Generic ("Общий")
├─Legal ("¹ Юридический")
├─Malware ("Вредоносные программы")
├─Proxy ("² Прокси")
├─Spam ("Спам")
├─Banned ("³ Запрещенный")
├─BadIP ("³ Неверный IP")
├─RL ("³ Скорость ограничена")
├─Conflict ("³ Конфликт")
└─Other ("⁴ Другие")0. Если вашему веб-сайту требуется доступ через локальную сеть или локальный хост, не блокируйте это. В противном случае вы можете заблокировать это.
1. Стандартные файлы сигнатур не используют это, но оно по-прежнему поддерживается на случай, если оно может оказаться полезным для некоторых пользователей.
2. Если ваши пользователи могут получить доступ к вашему сайту через прокси, не блокируйте это. В противном случае вы можете заблокировать это.
3. Прямое использование в сигнатуры не поддерживается, но в определенных обстоятельствах его можно вызвать другими способами.
4. Относится к случаям, когда сокращенные слова вообще не используются или не распознаются CIDRAM.
Один на сигнатур. Сигнатур может вызывать несколько профилей, но может использовать только одно сокращенное слово. Возможно, подойдет несколько сокращенных слов, но поскольку можно использовать только одно, мы стремимся всегда использовать только наиболее подходящие.
Приоритет. Выбранная опция всегда имеет приоритет над невыбранной опцией. Например, если используется несколько сокращенных слов, но только одно из них установлено как заблокированное, запрос все равно будет заблокирован.
Человеческие конечные точки и облачные сервисы. Облачная служба может относиться к провайдерам веб-хостинга, фермам серверов, центрам обработки данных, или ряду других вещей. Конечная точка человека относится к средствам, с помощью которых человек получает доступ к интернету, например, через интернет-провайдера. Сеть обычно предоставляет только одно или другое, но иногда может предоставлять оба. Мы стремимся никогда не идентифицировать потенциальные конечные точки человека как облачные сервисы. Следовательно, облачная служба может быть идентифицирована как нечто другое, если ее диапазон используется известными конечными точками человека. Точно так же мы стремимся всегда идентифицировать облачные сервисы, диапазоны которых не используются никакими известными конечными точками человека, как облачные сервисы. Следовательно, запрос, явно идентифицированный как облачная служба, вероятно не имеет общего диапазона ни с какими известными конечными точками человека. Точно так же запрос, явно идентифицированный атаками или спам риском, вероятно действительно разделяет их. Тем не менее, интернет всегда в движении, цели сетей со временем меняются, а диапазоны всегда покупаются или продаются, поэтому оставайтесь сознательными и бдительными в отношении ложных срабатываний.
- Время в течение которого следует отслеживать IP-адреса. Стандарт = 7d0°0′0″ (1 неделя).
- Максимальное число нарушений IP-разрешено брать на себя, прежде чем она запрещена отслеживание IP. Стандарт = 10.
- Разрешить модулям переопределять параметры отслеживания? True = Да [Стандарт]; False = Нет.
- Если одновременно происходит слишком много попыток доступа к одним и тем же ресурсам (например, одновременные запросы к нескольким процессам PHP на одном компьютере для одних и тех же ресурсов), некоторые из этих попыток могут завершиться неудачей. В редком и маловероятном случае, если это затронет файлы сигнатурей или модули, CIDRAM может быть лишен возможности принять эффективное решение по запросу. Если это произойдет, следует ли блокировать запрос, и какое сообщение о состоянии HTTP должен отправить CIDRAM?
conflict_response
├─0 (Не блокируйте запрос.): Если вы предпочитаете, чтобы запросы
│ блокировались только в том случае если вы
│ уверены что они вредоносные, или хотите
│ проявить осторожность в отношении ложных
│ срабатываний (за счет нежелательного
│ трафика который иногда проходит),
│ выберите это. Если вы предпочитаете,
│ чтобы запросы блокировались если вы не
│ уверены в их безвредности, или хотите
│ проявить бдительность (пусть и ценой
│ случайных ложных срабатываний), выберите
│ один из других доступных вариантов.
├─409 (409 Конфликт): Рекомендуется при конфликтах ресурсов
│ (например, конфликтах слияния, конфликтах
│ доступа к файлам, и т.д). Не рекомендуется
│ в других контекстах.
└─429 (429 Too Many Requests (Слишком много запросов)): Рекомендуется для ограничения скорости,
при борьбе с DDoS-атаками, и для
предотвращения флуда. Не рекомендуется в
других контекстах.Конфигурация для проверки того, откуда исходят запросы.
- Элементы управления для проверки запросов от поисковых систем.
search_engines
├─Amazonbot ("Amazonbot")
├─Applebot ("Applebot")
├─Baidu ("* Baiduspider/百度")
├─Bingbot ("* Bingbot")
├─DuckDuckBot ("* DuckDuckBot")
├─Googlebot ("* Googlebot")
├─MojeekBot ("MojeekBot")
├─Neevabot ("* Neevabot")
├─PetalBot ("* PetalBot")
├─Qwantify ("Qwantify/Bleriot")
├─SeznamBot ("SeznamBot")
├─Sogou ("* Sogou/搜狗")
├─Yahoo ("Yahoo/Slurp")
├─Yandex ("* Yandex/Яндекс")
└─YoudaoBot ("YoudaoBot")Что такое «положительные» и «отрицательные»? При проверке идентификации, представленной запросом, успешный результат может быть описан как «положительный» или «отрицательный». Когда представленная идентификация подтверждается как истинная идентификация, она будет описана как «положительная». Когда подтвердится, что представленное удостоверение идентификации было сфальсифицировано, оно будет описано как «отрицательное». Однако неудачный результат (например, сбой проверки, или невозможность определить достоверность представленной идентификации) не будет описываться как «положительный» или «отрицательный». Вместо этого неудачный результат будет описан просто как непроверенный. Когда не предпринимается никаких попыток проверить идентификацию, представленную в запросе, запрос также будет описан как непроверенный. Термины имеют смысл только в том контексте, когда идентификация, представленная запросом, распознается и, следовательно, когда возможна проверка. В случаях, когда представленное удостоверение идентификации не соответствует параметрам, указанным выше, или если удостоверение идентификации не представлено, указанные выше параметры становятся неактуальными.
Что такое «байпасы отдельных нарушений»? В некоторых случаях положительно-проверенный запрос может быть заблокирован из-за файлов сигнатуры, модулей, или других условий запроса, и байпасы могут быть необходимы, чтобы избежать ложных срабатываний. В случае, когда байпас предназначен для устранения ровно одного нарушения, не больше и не меньше, такой байпас можно описать как «обход с отдельных нарушений».
- Эта опция имеет соответствующий байпас под
bypasses➡used. Рекомендуется убедиться, что флажок для соответствующего байпаса отмечен так же, как флажок для попытки проверки этой опции.
- Элементы управления для проверки запросов от платформ социальных сетей.
social_media
├─Embedly ("* Embedly")
├─Facebook ("** Facebook")
├─Pinterest ("* Pinterest")
├─Snapchat ("* Snapchat")
└─Twitterbot ("*!! Twitterbot")Что такое «положительные» и «отрицательные»? При проверке идентификации, представленной запросом, успешный результат может быть описан как «положительный» или «отрицательный». Когда представленная идентификация подтверждается как истинная идентификация, она будет описана как «положительная». Когда подтвердится, что представленное удостоверение идентификации было сфальсифицировано, оно будет описано как «отрицательное». Однако неудачный результат (например, сбой проверки, или невозможность определить достоверность представленной идентификации) не будет описываться как «положительный» или «отрицательный». Вместо этого неудачный результат будет описан просто как непроверенный. Когда не предпринимается никаких попыток проверить идентификацию, представленную в запросе, запрос также будет описан как непроверенный. Термины имеют смысл только в том контексте, когда идентификация, представленная запросом, распознается и, следовательно, когда возможна проверка. В случаях, когда представленное удостоверение идентификации не соответствует параметрам, указанным выше, или если удостоверение идентификации не представлено, указанные выше параметры становятся неактуальными.
Что такое «байпасы отдельных нарушений»? В некоторых случаях положительно-проверенный запрос может быть заблокирован из-за файлов сигнатуры, модулей, или других условий запроса, и байпасы могут быть необходимы, чтобы избежать ложных срабатываний. В случае, когда байпас предназначен для устранения ровно одного нарушения, не больше и не меньше, такой байпас можно описать как «обход с отдельных нарушений».
- Эта опция имеет соответствующий байпас под
bypasses➡used. Рекомендуется убедиться, что флажок для соответствующего байпаса отмечен так же, как флажок для попытки проверки этой опции.
** Требуется функциональность поиска ASN (например, через модуль IP-API или BGPView).
*!! Высокая вероятность ложных срабатываний из-за iMessage.
- Элементы управления для проверки других типов запросов, где это возможно.
other
├─AdSense ("AdSense")
├─AmazonAdBot ("* AmazonAdBot")
├─ChatGPT-User ("!! ChatGPT-User")
├─GPTBot ("!! GPTBot")
└─Grapeshot ("* Oracle Data Cloud Crawler (Grapeshot)")Что такое «положительные» и «отрицательные»? При проверке идентификации, представленной запросом, успешный результат может быть описан как «положительный» или «отрицательный». Когда представленная идентификация подтверждается как истинная идентификация, она будет описана как «положительная». Когда подтвердится, что представленное удостоверение идентификации было сфальсифицировано, оно будет описано как «отрицательное». Однако неудачный результат (например, сбой проверки, или невозможность определить достоверность представленной идентификации) не будет описываться как «положительный» или «отрицательный». Вместо этого неудачный результат будет описан просто как непроверенный. Когда не предпринимается никаких попыток проверить идентификацию, представленную в запросе, запрос также будет описан как непроверенный. Термины имеют смысл только в том контексте, когда идентификация, представленная запросом, распознается и, следовательно, когда возможна проверка. В случаях, когда представленное удостоверение идентификации не соответствует параметрам, указанным выше, или если удостоверение идентификации не представлено, указанные выше параметры становятся неактуальными.
Что такое «байпасы отдельных нарушений»? В некоторых случаях положительно-проверенный запрос может быть заблокирован из-за файлов сигнатуры, модулей, или других условий запроса, и байпасы могут быть необходимы, чтобы избежать ложных срабатываний. В случае, когда байпас предназначен для устранения ровно одного нарушения, не больше и не меньше, такой байпас можно описать как «обход с отдельных нарушений».
- Эта опция имеет соответствующий байпас под
bypasses➡used. Рекомендуется убедиться, что флажок для соответствующего байпаса отмечен так же, как флажок для попытки проверки этой опции.
!! Большинство пользователей, вероятно, захотят чтобы это было заблокировано, независимо от того, является ли оно реальным или фальсифицированным. Этого можно добиться, не выбирая «попробуй проверить» и выбирая «блокировать непроверенные запросы». Однако, поскольку некоторые пользователи могут захотеть иметь возможность проверять такие запросы (чтобы блокировать отрицательные и разрешать положительные), вместо блокировки таких запросов через модули, здесь предоставляются варианты обработки таких запросов.
- Элементы управления для настройки других функциональность в контексте проверки.
adjust
├─Negatives ("Заблокированные негативы")
└─NonVerified ("Заблокировано непроверено")Конфигурация для ReCaptcha (предоставляет людям возможность восстановить доступ при блокировании).
- Когда следует предлагать CAPTCHA? Примечание: Запросы из белого списка или проверенные и неблокированные запросы никогда не требуют выполнения CAPTCHA. Также обратите внимание: CAPTCHA может обеспечить полезный дополнительный уровень защиты от ботов и различных вредоносных автоматических запросов, но не обеспечивает никакой защиты от вредоносных люди.
usemode
├─0 (Никогда !!!)
├─1 (Только когда блокировке, в пределах лимита сигнатурей, и не забанен.)
├─2 (Только когда заблокирован, специально помечен для использования, в пределах лимита сигнатурей, и не забанен.)
├─3 (Только когда в пределах лимита сигнатурей, и не забанен (вне зависимости от того, заблокирован ли).)
├─4 (Только когда не заблокирован.)
├─5 (Только когда не заблокирован, или специально помечен для использования, в пределах лимита сигнатурей, и не забанен.)
└─6 (Только когда не заблокирован, при запросах конфиденциальных страниц.)- Свяжите CAPTCHA к IP-адреса?
- Свяжите CAPTCHA к пользователи?
- Это значение можно найти на панели управления вашей службы CAPTCHA.
Смотрите также:
- Это значение можно найти на панели управления вашей службы CAPTCHA.
Смотрите также:
- Количество часов, чтобы вспомнить инстанция CAPTCHA. Стандарт = 720 (1 месяц).
- Записывать все попытки CAPTCHA? Если да, указать имя использовать для файла журнала. Если нет, оставьте эту переменную пустым.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Максимально допустимое количество сигнатурей перед снятием CAPTCHA. Стандарт = 1.
- Какой API использовать?
api
├─V2 ("V2 (Флажок)")
└─Invisible ("V2 (Невидимый)")- Показать предупреждение о файлах куки? True = Да [Стандарт]; False = Нет.
- Показать сообщение API? True = Да [Стандарт]; False = Нет.
- Какой код состояния следует использовать при отображении CAPTCHA для неблокированных запросов?
nonblocked_status_code
├─200 (200 OK (Хорошо)): Наименее надежный, но наиболее удобный
│ для пользователя. Автоматизированные
│ запросы, скорее всего, интерпретируют
│ этот ответ как указание на то, что запрос
│ был выполнен успешно.
├─403 (403 Forbidden (Запрещено)): Более надежен, но менее удобен в
│ использовании. Рекомендуется для
│ большинства общих обстоятельств.
├─418 (418 I'm a teapot (Я чайник)): Отсылает к первоапрельской шутке (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). Очень
│ маловероятно, что это будет понято
│ каким-либо клиентом, ботом, браузером, или
│ кем-либо еще. Предоставляется для
│ развлечения и удобства, но обычно не
│ рекомендуется.
├─429 (429 Too Many Requests (Слишком много запросов)): Рекомендуется для ограничения скорости,
│ при борьбе с DDoS-атаками, и для
│ предотвращения флуда. Не рекомендуется в
│ других контекстах.
└─451 (451 Unavailable For Legal Reasons (Недоступно По Юридическим Причинам)): Рекомендуется при блокировке
преимущественно по юридическим причинам.
Не рекомендуется в других контекстах.Конфигурация для HCaptcha (предоставляет людям возможность восстановить доступ при блокировании).
- Когда следует предлагать CAPTCHA? Примечание: Запросы из белого списка или проверенные и неблокированные запросы никогда не требуют выполнения CAPTCHA. Также обратите внимание: CAPTCHA может обеспечить полезный дополнительный уровень защиты от ботов и различных вредоносных автоматических запросов, но не обеспечивает никакой защиты от вредоносных люди.
usemode
├─0 (Никогда !!!)
├─1 (Только когда блокировке, в пределах лимита сигнатурей, и не забанен.)
├─2 (Только когда заблокирован, специально помечен для использования, в пределах лимита сигнатурей, и не забанен.)
├─3 (Только когда в пределах лимита сигнатурей, и не забанен (вне зависимости от того, заблокирован ли).)
├─4 (Только когда не заблокирован.)
├─5 (Только когда не заблокирован, или специально помечен для использования, в пределах лимита сигнатурей, и не забанен.)
└─6 (Только когда не заблокирован, при запросах конфиденциальных страниц.)- Свяжите CAPTCHA к IP-адреса?
- Свяжите CAPTCHA к пользователи?
- Это значение можно найти на панели управления вашей службы CAPTCHA.
Смотрите также:
- Это значение можно найти на панели управления вашей службы CAPTCHA.
Смотрите также:
- Количество часов, чтобы вспомнить инстанция CAPTCHA. Стандарт = 720 (1 месяц).
- Записывать все попытки CAPTCHA? Если да, указать имя использовать для файла журнала. Если нет, оставьте эту переменную пустым.
Полезный совет: Вы можете прикрепить информацию о дате и времени к именам файлов журналов, используя заполнители формата времени. Доступные заполнители формата времени отображаются на general➡time_format.
- Максимально допустимое количество сигнатурей перед снятием CAPTCHA. Стандарт = 1.
- Какой API использовать?
api
├─V1 ("V1")
└─Invisible ("V1 (Невидимый)")- Показать предупреждение о файлах куки? True = Да [Стандарт]; False = Нет.
- Показать сообщение API? True = Да [Стандарт]; False = Нет.
- Какой код состояния следует использовать при отображении CAPTCHA для неблокированных запросов?
nonblocked_status_code
├─200 (200 OK (Хорошо)): Наименее надежный, но наиболее удобный
│ для пользователя. Автоматизированные
│ запросы, скорее всего, интерпретируют
│ этот ответ как указание на то, что запрос
│ был выполнен успешно.
├─403 (403 Forbidden (Запрещено)): Более надежен, но менее удобен в
│ использовании. Рекомендуется для
│ большинства общих обстоятельств.
├─418 (418 I'm a teapot (Я чайник)): Отсылает к первоапрельской шутке (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). Очень
│ маловероятно, что это будет понято
│ каким-либо клиентом, ботом, браузером, или
│ кем-либо еще. Предоставляется для
│ развлечения и удобства, но обычно не
│ рекомендуется.
├─429 (429 Too Many Requests (Слишком много запросов)): Рекомендуется для ограничения скорости,
│ при борьбе с DDoS-атаками, и для
│ предотвращения флуда. Не рекомендуется в
│ других контекстах.
└─451 (451 Unavailable For Legal Reasons (Недоступно По Юридическим Причинам)): Рекомендуется при блокировке
преимущественно по юридическим причинам.
Не рекомендуется в других контекстах.Конфигурация для юридических требований.
- Псевдонимный IP-адреса при записи файлов журнала? True = Да [Стандарт]; False = Нет.
- Адрес соответствующей политики конфиденциальности, отображаемый в нижнем колонтитуле любых сгенерированных страниц. Укажите URL-адрес, или оставьте пустым для отключения.
Конфигурация для шаблонов и темов.
- Стандартная тема для CIDRAM.
theme
├─default ("Default")
├─bluemetal ("Blue Metal")
├─fullmoon ("Full Moon")
├─moss ("Moss")
├─primer ("Primer")
├─primerdark ("Primer Dark")
├─rbi ("Red-Blue Inverted")
├─slate ("Slate")
└─…Другие- Увеличение шрифта. Стандарт = 1.
- URL файла CSS для пользовательских тем.
- Заголовок страницы для отображения событий блокировки.
block_event_title
├─CIDRAM ("CIDRAM")
├─denied ("Доступ запрещен!")
└─…Другие- Заголовок страницы для отображения запросов CAPTCHA.
captcha_title
├─CIDRAM ("CIDRAM")
└─…Другие- Вставляется как HTML в начало всех страниц «доступ запрещен». Это может быть полезно, если вы хотите включить логотип веб-сайта, персонализированный заголовок, скрипты, или подобное на всех таких страницах.
- Вставляется как HTML в конце всех страниц «доступ запрещен». Это может быть полезно, если вы хотите включить юридическое уведомление, контактную ссылку, деловую информацию, или подобное на всех таких страницах.
Конфигурация для ограничения скорости (не рекомендуется для общего пользования).
- Максимальный размер полосы пропускания, разрешенный в течение периода пособия, до включения ограничения скорости для будущих запросов. Значение 0 отключает этот тип ограничения скорости. Стандарт = 0KB.
- Максимальное количество запросов, разрешенных в течение периода пособия, до включения ограничения скорости для будущих запросов. Значение 0 отключает этот тип ограничения скорости. Стандарт = 0.
- Точность использования при мониторинге использования IPv4. Значение отражает размер блока CIDR. Установить как 32 для наилучшей точности. Стандарт = 32.
- Точность использования при мониторинге использования IPv6. Значение отражает размер блока CIDR. Установить как 128 для наилучшей точности. Стандарт = 128.
- Продолжительность мониторинга использования. Стандарт = 0°0′0″.
- Исключения (т.е., запросы, которые не должны ограничиваться). Действует только при включенном ограничении скорости.
exceptions
├─Whitelisted ("Запросы отмечены как в белом списке")
├─Verified ("Проверенные запросы от поисковых систем и социальных сетей")
└─FE ("Запросы к фронтенду CIDRAM")- Должны ли квоты для разных доменов и хостов храниться раздельно или совместно? True = Квоты будут храниться раздельно. False = Квоты будут храниться совместно [Стандарт].
Дополнительные параметры кэша. Примечание: Изменение этих значений потенциально может привести к выходу из системы.
- Указанное здесь значение будет добавлено в начало всех ключей записи кэша. Стандарт = «CIDRAM_». Когда на одном сервере существует несколько установок, это может быть полезно для хранения их кэшей отдельно.
- Указывает, использовать ли APCu для кэширования. Стандарт = True.
- Указывает, использовать ли Memcached для кэширования. Стандарт = False.
- Указывает, использовать ли Redis для кэширования. Стандарт = False.
- Указывает, использовать ли PDO для кэширования. Стандарт = False.
- Значение хоста Memcached. Стандарт = «localhost».
- Значение порта Memcached. Стандарт = «11211».
- Значение хоста Redis. Стандарт = «localhost».
- Значение порта Redis. Стандарт = «6379».
- Значение тайм-аута Redis. Стандарт = «2.5».
- Номер базы данных Redis. Стандарт = 0. Примечание: В Redis Cluster нельзя использовать значения, отличные от 0.
- Значение DSN PDO. Стандарт = «mysql:dbname=cidram;host=localhost;port=3306».
FAQ. Что такое «PDO DSN»? Как я могу использовать PDO с CIDRAM?
- Имя пользователя PDO.
- Пароль PDO.
Стандартная сигнатур байпаса конфигурация.
- Какие байпасы следует использовать?
used
├─AbuseIPDB ("AbuseIPDB")
├─AmazonAdBot ("AmazonAdBot")
├─Baidu ("Baiduspider/百度")
├─Bingbot ("Bingbot")
├─DuckDuckBot ("DuckDuckBot")
├─Embedly ("Embedly")
├─Feedbot ("Feedbot")
├─Feedspot ("Feedspot")
├─GoogleFiber ("Google Fiber")
├─Googlebot ("Googlebot")
├─Grapeshot ("Grapeshot")
├─Jetpack ("Jetpack")
├─Neevabot ("Neevabot")
├─PetalBot ("PetalBot")
├─Pinterest ("Pinterest")
├─Redditbot ("Redditbot")
├─Skype ("Skype URL Preview")
├─Snapchat ("Snapchat")
├─Sogou ("Sogou/搜狗")
└─Yandex ("Yandex/Яндекс")Смотрите также:
Все сигнатуры IPv4 придерживаться формат: xxx.xxx.xxx.xxx/yy [Функция] [Параметр].
xxx.xxx.xxx.xxxпредставляет начало блока CIDR (октеты для первым IP-адреса в блока).yyпредставляет размер блока CIDR [1-32].[Функция]инструктирует скрипт что делать с сигнатур (как сигнатур должны быть обработаны).[Параметр]представляет все что дополнительная информация что может потребоваться для[Функция].
Все сигнатуры IPv6 придерживаться формат: xxxx:xxxx:xxxx:xxxx::xxxx/yy [Функция] [Параметр].
xxxx:xxxx:xxxx:xxxx::xxxxпредставляет начало блока CIDR (октеты для первым IP-адреса в блока). Полное обозначение и сокращенное обозначение являются приемлемыми (и каждый из них ДОЛЖЕН следовать соответствующим стандартам для обозначение IPv6, но с одним исключением: IPv6-адрес никогда не может начинаться с аббревиатуры когда использовании в сигнатуры для этого скрипт, из-за способа в котором они реконструируются посредством скрипт; Например,::1/128должны быть выражены, когда использовании в сигнатур, в виде0::1/128, и::0/128выражены в виде0::/128).yyпредставляет размер блока CIDR [1-128].[Функция]инструктирует скрипт что делать с сигнатур (как сигнатур должны быть обработаны).[Параметр]представляет все что дополнительная информация что может потребоваться для[Функция].
CIDRAM сигнатурные файлы ДОЛЖЕН использовать разрыВы строк Unix-стиле (%0A, или \n)! Другие типы/стили разрыва строки (например, Windows %0D%0A или \r\n разрыВы строк, Mac %0D или \r разрыВы строк, и т.д.) МОЖЕТ быть использовано, но НЕ являются предпочтительными. РазрыВы строк не-Unix-стиле будут нормализованы к разрыВы строк Unix-стиле посредством скрипт.
Точное и правильное обозначение CIDR необходимо, в противном случае скрипт не будет признает сигнатур. Дополнительно, все сигнатуры CIDR для этого скрипт ДОЛЖНА начинаться с IP-адресом чья номер IP которого можно разделить равномерно в блок разделения представляющий от его размер блока CIDR (например, если Вы хотите чтобы заблокировать все IP-адреса из 10.128.0.0 к 11.127.255.255, 10.128.0.0/8 НЕ будут признаны посредством скрипт, но 10.128.0.0/9 и 11.0.0.0/9 используется в сочетании, БУДУТ признаны посредством скрипт).
Все что в сигнатуры файлы которые не признается как качестве сигнатур ни как относятся синтаксис посредством скрипт будут ПРОИГНОРИРОВАНЫ, поэтому это означает что Вы можете безопасно поставить любые данные несигнатурного что Вы хочешь в файлов сигнатур без разбивая их и без разбивая скрипт. Комментарии являются приемлемыми в файлов сигнатур, без какого-либо специального форматирования требуется. Shell-стиле хэширования для комментарии является предпочтительным, но не принудительная; Функционально, это не имеет никакого значения для сценария ли или не Вы выбираете использовать хэширование Shell-стиле для комментарии, но использовать хэширование Shell-стиле может помогает IDE и простые текстовые редакторы чтобы правильно выделить различные части файлов сигнатур (и так, Shell-стиле хэширования может помочь в качестве наглядного пособия при редактировании).
В возможные значения для [Функция]:
- Run
- Whitelist
- Greylist
- Deny
Если «Run» используется, когда сигнатур срабатывает, скрипт будет пытаться выполнить (используя заявление require_once) внешний PHP скрипт, определяется значением [Параметр] (рабочий каталог должен быть каталог „/vault/“ из скрипт).
Примеры: 127.0.0.0/8 Run example.php
Это может быть полезно если Вы хотите чтобы выполнить некоторые специфические PHP код для некоторых конкретных IP-адресов и/или CIDR.
Если «Whitelist» используется, когда сигнатур срабатывает, скрипт будет сброса всех обнаружений (если есть какие-либо обнаружений) и нарушить функцию тестирования. [Параметр] будут игнорироваться. Эта функция является эквивалентом белого списка конкретный IP или CIDR от обнаружения.
Примеры: 127.0.0.1/32 Whitelist
Если «Greylist» используется, когда сигнатур срабатывает, скрипт будет сброса всех обнаружений (если есть какие-либо обнаружений) и перейти к следующему файлу сигнатуры чтобы продолжить обработку. [Параметр] будут игнорироваться.
Примеры: 127.0.0.1/32 Greylist
Если «Deny» используется, когда сигнатур срабатывает, предполагая что не сигнатур из белый список были срабатывать для данного IP-адреса и/или данного CIDR, доступ к защищенной странице будет запрещен. «Deny» то что Вы хотите использовать на самом деле блокировать IP-адрес и/или диапазон CIDR. Когда какие-либо сигнатуры срабатывает которые используют «Deny», страница «Доступ Закрыт» из скрипт будет генерироваться и запрос на защищенной странице убит.
Значение [Параметр] принимаются с «Deny» будут обрабатываться на страницы для «Доступ Закрыт», поставляется клиенту/пользователю как цитируется причиной их доступа к запрашиваемой странице закрытия. Это может быть коротким и простым предложением, объясняя почему Вы выбрали чтобы блокировать их (что-нибудь должно хватить, даже простой „Я не хочу чтобы Ты на моем сайте“), или один из небольшой кучки сокращённых слов поставляемые из сценария, что если используется, будет заменен скриптом с предварительно подготовленной объяснения для почему клиент/пользователь был заблокирован.
Предварительно подготовленные объяснения имеют поддержку L10N и может быть переведен с помощью скриптом основанный на языке который Вы укажете в директиве lang для конфигурации скрипт. Дополнительно, Вы можете поручить скрипт игнорировать сигнатуры с «Deny» на основе их значение [Параметр] (если они используют эти сокращенные слова) с помощью директив определяется конфигурацией скриптом (каждая сокращенная слово имеет соответствующую директиву чтобы обрабатывать соответствующие сигнатуриь или игнорировать их). Значение [Параметр] которые не используют эти сокращенные слова, однако, не имеют поддержку L10N и поэтому не будет переведен с помощью скриптом, и дополнительно, непосредственно не контролируется с конфигурацией скрипт.
Доступные сокращенные слова:
- Attacks
- Bogon
- Cloud
- Generic
- Legal
- Malware
- Proxy
- Spam
Если Вы хотите разделить ваши собственные сигнатуры на отдельные секции, Вы можете идентифицировать эти отдельные секции к скрипт путем добавления «теги секций» сразу же после того как сигнатуры каждого секция, наряду с названием вашей сигнатур секция (смотрите пример ниже).
# Секция 1.
1.2.3.4/32 Deny Bogon
2.3.4.5/32 Deny Cloud
4.5.6.7/32 Deny Generic
5.6.7.8/32 Deny Spam
6.7.8.9/32 Deny Proxy
Tag: Секция 1Чтобы разорвать теги секций и для обеспечения что теги не идентифицированы неправильно для сигнатур секции от ранее в файлов сигнатур, просто убедитесь что есть по крайней мере два последовательных разрывы строк между тегом и ваших предыдущих сигнатур секции. Любые сигнатуры без тегов будут «IPv4» или «IPv6» в стандарта (в зависимости от того, какие типы сигнатур срабатывает).
1.2.3.4/32 Deny Bogon
2.3.4.5/32 Deny Cloud
4.5.6.7/32 Deny Generic
5.6.7.8/32 Deny Spam
Tag: Секция 1В приведенном выше примере, 1.2.3.4/32 и 2.3.4.5/32 будут помечены как «IPv4», в то время как 4.5.6.7/32 и 5.6.7.8/32 будут помечены как «Секция 1».
Та же логика может применяться и для разделения других типов тегов.
В частности, теги секций могут быть очень полезны для отладки при возникновении ложных срабатываний, обеспечивая легкое средство поиска точного источника проблемы, и может быть очень полезна для фильтрации записей в файле журнала при просмотре файлов журнала через фронтенд (имена секций можно щелкнуть по странице журналов фронтенд и их можно использовать в качестве критерия фильтрации). Если теги секций опущены для некоторых определенных сигнатурей, когда эти сигнатуры запускаются, CIDRAM использует имя файла сигнатуры вместе с типом заблокированного IP-адреса (IPv4 или IPv6) в качестве отказоустойчивый, и таким образом, теги секций полностью необязательны. В некоторых случаях они могут быть рекомендованы, например, когда файлы сигнатуры смутно названы или когда в противном случае может быть трудно четко идентифицировать источник сигнатурей, в результате чего запрос блокируется.
Если Вы хотите сигнатуры чтобы истекают через какое-то время, аналогичным способом к теги секций, Вы можете использовать «истечение теги» чтобы указать когда сигнатур должна перестать быть действительным. Истечение теги используют формат «ГГГГ.ММ.ДД» (смотрите пример ниже).
# Секция 1.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
Expires: 2016.12.31Истекшие сигнатуры никогда не будут инициироваться ни при каких запросах, несмотря ни на что.
Если Вы хотите указать страну происхождения для какой-либо определенной сигнатуры, вы можете сделать это, используя «тег происхождения». Тег происхождения принимает код «ISO 3166-1 Alpha-2», соответствующий стране происхождения для сигнатурей, к которым он относится. Эти коды должны быть написаны в верхнем регистре (в нижнем или смешанном случае не будут отображаться правильно). Когда используется тег происхождения, он добавляется в запись поля «Почему Заблокированные» для любых запросов, заблокированных в результате сигнатурей, к которым применяется тег.
Если установлен дополнительный компонент «flags CSS», при просмотре лог-файлов через страницу журналов фронтенд, информация, добавленная тегами происхождения, заменяется флагом страны, соответствующей этой информации. Эта информация, будь то в ее необработанном виде или в качестве флага страны, доступна для кликов, а при нажатии, будет фильтровать записи в журнале посредством других аналогичных идентификационных записей журнала (эффективно позволяя тем, кто обращается к странице журналов, фильтровать по стране происхождения).
Примечание: Технически это не какая-либо форма геолокации, из-за чего она не предполагает поиска какой-либо конкретной информации, относящейся к входящим IP-адресам, а скорее просто позволяет нам явно указать страну происхождения для любых запросов, заблокированных конкретными сигнатурами. В одном секция сигнатуры допустимы несколько тегов происхождения.
Гипотетический пример:
1.2.3.4/32 Deny Generic
Origin: CN
2.3.4.5/32 Deny Generic
Origin: FR
4.5.6.7/32 Deny Generic
Origin: DE
6.7.8.9/32 Deny Generic
Origin: US
Tag: FoobarЛюбые теги могут использоваться совместно, и все теги являются необязательными (смотрите пример ниже).
# Пример Секция.
1.2.3.4/32 Deny Generic
Origin: US
Tag: Пример Секция
Expires: 2016.12.31Когда большое количество файлов сигнатур установлено и активно используется, инсталляция могут стать довольно сложными, и могут быть некоторые сигнатуры, которые перекрываются. В этих случаях для предотвращения включения нескольких перекрывающихся сигнатурей во время блочных событий, отложенные теги могут использоваться для отсрочки определенных секция сигнатуры в случаях, когда установлен и активно используется какой-либо другой файл сигнатур. Это может быть полезно в случаях, когда некоторые сигнатуры обновляются чаще других, чтобы отложить менее часто обновляемые сигнатуры в пользу более часто обновляемых сигнатурей.
Отложенные теги используются аналогично другим типам тегов. Значение тега должно соответствовать установленному и активно используемому файлу сигнатуры, от которого будет отложено.
Пример:
1.2.3.4/32 Deny Generic
Origin: AA
2.3.4.5/32 Deny Generic
Origin: BB
Defers to: preferred_signatures.datТеги профиля позволяют отображать дополнительную информацию на тестовой странице IP и могут использоваться модулями и вспомогательными правилами для более сложного поведения и принятия точных решений.
Теги профиля используются так же, как и другие типы тегов. Значения тегов профиля могут использоваться как условие для модулей и вспомогательных правил. Теги профиля могут предоставлять несколько значений, разделяя их точкой с запятой. Конечный пользователь никогда не видит значения тегов профиля.
Пример:
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
Profile: Example;Just some generic stuff;Foo;Bar
Origin: BBУпрощенная форма маркап YAML может быть использован в сигнатур файлы для целей определения поведения и установок специфичные для отдельных сигнатур секций. Это может быть полезно если Вы хотите чтобы значение ваших директив конфигурации отличаться на основе индивидуальных сигнатур и сигнатур секций (например; если Вы хотите чтобы предоставить адрес электронной почты для поддержки билетов для любых пользователей что заблокированных с помощью один специфична сигнатур, но не хотите чтобы предоставить адрес электронной почты для поддержки билетов для пользователей что заблокированных с помощью любых других сигнатур; если Вы хотите чтобы некоторые специфический сигнатур чтобы вызвать страницу перенаправления; если Вы хотите чтобы отметить секция сигнатур для использования с reCAPTCHA/hCAPTCHA; если Вы хотите чтобы войти блокировал попытки доступа к отдельным файлам на основе индивидуальных сигнатурей и/или сигнатур секций).
Применение маркап YAML в файлов сигнатур совершенно не обязательно (то есть, Вы можете использовать его, если Вы хотите сделать это, но Вы не обязаны делать это), и способен использовать большинство (но не все) директивы конфигурации.
Заметка: Имплементация в CIDRAM для маркап YAML очень упрощенно и очень ограничено; Это предназначен для выполнения требований конкретных для CIDRAM таким образом что имеет знакомство с маркап YAML, но не следует ни соответствует официальным спецификациям (и поэтому не будет вести себя так же как более тщательный имплементации в другом месте, и может не подходить для других проектов в другом месте).
В CIDRAM, сегменты маркап YAML определены для скрипт с тремя черточками („---“), и заканчиваются вместе со содержащими сигнатур секций с разрывы строк двойной. Типичный сегмент маркап YAML в сигнатуры секция состоит из трех черточек на строка сразу же после того как список CIDR и любые теги, с последующим двухмерной списка пары ключ-значение (первое измерение, категории директива конфигурации; второе измерение, директива конфигурации) для которых директивы конфигурации должны быть изменены (и какие ценности) всякий раз когда сигнатуры в этом сигнатур секция срабатывании (см ниже примеры).
# Foobar 1.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
4.5.6.7/32 Deny Generic
Tag: Foobar 1
---
general:
http_response_header_code: 403
emailaddr: username@domain.tld
logging:
standard_log: "logfile.{yyyy}-{mm}-{dd}.txt"
apache_style_log: "access.{yyyy}-{mm}-{dd}.txt"
serialised_log: "serial.{yyyy}-{mm}-{dd}.txt"
recaptcha:
lockip: false
lockuser: true
expiry: 720
recaptcha_log: "recaptcha.{yyyy}-{mm}-{dd}.txt"
enabled: true
template_data:
css_url: "https://domain.tld/cidram.css"
# Foobar 2.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
4.5.6.7/32 Deny Generic
Tag: Foobar 2
---
general:
http_response_header_code: 503
logging:
standard_log: "logfile.Foobar2.{yyyy}-{mm}-{dd}.txt"
apache_style_log: "access.Foobar2.{yyyy}-{mm}-{dd}.txt"
serialised_log: "serial.Foobar2.{yyyy}-{mm}-{dd}.txt"
# Foobar 3.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
4.5.6.7/32 Deny Generic
Tag: Foobar 3
---
general:
http_response_header_code: 403
silent_mode: "http://127.0.0.1/"Когда «usemode» является 2 или 5, чтобы «специально отметить» сигнатур секций для использования с reCAPTCHA/hCAPTCHA, запись включается в сегменте YAML для этого секция сигнатуры (смотрите пример ниже).
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
Tag: CAPTCHA Marked
---
recaptcha:
enabled: true
hcaptcha:
enabled: trueК тому же, если Вы хотите CIDRAM полностью игнорировать некоторые конкретные секций в любой из сигнатур файлы, Вы можете использовать файл ignore.dat чтобы указать какие секций игнорировать. На новой строка, писать Ignore, а затем пробел, а затем название секций что Вы хотите CIDRAM игнорировать (смотрите пример ниже).
Ignore Секция 1Это также может быть достигнуто с помощью интерфейса, предоставленного на странице «списка секций» на фронтенд в CIDRAM.
Если Вы считаете, что писать собственные файлы сигнатуры или настраиваемые модули слишком сложны для вас, более простой альтернативой может быть использование интерфейса, предоставляемого страницей «вспомогательных правил» на фронтенде CIDRAM. Выбрав соответствующие параметры и указав детали о конкретных типах запросов, вы можете указать CIDRAM, как реагировать на эти запросы. «Вспомогательные правила» выполняются после того, как все файлы сигнатур и модули уже завершены.
Модули могут использоваться для расширения функциональности CIDRAM, выполнения дополнительных задач, или обработки дополнительной логики.
Из-за того что модули написаны в виде файлов PHP, если Вы хорошо знакомы с кодовой базой CIDRAM, Вы можете структурировать свои модули, и писать свои сигнатуры модуля, как Вы хотите (в рамках того, что возможно с PHP).
Заметка: Если вам неудобно работать с кодом PHP, писать собственные модули не рекомендуется.
Некоторые функции предоставляются CIDRAM для использования модулей, что упрощает создание собственных модулей. Информация об этой функциональности описана ниже.
Сигнатуры модулей обычно пишутся с помощью $this->trigger. В большинстве случаев это method будет более важным, чем что-либо еще для написания модулей.
$this->trigger принимает 4 параметра: $Condition, $ReasonShort, $ReasonLong (необязательно), и $DefineOptions (необязательно).
Оценивается правдоподобность $Condition, и если «true», сигнатур «срабатывает». Если «false», сигнатур не «срабатывает». $Condition обычно содержит PHP-код для оценки состояния, которое должно вызвать блокировку запроса.
$ReasonShort указывается в поле «Почему Заблокированные», когда сигнатур «срабатывает».
$ReasonLong – Это необязательное сообщение, которое будет отображаться пользователю/клиенту, когда они заблокированы, чтобы объяснить, почему они были заблокированы. По умолчанию используется стандартное сообщение «Доступ Закрыт» при его отсутствии.
$DefineOptions – Это необязательный массив, содержащий пары ключ/значение, используемые для определения параметров конфигурации, специфичных для инстанция запроса. Параметры конфигурации будут применены, когда сигнатур будет срабатывает.
$this->trigger возвращает «true», когда сигнатур «срабатывает», а когда нет, «false».
Байпасы сигнатуры обычно пишутся с помощью $this->bypass.
$this->bypass принимает 3 параметра: $Condition, $ReasonShort, и $DefineOptions (необязательно).
Оценивается правдоподобность $Condition, и если «true», сигнатур «срабатывает». Если «false», байпас не «срабатывает». $Condition обычно содержит PHP-код для оценки состояния, которое не должно вызвать блокировку запроса.
$ReasonShort указывается в поле «Почему Заблокированные», когда байпас «срабатывает».
$DefineOptions – Это необязательный массив, содержащий пары ключ/значение, используемые для определения параметров конфигурации, специфичных для инстанция запроса. Параметры конфигурации будут применены, когда байпас будет срабатывает.
$this->bypass возвращает «true», когда байпас «срабатывает», а когда нет, «false».
Это можно использовать для получения имени хоста IP-адреса. Если Вы хотите создать модуль для блокирования имен хостов, это закрытие может быть полезно.
Пример:
<?php
/** Fetch hostname. */
if (empty($this->CIDRAM['Hostname'])) {
$this->CIDRAM['Hostname'] = $this->dnsReverse($this->BlockInfo['IPAddr']);
}
/** Example signature. */
if (strlen($this->CIDRAM['Hostname']) && $this->CIDRAM['Hostname'] !== $this->BlockInfo['IPAddr']) {
$this->trigger($this->CIDRAM['Hostname'] === 'www.foobar.tld', 'Foobar.tld', 'Hostname Foobar.tld is not allowed.');
}Модули выполняются в пределах своей собственной области действия, а любые переменные, определенные модулем, не будут доступны для других модулей, или родительскому скрипту, если они не хранятся в массиве $CIDRAM (все остальное очищается после завершения выполнения модуля).
Ниже перечислены некоторые общие переменные, которые могут быть полезны для вашего модуля:
| Переменная | Описание |
|---|---|
$this->BlockInfo['DateTime'] |
Текущая дата и время. |
$this->BlockInfo['IPAddr'] |
IP-адрес для текущего запроса. |
$this->BlockInfo['ScriptIdent'] |
Версия сценария CIDRAM. |
$this->BlockInfo['Query'] |
Запрос текущего запроса. |
$this->BlockInfo['Referrer'] |
Ссылка для текущего запроса (если таковая существует). |
$this->BlockInfo['UA'] |
Пользовательский агент для текущего запроса. |
$this->BlockInfo['UALC'] |
Пользовательский агент для текущего запроса (в нижнем регистре). |
$this->BlockInfo['ReasonMessage'] |
Сообщение, которое будет отображаться пользователю/клиенту для текущего запроса, если они заблокированы. |
$this->BlockInfo['SignatureCount'] |
Количество сигнатурей, инициированных для текущего запроса. |
$this->BlockInfo['Signatures'] |
Справочная информация для любых сигнатур, инициированных для текущего запроса. |
$this->BlockInfo['WhyReason'] |
Справочная информация для любых сигнатур, инициированных для текущего запроса. |
Было обнаружено, что следующие пакеты и продукты несовместимы с CIDRAM:
Модули были доступны для обеспечения совместимости следующих пакетов и продуктов с CIDRAM:
Смотрите также: Графики Совместимости.
- Что такое «сигнатур»?
- Что такое «CIDR»?
- Что такое «ложноположительный»?
- Может CIDRAM блокировать целые страны?
- Как часто обновляются сигнатуры?
- Я столкнулся с проблемой при использовании CIDRAM, и я не знаю, что с этим делать! Пожалуйста помоги!
- Я заблокирован CIDRAM с веб-сайта, который я хочу посетить! Пожалуйста помоги!
- Я хочу использовать CIDRAM v3 с версией PHP ниже 7.2; Вы можете помочь?
- Могу ли я использовать одну установку CIDRAM для защиты нескольких доменов?
- Я не хочу возиться с установкой этого и заставить его работать с моим сайтом; Могу я просто заплатить вам за все это?
- Могу ли я нанять вас или любого из разработчиков этого проекта для частной работы?
- Мне нужны модификации специалиста, настройки и т.д.; Вы можете помочь?
- Я разработчик, веб-дизайнер, или программист. Могу ли я принять или предложить работу, связанную с этим проектом?
- Я хочу внести свой вклад в проект; Я могу сделать это?
- Могу ли я использовать cron для автоматического обновления?
- Что такое «нарушения»?
- Может ли CIDRAM блокировать имена хостов?
- Что я могу использовать для «default_dns»?
- Могу ли я использовать CIDRAM для защиты других вещей, помимо веб-сайтов (например, серверов электронной почты, FTP, SSH, IRC и т.д.)?
- Будут ли возникать проблемы, если я буду использовать CIDRAM одновременно с использованием CDN или кэширования?
- Будет ли CIDRAM защищать мой сайт от атак DDoS?
- Когда я активирую или деактивирую модули или файлы сигнатуры на странице обновлений, он сортирует их по алфавиту в конфигурации. Могу ли я изменить способ сортировки?
- Что такое «PDO DSN»? Как я могу использовать PDO с CIDRAM?
- CIDRAM блокирует cronjobs; Как это исправить?
В контексте CIDRAM, «сигнатур» относится к данным, которые служат индикатора/идентификатора, для чего-то конкретного что мы ищем, обычно IP-адрес или CIDR, и включает в себя некоторые инструкции для CIDRAM, говоря это лучший способ ответить когда сталкивается с тем что мы ищем. Типичная сигнатур для CIDRAM выглядит примерно так:
Для «файлов сигнатуры»:
1.2.3.4/32 Deny Generic
Для «модули»:
$this->trigger(strpos($this->BlockInfo['UA'], 'Foobar') !== false, 'Foobar-UA', 'User agent "Foobar" not allowed.');Заметка: Сигнатуры для «файлов сигнатуры» и сигнатуры для «модули» – Это не одно и то же.
Часто (но не всегда), сигнатуры будут объединены в группы, Формирование «сигнатур секций», часто сопровождается комментариями, маркуп, и/или связанные метаданные, которые могут быть использованы для обеспечения дополнительного контекста для сигнатуры и/или дальнейшей инструкции.
«CIDR» является акронимом для «Classless Inter-Domain Routing» („Бесклассовая адресация“) [1, 2], и это акроним, который используется как часть имени этого пакета, «CIDRAM», который является акронимом для «Classless Inter-Domain Routing Access Manager» („Бесклассовая Адресация Доступа Менеджер“).
Однако, в контексте CIDRAM (таких как, в этой документации, в рамках обсуждений касающихся CIDRAM, или в данных языка CIDRAM), когда «CIDR» (единственное число) или «CIDRы» (множественное число) упоминается (и поэтому, посредством чего мы используем эти слова как существительные в своем собственном праве, в отличие от акронимов), наш смысл и намерение: Подсеть (или подсетей), выраженные с использованием нотации CIDR. Причина по которой CIDR (или CIDRы) используется вместо подсети (или подсетей): Чтобы уточнить, что это специально подсети, выраженные с использованием нотации CIDR, которая ссылается на (потому нотации CIDR только один из нескольких способов, которыми подсети могут быть выражены). Поэтому CIDRAM можно считать «подсети доступа менеджер».
Хотя это двойное значение «CIDR» может представлять некоторую двусмысленность в некоторых случаях, это объяснение, наряду с предоставленным контекстом, должен помочь решить такую двусмысленность.
Термин «ложноположительный» (альтернативно: «ложноположительными ошибка»; «ложная сигнализация»; Английский: false positive; false positive error; false alarm), описал очень просто, и в обобщенном контексте, используется при проверке условия, для ссылаясь на результаты этого теста, когда результаты будут положительный (то есть, условия определяется будут «положительный», или «истинно»), но как ожидается будет (или должно было) отрицательный (то есть, условие, в действительности, является «отрицательный», или «ложно»). Термин «ложноположительный» можно было бы считать аналогом «плачет волк» (английский идиома в которой условие проверяется является ли там волк возле стада, условие является «ложно» в том, что нет никакого волка возле стада, и условие сообщается «положительный» посредством пастух путем кричать «волк, волк»), или аналогично ситуации в медицинском тестировании в которой пациент диагностирован как какую-то болезнь, когда в действительности, у них нет болезни.
Связанные результаты при проверке условия можно описать с использование терминов «истинноположительный», «истинноотрицательный» и «ложноотрицательный». «Истинноположительный» описывает когда результаты испытаний и фактическое состояние условия оба являются истинными (или положительные), и «истинноотрицательный» описывает когда результаты испытаний и фактическое состояние условия оба являются ложными (или отрицательные); «Истинноположительный» или «истинноотрицательный» рассматриваются как «правильный вывод». Противоположностью «ложноположительный» является «ложноотрицательный»; «Ложноотрицательный» описывает когда результаты испытаний отрицательные (то есть, условие определяется как отрицательные, или ложными), но как ожидается будет (или должно было) положительные (то есть, условие, в действительности, является «положительный», или «истинно»).
В контексте CIDRAM, эти термины относятся к сигнатур CIDRAM и что/кого они блокируют. Когда CIDRAM блокирует IP-адрес из-за плохой, устаревшей или неправильной сигнатур, но не должно быть сделано, или когда он делает это по неправильным причинам, мы называем это событие как «ложноположительный». Когда CIDRAM не удается блокировать IP-адрес, который должен был быть заблокированы, из-за непредвиденных угроз, недостающие сигнатур или недостатки в своих сигнатурей, мы называем это событие как «обнаружение не удалось» (аналогична «ложноотрицательный»).
Это может быть суммированы в таблице ниже:
| CIDRAM НЕ должны блокировать IP-адрес | CIDRAM ДОЛЖНЫ блокировать IP-адрес | |
|---|---|---|
| CIDRAM НЕ блокирует IP-адрес | Истинноотрицательный (правильный вывод) | Обнаружение не удалось (аналогична ложноотрицательный) |
| CIDRAM ДЕЛАЕТ блокирует IP-адрес | Ложноположительный | Истинноположительный (правильный вывод) |
Да. Самый простой способ сделать это - Установить модуль BGPView и настроить его в соответствии с вашими потребностями.
Частота обновления зависит от файлов сигнатур. Предпринята попытка обновить файлов сигнатур в максимально возможной степени, но, потому всех нас есть различные другие обязательства, наша жизнь вне проекта, и мы не получаем материальной компенсации (т.е., оплата) за наши усилия по проекту, точный график обновления не может быть гарантирован. В общем, обновления происходят, когда есть время, и мы стараемся расставить приоритеты на основе необходимости и частота изменения между диапазонами. Помощь всегда приветствуется, если Вы готовы предложить любую.
Я столкнулся с проблемой при использовании CIDRAM, и я не знаю, что с этим делать! Пожалуйста помоги!
- Используете ли Вы последнюю версию программного обеспечения? Используете ли Вы последние версии ваших файлов сигнатуры? Если ответ на любой из этих двух вопросов отрицательный, попробуйте сначала обновить все, и попытайтесь решить проблема. Если оно сохраняется, продолжайте чтение.
- Вы проверили всю документацию? Если нет, сделайте это. Если проблема не может быть решена с помощью документации, продолжите чтение.
- Вы проверили странице «issues», чтобы узнать упоминалась ли эта проблема ранее? Если это было уже упоминалось, проверить были ли предоставлены какие-либо предложения, идеи и/или решения, и следуйте по необходимости чтобы попытаться решить проблема.
- Если проблема не решена, пожалуйста, обратитесь за помощью, создав новую «issue» на странице «issues».
CIDRAM предоставляет владельцам веб-сайтов возможность блокировать нежелательный трафик, но владельцы веб-сайтов обязаны сами решать, как они хотят использовать CIDRAM. В случае ложноположительный, файлами сигнатуры обычно включается в CIDRAM, поправки могут быть сделаны, но в отношении того чтобы быть разблокированным с определенных веб-сайтов, Вам необходимо связаться с владельцами этих веб-сайтов. В случаях когда исправления сделаны, по крайней мере, они должны будут обновить свои файлов сигнатур и/или инсталляция, и в других случаях (таких как, например, когда они есть модифицировал свою инсталляция, создали свои собственные сигнатуры, и т.д.), ответственность за решение вашей проблемы полностью принадлежит им, и полностью вне нашего контроля.
Нет. PHP≥7.2 является минимальным требованием для CIDRAM v3.
Смотрите также: Графики Совместимости.
Да. CIDRAM инсталляций не привязаны к определенным домены, и поэтому может использоваться для защиты нескольких доменов. В общем, мы ссылаемся на CIDRAM инсталляций, защищающие только один домен, как «однодоменные инсталляций», и мы ссылаемся на CIDRAM инсталляций, защищающие несколько доменов и/или поддоменов, как «многодоменные инсталляций». Если Вы используете многодоменную инсталляция, и необходимо использовать разные файлы сигнатур для разных доменов, или необходимо настроить CIDRAM по-разному для разных доменов, это можно сделать. После загрузки файла конфигурации (config.yml), CIDRAM проверит наличие «файл переопределения конфигурации» специфичные для запрашиваемого домена или поддомена (xn----7sbaabjijgdno9cdqkbchu3o.tld.config.yml), и если он будет найден, любые значений конфигурации, определенные в файл переопределения конфигурации, будет использоваться для экземпляра выполнения вместо значений конфигурации, определенных конфигурационным файлом. Конфигурация переопределяет файлы, идентичные конфигурационному файлу, и на Ваше усмотрение, Может содержать все директивы конфигурации, доступные для CIDRAM, или какой бы небольшой подсекция требуется, при необходимости. Имена для конфигурация переопределяет файлов соответствуют домену для которого они предназначены (так, например, если Вам нужен файл переопределения конфигурации для домена, https://www.some-domain.tld/, его файл переопределения конфигурации должен иметь имя some-domain.tld.config.yml, и должен быть помещен в vault, вместе с файлом конфигурации, config.yml). Доменные имена извлекаются из заголовка HTTP_HOST запроса; «www» игнорируется.
Я не хочу возиться с установкой этого и заставить его работать с моим сайтом; Могу я просто заплатить вам за все это?
Может быть. Это рассматривается в каждом конкретном случае. Расскажите, что вам нужно, что Вы предлагаете, и мы расскажем вам, можем ли мы помочь.
См. Выше.
См. Выше.
Я разработчик, веб-дизайнер, или программист. Могу ли я принять или предложить работу, связанную с этим проектом?
Да. Наша лицензия не запрещает это.
Да. Вклады в проект очень приветствуются. Для получения дополнительной информации см. «CONTRIBUTING.md».
Да. API встроен в фронтенд для взаимодействия со обновления страница через внешние скрипты. Имеется отдельный скрипт: «Cronable». Он может использоваться вашим cron manager или cron scheduler для автоматического обновления этого и других поддерживаемых пакетов (этот скрипт предоставляет собственную документацию).
«Количество сигнатурей» и «нарушений» относятся к серьезности и количеству сигнатурей, запущенных во время любого конкретного запроса, будь то из-за файлов сигнатурей, модулей, вспомогательных правил, или иным образом, но в то время как «количество сигнатурей» сохраняется только для этого конкретного запроса, «нарушений» могут сохраняться для любого количества запросов, пока это определяется default_tracktime.
Это обеспечивает механизм, гарантирующий, что запросы из потенциально опасных источников могут быть заблокированы при вторичных запросах из любого конкретного такого источника, при уже заблокирован во время предыдущего запроса с достаточным количеством нарушений.
Да. Этого можно добиться, создав вспомогательное правило или пользовательский модуль.
Как правило, IP-адрес любого надежного DNS-сервера должен быть достаточным. Если вы ищете предложения, public-dns.info и OpenNIC предоставляют обширные списки известных общедоступных DNS-серверов. В качестве альтернативы см. таблицу ниже:
| IP | Оператор |
|---|---|
1.1.1.1 |
Cloudflare |
8.8.4.48.8.8.82001:4860:4860::88442001:4860:4860::8888 |
Google Public DNS |
9.9.9.9149.112.112.112 |
Quad9 DNS |
84.200.69.8084.200.70.402001:1608:10:25::1c04:b12f2001:1608:10:25::9249:d69b |
DNS.WATCH |
208.67.220.220208.67.222.220208.67.222.222 |
OpenDNS Home |
77.88.8.177.88.8.82a02:6b8::feed:0ff2a02:6b8:0:1::feed:0ff |
Yandex.DNS |
8.20.247.208.26.56.26 |
Comodo Secure DNS |
216.146.35.35216.146.36.36 |
Dyn |
64.6.64.664.6.65.6 |
Verisign Public DNS |
37.235.1.17437.235.1.17745.33.97.5172.104.237.57172.104.49.100 |
FreeDNS |
156.154.70.1156.154.71.12610:a1:1018::12610:a1:1019::1 |
Neustar Security |
45.32.36.3645.77.165.194 |
Fourth Estate |
74.82.42.42 |
Hurricane Electric |
195.46.39.39195.46.39.40 |
SafeDNS |
89.233.43.7191.239.100.100 2001:67c:28a4::2a01:3a0:53:53:: |
UncensoredDNS |
208.76.50.50208.76.51.51 |
SmartViper |
Заметка: Я не предъявляю никаких претензий или гарантий относительно практики конфиденциальности, безопасности, эффективности и надежности любых DNS-сервисов, перечисленных или иным образом. Пожалуйста, сделайте собственное исследование, когда принимаете решения о них.
Могу ли я использовать CIDRAM для защиты других вещей, помимо веб-сайтов (например, серверов электронной почты, FTP, SSH, IRC и т.д.)?
Вы можете (юридически), но не должны (технически; практически). Наша лицензия не ограничивает какие технологии используют CIDRAM, но CIDRAM является WAF (брандмауэром веб-приложений) и всегда предназначался для защиты веб-сайтов. Поскольку он не был разработан с учетом других технологий, он вряд ли будет эффективным или обеспечит надежную защиту других технологий, реализация, вероятно, будет сложной, и риск ложноположительный и пропущенных обнаружений очень высок.
Будут ли возникать проблемы, если я буду использовать CIDRAM одновременно с использованием CDN или кэширования?
Возможно. Это зависит от характера рассматриваемой услуги и того, как вы ее используете. Как правило, если вы только кэшируете статические активы (изображения, CSS, и т.д.; все, что обычно не меняется со временем), проблем не должно быть. Однако могут возникнуть проблемы, если вы кэшируете данные, которые в противном случае обычно генерировались бы динамически при запросе, или если вы кэшируете результаты запросов POST (это по существу сделает ваш сайт и его среду обязательным статическим, и CIDRAM вряд ли обеспечит какую-либо значимую выгоду в обязательной статической среде). Также могут быть особые требования к конфигурации для CIDRAM, в зависимости от того какой CDN или кэширующий сервис вы используете (вам необходимо убедиться, что CIDRAM настроен правильно для конкретной службы CDN или кэширования, которую вы используете). Неправильное конфигурирование CIDRAM может привести к значительно проблематичным ложным срабатываниям и пропущенным обнаружениям.
Краткий ответ: Нет.
Чуть более длинный ответ: CIDRAM поможет уменьшить влияние нежелательного трафика на ваш сайт (таким образом снижая затраты на пропускную способность вашего веб-сайта), поможет уменьшить влияние нежелательного трафика на ваше оборудование (например, способность вашего сервера обрабатывать и обслуживать запросы), и может помочь уменьшить различные другие потенциальные негативные последствия, связанные с нежелательным трафиком. Однако для понимания этого вопроса необходимо помнить две важные вещи.
Во-первых, CIDRAM является пакетом PHP и, следовательно, работает на компьютере, где установлен PHP. Это означает, что CIDRAM может видеть и блокировать запрос только после того, как сервер уже получил его. Во-вторых, эффективное смягчение DDoS должно отфильтровывать запросы до того, как они достигнут сервера, на который нацелена атака DDoS. В идеале, атаки DDoS должны быть обнаружены и смягчены решениями, способными отбрасывать или перенаправлять трафик, связанный с атаками, прежде чем он достигнет целевого сервера в первую очередь.
Это может быть реализовано с использованием специализированных, локальных аппаратных решений, и/или облачные решения, такие как специализированные службы смягчения DDoS, маршрутизация DNS домена через сети, устойчивые к DDoS, облачная фильтрация, или их комбинацию. В любом случае, этот предмет слишком сложный, чтобы подробно объяснить всего лишь параграф или два, поэтому я бы рекомендовал продолжить исследования, если это предмет, который вы хотите продолжить. Когда истинный характер атак DDoS будет правильно понят, этот ответ будет иметь больше смысла.
Когда я активирую или деактивирую модули или файлы сигнатуры на странице обновлений, он сортирует их по алфавиту в конфигурации. Могу ли я изменить способ сортировки?
Да. Если вам нужно заставить некоторые файлы выполнить в определенном порядке, вы можете добавить некоторые произвольные данные до их имен в директиве конфигурации, где они указаны, разделенные двоеточием. Когда страница обновлений впоследствии сортирует файлы снова, эти добавленные произвольные данные будут влиять на порядок сортировки, в результате чего они должны выполняться в том порядке, в котором вы хотите, без необходимости переименовывать их.
Например, предполагая конфигурационную директиву с файлами, перечисленными ниже:
modules: |
file1.php
file2.php
file3.php
file4.php
file5.phpЕсли вы хотите, чтобы file3.php выполнялся первым, вы могли бы добавить что-то вроде aaa: перед именем файла:
modules: |
file1.php
file2.php
aaa:file3.php
file4.php
file5.phpЗатем, если новый файл, file6.php, активирован, когда страница обновлений снова сортирует их все, это должно закончиться следующим образом:
modules: |
aaa:file3.php
file1.php
file2.php
file4.php
file5.php
file6.phpТакая же ситуация, когда файл деактивирован. Наоборот, если вы хотите, чтобы файл выполнялся последним, вы могли бы добавить что-то вроде zzz: перед именем файла. В любом случае вам не нужно будет переименовывать указанный файл.
«PDO» является акроним для «PHP Data Objects» (объектов данных PHP). Он предоставляет интерфейс для PHP, чтобы иметь возможность подключаться к некоторым системам баз данных, обычно используемым различными приложениями PHP.
«DSN» является акроним для «data source name» (имени источника данных). «PDO DSN» описывает как PDO должен подключаться к базе данных.
CIDRAM предоставляет возможность использовать PDO для целей кэширования. Чтобы это работало должным образом, вам необходимо соответствующим образом настроить CIDRAM, включив PDO, создать новую базу данных для CIDRAM использовать (если вы еще не имеете в виду базу данных для CIDRAM использовать), и создать новую Таблица в вашей базе данных в соответствии со структурой, описанной ниже.
Когда соединение с базой данных успешно, но необходимая таблица не существует, автоматическое создание таблицы будет предпринято. Тем не менее, это поведение не было тщательно проверено, и успех не может быть гарантирован.
Это, конечно, применимо, только если вы действительно хотите, чтобы CIDRAM использовал PDO. Если вы достаточно довольны тем, что CIDRAM использует кэширование плоских файлов (в соответствии с его конфигурацией по умолчанию) или любые другие предоставляемые опции кэширования, вам не нужно беспокоиться о настройке баз данных, таблиц, и т.д.
Структура, описанная ниже, использует «cidram» в имени базы данных, но вы можете использовать любое имя, которое вы хотите для своей базы данных, при условии, что это же имя реплицируется в конфигурации DSN.
╔══════════════════════════════════════════════╗
║ DATABASE "cidram" ║
║ │╔═══════════════════════════════════════════╩═════╗
║ └╫─TABLE "Cache" (UTF-8) ║
║ ╠═╪═FIELD══CHARSET═DATATYPE═════KEY══NULL═DEFAULT═╣
║ ║ ├─"Key"──UTF-8───VARCHAR(128)─PRI──×────× ║
║ ║ ├─"Data"─UTF-8───TEXT─────────×────×────× ║
╚══╣ └─"Time"─×───────INT(>=10)────×────×────× ║
╚═════════════════════════════════════════════════╝Директива конфигурации CIDRAM pdo_dsn должна быть настроена, как описано ниже.
Согласно базе данных драйвер используется...
├─4d (Предупреждение: экспериментально, не проверено, не рекомендуется!)
│ │
│ │ ╔═══════╗
│ └─4D:host=localhost;charset=UTF-8
│ ╚╤══════╝
│ └Хост, с которым нужно связаться, чтобы найти базу данных.
├─cubrid
│ │
│ │ ╔═══════╗ ╔═══╗ ╔═════╗
│ └─cubrid:host=localhost;port=33000;dbname=example
│ ╚╤══════╝ ╚╤══╝ ╚╤════╝
│ │ │ └Имя базы данных для
│ │ │ использования.
│ │ │
│ │ └Номер порта для подключения к хосту.
│ │
│ └Хост, с которым нужно связаться, чтобы найти базу данных.
├─dblib
│ │
│ │ ╔═══╗ ╔═══════╗ ╔═════╗
│ └─dblib:host=localhost;dbname=example
│ ╚╤══╝ ╚╤══════╝ ╚╤════╝
│ │ │ └Имя базы данных для использования.
│ │ │
│ │ └Хост, с которым нужно связаться, чтобы найти базу данных.
│ │
│ └Возможные значения: «mssql», «sybase», «dblib».
├─firebird
│ │
│ │ ╔═══════════════════╗
│ └─firebird:dbname=/path/to/database.fdb
│ ╚╤══════════════════╝
│ ├Может быть путем к файлу локальной базы данных.
│ │
│ ├Может соединиться с хостом и номером порта.
│ │
│ └Вам следует обратиться к документации Firebird, если вы
│ хотите использовать это.
├─ibm
│ │
│ │ ╔═════╗
│ └─ibm:DSN=example
│ ╚╤════╝
│ └Каталогизированная база данных для связи.
├─informix
│ │
│ │ ╔═════╗
│ └─informix:DSN=example
│ ╚╤════╝
│ └Каталогизированная база данных для связи.
├─mysql (Наиболее рекомендуется!)
│ │
│ │ ╔═════╗ ╔═══════╗ ╔══╗
│ └─mysql:dbname=example;host=localhost;port=3306
│ ╚╤════╝ ╚╤══════╝ ╚╤═╝
│ │ │ └Номер порта для подключения к
│ │ │ хосту.
│ │ │
│ │ └Хост, с которым нужно связаться, чтобы найти
│ │ базу данных.
│ │
│ └Имя базы данных для использования.
├─oci
│ │
│ │ ╔═════╗
│ └─oci:dbname=example
│ ╚╤════╝
│ ├Может ссылаться на конкретную каталогизированную базу данных.
│ │
│ ├Может соединиться с хостом и номером порта.
│ │
│ └Вам следует обратиться к документации Oracle, если вы хотите
│ использовать это.
├─odbc
│ │
│ │ ╔═════╗
│ └─odbc:example
│ ╚╤════╝
│ ├Может ссылаться на конкретную каталогизированную базу данных.
│ │
│ ├Может соединиться с хостом и номером порта.
│ │
│ └Вам следует обратиться к документации ODBC/DB2, если вы хотите
│ использовать это.
├─pgsql
│ │
│ │ ╔═══════╗ ╔══╗ ╔═════╗
│ └─pgsql:host=localhost;port=5432;dbname=example
│ ╚╤══════╝ ╚╤═╝ ╚╤════╝
│ │ │ └Имя базы данных для использования.
│ │ │
│ │ └Номер порта для подключения к хосту.
│ │
│ └Хост, с которым нужно связаться, чтобы найти базу данных.
├─sqlite
│ │
│ │ ╔════════╗
│ └─sqlite:example.db
│ ╚╤═══════╝
│ └Путь к файлу локальной базы данных для использования.
└─sqlsrv
│
│ ╔═══════╗ ╔══╗ ╔═════╗
└─sqlsrv:Server=localhost,1521;Database=example
╚╤══════╝ ╚╤═╝ ╚╤════╝
│ │ └Имя базы данных для использования.
│ │
│ └Номер порта для подключения к хосту.
│
└Хост, с которым нужно связаться, чтобы найти базу данных.Если Вы не уверены, что использовать для какой-либо конкретной части вашего DSN, попробуйте сначала выяснить, работает ли она как есть, ничего не меняя.
Обратите внимание, что pdo_username и pdo_password должны совпадать с именем пользователя и паролем, которые Вы выбрали для своей базы данных.
Если Вы используете выделенный файл для целей cronjobs и если этот файл не нужно вызывать во время обычных пользовательских запросов (т.е., вне контекста cronjobs), убедиться, что CIDRAM вообще не выполняется во время ваших cronjobs (т.е., не подключайте CIDRAM к файлу, ответственному за обработку ваших cronjobs) – Это самый простой способ исправить это.
В качестве альтернативы, если это невозможно, но IP-адрес вашего сервера cron является относительно последовательным и предсказуемым, Вы можете попробовать занести в белый список IP-адрес вашего сервера cron, например, путем создания сигнатуры в индивидуальный файле сигнатуры, или путем создания вспомогательного правила. Если IP-адрес вашего сервера cron регулярно вращается и не особенно предсказуемо, но тем не менее остается внутри той же конкретной сети, Вы можете попробовать указать в своем файле ignore.dat имя раздела сигнатуры, ответственного за его блокировку.
Если Вы попробовали все эти идеи и ни одна из них не сработала для вас, или если вам нужна помощь, чтобы выяснить, как это сделать, Вы можете создать новую issue на странице issues CIDRAM, чтобы попросить о помощи.
Этот раздел документации предназначен для описания возможных юридических соображений, касающихся использования и имплементации пакета, и предоставления некоторой базовой связанной информации. Это может быть важно для некоторых пользователей в качестве средства обеспечения соответствия любым юридическим требованиям, которые могут существовать в странах, в которых они работают, и некоторым пользователям, возможно, придется корректировать свои политики веб-сайта в соответствии с этой информацией.
Прежде всего, поймите, что я (автор пакета) не квалифицированный юрист любого рода. Поэтому я не имею юридической силы для предоставления юридических консультаций. Кроме того, в некоторых случаях, точные законодательные требования могут различаться между различными странами и юрисдикциями, и эти различные юридические требования могут иногда противоречить (таких как, например, в случае стран, которые поддерживают права на неприкосновенность частной жизни, и право быть забытым, по сравнению с странами, которые предпочитают расширенное хранение данных). Учтите также, что доступ к пакету не ограничивается конкретными странами или юрисдикциями, и, следовательно, пользовательская база пакетов, вероятно, будет географически разнообразной. При рассмотрении этих вопросов, я не в состоянии заявить, что это означает быть «юридически совместимым» для всех пользователей, во всех отношениях. Однако я надеюсь, что приведенная здесь информация поможет вам самим принять решение о том, что вы должны сделать, чтобы оставаться юридически совместимым в контексте пакета. Если у вас есть какие-либо сомнения относительно информации, или если вам нужна дополнительная помощь и рекомендации с юридической точки зрения, Я бы рекомендовал обратиться к квалифицированному юристу.
В соответствии с уже заявленной лицензией на пакет, пакет предоставляется без каких-либо гарантий. Это включает (но не ограничивается) всю сферу ответственности. Пакет предоставляется вам для вашего удобства, в надежде, что он будет полезен, и что он принесет вам определенную пользу. Однако, независимо от того, используете ли вы или реализуете пакет, это ваш собственный выбор. Вы не обязаны использовать или внедрять пакет, но когда вы это делаете, вы несете ответственность за это решение. Ни я, ни другие участники пакета не несут юридическую ответственность за последствия решений, которые вы принимаете, независимо от того, являются ли они прямыми, косвенными, подразумеваемыми или нет.
В зависимости от его точной конфигурации и имплементации пакет может передавать и обмениваться информацией с третьими лицами в некоторых случаях. Эта информация может быть определена как «персональные данные» (PII/ПИИ) в некоторых контекстах, в некоторых юрисдикциях.
Как эта информация может использоваться этими третьими лицами, зависит от различных политик, установленных этими третьими лицами, и выходит за рамки этой документации. Однако, во всех таких случаях обмен информацией с этими третьими лицами может быть отключен. Во всех таких случаях, если вы решите включить его, вы несете ответственность за исследование любых проблем, которые могут возникнуть в отношении конфиденциальности, безопасности и использования PII/ПИИ этими третьими лицами. Если существуют какие-либо сомнения, или если вы неудовлетворены действиями этих третьих сторон в отношении PII/ПИИ, лучше всего отключить весь обмен информацией с этими третьими лицами.
В целях прозрачности тип информации, совместно используемой, и с кем, описан ниже.
Если вы используете какие-либо функции или модули, предназначенные для работы с именами хостов (например, "модуль блокатор для плохие хосты", "tor project exit nodes block module", или "проверка поисковой системы"), CIDRAM должен иметь возможность получить имя хоста входящих запросов. Как правило, он делает это, запрашивая имя хоста IP-адреса входящих запросов с DNS-сервера, или путем запроса информации через функциональные возможности, предоставляемые системой, где установлен CIDRAM (это обычно называют «поиском имени хоста»). DNS-серверы, определенные по умолчанию, принадлежат службе Google DNS (но это можно легко изменить с помощью конфигурации). Точные услуги, которые связаны с, зависят от конфигурации (это можно легко отрегулировать). В случае использования функциональных возможностей, предоставляемых системой, где установлен CIDRAM, вам необходимо обратиться к системному администратору, чтобы определить, какие поисковые запросы маршрутов используются. Поиск имени хоста можно предотвратить в CIDRAM, избегая затронутых модулей, или изменяя конфигурацию пакета в соответствии с вашими потребностями.
Соответствующие директивы конфигурации:
general->allow_gethostbyaddr_lookupgeneral->default_dnsgeneral->force_hostname_lookupverification->otherverification->search_enginesverification->social_media
Когда проверка поисковых систем включена, CIDRAM пытается выполнить «переадресацию DNS-запросов», чтобы проверить, являются ли запросы, утверждающие, что они происходят из поисковых систем, являются подлинными. По аналогии, когда включена проверка социальных сетей, CIDRAM делает то же самое для кажущихся запросов социальных сетях. Для этого он использует службу Google DNS для попытки разрешить IP-адреса из имен хостов этих входящих запросов (в этом процессе имена хостов этих запросов совместно используются службой).
Соответствующие директивы конфигурации:
verification->otherverification->search_enginesverification->social_media
CIDRAM поддерживает reCAPTCHA и hCAPTCHA. Для правильной работы им требуются ключи API. Стандартно они отключены, но их можно включить, настроив необходимые ключи API. При включении может происходить обмен данными между службой и CIDRAM или браузером пользователя. Это может потенциально включать передачу информации, такой как IP-адрес пользователя, пользовательский агент, операционная система, и другие детали, доступные для запроса.
Stop Forum Spam – Это фантастический бесплатный сервис, который может помочь защитить форумы, блоги и веб-сайты от спамеров. Он делает это, предоставляя базу данных известных спамеров и API, который может быть использован для проверки того, указан ли IP-адрес, имя пользователя или адрес электронной почты в его базе данных.
CIDRAM предоставляет необязательный модуль, который использует этот API для проверки того, принадлежит ли IP-адрес входящих запросов к подозреваемому спамеру. Когда модуль установлен и активирован, пользовательские IP-адреса могут использоваться совместно с сервисом в соответствии с конфигурацией и назначением модуля.
CIDRAM предоставляет необязательный модуль для блокировки оскорбительный IP-адресов с помощью API AbuseIPDB. Когда модуль установлен и активирован, пользовательские IP-адреса могут использоваться совместно с сервисом в соответствии с конфигурацией и назначением модуля.
CIDRAM предоставляет дополнительные модули для выполнения поиска ASN и кода страны с помощью BGPView API и IP-API API. Эти поиски предоставляют возможность блокировать или вносить в белый список запросы на основе их ASN или страны происхождения. Когда один из них установлен и активирован, пользовательские IP-адреса могут использоваться совместно с сервисом в соответствии с конфигурацией и назначением модуля.
CIDRAM предоставляет необязательный модуль для блокировки оскорбительный IP-адресов с помощью API Project Honeypot. Когда модуль установлен и активирован, пользовательские IP-адреса могут использоваться совместно с сервисом в соответствии с конфигурацией и назначением модуля.
Журналов (альтернативно: регистрация, логгинг) – Это важная часть CIDRAM по ряду причин. Может быть трудно диагностировать и разрешать ложные-срабатывания, когда события блока, вызывающие их, не регистрируются. Без регистрируются событий блока может быть трудно точно определить, насколько эффективная CIDRAM в любом конкретном контексте, и может быть трудно определить, где его недостатки могут быть, и какие изменения могут потребоваться для его конфигурации или сигнатуры соответственно, чтобы он продолжал функционировать по назначению. Несмотря на это, регистрация может быть нежелательна для всех пользователей и остается полностью необязательной. В CIDRAM регистрация по умолчанию отключена. Чтобы включить его, CIDRAM должен быть настроен соответствующим образом.
Дополнительно, ли ведение журнала разрешено законом, и в какой степени (например, типы информации, которые могут быть зарегистрированы, как долго, и при каких обстоятельствах), может варьироваться в зависимости от юрисдикции и контекста, в котором реализуется CIDRAM (например, если вы работаете как индивидуальный лицо, корпоративный лицо, если вы работаете на коммерческой или некоммерческой основе). Поэтому это может быть полезно для вас внимательно прочитать этот раздел.
CIDRAM может выполнять несколько типов ведения журнала. Различные типы ведения журнала включают различные типы информации по разным причинам.
Основной тип ведения журнала, который может выполнять CIDRAM, относится к «блочным событиям». Этот тип ведения журнала относится к тому, когда CIDRAM блокирует запрос, и может предоставляться в трех разных форматах:
- Человекочитаемые лог-файлы.
- Лог-файлы в стиле Apache.
- Сериализованные лог-файлы.
Событие блока, записанное в человекочитаемые лог-файлы, обычно выглядит примерно так (в качестве примера):
ИД: 1234
Скрипт Версия: CIDRAM v1.6.0
Дата/Время: Day, dd Mon 20xx hh:ii:ss +0000
IP-адрес: x.x.x.x
Имя хоста: dns.hostname.tld
Количество сигнатурей: 1
Идентификаторы для сигнатурей: x.x.x.x/xx
Почему Заблокированные: Облачный сервис ("Имя Сети", Lxx:Fx, [XX])!
Агент пользователя (User Agent): Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
Реконструированный URI: https://your-site.tld/index.php
Статус CAPTCHA: Включается.Это же событие блока, записанное в лог-файл в стиле Apache, будет выглядеть примерно так:
x.x.x.x - - [Day, dd Mon 20xx hh:ii:ss +0000] "GET /index.php HTTP/1.1" 200 xxxx "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36"Зарегистрированное событие блокировки обычно включает следующую информацию:
- Идентификационный номер, ссылающийся на событие блока.
- Версия используемой CIDRAM.
- Дата и время, когда произошло событие блока.
- IP-адрес заблокированного запроса.
- Имя хоста IP-адреса заблокированного запроса (если доступно).
- Количество сигнатурей, вызванных запросом.
- Ссылки на сигнатуры срабатывают.
- Ссылки на причины блочного события и некоторые основные связанные данные об отладке.
- Пользовательский агент заблокированного запроса (как запрашивающий объект идентифицировал себя с запросом).
- Реконструкция идентификатора запрашиваемого ресурса.
- Состояние CAPTCHA для текущего запроса (при необходимости).
Директивы конфигурации, отвечающие за этот тип ведения журнала, и для каждого из трех доступных форматов:
logging->apache_style_loglogging->serialised_loglogging->standard_log
Когда эти директивы остаются пустыми, этот тип ведения журнала останется отключенным.
Этот тип ведения журнала относится конкретно к экземплярам CAPTCHA и возникает только тогда, когда пользователь пытается завершить экземпляр CAPTCHA.
Запись журнала CAPTCHA содержит IP-адрес пользователя, пытающегося выполнить экземпляр CAPTCHA, дату и время, в которое произошла попытка, и состояние CAPTCHA. Запись журнала CAPTCHA обычно выглядит примерно так (в качестве примера):
IP-адрес: x.x.x.x - Дата/Время: Day, dd Mon 20xx hh:ii:ss +0000 - Статус CAPTCHA: Успех!Директива конфигурации, ответственная за ведение журнала CAPTCHA:
hcaptcha->hcaptcha_logrecaptcha->recaptcha_log
Этот тип ведения журнала связан с попытками входа в фронтенд и возникает только тогда, когда пользователь пытается войти в фронтенд (при условии, что фронтенд включен).
Эти записи журнала содержат IP-адрес пользователя, пытающегося войти в систему, дату и время совершения попытки, и результаты попытки (успешно вошел в систему или не смог войти в систему). Обычно они выглядят примерно так (в качестве примера):
x.x.x.x - Day, dd Mon 20xx hh:ii:ss +0000 - "admin" - Вошли в систему.Соответствующие директивы конфигурации:
frontend->frontend_log
Возможно, вы захотите очистить журналы через определенный промежуток времени или, возможно, потребуется сделать это по закону (то есть, количество времени, которое законно допустимо для вас сохранять журналы, может быть ограничено законом). Вы можете достичь этого, включив маркеры даты/времени в имена ваших файлов журналов в соответствии с настройками вашего пакета (например, {yyyy}-{mm}-{dd}.log), и затем разрешить вращение журнала (поворот журнала позволяет выполнять некоторые действия на лог-файлах при превышении указанных пределов).
Например: Если мне было необходимо закончить журналы через 30 дней, я мог бы указать {dd}.log в именах моих лог-файлов ({dd} представляет дни), установить значение log_rotation_limit в 30, и установить значение log_rotation_action в Delete.
И наоборот, если вам необходимо сохранять журналы в течение длительного периода времени, вы можете либо не использовать поворот журнала вообще, либо вы можете установить значение log_rotation_action в Archive, чтобы сжать лог-файлы, тем самым уменьшив общий объем занимаемого ими дискового пространства.
Соответствующие директивы конфигурации:
logging->log_rotation_actionlogging->log_rotation_limit
Также возможно обрезать отдельные лог-файлы, если они превышают определенный размер, если это то, что вы хотите/нуждаетесь сделать.
Соответствующие директивы конфигурации:
logging->truncate
Во-первых, если вы не знакомы с термином, «псевдонимизация» относится к обработке персональных данных таким образом, что она не может быть идентифицирована ни с каким конкретным объектом данных без дополнительной информации, и при условии, что такая дополнительная информация поддерживается отдельно и подлежит техническим и организационным мерам для обеспечения того, чтобы личные данные не могли быть идентифицированы ни одному физическому лицу.
В некоторых случаях вам может быть юридически требуется анонимизировать или псевдонимизировать любого PII/ПИИ, собранного, обработанного, или сохраненного. Хотя эта концепция существует уже довольно давно, GDPR/DSGVO особенно упоминает и специально поощряет «псевдонимизация».
CIDRAM может псевдонимизировать IP-адреса при входе в журналы, если это то, что вы хотите/нуждаетесь сделать. Когда CIDRAM псевдонимизирует IP-адреса, при входе в журналы, окончательный октет адресов IPv4, и все после второй части адресов IPv6 представлено символом «x» (эффективно округляя адреса IPv4 до начального адреса 24-й подсети, в которую они входят, и адреса IPv6 на начальный адрес 32-й подсети, в которую они входят).
Заметка: Процесс псевдонимизации IP-адреса в CIDRAM не влияет на функцию отслеживания IP-адресов в CIDRAM. Если это проблема для вас, лучше всего отключить IP-отслеживание.
Соответствующие директивы конфигурации:
legal->pseudonymise_ip_addresses
Если вы хотите сделать еще один шаг, не позволяя полностью регистрировать определенные типы информации, это также можно сделать. На странице конфигурации обратитесь к директиве конфигурации fields, чтобы контролировать, какие поля будут отображаться в записях журнала и на странице «Доступ Закрыт».
Заметка: Нет никаких оснований для псевдонимизировать IP-адресов при полном исключении их из журналов.
Соответствующие директивы конфигурации:
general->fields
CIDRAM необязательно может отслеживать статистику, такую как общее количество событий блока или экземпляров CAPTCHA, которые произошли с определенного момента времени. Эта функция отключена по умолчанию, но можно включить с помощью конфигурации пакета. Эта функция отслеживает только общее количество произошедших событий и не содержит никакой информации о конкретных событиях (и поэтому не следует рассматривать как PII/ПИИ).
Соответствующие директивы конфигурации:
general->statistics
CIDRAM не шифрует свой кэш или какую-либо информацию журнала. Шифрование кэша и журналов могут быть введены в будущем, но в настоящее время нет конкретных планов. Если вы обеспокоены тем, что несанкционированные сторонние лица получают доступ к частям CIDRAM, которые могут содержать PII/ПИИ или конфиденциальную информацию, такую как ее кэш или журналы, я бы рекомендовал, чтобы CIDRAM не был установлен в общедоступном месте (например, установить CIDRAM за пределами стандартного каталога public_html или его эквивалента, доступного большинству стандартных веб-серверов) и я рекомендую применять соответствующие ограничительные разрешения для каталога установки (в частности, для каталога «vault»). Если этого недостаточно для решения ваших проблем, настройте CIDRAM таким образом, чтобы типы информации, вызывающие ваши проблемы, не собирались или не регистрировались в первую очередь (например, путем отключения ведения журнала).
CIDRAM устанавливает файлы куки в двух точках своей кодовой базы. Во-первых, когда пользователь успешно завершает экземпляр CAPTCHA (and assuming that lockuser is set to true), CIDRAM устанавливает куки, чтобы иметь возможность запоминать для последующих запросов, что пользователь уже завершил экземпляр CAPTCHA, так что ему не нужно постоянно запрашивать у пользователя завершение экземпляра CAPTCHA при последующих запросах. Во-вторых, когда пользователь успешно входит в фронтенд, CIDRAM устанавливает куки, чтобы иметь возможность запоминать пользователя для последующих запросов (то есть, куки используются для аутентификации пользователя в сеансе фронтенд).
В обоих случаях предупреждения куки отображаются на видном месте (если применимо), предупреждающее пользователя о том, что куки будет установлен, если они участвуют в соответствующем действии. Куки не установлены ни в одном другом месте в кодовой базе.
Заметка: «Невидимые» CAPTCHA API могут быть несовместимы с законами о файлах куки в некоторых юрисдикциях, и следует избегать на любых сайтах, на которые распространяются такие законы. Может быть предпочтительнее использовать вместо этого другие предоставленные API, или просто полностью отключить CAPTCHA.
Соответствующие директивы конфигурации:
recaptcha->lockuserrecaptcha->apihcaptcha->lockuserhcaptcha->api
CIDRAM не собирает и не обрабатывает какую-либо информацию для маркетинговых или рекламных целей и не продает и не получает прибыль от любой собранной или занесенной в журнал информации. CIDRAM не коммерческим предприятием и не имеет отношения к каким-либо коммерческим интересам, поэтому делать это не имеет смысла. Это имело место с самого начала проекта и по-прежнему имеет место сегодня. Кроме того, делать эти вещи было бы контрпродуктивным для духа и намеченной цели проекта в целом, и до тех пор, пока я продолжаю поддерживать проект, никогда не произойдет.
В некоторых случаях вам может быть юридически необходимо четко отображать ссылку на вашу политику конфиденциальности на всех страницах и разделах вашего сайта. Это может быть важно как средство обеспечения того, чтобы пользователи были хорошо информированы о ваших точных правилах конфиденциальности, типах PII/ПИИ, которые вы собираете, и о том, как вы собираетесь их использовать. Чтобы иметь возможность включить такую ссылку на странице CIDRAM «Доступ Закрыт», предоставляется директива конфигурации для указания URL-адреса вашей политики конфиденциальности.
Заметка: Настоятельно рекомендуется, чтобы страница политики конфиденциальности не была помещена за защитой CIDRAM. Если CIDRAM защищает вашу страницу политики конфиденциальности, а пользователь, заблокированный CIDRAM, нажимает ссылку на вашу политику конфиденциальности, они будут снова заблокированы и не смогут увидеть вашу политику конфиденциальности. В идеале вы должны ссылаться на статическую копию вашей политики конфиденциальности, такую как HTML-страница или текстовый файл, который не защищен CIDRAM.
Соответствующие директивы конфигурации:
legal->privacy_policy
«Общее Регулирование Защиты Данных» – Это регламент Европейского Союза, который вступает в силу с 25 Мая 2018 года. Основная цель регулирования – Дать контроль гражданам и жителям ЕС в отношении их личных данных, и унифицировать регулирование в ЕС относительно конфиденциальности и личных данных.
Регулирование содержит конкретные положения, касающиеся обработки «личной идентифицируемой информации» (PII/ПИИ) любых «субъектов данных», (любое идентифицированное или идентифицируемое физическое лицо) из или в пределах ЕС. Чтобы соответствовать регулированию, «предприятия» (согласно определению, указанным в регулирование), и любые соответствующие системы и процессы должны реализовать «конфиденциальность по дизайну» по умолчанию, должны использовать максимально возможные настройки конфиденциальности, должны обеспечивать необходимые гарантии для любой сохраненной или обработанной информации (включая, но не ограничиваясь, внедрение псевдонимизированный или полную анонимизированный данных), должны четко и недвусмысленно объявлять типы собираемых ими данных, как они обрабатывают его, по каким причинам, как долго они его сохраняют, и делится ли они этими данными с любыми третьими лицами, типами данных, совместно используемыми с третьими лицами, как, почему, и т.д.
Данные не могут быть обработаны, если нет законных оснований для этого, в соответствии с определением правила. Как правило, это означает, что для обработки данных субъекта данных на законной основе, это должно выполняться в соответствии с юридическими обязательствами, или только после того, как явное, хорошо информированное, однозначное согласие было получено от субъекта данных.
Поскольку аспекты регулирования могут развиваться во времени, чтобы избежать распространения устаревшей информации, лучше узнать о регулировании из авторитетного источника, а не просто включать соответствующую информацию в документацию к пакету (которые в конечном итоге могут устареть, поскольку регулирование развивается).
Некоторые рекомендуемые ресурсы для получения дополнительной информации:
- Новый европейский регламент по защите данных – последствия для российских организаций
- GDPR — новые правила обработки персональных данных в Европе для международного IT-рынка
- Общий регламент по защите данных
- REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
Существуют значительные различия между v3 и предыдущими основными версиями. Как работают точки входа, как структурированы модули, и как работает средство обновления для v3, отличается от того, как все это работало в предыдущих основных версиях. Из-за этих различий лучший способ обновить предыдущие основные версии до v3 — выполнить новую установку.
Если вы хотите сохранить свою конфигурацию и вспомогательные правила, перед началом процесса обновления перейдите на страницу фронтенд резервного копирования. Оттуда можно экспортировать конфигурацию и вспомогательные правила. Экспорт приведет к загрузке файла. После обновления до новой основной версии этот файл можно использовать для импорта ранее экспортированных данных в установку.
Модули, предназначенные для предыдущих основных версий, должны быть переписаны, чтобы правильно работать в v3, из-за изменений в структуре модулей. Прямая миграция не работает. То же самое верно и для событий.
Структура файлов сигнатур не изменилась, поэтому файлы сигнатур, предназначенные для предыдущих основных версий, могут быть напрямую перенесены в v3 без каких-либо ожидаемых проблем.
Модули, файлы сигнатур и события имеют свои собственные выделенные каталоги, что является новым дополнением начиная с v3 (поэтому для v3 каждый из них будет заходить в свои соответствующие выделенные каталоги, а не в корень vault).
Некоторые файлы сигнатур, модули и списки блокировки, общедоступные для предыдущих основных версий, устарели, поэтому не все будет доступно для v3. В большинстве случаев они все равно не понадобятся из-за новых функций, добавленных с v3.
Есть некоторые тонкие изменения в том, как структурированы вспомогательные правила, и есть изменения в конфигурации, но если вы используете функцию импорта/экспорта на странице резервного копирования фронтэнда, вам не нужно будет вручную переписывать, настраивать или воссоздавать что-либо. При импорте CIDRAM знает, что нужно, и автоматически сделает это за вас.
CIDRAM v4 еще не существует. Однако, когда придет время обновиться с v3 до v4, процесс обновления должен быть намного проще. Мы не будем точно знать, насколько существенно это будет отличаться пока не придет время, но я ожидаю, что различий будет намного меньше чем раньше, и механизмы уже были реализованы в v3 с самого начала, чтобы облегчить процесс обновления. Пока нет существенных изменений в средстве обновления или в том, как работают точки входа, теоретически должно быть возможно полностью обновиться через фронтенд, без необходимости выполнять новую установку.
Более подробная информация будет включена сюда, в документацию, в соответствующее время в будущем.
Последнее обновление: 9 Января 2025 г (2025.01.09).