Cum să ascunzi faptul că un site folosește WordPress?

Un aspect care este adesea neglijat - șterge fișierul readme.html din directorul rădăcină al WordPress. Acesta nu doar identifică instalarea ca fiind WordPress, dar conține și versiunea exactă. Și nu uita să repeți acest pas după actualizări.

Întrebare înrudită: Cum să împiedici accesul sau să ștergi automat readme.html, license.txt, wp-config-sample.php

Singurul răspuns valid: IMPOSIBIL

Atât de multe răspunsuri cu multe voturi... este timpul să lămurim lucrurile. Adevărul este că este practic imposibil și chiar dacă ar fi posibil, viața este probabil prea scurtă pentru a depune efortul necesar. Orice răspuns care promovează pași pentru a ascunde WP este doar o pierdere de timp și vă va induce în eroare, făcându-vă să credeți că ascundeți WP (ceea ce este absurd).

1) Problema nu sunt URL-urile evidente wp-*, meta generator etc. Problemele dificile sunt legate de modele asociate cu WordPress pe care un sistem creat de la zero nu le-ar implementa, cum ar fi paginile de autor, paginile de an, lună, zi, utilizarea parametrului p=nnn ca parametru valid, prezența formularului de comentarii cu clasa, structura și numele de link specifice WordPress, fără a mai vorbi de auto-promovarea plugin-urilor de caching și Yoast SEO și probabil multe alte plugin-uri pe care le vedeți doar când inspectați HTML-ul în sine.

2) Există și alte metode nenumărate care arată existența WP (și nu le puteți învinge):

• Chiar și header-ul de răspuns PHP (după cum a observat Dan Gayle mai jos) returnează un header specific WP.

• Oricine poate interoga oricare dintre zeci de fișiere .php din rădăcină: site.com/wp-cron.php sau site.com/xmlrpc.php (sau altele, pe care nu le puteți ascunde) și răspunsul header va fi 200 în loc de 404 not found.

• oricine poate verifica dacă există endpoint-uri JSON pentru a obține un răspuns specific WP.

• În interiorul HTML-ului paginii, multe dintre fișierele .css sau .js conțin fraze specifice, care se referă clar la WP.

• În HTML-ul paginii, este ușor să găsiți elemente/clase CSS, cum ar fi <div class="entry-content post-14"... sau altele (care este un indiciu direct că structura folosită este cea a WP).

• În HTML-ul paginii, veți vedea cu ușurință folderul uploads, sau chiar dacă îl redenumiți prin hardcodare, partea cu data precum uploads/2018/05/image.jpg (sau chiar image-315x225.jpg) arată structura tipică WP.

• cum multe site-uri sunt acum construite folosind MultiSite, acestea folosesc link-uri precum /site/2...

• ping către oricare readme al plugin-urilor/temelor (toate conțin), precum nume-plugin/readme.txt, returnând status 200.

• și multe, multe, multe alte lucruri pe care nici voi (nici măcar profesioniștii) nu le veți putea ascunde și doar vă veți pierde zilele!

Concluzie

Și chiar dacă depuneți efortul de a curăța tot ce indică faptul că acesta este un WordPress, este posibil să fie nevoie să refaceți sau măcar să reverificați după fiecare actualizare de plugin sau de nucleu. Viața este pur și simplu prea scurtă pentru asta.

S-ar putea să-i păcăliți pe niște diletanti, dar nu vă puteți ascunde de un inspector bun. Dacă faceți asta ca măsură de securitate, atunci este o securitate prin obscuritate, ceea ce este întotdeauna greșit, iar dacă vă este rușine că folosiți WordPress, permiteți-mi să vă spun ceva - nimănui nu-i pasă, iar chiar și acei puțini cărora le pasă probabil nu vor ști să descopere singuri.

Singurul lucru de care ar trebui să vă pese este să protejați WordPress cât de mult puteți și să monitorizați actualizările sale regulate.

Am folosit întotdeauna metoda Roots Theme.
Dar aplicarea ei pe temele din ThemeJungle este de obicei o durere de cap.

Așa că am început să experimentez cu constantele WP_CONTENT_*. Cred că aceasta este o metodă mult mai puțin predispusă la erori și iată ce am reușit să funcționeze până acum:

