Як я затемнюю встановлення 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.

Я прочитав документацію на апаш; Теоретично я розумію поняття, але мені потрібна практична допомога.

EDIT: Я шукаю рішення, яке використовує .htaccess замість httpd.conf, оскільки моя конкретна установка робить використання httpd.conf непослідовним.

TLDR; Неможливо затьмарити WordPress, використовуючи лише директиви у вашому файлі .htaccess.

Тепер приходить казка про горе і жах. Наш друг, fbh мав рацію щодо труднощів у приховуванні WordPress, це не стосується жовтих трусів. Арр! Ось подробиці цієї (помилкової) пригоди. Будьте попереджені!

Мотивація

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

Кроки до вашої приреченості

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

   Контроль налаштувань 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-content Wordpress.stackexchange має чудову статтю про видалення wp-контенту. Вам доведеться переглядати деякі константи WP, і це дуже працює. Вам також доведеться перенаправляти всі звернення з wp-content"на будь-який вміст". Це, ймовірно, не буде проблемою, якщо це буде чисте розгортання. Якщо ви змінюєте раніше існуюче розгортання, вам доведеться зробити деякі додаткові речі.

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

6. Збирайте та замінюйте всі посилання на 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, будь ласка, не намагайтеся затьмарити WordPress. Це не варто.

Якщо ви намагаєтесь приховати, що ви використовуєте wordpress через сухарі, то вам справді належить виконати певну роботу. Якщо ви робите wp * хитрість, що з wp-content та wp-include? Не маючи можливості дістатись до них, ви зламаєте сторінку, і це буде виглядати жахливо.

Крім того, у Wordpress є так багато речей, що це дійсно потребує певної роботи - і вам, швидше за все, доведеться зробити це багато заново, коли буде встановлено оновлення. (Оскільки кілька переспрямувань в Apache не вдасться зробити трюк)

Якщо ви просто намагаєтесь приховати це від пана і пані всіх, то, звичайно, ви повинні мати змогу дещо це зробити з незрозумілістю.

Ви читали посібник із «загартовування Wordpress»? Якщо ні, то слід перевірити це: http://codex.wordpress.org/Hardening_WordPress Це чудовий вступ до багатьох речей, які ви можете зробити.

Крім того, якщо ви хочете приховати той факт, що ви використовуєте Wordpress, навіщо його використовувати?

Спробуйте виконати конфігурацію в конфігурації apache. Це може бути включати файл, як /etc/wordpress/htaccess. Це дозволить використовувати Directoryдирективу конфігурації. Однак вам потрібно буде перезапустити apache для завантаження змін. Використовуйте витончений перезапуск, якщо не хочете переривати обслуговування.

Для обмеження доступу до .htaccessфайлів файлами вони повинні знаходитись у відповідних каталогах. Вони функціонують так само, як вміст Directoryдирективи про конфігурацію. Можливо, вам потрібно буде включити необхідні .htaccessпараметри у вашій конфігурації apache. Цей метод не настільки ефективний, як використання команди в конфігурації apache, тому що його потрібно часто переробляти.