Можно ли определить параметр перегрузки в файле htaccess

Обновлено: 22.11.2024

Мы настраиваем обратный прокси-сервер, защищающий доступ к приложению и защищающий сервер приложений от Интернета. При этом мы познакомимся с несколькими методами настройки и будем работать с ModRewrite впервые.

Зачем мы это делаем?

Требования

Ниже приведен рекомендуемый набор требований. На самом деле вам все это не нужно, но если вы будете старательно им следовать, я уверен, что все примеры будут работать 1:1. Если вы выберете более короткий путь, вероятно, потребуется некоторая настройка с путями и предопределенными псевдонимами.

Веб-сервер Apache, в идеале созданный с использованием файловой структуры, показанной в Уроке 1 (Сборка веб-сервера Apache).
Понимание минимальной конфигурации из Учебника 2 (Настройка минимального сервера Apache).
Веб-сервер Apache с поддержкой SSL/TLS, как показано в Уроке 4 (Настройка сервера SSL).
Веб-сервер Apache с расширенным журналом доступа, как показано в Уроке 5 (Расширение и анализ журнала доступа).
Веб-сервер Apache с ModSecurity, как показано в Уроке 6 (Внедрение ModSecurity).
Веб-сервер Apache с основным набором правил, как показано в Уроке 7 (включая основной набор правил)

Шаг 1. Подготовка серверной части

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

Шаг 2. Включение прокси-модуля

Для использования Apache в качестве прокси-сервера требуется несколько модулей. Мы скомпилировали их в первом уроке и теперь можем просто связать их.

Этот режим также возможен в Apache, хотя и по историческим причинам. Альтернативные программные пакеты, предлагающие эти функции, хорошо зарекомендовали себя, например. Кальмар. Этот случай актуален, поскольку ошибочная конфигурация может иметь фатальные последствия, особенно если прямой прокси-сервер принимает запросы от любого клиента и отправляет их дальше в Интернет в анонимной форме. Это называется открытым прокси. Это необходимо предотвратить, так как мы не хотим использовать Apache в этом режиме. Для этого требуется директива, которая в прошлом использовалась для ссылки на рискованное значение по умолчанию по умолчанию, но теперь правильно предопределена как off :

Эта директива на самом деле означает переадресацию запросов на серверы в Интернете, даже если имя указывает на общую настройку. Как упоминалось ранее, директива правильно настроена для Apache 2.4 и упоминается здесь только для защиты от вопросов или неправильных настроек в будущем.

Шаг 3. Прокси-пасс

Это подводит нас к фактическим настройкам прокси: существует множество способов указать Apache пересылать запрос серверному приложению. Мы рассмотрим каждый вариант по очереди. Наиболее распространенный способ проксирования запросов основан на директиве ProxyPass. Он используется следующим образом:

Самая важная директива — ProxyPass. Он определяет путь /service1 и указывает, как он сопоставляется с серверной частью: с определенной выше службой, работающей на нашем собственном хосте, localhost, на порту 8000. Путь к серверу приложений снова /service1 . Мы проксируем симметрично, потому что путь к интерфейсу идентичен пути к серверу. Однако это сопоставление не является абсолютно обязательным. Технически было бы вполне возможно проксировать service1 на / , но это приводит к административным трудностям и недоразумениям, если путь в файле журнала приложения больше не сопоставляется с путем на обратном прокси-сервере, и запросы больше не могут быть легко сопоставлены.

Шаг 4. Прокси-раздел

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

Блок прокси похож на расположение и блок каталогов, с которыми мы уже познакомились в нашей конфигурации. Это так называемые контейнеры. Контейнеры указывают веб-серверу, как структурировать работу. Когда контейнер появляется в конфигурации, он готовит для него структуру обработки. В случае с mod_proxy доступ к серверной части также возможен без контейнера Proxy. Однако защита доступа не принимается во внимание, и другие директивы больше не имеют места, куда ее можно вставить. Без блока Proxy обработка сложных серверов остается немного бессистемной, и было бы неплохо настроить и эту часть. Используя директиву ProxySet, мы могли бы вмешаться еще больше и указать такие вещи, как поведение соединения. Min, max и smax могут использоваться для указания количества потоков, назначенных пулу прокси-соединений. Это может влиять на производительность от случая к случаю.На поведение поддержания активности прокси-соединения можно влиять, и для него можно определить множество различных тайм-аутов. Дополнительная информация доступна в документации проекта Apache.

Шаг 5. Определение исключений при проксировании и другие настройки

Используемая нами директива ProxyPass перенаправляет все запросы для /service1 на серверную часть. Однако на практике часто бывает так, что вы не хотите пересылать все подряд. Предположим, есть путь /service1/admin, который мы не хотим показывать в Интернете. Этого также можно избежать с помощью соответствующей настройки ProxyPass, где исключение инициируется с помощью восклицательного знака. Важно определить исключение перед настройкой фактической команды прокси:

