Ошибка HTTP — WordPress Flash Uploader

Недавно несколько наших клиентов переместили свои сайты на VPS (виртуальный частный сервер) с 64-разрядными CentOS, WHM, cPanel, Apache 2.2, PHP 5.3 и My SQL 5.x. Это было вызвано желанием повысить производительность и улучшить контроль над собственным запуском. размещенная интернет-среда, и VPS, казалось, лучше всего подходил в это время. В целом, их трафик был лучше, чем ожидалось, без серьезных проблем. Однако одной ошибкой, которая заметила, что это происходило неоднократно при попытке использовать Flash Uploader в WordPress, была ужасающая ошибка HTTP.

Flash Uploader в WordPress HTTP ошибка

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

Прежде всего, обратите внимание, что эта ошибка СОЕДИНЕНА с модулем MOD_SECURITY в Apache. В более ранних версиях WordPress это была ошибка, но она была исправлена ​​в версии 2.8. Если вы увидите эту ошибку в более поздней версии WordPress (мы используем версию 3.2.1), она, скорее всего, подключена к вашему серверу Apache с помощью модуля MOD_SECURITY. Чтобы решить эту проблему, вам нужно определить, установлен ли у вас mod_security или mod_security2, поскольку разрешение каждого модуля совершенно разное.

MOD_SECURITY — это брандмауэр с открытым исходным кодом, который устанавливается как модуль для веб-серверов Apache. Существует две часто используемые версии модуля mod_security, первая версия mod_security была просто mod_security, последняя версия называется mod_security2. В этом посте последняя версия mod_security — MODSecurity 2.6.

Что вызывает ошибку HTTP

Как упоминалось ранее, наши клиенты используют CentOS 5.7 с WHM и cPanel, поэтому примеры, которые вы видите здесь, основаны на этой конфигурации. Однако вы сможете применить наши предложения в своей среде, если вы знаете операционную систему сервера и расположение файлов сервера для Apache и Mod_Security.

Ошибка HTTP вызвана mod_security, поскольку в mod_security существует правило безопасности, которое запускается загрузчиком Flash WordPress. Это правило безопасности предназначено для предотвращения известных ошибок безопасности Flash, которые использовались для внедрения кода на сайт. Это правило безопасности отображает сообщение в журналах mod_security в WHM, когда вы пытаетесь отправить файл с помощью Flash Uploader. Сообщение, которое мы получили, было следующим;

Доступ запрещен с кодом 406 (этап 2). Адаптация к шаблону «^ Shockwave Flash» на странице REQUEST_HEADERS: User-Agent. [file «/usr/local/apache/conf/modsec2.user.conf»] [line «203»]

Ваше сообщение может отличаться в зависимости от установленной версии mod_security. Как видно из нашего сообщения, в нем четко указано, что правило, начатое путем сопоставления с шаблоном, находилось в файле modsec2.user.conf, что помогло нам определить, что мы установили mod_security2.

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

mod_security

Если у вас есть более ранняя версия mod_security, проще исправить ошибку HTTP для Flash Uploader, поскольку ваши изменения могут быть включены в файл .htaccess в корневом каталоге. Это один из самых запутанных аспектов улучшений, которые мы обнаружили в Интернете, так как не многие веб-сайты различают патчи между mod_security и mod_security2.

Для mod_security просто отключите это правило для файла async-upload.php в вашем файле .htaccess. Вы можете сделать это, вставив следующую директиву в файл your.htaccess в корневом каталоге вашего сайта.

SecFilterEngine Off

SecFilterScanPOST Off

Теперь, когда вы используете программу передачи файлов WordPress, это правило mod_security не будет запущено. Flash Uploader использует сайт async-upload.php, и в соответствии с вышеуказанной директивой фильтр безопасности и сканирование для этой страницы отключены.

Важно отметить, что вы не хотите отключать mod_security для всего сайта! Мы нашли много постов в интернете, которые определили вышеуказанную директиву без спецификаций файлов. НЕ ДЕЛАЙТЕ ЭТОГО! Вы откроете свой сайт для всех типов уязвимостей, потому что вы полностью отключите mod_security.

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

MOD_SECURITY2

Если вы используете mod_security2, изменения .htaccess не будут работать!

Mod_security2 не позволяет вносить изменения в свои политики безопасности через файл .htaccess. Единственный способ внести изменения — это файл с именем /usr/local/apache/conf/modsec2/custom.conf. Это важное различие между mod_security и mod_security2, которое, я уверен, вызвало у многих владельцев сайтов много страданий и сожалений.

Чтобы исправить эту ошибку, если вы используете mod_security2, он требует двухэтапного процесса;

Шаг 1

A) В WHM откройте журнал MOD_Security в разделе «Плагины / Мод безопасности».

Б) В верхней части страницы вы увидите кнопку «Редактировать конфигурацию». Нажмите на нее и откройте Mod Sec2 Rules.

C) Прокрутите вниз, пока не найдете следующую запись под слоганом #Spam Boty —

SecRule HTTP_User-Agent "^ Shockwave Flash"

D) Нам нужно изменить эту запись, чтобы добавить идентификатор, чтобы мы могли ссылаться на него позже в нашем переопределении mod_security. Скопируйте это правило в новую строку, закомментируйте старое правило и добавьте:

#SecRule HTTP_User-Agent "^ Shockwave Flash"

SecRule HTTP_User-Agent "^ Shockwave Flash" "id: xxxxxxxxxx"

Замените «xxxxxxxxxx» на любой номер, который будет использоваться в качестве идентификатора для этого правила. Неважно, что это за номер, но вы должны помнить его на шаге 2 (С) в этих инструкциях.

E) Вернитесь к правилу Modsec2 и убедитесь, что 2 строки ниже не читаются в вашем файле Modsec2. Линии должны выглядеть следующим образом;

## белый список ##

Включить "/usr/local/apache/conf/modsec2/whitelist.conf"

Включить "/usr/local/apache/conf/modsec2/custom.conf"

На шаге 2 мы внесем изменения в файл custom.conf и хотим убедиться, что наши изменения включены в правила ModSec2.

F) Сохраните этот файл, нажав кнопку «Сохранить конфигурацию» внизу страницы.

Шаг 2 —

А) Теперь откройте SSH-соединение с сервером, используя ваш любимый SSH-клиент. Мы использовали Putty для наших целей.

B) CD do / usr / local / apache / conf / modsec2 /

C) Используя vi, измените файл custom.conf следующим образом;

SecRuleRemoveById xxxxxxxxxx

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

Опять же, важно заменить «xxxxxxxxxx» на любой номер, выбранный на шаге 1 (D) выше. Этот номер является произвольным идентификатором, который мы присвоили и используем для определения роли безопасности Mod_sec2, которую мы хотим заменить.

D) Перезагрузите сервер, чтобы внести изменения, которые были сделаны.

Когда сервер вернется в онлайн-режим после перезагрузки компьютера, проверьте свои изменения, загрузив файл на сайт WordPress с помощью Flash Uploader. Если вы выполнили все шаги правильно, ваш файл теперь должен быть отправлен правильно без ошибки Dreaded HTTP!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *