Как скрыть мою установку Wordpress через htaccess?

(Я знаю, что безопасность через неизвестность не рекомендуется).

Я пытаюсь скрыть тот факт, что я использую Wordpress. Этот пост полезен, но он касается только контента (вроде). Я заинтересован в следующем:

1. Пользователь пытается получить доступ к любому URL-адресу wp*в качестве подстроки через свой браузер.

   Результат: перенаправлен на 404 страницу.

2. Пользователь / администратор блога знает, чтобы войти в систему, на которую они должны зайти http://example.com/blogin/.

   Результат: Apache перенаправляет их наhttp://example.com/wp-admin/.

3. Если пользователь пытается получить прямой доступ wp-adminиз своего браузера, его отправляют на # 1.

   Результат: перенаправлен на 404 страницу.

То, что я сделал до сих пор

1. Для установки WordPress по умолчанию я заметил, что могу получить доступ к любым wp*файлам в (относительном) корневом каталоге установки WP. В частности, wp-settings.phpбыло проблематично, потому что он дал информацию о моей настройке. Если пользователь получит к нему доступ, он выдаст несколько ошибок PHP и покажет часть структуры каталога. Я отредактировал мой файл php.ini, чтобы display_errorsотключить. Теперь доступ http://example.com/wp-settngs.phpвызывает пустую страницу.

2. Само по себе это не идеально, потому что показывает, что wp-settings.phpсуществует. На самом деле, доступ ко всем различным wp*файлам возможен (с разными результатами). Затем я помещаю в файл htaccess следующее:

         RewriteEngine On
         RewriteBase /
         RewriteCond %{PATH_INFO} wp* [NC]
         RewriteRule .* - [F]
   

   Это сработало отлично! Все, что с, wp*было перенаправлено на мою страницу 404. Но теперь я не могу получить доступ к моей странице администратора.

3. Я попытался вставить эту строку в коде выше: RewriteRule ^blogin wp-admin [NC,R,L]. Это должно было быть сразу после, RewriteBaseно это не сработало.

4. Я пытался сделать:

   <Directory /home/example/wp*> 
    Order Allow, Deny 
    Allow from example.com 
    Deny from all 
   </Directory> 
   

   надеясь, что референт с моего сайта (через переписывание правила) сможет получить доступ к wp-admin, но не кто-то извне. Это тоже не сработало. apache пожаловался, что вы не можете использовать эту директиву из htaccess.

Я прочитал документацию Apache; Я понимаю концепции теоретически, но мне нужна практическая помощь.

РЕДАКТИРОВАТЬ: Я ищу решение, которое использует .htaccess вместо httpd.conf, так как моя конкретная настройка делает использование httpd.conf несовместимым.

TLDR; Невозможно скрыть WordPress, используя только директивы в вашем файле .htaccess.

Теперь приходит рассказ о горе и ужасе. Наш друг, fbh, был прав насчет сложности сокрытия WordPress, не для пузатых трусов. ARR! Вот подробности этого (неправильного) приключения. Вы должны быть предупреждены!

мотивация

Я один из тех парней, которым нравятся идеальные вещи. Я буду тратить впустую время на разработку чего-то, чтобы быть «правильным путем». Одна из вещей, которые мне не понравились в настройке WordPress по умолчанию, заключалась в том, что пользователь мог набрать http://ex.com/wp-settings.php, и тогда весь этот php жаргон вылетел бы повсюду. В конце концов мне удалось отключить ошибки через PHP, но это привело к большему желанию иметь только те вещи, которые были сделаны с тех пор, как можно найти ресурсы с сервера ... и что все остальное будет 404/3 'указано на нашей странице пользовательского поиска. После этого у меня появилась идея, что я хотел бы полностью скрыть базовый фреймворк (т.е. WP) ... в любом случае ... если вы хотите скрыть WP, это возможно. Но это действительно сложно.

Шаги к твоей гибели

1. Измените настройки PHP ini соответствующим образом. (т.е. отключите отображение ошибок). Вы можете подумать, что это не нужно, потому что, если мы используем .htaccess для перенаправления, люди не увидят ошибок, потому что они не смогут получить доступ к ресурсам, вызывающим ошибки (я смотрю на вас wp-settings.php). Но ошибки могут появляться на отображаемых страницах, поэтому вы определенно хотите их устранить. То, что WP_*директивы установлены, не обязательно означает, что все будет работать так, как вы думаете. Я обнаружил, что на моем сервере мне пришлось установить display_errors на false FIRST, потому что WP_DISPLAY_ERRORS предполагал, что по умолчанию установлено значение false.

   Управление настройками PHP ini может быть таким же простым, как помещение директивы в ваш файл .htaccess. Или, в моем случае, так сложно, как создать обработчик CGI и затем поместить туда файл php.ini. YMMV в зависимости от вашей настройки.

2. Удалите весь доступ к файлам / каталогам с wp-префиксом. Идея заключается в том, что ваше развертывание WP связано с вашим контентом, а не с WP (если только он специально не ориентирован на WP). Людям не имеет смысла хотеть видеть то, что имеет http; // ex.com/wp-cron.php ... если они не имеют ничего хорошего. Я достиг этого через это:

    # If the resource requested is a `wp-*` file or directory, poop to a 403. 
    RewriteCond %{REQUEST_FILENAME} wp-.*$ [NC] 
    RewriteCond %{ENV:REDIRECT_STATUS} ^$ 
    RewriteCond %{REQUEST_FILENAME} -f [NC,OR] 
    RewriteCond %{REQUEST_FILENAME} -d [NC] 
    RewriteRule .* - [F,L] 
   