^{/m este folderul uploads, /t este folderul themes și /t/t este folderul temei active. Site-ul nu este complex, deci sunt încărcate puține resurse...}

WP_CONTENTLESS

wp-config.php

Setarea wp-content în rădăcina site-ului (/public_html/).

/** 
 În WP_CONTENT, următoarele foldere ar trebui să existe: 
 /languages , /mu-plugins , /plugins , /themes , /upgrade , /uploads  

 Definițiile WP_CONTENT_* de mai jos ELIMINĂ existența folderului /wp-content 
 și face ca conținutul său să rezide în RĂDĂCINA site-ului tău

 Este necesară o atenție MAXIMĂ atunci când efectuați activități de întreținere a fișierelor pe server (ex.: actualizări WP, schimbare de webmaster...), 
 deoarece folderele Themes și Plugins sunt destinate să fie redenumite în /t și /p (candidați serioși la ștergere necugetată)

 Vă rugăm să rețineți:
 - schimbăm folderul Plugins în definițiile WP_PLUGIN_*
 - folderul Themes este schimbat de un Plugin MustUse 
   (/mu-plugins/set-extra-themes-folder.php)
 - folderul Uploads este schimbat în pagina de setări WordPress 
   (http://example.com/wp-admin/options-media.php)
 - calea hardcodată care trebuie utilizată în WP_CONTENT_DIR și WP_PLUGIN_DIR poate fi verificată utilizând o acțiune în interiorul Plugin-ului set-extra-themes-folder (verificați comentariile din acest fișier)
*/
define( 'WP_CONTENT_DIR', '/www/htdocs/username/public_html' );
define( 'WP_CONTENT_URL', 'http://www.example.com' );

define( 'WP_PLUGIN_DIR', '/www/htdocs/username/public_html/p' );
define( 'WP_PLUGIN_URL', 'http://www.example.com/p' );

Am întrebat despre asta în [wp-hackers] - Any drawbacks in setting WP_CONTENT_DIR (and URL) to DOCUMENT_ROOT?, unde John Blackbourn¹, Mike Little² și Otto³ au fost suficient de amabili să ofere sfaturi:

^{1
Am avut această structură activă pe un site în ultimele 18 luni și nu am întâlnit probleme. Ca și în cazul oricărei modificări a locației directorului de conținut, va trebui să verificați dublu orice plugin adăugat pe site pentru a vă asigura că nu presupun că directorul de conținut este la wp-content.}

^{2
Există discuții pe internet conform cărora $_SERVER['DOCUMENT_ROOT'] poate fi vulnerabil la hacking. În acest caz, acest lucru este extrem de periculos deoarece există multe locuri unde require() sau include() WP_CONTENT_DIR . 'ceva';}

^{3
Există cazuri în care conținutul din $_SERVER poate fi perfect sigur, dar din motive de securitate, este mai bine să-l tratați întotdeauna ca pe date neîncrezătoare. Pentru acest caz specific, hardcodați directorul.}

Un nou folder pentru teme

/mu-plugins/set-extra-themes-folder.php

Deoarece nu există constante WP_THEMES_*, avem nevoie de funcția register_theme_directory() pentru a "Înregistra un director care conține teme."
Am încercat să setez directorul suplimentar în rădăcină, dar rezultatele sunt amuzante (adică: nu funcționează).

<?php
/*
    Plugin Name: Set Extra Themes Folder
    Version: 1.0
    Description: Permite utilizarea directorului - http://example.com/t - ca director suplimentar pentru teme
    Plugin URI: http://wordpress.stackexchange.com/questions/1507
    Author: brasofilo
    Author URI: http://rodbuaiz.com
*/


/**
 * Eliminați comentariul de la următoarea linie pentru a afla calea corectă de introdus în register_theme_diretory()
*/
//add_action( 'admin_head', 'brsfl_alert_directory_path' );

function brsfl_alert_directory_path()
{
    echo '<script type="text/javascript">
        alert("Director: '.$_SERVER['DOCUMENT_ROOT'].'");
    </script>';
}


/**
 * Următorul cod va permite utilizarea directorului "t" ca director suplimentar pentru teme
*/
register_theme_directory( '/www/htdocs/username/public_html/t' );