Вы часто видите конфигурации, которые перенаправляют все пространство имен ниже / на серверную часть. Затем часто определяется ряд исключений из приведенного выше шаблона. Я думаю, что это неправильный подход, и я предпочитаю пересылать только то, что действительно обрабатывается. Преимущество очевидно: сканеры и автоматические атаки, ищущие следующую жертву из пула IP-адресов в Интернете, запрашивают множество несуществующих путей на нашем сервере. Теперь мы можем перенаправить их на серверную часть и можем перегрузить серверную часть или даже подвергнуть ее опасности. Или мы можем просто сбросить эти запросы на обратный прокси-сервер. Последнее явно предпочтительнее по соображениям безопасности.

Важная директива, которая может быть опционально частью прокси, касается времени ожидания. Мы определили собственное значение тайм-аута для нашего сервера. Этот тайм-аут также используется сервером для соединения с бэкендом. Но это не всегда разумно, потому что, хотя мы можем ожидать от клиента, что он быстро выполнит свой запрос и не будет тянуть время, в зависимости от бэкэнд-приложения, обработка ответа может занять некоторое время. Для короткого общего тайм-аута, который разумно иметь для клиента из соображений безопасности, обратный прокси-сервер слишком быстро прерывает доступ к серверной части. По этой причине существует директива ProxyTimeout, которая влияет только на подключение к серверной части. Кстати, измерение времени — это не общее время обработки на серверной части, а продолжительность времени между IP-пакетами: когда серверная часть отправляет часть ответа, часы сбрасываются.

Шаг 6. Модификация

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

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

Давайте посмотрим на такой запрос и возвращенное перенаправление:

В основной части ответа перенаправление включено в виде ссылки в тексте HTML. Это предусмотрено для пользователей, чтобы щелкнуть вручную, если браузер не инициирует перенаправление. Однако это очень маловероятно и, вероятно, включено только по историческим причинам.

Теперь вы можете спросить себя, почему мы открываем механизм перезаписи в контексте сервера и не работаем со всем на уровне VirtualHost. В примере, который я выбрал, вы видите, что это приведет к избыточности, потому что перенаправление с «/» на «index.html» должно происходить через порт 80, а также через зашифрованный порт 443. Это эмпирическое правило: это лучше всего для нам определять и наследовать все, что используется на всех виртуальных хостах в контексте сервера. На этом уровне мы также имеем дело с отдельными правилами для одного виртуального хоста. Обычно для перенаправления всех запросов с порта 80 на порт 443, где включено шифрование, используется следующее правило:

Теперь схема, которую мы хотим, ясна. Но слева от него появляется новый предмет. Мы не подавляем путь так быстро, как указано выше. Вместо этого мы помещаем его в круглые скобки и используем $1, чтобы снова ссылаться на содержимое круглых скобок в перенаправлении. Это означает, что мы перенаправляем запрос на порт 80, используя тот же URL-адрес на порту 443.

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

Шаг 7: ModRewrite [прокси]

Давайте воспользуемся ModRewrite для настройки обратного прокси-сервера. Делаем это следующим образом:

Это достаточно для настройки с использованием правила перезаписи. В этом примере нет реального преимущества перед синтаксисом ProxyPass. Однако ссылки на части путей с использованием $1 , $2 и т. д. обеспечивают некоторую гибкость. Но если мы все равно работаем с правилами перезаписи, то путем проксирования правил перезаписи мы гарантируем, что RewriteRule и ProxyPass не вступят в конфликт, затрагивая один и тот же запрос и влияя друг на друга.

Однако теперь может случиться так, что мы захотим использовать один обратный прокси-сервер для объединения нескольких серверных частей или для распределения нагрузки между несколькими серверами. Это требует нашего собственного балансировщика нагрузки. Мы рассмотрим это в следующем разделе.

Шаг 8. Балансировщик [прокси]

Сначала нам нужно загрузить модуль балансировки нагрузки Apache:

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

Вот список всех четырех доступных алгоритмов:

mod_lbmethod_byrequests (подсчитывает запросы)
mod_lbmethod_bytraffic (суммарный размер запросов и ответов)
mod_lbmethod_bybusyness (балансировка нагрузки на основе активных потоков в соединении, установленном с серверной частью. Серверная часть с наименьшим количеством потоков получает следующий запрос)
mod_lbmethod_heartbeat (серверная часть может даже связываться через пульсацию в сети и использовать ее для информирования обратного прокси-сервера о том, есть ли у него свободная емкость).

Различные модули хорошо задокументированы в Интернете, поэтому этого краткого описания будет достаточно на данный момент.

Наконец, нам все еще нужен модуль, который поможет нам управлять общими сегментами памяти. Эти функции требуются модулем балансировки прокси и предоставляются mod_slotmem_shm.so .

Теперь мы готовы настроить балансировщик нагрузки. Мы можем настроить его через RewriteRule. Это изменение также влияет на секцию прокси, где необходимо ссылаться на только что определенный балансировщик и разрешать его:

Помимо заголовка keep-alive, интерес представляет также обработчик запроса. Таким образом, запрос был обработан обработчиком прокси-сервера. Мы также видим записи для маршрута, в частности значения, определенные как backend-port-8000 и backend-port-8001. Это позволяет определить из журнала доступа сервера точный маршрут запроса.