3. Узнайте, как просто пройти через Мордор. Отменив все права доступа, wp-*вы больше не сможете получить доступ к административной части WP. Это действительно отстой. В дополнение к этому депрессивному, вы только что поняли, что вы не знаете, что на RewriteCond %{ENV:REDIRECT_STATUS} ^$самом деле. Ну, я попытался сделать «секретный» бэкдор на страницу администратора WP. Я использовал этот код:

    # If the resource requested is 'mordor' (with or without an ending
    # slash) do a URL rewrite to `wp-login.php`. 
    RewriteCond %{REQUEST_URI} mordor/?$ [NC]
    RewriteRule mordor/?$ /wp-login.php [NC,L]
   

   Поэтому URL: http://ex.com/mordor должен привести нас к странице входа. Причина, по которой у нас была REDIRECTстрока на шаге выше, заключается в том, что, поскольку этот URL перезаписывается в wp-*URL, мы не хотим, чтобы первое правило перезаписи получало его. Поскольку он перенаправляется изнутри, REDIRECT_STATUSон будет настроен правильно, и это не подтолкнет нас к 403/4 земле.

4. Удалить wp-контент. В Wordpress.stackexchange есть отличная статья по удалению wp-контента. Вы должны переопределить некоторые константы WP, и это в значительной степени работает. Вы также должны перенаправить все обращения wp-contentк «what-content». Это, вероятно, не будет проблемой, если это чистое развертывание. Если вы изменяете уже существующее развертывание, вам придется сделать некоторые дополнительные вещи.

5. Переписывать URL-адреса в wp-контент необязательно RewriteRule (.*)(wp-content)(.*) $1whatever-content$3 [NC,R,L] . Это идет в вашем файле .htaccess. Если ваш пользователь попытается получить доступ к некоторому старому контенту через wp-contentURL, он будет перенаправлен сюда.

6. Grep и заменять все ссылки на wp-контент в вашей БД необязательно . Вы все еще есть wp-contentв вашей базе данных. Если вы хотите освободить WP, вам нужно избавиться от этого. Я экспортировал / mysql выгрузил свою базу данных, сделал поиск и заменил wp-contentстроку на новую строку. Вы можете сказать ... зачем мне это делать, если apache перепишет мои URL? Проблема в том, что исходный код будет содержать эти ссылки, поэтому, если вы действительно заинтересованы в маскировке WordPress, вам нужно это сделать. Примечание: на данный момент я должен был просто остановиться и принять реальность, что это не сработает. Но я хотел, чтобы мистер Т пожалел меня.

7. Заменить все ссылки на wp-includesи wp-adminв источнике. Большая часть функциональности WordPress зависит от этих двух каталогов: wp-includesи wp-admin. Это означает, что эти имена каталогов жестко закодированы в исходном коде. Это означает, что вам придется создавать новые каталоги (поскольку PHP использует базовую файловую систему ОС, а не apache) для доступа к ним, а затем ЗАПИСЫВАЕТ ЭТИ ИЗДЕЛИЯ в выдаваемый html. Это просто слишком много проблем. Я быстро сдался и пошел в ванную за какашками.

Урок

Конечно, я мог бы просто прочитать http://codex.wordpress.org/Hardening_WordPress и следовать этим шагам. Но я хотел идеальный сайт. Теперь я просто хочу вернуть все эти часы. Самое большое, что мешало мне остановиться, было то, что я нигде не читал в Интернете, что это было много работы и почти невозможно сделать. Вместо этого я читаю о людях, пытающихся сделать это без ощущения, были ли они успешными или нет. Итак, моему прошлому себе, которому я отправлю это через Apple Time Machine, пожалуйста, не пытайтесь скрыть WordPress. Это того не стоит.

Если вы пытаетесь скрыть, что используете WordPress из-за взломщиков, то вам действительно есть над чем поработать. Если вы делаете трюк с wp *, как насчет wp-content и wp-includes? Не имея возможности добраться до них, вы сломаете страницу, и это будет выглядеть ужасно.

Кроме того, в Wordpress так много вещей, что это действительно требует некоторой работы - и вам, скорее всего, придется делать это снова, когда установлено обновление. (Поскольку некоторые перенаправления в Apache не сработают)

Если вы просто пытаетесь скрыть это от мистера и миссис всех, тогда, конечно, вы должны быть в состоянии сделать это с неясностью.

Вы читали руководство по "ужесточению Wordpress"? Если нет, вы должны проверить это: http://codex.wordpress.org/Hardening_WordPress Это дает хорошее представление о многих вещах, которые вы можете сделать.

Кроме того, если вы хотите скрыть тот факт, что вы используете Wordpress, зачем его использовать?

Попробуйте выполнить настройку в конфигурации apache. Это может быть включение файла, как /etc/wordpress/htaccess. Это позволит вам использовать Directoryдирективу конфигурации. Однако вам нужно будет перезапустить apache для загрузки изменений. Используйте постепенный перезапуск, если вы не хотите прерывания обслуживания.

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