/**
 * Eliminarea scripturilor implicite din wp-includes pentru cele de pe CDN
*/
add_action('init', 'brsfl_init_scripts');

function brsfl_init_scripts() 
{
    if ( !is_admin() ) 
    {
        wp_deregister_script( 'jquery' );
        wp_deregister_script( 'swfobject' );
        wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', false, '1.7.1' );
        wp_register_script( 'swfobject', 'https://ajax.googleapis.com/ajax/libs/swfobject/2.2/swfobject.js', false, null, true );
        wp_enqueue_script( 'jquery' );
        wp_enqueue_script( 'swfobject' );
    }
}

Folderul Uploads

/wp-admin/options-media.php

În loc de http://example.com/uploads, va fi http://example.com/m.
Dacă debifați Organize my uploads into..., URL-urile resurselor vor avea un aspect WPless.
Dacă site-ul este live, va trebui efectuată o înlocuire în baza de date și mutarea fișierelor.

Plugin-uri și conținut head

Consultați răspunsul lui Cris_O în această întrebare.

Readme.html

Consultați răspunsul lui Rarst în această întrebare.

Alți pași

Ca de obicei, temele din ThemeJungle pot necesita modificări specifice în temă.
De exemplu... TimThumb care nu funcționează (!!!lol!!!).

Poți avea WordPress pe un server și să extragi conținutul de pe alt server, incluzând doar conținutul de care ai nevoie.

Dacă ai nevoie de RSS, ar trebui să faci același lucru și pentru acesta.

În esență, ar fi ca și cum ai servi pagini statice printr-un proxy sau CDN, dar doar părțile pe care vrei să le afișezi. Apoi, ai putea folosi un sistem de comentarii bazat pe JavaScript, cum ar fi Disqus.

Utilizare foarte redusă a resurselor, deoarece nu există baze de date pe serverul care servește conținutul.

Poți crea o adresă personalizată pentru a te autentifica în blogul tău. Astfel, nu vei mai folosi calea clasică "myblog.com/wp-admin" pentru a ajunge la panoul de control. Această pagină te va ajuta să creezi autentificări discrete, ceea ce este benefic și din punct de vedere al securității.

Astfel, persoanele care încearcă să acceseze blogul tău adăugând wp-admin la URL, nu vor putea ghici :)

Pe lângă cele menționate mai sus, trebuie să restricționați accesul la diferitele fișiere și directoare wp*. Dacă cineva ar dori să verifice dacă utilizați WordPress, ar putea încerca să ghicească dacă aveți wp-settings.php sau dacă ar putea accesa un anumit director. Returnarea unui cod 403 nu este suficientă, deoarece le spune utilizatorilor că resursa există; doar că nu au acces la ea.

Nu sunt un expert în Apache, așa că am pus această întrebare pe serverfault.

Nu uitați că o mulțime din informațiile din antetul HTTP care sunt trimise împreună cu cererea dvs. pot identifica site-ul ca fiind pe WordPress. De exemplu, dacă verifici antetele pe următoarele site-uri, este evident:

$ curl -I http://www.rollingstones.com/
Server: WP Engine/5.0

$ curl -I http://www.mattcutts.com
X-Powered-By: W3 Total Cache/0.9.1.3

$ curl -I http://blogs.reuters.com/us/
WP-Super-Cache: Served supercache file from PHP

Unele dintre acestea sunt setate de server, altele de plugin-uri, așa că nu există o singură metodă pentru a elimina 100% din ele, dar dacă folosești PHP 5.3 poți utiliza