В следующем руководстве мы увидим, что балансировщик прокси можно использовать и в других ситуациях. Однако на данный момент мы будем довольны тем, что происходит, и теперь обратимся к RewriteMaps. RewriteMap — это вспомогательная структура, которая снова увеличивает возможности ModRewrite. В сочетании с прокси-сервером гибкость значительно возрастает.

Шаг 9. Перезапись карты [прокси]

Карты RewriteMaps бывают разных вариантов. Они работают, присваивая значение ключевому параметру при каждом запросе. Хеш-таблица — простой пример. Но тогда также можно настроить внешние сценарии как программируемый RewriteMap. Возможны следующие типы карт:

txt : здесь ищется пара ключ-значение в текстовом файле.
rnd: здесь можно указать несколько значений для каждого ключа. Затем они выбираются случайным образом.
dbm : этот вариант работает так же, как вариант txt, но дает большое преимущество в скорости, поскольку используется двоичная хеш-таблица.
int : эта аббревиатура означает внутреннюю функцию и относится к функции из следующего списка: toupper , tolower , escape и unescape .
prg : в этом варианте вызывается внешний скрипт. Сценарий запускается вместе с сервером, и каждый раз при доступе к RewriteMap получает новые данные через STDIN.
dbd и fastdbd : значение ответа ищется в запросе к базе данных.

Из этого списка видно, что карты RewriteMaps чрезвычайно гибки и могут использоваться в различных ситуациях. Определение бэкенда для проксирования — это только одно из многих возможных применений. В нашем примере мы хотим, чтобы запрос от конкретного клиента всегда направлялся к одному и тому же бэкенду. Это можно сделать несколькими способами, в частности, путем установки файла cookie. Но мы не хотим вмешиваться в запросы. Мы могли бы разделить по диапазонам сети. Но как предотвратить попадание большого количества клиентов из определенного сетевого диапазона в один и тот же сервер? Должна быть какая-то раздача. Для этого мы комбинируем ModSecurity с использованием ModRewrite и RewriteMap. Давайте рассмотрим это шаг за шагом.

Сначала мы вычисляем хеш-значение на основе IP-адреса клиента. Это означает, что мы преобразуем IP-адрес в, казалось бы, случайную шестнадцатеричную строку, используя ModSecurity:

Мы использовали hexEncode для преобразования двоичного хеш-значения, сгенерированного с помощью sha1, в читаемые символы. Затем мы применяем регулярное выражение к этому значению. «^(.)» означает, что мы хотим найти совпадение по первому символу. Из флагов ModSecurity, которые следуют за захватом, представляет интерес. Это указывает на то, что мы хотим зафиксировать значение в круглых скобках в предыдущем условии регулярного выражения. Затем мы помещаем его в переменную среды IPHashChar.

Если есть какая-то неуверенность в том, будет ли это действительно работать, то содержимое переменной IPHashChar можно распечатать и проверить с помощью %e в журнале доступа к серверу. Это подводит нас к RewriteMap и самому запросу:

Мы вводим карту с помощью команды RewriteMap. Присваиваем ему имя, определяем его тип и путь к файлу. RewriteMap вызывается в RewriteRule. Прежде чем мы действительно получим доступ к карте, мы включаем условие перезаписи. Это делается с помощью директивы RewriteCond. Там мы ссылаемся на переменную среды IPHashChar и определяем первый байт переменной. Мы знаем, что в вариант включен только один байт, но это не помешает нашим планам. На следующей строке типичное начало директивы Proxy. Но вместо того, чтобы теперь указывать серверную часть, мы ссылаемся на RewriteMap по ранее назначенному имени. После двоеточия идет параметр запроса. Интересно, что мы используем %1 для связи с условиями перезаписи, заключенными в скобки. На переменную RewriteRule это не влияет, и на нее по-прежнему ссылаются через $1. После %1 идет значение по умолчанию, разделенное вертикальной чертой. Если что-то пойдет не так при доступе к карте, связь с локальным хостом будет осуществляться через порт 8000.

Все, что нам нужно сейчас, это RewriteMap. В примере кода мы указали текстовый файл. Лучшая производительность обеспечивается хэш-файлом, но в настоящее время это не главное. Вот файл карты /apache/conf/hashchar2backend.txt:

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

Шаг 10. Передача информации в серверные системы

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

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

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

Различные расширенные строки заголовков перечислены последовательно и заполнены значениями, если они есть.

Шаг 11 (полезный): настройка полного обратного прокси-сервера

Это небольшое дополнение подводит нас к концу этого руководства, а также к концу основного блока различных руководств. В нескольких руководствах мы увидели, как настроить веб-сервер Apache для лаборатории, от его компиляции до базовой конфигурации и настройки ModSecurity для обратных прокси, получив глубокое представление о том, как работает сервер и его наиболее важные модули.< /p>

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

Информационный бюллетень

Понравилось ли вам это руководство? Если да, то почему бы вам не подписаться на нашу рассылку, чтобы узнавать о новом контенте на этом сайте?

Ссылки

Лицензия/Копирование/Дальнейшее использование

Эта работа находится под лицензией Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Файлы Apache .htaccess позволяют пользователям настраивать каталоги веб-сервера, которыми они управляют, без изменения основного файла конфигурации.

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

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

Перенаправления

