Securitate și fișierul .htaccess în WordPress

12 aug. 2010, 17:28:13
Vizualizări: 2.96K
Voturi: 8

Acum aproximativ o lună am început un blog WordPress pe un server găzduit, legat de un hobby. Așadar, sunt nou în acest domeniu momentan.

Deoarece sunt preocupat de securitate, un lucru pe care l-am făcut a fost să instalez pluginul WP Security Scan. Conform rezultatelor pluginului, site-ul meu este în regulă, cu excepția faptului că primesc acest avertisment în rezultate ca fiind o problemă:

Fișierul .htaccess nu există în wp-admin/ (am verificat prin SSH și într-adevăr nu există)

Am căutat considerabil informații despre această problemă și am găsit prea multe detalii despre .htaccess. Am parcurs secțiunea "Hardening WordPress" pe site-ul WordPress.org, etc. Și am dat peste acest articol: http://digwp.com/2010/07/wordpress-security-lockdown/

În orice caz, m-am confuzat din cauza abundenței de informații disponibile.

Ce ar trebui să conțină fișierul .htaccess în wp-admin? Am citit că acest fișier .htaccess ar trebui să protejeze cu parolă directorul wp-admin și, de asemenea, am citit că acest lucru poate cauza probleme de funcționalitate.

Orice ajutor în acest sens este foarte apreciat.

Mulțumesc. -wdypdx22

Actualizare Ok, acum nu sunt autentificat pe blogul meu și folosesc un computer diferit de cel obișnuit. Introduc URL-ul www.mysite.com/wordpress/wp-admin/ și există o redirecționare către pagina de login. Dacă asta se întâmplă, atunci este chiar necesar un fișier htaccess în directorul wp-admin?

2
Comentarii

Ai încercat să întrebi dezvoltatorul WP Security Scan?

Doug Doug
12 aug. 2010 18:42:57

@Doug - Da, dezvoltatorul are un forum cu cel puțin 2 alte persoane care pun exact aceeași întrebare și niciun răspuns. De asemenea, am postat pe wordpress.org și nici acolo nu am primit răspuns. Deci, poate că nu contează chiar deloc?

wdypdx22 wdypdx22
12 aug. 2010 19:52:28
Toate răspunsurile la întrebare 4
5

ACTUALIZARE: Când am postat prima dată răspunsul meu, am ratat esența întrebării; răspunsul meu era despre securitatea generală a .htaccess și este acum listat sub linia dublă (uită-te mai jos dacă te interesează.) Din păcate, nu am experiență specifică în securizarea /wp-admin/ folosind .htaccess, așa că voi enumera pur și simplu cele două resurse pe care le voi urmări când și dacă voi avea nevoie:

Prima recomandă următoarele (și aici este o discuție despre asta.)

<Files ~ "\.(php)$">
AuthUserFile /etc/httpd/htpasswd
AuthType Basic
AuthName "restricted"
Order Deny,Allow
Deny from all
Require valid-user
Satisfy any
</Files>

Ultima are multă informație, în special în comentarii, dar recunosc că furnizarea unei liste de citit nu este răspunsul pe care îl căutai.

Îmi pare rău că nu am putut fi mai de ajutor în această privință.

========================================

În mod obișnuit, WordPress are doar următoarele, care gestionează procesarea permalink-urilor și nu este legat de securitate:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Recent am descoperit plugin-ul WP htaccess Control care gestionează o mare parte din .htaccess pentru tine și îmi place foarte mult. După ajustarea setărilor sale, a adăugat următoarele opțiuni:

# WPhtC: Dezactivează ServerSignature pe paginile de eroare generate
ServerSignature Off

# WPhtC: Dezactivează navigarea în director
Options All -Indexes

# WPhtC: Protejează WP-config.php
<files wp-config.php>
order allow,deny
deny from all
</files>

# WPhtC: Protejează fișierul .htaccess
<files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
</files>

De asemenea, a adăugat aceste opțiuni care sunt despre performanță și nu despre securitate:

# WPhtC: Setare mod_gzip
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

# WPhtC: Setare mod_deflate
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent env=!dont-vary
</IfModule>

Pe lângă acesta, există câteva plugin-uri pe care nu le-am încercat, dar care se concentrează pe securitate și care interacționează cu .htaccess - ai putea să le încerci pe fiecare doar pentru a vedea ce fac cu fișierul .htaccess:

Pe lângă asta, dacă vrei să știi resursa (IMO) #1 expertă despre securitatea Apache legată de WordPress, o poți găsi pe AskApache.com; tipul este hardcore! Blogul său nu va rezolva problema ta "prea multă informație", dar cel puțin poți să-l vezi ca pe o resursă autoritară!

Iată câteva exemple (deși nu toate sunt direct legate de WordPress, toate sunt aplicabile):

Oricum, sper că acest lucru este de ajutor.

12 aug. 2010 18:27:52
Comentarii

Informații excelente pentru securitatea generală, dar nu răspunde despre folderul /wp-admin/

Ryan Gibbons Ryan Gibbons
12 aug. 2010 18:36:49

Deși aceste informații pot fi utile, niciuna nu are legătură cu întrebarea. Toate se referă la .htaccess în directorul rădăcină. Întrebarea inițială era despre .htaccess în subdirectorul wp-admin.

Doug Doug
12 aug. 2010 18:45:07

@Insanity5902 @Doug: Scuzele mele. Pur și simplu nu am văzut asta când am citit.

MikeSchinkel MikeSchinkel
12 aug. 2010 18:59:31

Am acceptat răspunsul tău în principiu pentru că, la urma urmei, securitatea generală este scopul meu. Blogul meu este foarte nou, dar traficul meu este în creștere. Practic, doresc să am măsuri de securitate în cazul în care voi începe să primesc mult trafic. -Mulțumesc

wdypdx22 wdypdx22
12 aug. 2010 20:28:03

@wdypdx - Mulțumesc mult. M-am simțit foarte jenat când am realizat că am ratat întrebarea ta principală scrisă cu bold. Mă bucur că totul a ieșit bine.

MikeSchinkel MikeSchinkel
12 aug. 2010 20:29:52
0

Ideea din spatele acestei măsuri este că, dacă aveți fișiere reziduale rămase din actualizări anterioare sau vulnerabilități zero-day, sistemul dumneavoastră ar putea fi hackuit. De asemenea, securizarea wp-admin prin altă metodă va ajuta împotriva atacurilor brute-force.

O idee) Dacă doar dumneavoastră editați site-ul, puteți limita accesul la director după IP făcând ceva de genul:

<Files *>
Order deny,allow
Deny from All
Allow from 1.2.3.4
</Files>

Pentru a face acest lucru mai tolerabil pentru sistemele cu IP dinamic; ar trebui să puteți permite un subbloc, deci dacă dvs. aveți un pool de IP-uri întotdeauna între 1.2.3.128 - 1.2.3.255, atunci puteți face ceva de genul 1.2.3.128/25

Altă idee) Cereți HTTPS, dați o eroare de permisiune refuzată dacă se încearcă accesul prin http. Dar nu redirecționați utilizatorii către https. Puteți folosi un certificat auto-semnat sau unul de la CA Cert pentru a evita achiziționarea unuia.

12 aug. 2010 18:32:56
3

Eu includ întotdeauna un fișier .htaccess în wp-admin, chiar dacă nu pun niciodată nimic în el, deoarece anulează fișierul din directorul rădăcină. Unii oameni folosesc fișierul .htaccess din wp-admin pentru a ascunde întregul director de toate adresele IP, cu excepția uneia singure, alții îl folosesc pentru a proteja directorul cu parolă.

Cu toate acestea, protejarea secțiunii de administrare cu .htaccess va dezactiva comunicațiile ajax, deoarece acestea interacționează cu wp-admin/admin-ajax.php.

În general, nu văd prea multe motive să adăugați ceva în fișierul .htaccess al administratorului, decât dacă sunteți extrem de paranoici. Atacurile vizează de obicei wp-content oricum.

12 aug. 2010 18:21:09
Comentarii

Un fișier .htaccess într-un subdirector poate suprascrie directiunile din directorul rădăcină, dar un fișier .htaccess gol nu anulează nimic.

Doug Doug
12 aug. 2010 18:48:10

Atunci am fost informat greșit. Hmmmm...

John P Bloch John P Bloch
12 aug. 2010 18:50:04

Ceea ce trebuie să faci este să inversezi ceea ce este în rădăcină, dacă există ceva. Cu toate acestea, răspunsul lui Insanity este mai bun decât cel marcat drept cel mai bun, deși ar fi mai bine dacă ar conține informațiile lui Insanity.

Arlen Beiler Arlen Beiler
13 aug. 2010 15:25:42
0

Eu folosesc și biblioteca sseqlib pentru mai multă securitate și diverse hack-uri în fișierul .htaccess; vezi linkurile

13 aug. 2010 14:14:37