header_remove("X-Foo"); (http://www.php.net/manual/en/function.header-remove.php)

pentru a elimina un antet PHP cunoscut înainte ca conținutul să fie trimis. Nu pot spune cu siguranță unde să plasezi acest cod (poate cineva poate completa cu această informație), dar probabil este sigur să-l pui chiar la începutul fișierului index.php ÎNAINTE de orice conținut care este trimis către browser.

Acest lucru poate fi greu de realizat dacă ești nou în PHP și mod_rewrite. Sugerez să verifici secțiunea din răspunsul meu. Sau poți încerca singur, poți folosi ceva de genul acesta pentru a ascunde structura căii wp-content/plugins:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^modules/(.*) /wp-content/plugins/$1 [L,QSA]
</IfModule>

Aceasta va schimba calea în /modules. Folosește ceva similar pentru alte structuri, poate fi nevoie de unele reguli de rescriere avansate, vezi http://httpd.apache.org/docs/current/mod/mod_rewrite.html pentru informații suplimentare despre mod_rewrite.

Dacă preferi ceva gata făcut, există câteva plugin-uri frumoase, unele comerciale, altele gratuite în depozitul WordPress, sugerez să încerci WP Hide & Security Enhancer. Acesta include multe funcționalități și ajută să schimbi aproape totul pentru a face WordPress-ul tău nerecunoscut. Iată câteva caracteristici ale codului:

• URL personalizat pentru Admin
• URL personalizat pentru Admin
• Blochează URL-ul implicit al adminului
• Blochează orice acces direct la dosare pentru a ascunde complet structura
• Nume de fișier personalizat pentru wp-login.php
• Blochează wp-login.php implicit
• Blochează wp-signup.php implicit
• Blochează API-ul XML-RPC
• Noua cale pentru XML-RPC
• URL personalizabil pentru temă
• URL nou pentru temă copil
• Schimbă numele fișierului de stil al temei
• wp-include personalizat
• Blochează căile implicite ale wp-include
• Blochează wp-content implicit
• URL-uri personalizate pentru plugin-uri
• Schimbă URL-ul individual al plugin-ului
• Blochează căile implicite ale plugin-urilor
• URL nou pentru încărcări
• Blochează URL-urile implicite pentru încărcări
• Elimină versiunea WordPress
• Blochează Meta Generator
• Dezactivează emoji și codul JavaScript necesar
• Elimină eticheta pingback
• Elimină Meta wlwmanifest
• Elimină Meta rsd_link
• Elimină wpemoji

și multe altele..

Nu vreau să repet opțiunile de codare, deoarece au fost acoperite în detaliu, cealaltă opțiune pe care o știu că funcționează este utilizarea unui plugin care ascunde wp. Am folosit acest plugin anterior cu rezultate satisfăcătoare. Se numește Hide My WordPress.

Majoritatea răspunsurilor se concentrează pe ascunderea WordPress în codul sursă al unei pagini, dar chiar înainte de asta, WP deja se trădează în header-ul HTTP al unei instalări standard. Încercați-vă propriul site pe un serviciu precum web-sniffer (simulați IE 6 și cereți un header HTTP 1.0) și veți vedea că printre răspunsuri se află:

<http://www.example.com/wp-json/>; rel="https://api.w.org/"

Acesta din urmă este un link către API-ul Wordpress.org. Este prezent de când API-ul REST a fost inclus în WP 4.4. Puteți să-l eliminați cu această linie chiar la începutul fișierului functions.php:

remove_action( 'template_redirect', 'rest_output_link_header', 11, 0 );

Multe plugin-uri, cum ar fi Jetpack pentru shortlink-urile sale, pot de asemenea insera link-uri în header-ul HTTP. Acestea pot face asta deoarece WP are un API HTTP, care vă permite să manipulați headerele. Puteți folosi această interfață pentru a elimina toate setările de header adăugate de plugin-uri dacă adăugați acțiunea suficient de târziu în proces.

În final, puteți folosi interfața de header din .htaccess pentru a intercepta orice face WP. De exemplu, puteți preveni trimiterea oricăror headere Link includând această linie:

<IfModule mod_headers.c>
Header unset Link
</IfModule>

Puteți personaliza o temă pentru a exclude toate informațiile despre WordPress. De asemenea, eliminați widget-ul meta și orice alt widget care ar afișa informații despre platformă.

Personal, prefer să-mi arăt recunoștința prin afișarea faptului că folosesc WordPress.

Puteți utiliza plugin-ul WPS Hide Login.
Vă autentificați în WordPress folosind wp-admin. Dar puteți schimba wp-admin cu un text personalizat folosind acest plugin.

Exemplu:

Înainte: http://example.com/wp-admin
După: http://example.com/text-personalizat-pentru-login