Иногда нам нужно сообщить пользователям, что ресурс временно или постоянно перемещен. Именно для этого мы используем Redirect и RedirectMatch.

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

Возвращает постоянный статус перенаправления (301), указывающий, что ресурс перемещен навсегда.

Возвращает временный статус перенаправления (302). Это значение по умолчанию.

Возвращает статус "Просмотреть другое" (303), указывающий, что ресурс был заменен.

Возвращает статус "Исключен" (410), указывающий, что ресурс был окончательно удален. При использовании этого статуса аргумент URL следует опустить.

Независимые ресурсы

Общий доступ к CORS

Эта директива добавит заголовок CORS для всех ресурсов в каталоге с любого веб-сайта.

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

Изображения из разных источников

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

Чтобы снизить вероятность таких атак, вам следует использовать атрибут crossorigin в запрашиваемых изображениях и приведенный ниже фрагмент кода в файле .htaccess для установки заголовка CORS с сервера.

В руководстве по устранению неполадок Google Fonts в Google Chrome сообщается, что, хотя Google Fonts может отправлять заголовок CORS с каждым ответом, некоторые прокси-серверы могут удалять его до того, как браузер сможет использовать его для отображения шрифта.

Время ресурсов из разных источников

Спецификация Resource Timing Level 1 определяет интерфейс для веб-приложений для доступа к полной информации о времени для ресурсов в документе.

Заголовок ответа Timing-Allow-Origin указывает источники, которым разрешено просматривать значения атрибутов, полученные с помощью функций Resource Timing API, которые в противном случае были бы сообщены как нулевые из-за ограничений между источниками.

Если ресурс не обслуживается с Timing-Allow-Origin или если заголовок не включает источник, делающий запрос, некоторые из атрибутов объекта PerformanceResourceTiming будут установлены в ноль.

Пользовательские страницы/сообщения об ошибках

Apache позволяет предоставлять пользователям настраиваемые страницы ошибок в зависимости от типа получаемой ими ошибки.

Страницы ошибок представлены в виде URL-адресов. Эти URL-адреса могут начинаться с косой черты (/) для локальных веб-путей (относительно DocumentRoot) или представлять собой полный URL-адрес, который может разрешить клиент.

Предотвращение ошибок

Этот параметр влияет на работу MultiViews для каталога, к которому применяется конфигурация.

Эффект MultiViews следующий: если сервер получает запрос на /some/dir/foo, если для /some/dir включено MultiViews, а /some/dir/foo не существует, то сервер считывает каталог ищет файлы с именем foo.* и эффективно подделывает карту типов, которая называет все эти файлы, назначая им те же типы мультимедиа и кодировки контента, которые были бы, если бы клиент запросил один из них по имени. Затем он выбирает наилучшее соответствие требованиям клиента.

Этот параметр отключает MultiViews для каталога, к которому применяется эта конфигурация, и предотвращает возврат Apache ошибки 404 в результате перезаписи, когда каталог с таким именем не существует

Типы мультимедиа и кодировки символов

Изменение метаданных файла не меняет значение заголовка Last-Modified. Таким образом, ранее кэшированные копии могут по-прежнему использоваться клиентом или прокси с предыдущими заголовками. Если вы измените метаданные (язык, тип контента, набор символов или кодировку), вам может потребоваться «прикоснуться» к затронутым файлам (обновив дату их последнего изменения), чтобы гарантировать, что все посетители получат исправленные заголовки контента.

Обслуживать ресурсы с правильными типами мультимедиа (например, типами MIME)

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

Серверы должны использовать текст/javascript для ресурсов JavaScript, как указано в спецификации HTML

Установите атрибут Charset по умолчанию

Каждый фрагмент контента в Интернете имеет набор символов. Большинство, если не все, содержимое представлено в формате Unicode UTF-8.

Используйте AddDefaultCharset для обслуживания всех ресурсов, помеченных как text/html или text/plain с кодировкой UTF-8.

Установите кодировку для определенных типов мультимедиа

Обслуживайте следующие типы файлов с параметром charset, установленным на `UTF-8`, используя директиву AddCharset, доступную в mod_mime.

Mod_rewrite и директивы RewriteEngine

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

Включить mod_rewrite

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

Вы не должны дублировать контент в нескольких источниках (с www и без него); это может вызвать проблемы SEO (дублированный контент), поэтому вам следует выбрать один из вариантов и перенаправить другой. Вы также должны использовать канонические URL-адреса, чтобы указать, какие URL-адреса должны сканировать поисковые системы (если они поддерживают эту функцию).

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

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

Параметры фрейма

В приведенном ниже примере отправляется заголовок ответа X-Frame-Options со значением DENY, уведомляющим браузеры не отображать содержимое веб-страницы ни в одном фрейме, чтобы защитить веб-сайт от кликджекинга.

Возможно, это не лучшая настройка для всех. Вы должны прочитать о двух других возможных значениях для заголовка X-Frame-Options: SAMEORIGIN и ALLOW-FROM .

Хотя вы можете отправить заголовок X-Frame-Options для всех страниц вашего веб-сайта, у этого есть потенциальный недостаток, заключающийся в том, что он запрещает даже любое кадрирование вашего контента (например, когда пользователи посещают ваш веб-сайт, используя страницу результатов поиска картинок Google). ).

Тем не менее, вы должны убедиться, что вы отправляете заголовок X-Frame-Options для всех страниц, которые позволяют пользователю выполнять операцию изменения состояния (например, страницы, содержащие ссылки для покупки в один клик, оформления заказа или банковского перевода). страницы подтверждения, страницы, которые вносят постоянные изменения в конфигурацию и т. д.).

Политика безопасности контента (CSP)

CSP (политика безопасности контента) снижает риск межсайтового скриптинга и других атак с внедрением контента, устанавливая `Политику безопасности контента`, которая разрешает доверенные источники контента для вашего веб-сайта.

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

Пример политики ниже:

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

Доступ к каталогу

Эта директива предотвратит доступ к каталогам, в которых нет файла индекса в любом формате, который настроен на сервере, например index.html или index.php .

Заблокировать доступ к скрытым файлам и каталогам

В системах Macintosh и Linux файлы, начинающиеся с точки, скрыты от просмотра, но не от доступа, если вы знаете их имя и местоположение. Эти типы файлов обычно содержат пользовательские настройки или сохраненное состояние утилиты и могут включать в себя довольно личные места, такие как, например, каталоги .git или .svn.

Каталог .well-known/ представляет собой стандартный (RFC 5785) префикс пути для «известных местоположений» (например: /.well-known/manifest.json , /.well-known/keybase.txt ). и поэтому доступ к его видимому контенту не должен быть заблокирован.

Заблокировать доступ к файлам с конфиденциальной информацией

Заблокируйте доступ к резервным и исходным файлам, которые могут быть оставлены некоторыми текстовыми редакторами и могут представлять угрозу безопасности, если кто-либо имеет к ним доступ.

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

Запретить некоторым браузерам прослушивание ответа MIME

Ограничивает все выборки по умолчанию источником текущего веб-сайта, устанавливая для директивы default-src значение 'self', что действует как резерв для всех директив Fetch.
- Это удобно, так как вам не нужно указывать все директивы Fetch, применимые к вашему сайту, например: connect-src 'self'; шрифт-источник 'я'; сценарий-источник 'я'; style-src 'self' и т. д.
- Это ограничение также означает, что вы должны явно указать, с каких сайтов ваш веб-сайт может загружать ресурсы, иначе он будет ограничен тем же источником, что и страница, отправляющая запрос.
Запрещает элемент на веб-сайте. Это делается для того, чтобы злоумышленники не могли изменить расположение ресурсов, загружаемых с относительных URL-адресов
- Если вы хотите использовать этот элемент, используйте вместо него base-uri 'self'
Разрешить отправку форм только из текущего источника с помощью: form-action 'self'
Запрещает всем веб-сайтам (включая ваш собственный) встраивать ваши веб-страницы, например, в элемент или, установив: frame-ancestors 'none' .
- Директива frame-ancestors помогает избежать атак с использованием кликджекинга и аналогична заголовку X-Frame-Options.
- Браузеры, поддерживающие заголовок CSP, будут игнорировать X-Frame-Options, если также указаны предки кадров
Заставляет браузер обрабатывать все ресурсы, которые обслуживаются через HTTP, как если бы они были безопасно загружены через HTTPS, устанавливая директиву upgrade-insecure-requests
- upgrade-insecure-requests не гарантирует HTTPS для навигации верхнего уровня. Если вы хотите, чтобы сам веб-сайт загружался через HTTPS, вы должны включить заголовок Strict-Transport-Security
Включает заголовок Content-Security-Policy во все ответы, способные выполнять сценарии. Сюда входят часто используемые типы файлов: документы HTML, XML и PDF. Хотя файлы Javascript не могут выполнять сценарии в «контексте просмотра», они включены для целевых веб-воркеров.

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

Политика реферала

Мы включаем заголовок Referrer-Policy в ответы для ресурсов, которые могут запрашивать (или переходить) к другим ресурсам.

Сюда входят часто используемые типы ресурсов: HTML, CSS, XML/SVG, документы PDF, сценарии и рабочие процессы.

Чтобы полностью предотвратить утечку реферера, вместо этого укажите значение no-referrer. Обратите внимание, что это может отрицательно сказаться на инструментах аналитики.

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

Метод TRACE, хотя и кажется безвредным, в некоторых сценариях может быть успешно использован для кражи учетных данных законных пользователей. См. Атака с межсайтовым отслеживанием (XST) и Руководство по тестированию веб-безопасности OWASP

Современные браузеры теперь предотвращают запросы TRACE, сделанные через JavaScript, однако были обнаружены другие способы отправки запросов TRACE с помощью браузеров, например с использованием Java.

Если у вас есть доступ к основному файлу конфигурации сервера, используйте директиву TraceEnable.

Удалить заголовок ответа X-Powered-By

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

По возможности отключите заголовок X-Powered-By на уровне языка/фреймворка (например, для PHP это можно сделать, установив в php.ini следующее.

Удалить нижний колонтитул с информацией о сервере, созданный Apache

Запретить Apache добавлять завершающую строку нижнего колонтитула, содержащую информацию о сервере, в документы, созданные сервером (например, сообщения об ошибках, списки каталогов и т. д.). См. директиву ServerSignature для получения дополнительной информации о том, что предоставляет подпись сервера, и директиву ServerTokens для получения информации о настройке информации, предоставленной в подписи.

Исправить неработающие заголовки AcceptEncoding

Сжатие типов мультимедиа

Сжимайте все выходные данные, помеченные одним из следующих типов мультимедиа, с помощью директивы AddOutputFilterByType.

Сопоставление расширений с типами мультимедиа

Сопоставьте следующие расширения имен файлов с указанным типом кодировки с помощью AddEncoding, чтобы Apache мог обслуживать типы файлов с соответствующим заголовком ответа Content-Encoding (это НЕ заставит Apache их сжимать!). Если эти типы файлов будут обслуживаться без соответствующего заголовка ответа Content-Encoding, клиентские приложения (например, браузеры) не будут знать, что им сначала нужно распаковать ответ, и, следовательно, не смогут понять содержимое.< /p>

Срок действия кэша

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

Как владелец веб-сайта, вы, возможно, задавались вопросом, является ли использование домена веб-сайта с www или без www просто вопросом предпочтений пользователя.

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

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

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

Зачем перенаправлять URL-адреса без www на www?

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

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

Кроме того, с доменом без www вы не можете использовать субдомен без файлов cookie, если не создадите отдельный домен для доставки статического контента.

Перенаправление URL-адресов без www на www

Существует несколько способов перенаправить URL-адреса без www на www: через панель управления вашей учетной записи хостинга, сеть доставки контента (CDN) или программное обеспечение веб-сервера.

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

hPanel

Самый простой способ перенаправить URL-адрес без www на www — это поместить правило в файл .htaccess. Вы можете сделать это через FTP, SSH или панель управления вашей учетной записи хостинга.

Пользователи hPanel могут легко открывать и редактировать файл .htaccess. Вот шаги, чтобы сделать это:

Это правило .htaccess теперь будет перенаправлять всех посетителей с версии вашего веб-сайта без www на версию с www.

cPanel

Пользователи cPanel могут перенаправлять URL-адреса без www на www с помощью настроек перенаправления или редактирования файла .htaccess. Если вы новичок, мы рекомендуем использовать первый метод:

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

Облачная вспышка

Если вы планируете настроить CDN, например Cloudflare, для повышения скорости и производительности сайта, вы также сможете использовать его для перенаправления не-www на домен www.

Примечание эксперта

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

Директор по работе с клиентами

После создания учетной записи войдите в систему и следуйте этим инструкциям:

Подождите, пока активируется перенаправление.

NGINX

Если вы используете хостинг виртуальных частных серверов и NGINX, следуйте инструкциям ниже, чтобы перенаправить URL-адреса без www на www:

Апач

Если вы используете VPS и Apache, вам также потребуется отредактировать файл .htaccess. Как и в предыдущем уроке, это можно сделать через SSH-терминал.

Прежде чем продолжить выполнение описанных ниже действий, убедитесь, что у вас есть root-доступ с привилегиями sudo и текстовый редактор, например Nano.

По умолчанию Apache не позволяет использовать файл .htaccess, поэтому шаги будут немного отличаться:

Все посетители сайта, использующие URL-адрес без www, теперь должны быть перенаправлены на версию с www.

Заключение

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

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

Хотя это может показаться сложным, процесс перенаправления займет всего минуту или две. В этой статье вы узнали, как перенаправлять URL-адреса без www на www несколькими способами:

Через панель управления вашей учетной записи хостинга — hPanel и cPanel.
Использование Cloudflare.
Для пользователей VPS через NGINX и Apache.

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

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

Эта функция была УСТАРЕЛА в PHP 7.2.0 и УДАЛЕНА в PHP 8.0.0. Крайне не рекомендуется полагаться на эту функцию.

Часто бывает сложно заставить существующее PHP-приложение работать в заданной многобайтовой среде. Это происходит потому, что большинство PHP-приложений написаны со стандартными строковыми функциями, такими как substr() , которые, как известно, неправильно обрабатывают строки с многобайтовым кодированием.

mbstring поддерживает функцию "перегрузки функций", которая позволяет добавить в такое приложение многобайтовую поддержку без изменения кода путем перегрузки многобайтовых аналогов стандартных строковых функций. Например, mb_substr() вызывается вместо substr(), если включена перегрузка функций. Эта функция во многих случаях упрощает перенос приложений, поддерживающих только однобайтовые кодировки, в многобайтовую среду.

Чтобы использовать перегрузку функций, задайте для mbstring.func_overload в php.ini положительное значение, которое представляет собой комбинацию битовых масок, указывающих категории перегружаемых функций.Он должен быть установлен в 1, чтобы перегрузить функцию mail(). 2 для строковых функций, 4 для функций регулярных выражений. Например, если установлено значение 7, почта, строки и функции регулярных выражений будут перегружены. Список перегруженных функций показан ниже.

Функции для перегрузки < td>2

значение mbstring.func_overload	исходная функция	перегруженная функция
1	mail()	mb_send_mail()
2	strlen()	mb_strlen()
2	strpos()	mb_strpos()
2	strrpos()	mb_strrpos()
2	substr()	mb_substr()
2	strtolower()	mb_strtolower()
2	strtoupper()	mb_strtoupper()
stripos()	mb_stripos()
2	strripos()	mb_strripos()
2	strstr()	mb_strstr()
2	stristr()	mb_stristr()
2	strrchr()	mb_strrchr()
2	substr_count()	mb_substr_count() < /tr>

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

На странице Avada > Состояние системы вы найдете некоторые ограничения WordPress и серверной среды, которые необходимо проверить, чтобы обеспечить бесперебойную работу вашего сайта. Любые значения, выделенные красным, могут нуждаться в увеличении. Ниже вы найдете наиболее распространенные ограничения, с которыми пользователи сталкиваются с проблемами. Продолжайте читать ниже, чтобы узнать больше о том, что представляют собой эти значения, почему их нужно корректировать и как вы можете их настроить.

ВАЖНОЕ ПРИМЕЧАНИЕ. Помните, что каждая служба хостинга отличается друг от друга, и методы, упомянутые ниже, могут вам подойти или не подойти. Прежде чем пытаться использовать эти методы для увеличения пределов статуса вашей системы, всегда лучше сначала связаться с вашим хостом и спросить его, могут ли они внести эти корректировки для вас.

Обзор

Ограничение памяти WP

Каков лимит памяти WP?

Лимит памяти WP — это максимальный объем памяти (ОЗУ), который ваш сайт может использовать одновременно. Когда вы достигнете предела памяти, вы столкнетесь с фатальной ошибкой. Несколько вещей потребляют память, например сам WordPress, используемая тема и плагины, установленные на вашем сайте. По сути, чем больше контента и функций вы добавляете на свой сайт, тем выше должен быть лимит памяти.

Зачем мне увеличивать лимит памяти WP?

Существует ряд факторов, которые могут повлиять на то, сколько памяти потребуется вашему веб-сайту, например контент, темы, плагины и т. д. Ограничение памяти по умолчанию для WordPress составляет 32 МБ. Если вы используете только небольшой сайт с базовыми функциями, этого значения по умолчанию более чем достаточно. Однако, как только вы начнете сталкиваться с "Неустранимая ошибка: размер памяти исчерпан…, возможно, пришло время настроить ограничение памяти.

Как увеличить лимит памяти WP

Чтобы увеличить лимит памяти, вам потребуется получить доступ к определенным файлам, таким как файлы php.ini, wp-config.php и .htaccess, и изменить их. Большинство хостов не предоставят вам полный доступ для изменения файла PHP.ini, потому что это влияет на весь сервер и все веб-сайты, размещенные на нем. Сначала свяжитесь с хостом, чтобы узнать, могут ли они настроить его для вас.

Для опытных пользователей, у которых есть собственные настройки сервера и полный доступ к файлу php.ini, сначала попробуйте метод 1, а затем другие методы. Для обычных пользователей мы рекомендуем вместо этого попробовать метод 2 и метод 3.

Способ 1: изменить лимит памяти PHP в файле php.ini

ВАЖНОЕ ПРИМЕЧАНИЕ. Многие общие хосты запрещают прямой доступ к файлу PHP.ini. Используйте этот метод только в том случае, если у вас есть прямой доступ к файлу PHP.ini или если вы находитесь на локальном хосте или на собственном сервере. Обратите внимание, что это не изменит значение красного предела памяти WP, отображаемое на вкладке «Статус системы», поскольку этот метод регулирует ограничение памяти PHP.

Шаг 1. Найдите файл PHP.ini. Если вы не можете его найти, вы можете создать свой собственный файл PHP.ini в корневой папке вашей установки WordPress.

Шаг 2. Если вы нашли существующий файл PHP.ini, откройте файл и найдите следующую строку кода (xx представляет число):

Затем измените xxM на желаемое ограничение. Например, 256M.

Шаг 3. Если вы создали собственный PHP.ini, затем добавьте в него тот же код:

Просто измените значение на рекомендуемое. Например, 256M.

Шаг 4. Сохраните изменения и перезагрузите локальный хост или сервер.

Способ 2. Измените лимит памяти WordPress в файле WP-config.php

ВАЖНОЕ ПРИМЕЧАНИЕ. Это значение отображается в состоянии ограничения памяти WP на странице состояния системы. Изменение этого значения на рекомендуемое значение (256 МБ) сделает состояние ограничения памяти WP зеленым на странице состояния системы.

Шаг 1. Найдите файл wp-config.php в корневой папке установки WordPress.

Шаг 2. Откройте файл wp-config.php в текстовом редакторе (Блокнот или TextEdit) и добавьте следующую строку код выше /* Это все, прекратите редактирование! Удачной публикации. */

Просто измените значение на рекомендуемое. Например, 256M.

Шаг 3. Сохраните файл и обновите вкладку "Статус системы". Если лимит памяти WP становится зеленым, значит, вы успешно увеличили лимит памяти WP.

Способ 3: изменить лимит памяти PHP в файле .htaccess

ВАЖНОЕ ПРИМЕЧАНИЕ. Обязательно сделайте резервную копию файла .htaccess перед редактированием. Это еще один способ изменить лимит памяти PHP. Это не повлияет на значение, отображаемое в WP Memory Limit на странице System Status.

Шаг 1. Найдите файл .htaccess, который обычно находится в корневой папке установки WordPress. Если вы не можете его найти, это может быть потому, что он спрятан. Вот руководство для Windows и руководство для Mac о том, как открыть скрытые файлы.

Шаг 2. Откройте файл .htaccess в текстовом редакторе (Блокнот или TextEdit) и добавьте следующую строку кода:

Просто измените значение на рекомендуемое. Например, 256M.

Шаг 3. Сохраните файл и обновите веб-сайт.

Ограничение времени PHP

Каков лимит времени PHP?

Ограничение времени PHP — это количество времени (в секундах), которое ваш сайт потратит на одну операцию до истечения времени ожидания. Это также сделано для того, чтобы избежать зависаний сервера. Значение по умолчанию для ограничения времени PHP составляет 30 секунд. Когда операция достигает установленного срока, она возвращает фатальную ошибку, которая выглядит следующим образом

Зачем мне увеличивать лимит времени PHP?

Поскольку значение по умолчанию составляет всего 30 секунд, вы, скорее всего, получите фатальную ошибку при выполнении более длительных операций. Мы рекомендуем изменить лимит времени PHP как минимум на 180 секунд или на 300 секунд в зависимости от того, что позволяет ваш хост.

Как увеличить лимит времени PHP

Чтобы увеличить лимит времени PHP, вам потребуется получить доступ и изменить определенные файлы, такие как файлы php.ini, wp-config.php и .htaccess. Большинство хостов не предоставят вам полный доступ для изменения файла PHP.ini, потому что это влияет на весь сервер и все веб-сайты, размещенные на нем. Сначала свяжитесь с хостом, чтобы узнать, могут ли они настроить его для вас.

Способ 1: изменить лимит времени PHP в файле PHP.ini

ВАЖНОЕ ПРИМЕЧАНИЕ. Многие общие хосты запрещают прямой доступ к файлу PHP.ini. Используйте этот метод, только если у вас есть прямой доступ к файлу PHP.ini или если вы находитесь на локальном хосте.

Затем измените xx на желаемое ограничение. Например, 300.

Шаг 3. Если вы создали свой собственный файл PHP.ini, добавьте в него тот же код:

Просто измените значение на рекомендуемое. Например, 300.

Шаг 4. Сохраните изменения и перезагрузите локальный хост или сервер.

Способ 2: изменить лимит времени PHP в файле WP-config.php

Шаг 1. Найдите файл wp-config.php в корневой папке установки WordPress.

Шаг 2. Откройте файл wp-config.php в текстовом редакторе (Блокнот или TextEdit) и добавьте следующую строку код после 'define('WP_DEBUG', false);:

Просто измените значение на рекомендуемое. Например, 300.

Шаг 3. Сохраните файл и обновите вкладку "Статус системы". Если лимит времени PHP становится зеленым, значит, вы успешно увеличили лимит времени PHP.

Способ 3. Измените лимит времени PHP в файле .htaccess

Шаг 1. Найдите файл .htaccess, который обычно находится в корневой папке установки WordPress. Если вы не можете его найти, это может быть потому, что он спрятан. Вот учебник для Windows и учебник для Mac о том, как выявить скрытые файлы на вашем компьютере.

Шаг 2. Откройте файл .htaccess в текстовом редакторе (Блокнот или TextEdit) и добавьте следующую строку кода:

Затем просто введите рекомендуемое значение. Например, 300.

Шаг 3. Сохраните файл и обновите веб-сайт.

Максимальные входные переменные PHP

Что такое максимальное количество входных переменных PHP?

Максимальное количество входных переменных PHP — это максимальное количество переменных, которые ваш сервер может использовать для одной функции, чтобы избежать перегрузок. Значение по умолчанию для PHP Max Input Vars составляет 1000, а рекомендуемое значение — 1540. Это ограничение приведет к обрезанию некоторых данных поста, таких как элементы меню, что вызывает проблемы, например, элементы меню не сохраняются или пропадают.

Зачем мне увеличивать максимальное число входных переменных PHP?

Возможно, вам придется увеличить максимальный входной параметр PHP, если у вас возникли проблемы с меню. Если ваши пункты меню не сохраняются должным образом или если последние несколько пунктов меню опущены, это, скорее всего, связано с тем, что значение PHP Max Input Vars слишком низкое. Мы рекомендуем, чтобы ваши PHP Max Input Vars были 1540, чтобы загрузить все пункты меню классической демонстрации.

Как увеличить максимальное количество входных переменных PHP

Как и в случае с другими значениями выше, вам потребуется получить доступ и изменить файлы php.ini или .htaccess. Большинство хостов не предоставят вам полный доступ для изменения файла PHP.ini, потому что это влияет на весь сервер и все веб-сайты, размещенные на нем. Сначала свяжитесь с хостом, чтобы узнать, могут ли они настроить его для вас.

Для опытных пользователей, у которых есть собственные настройки сервера и полный доступ к файлу php.ini, сначала попробуйте метод 1, а затем другой метод. Для обычных пользователей мы рекомендуем вместо этого попробовать метод 2.

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