Việc di chuyển wp-config bên ngoài web root có thực sự có lợi?


135

Một trong những thực tiễn tốt nhất về bảo mật phổ biến nhất hiện nay dường như là di chuyển wp-config.phpmột thư mục cao hơn thư mục gốc của vhost . Tôi chưa bao giờ thực sự tìm thấy một lời giải thích tốt cho điều đó, nhưng tôi cho rằng nó sẽ giảm thiểu rủi ro của một tập lệnh độc hại hoặc bị nhiễm trong webroot khi đọc mật khẩu cơ sở dữ liệu.

Nhưng, bạn vẫn phải để WordPress truy cập nó, vì vậy bạn cần mở rộng open_basedirđể bao gồm thư mục phía trên tài liệu gốc. Không phải điều đó chỉ đánh bại toàn bộ mục đích, và cũng có khả năng phơi bày nhật ký máy chủ, sao lưu, vv cho những kẻ tấn công sao?

Hoặc là kỹ thuật chỉ cố gắng ngăn chặn một tình huống wp-config.phpsẽ được hiển thị dưới dạng văn bản thuần túy cho bất kỳ ai yêu cầu http://example.com/wp-config.php, thay vì bị phân tách bởi công cụ PHP? Điều đó có vẻ như là một sự cố rất hiếm gặp và nó sẽ không vượt quá những nhược điểm của việc lộ nhật ký / sao lưu / vv đối với các yêu cầu HTTP.

Có lẽ bạn có thể di chuyển nó ra bên ngoài gốc tài liệu trong một số thiết lập lưu trữ mà không để lộ các tệp khác, nhưng không phải trong các thiết lập khác?


Kết luận: Sau rất nhiều lần qua lại về vấn đề này, hai câu trả lời đã xuất hiện mà tôi nghĩ nên được coi là những câu có thẩm quyền. Aaron Adams là một trường hợp tốt để ủng hộ việc di chuyển wp-config, và chrisguitarguy làm cho một trường hợp tốt chống lại nó . Đó là hai câu trả lời bạn nên đọc nếu bạn chưa quen với chủ đề này và không muốn đọc toàn bộ. Các câu trả lời khác là dư thừa hoặc không chính xác.


Thật sự không cần thiết phải cắm lựa chọn câu trả lời của bạn và từ chối tất cả các câu trả lời khác, bên trong câu hỏi của bạn. Như bạn có thể thấy bên dưới, đó là hệ thống bỏ phiếu stackexchange để làm gì, để bỏ phiếu cho câu trả lời có ý nghĩa với mọi người, trong khi người hỏi nên sử dụng cơ chế "câu trả lời được chấp nhận" và phiếu bầu lên / xuống của chính bạn.
Kzqai

6
Tôi không làm điều đó cho 99% câu hỏi tôi đã hỏi, nhưng tôi nghĩ nó phù hợp trong trường hợp cụ thể này. Có 8 câu trả lời cho câu hỏi, một số trong đó khá dài / phức tạp và một số trong đó có rất nhiều câu trả lời mặc dù có chứa thông tin không chính xác hoặc không thêm bất cứ điều gì vào cuộc hội thoại. Tôi nghĩ rằng việc đưa ra một kết luận bán có thẩm quyền là hữu ích cho những người đọc chủ đề lần đầu tiên. Như mọi khi, độc giả có thể tự do tạo nên tâm trí của họ; Tôi chỉ đưa ra ý kiến ​​của mình với tư cách là OP.
Ian Dunn

1
@Kzqai: "Hệ thống bỏ phiếu stackexchange" là một quy trình dân chủ và những người tham gia thường 1) không rõ ràng về những gì OP thực sự yêu cầu hoặc cố gắng giải quyết, và 2) không hiểu được tính hợp lệ của câu trả lời cụ thể nào. Sau khi các câu trả lời bị lừa và các phiếu đã được bỏ, sẽ rất hữu ích khi OP làm rõ những phản hồi đó cung cấp hỗ trợ. Rốt cuộc, OP là người duy nhất biết và tôi ước nhiều OP làm như vậy. Đúng, mọi người "bỏ phiếu trả lời có ý nghĩa với mọi người", nhưng hãy để OP có lời cuối cùng về những gì có ý nghĩa với anh ta.
Mac

Câu trả lời:


127

Câu trả lời ngắn gọn: có

Câu trả lời cho câu hỏi này là không rõ ràng , và nói cách khác là hoàn toàn vô trách nhiệm .


Câu trả lời dài: một ví dụ thực tế

Cho phép tôi cung cấp một ví dụ rất thực, từ máy chủ rất thực của tôi, nơi di chuyển wp-config.phpbên ngoài web root đặc biệt ngăn không cho nội dung của nó bị bắt .

Con bọ:

Hãy xem mô tả về lỗi này trong Plesk (được sửa trong 11.0.9 MU # 27):

Plesk đặt lại chuyển tiếp tên miền phụ sau khi đồng bộ hóa đăng ký với gói lưu trữ (117199)

Nghe có vẻ vô hại đúng không?

Chà, đây là những gì tôi đã làm để kích hoạt lỗi này:

  1. Thiết lập một tên miền phụ để chuyển hướng đến một URL khác (ví dụ như site.staging.server.comđể site-staging.ssl.server.com).
  2. Đã thay đổi gói dịch vụ của thuê bao (ví dụ: cấu hình PHP của nó).

Khi tôi làm điều này, Plesk đặt lại tên miền phụ thành mặc định: phục vụ nội dung của ~/httpdocs/, không có trình thông dịch (ví dụ PHP) hoạt động.

Và tôi đã không thông báo. Cho vài tuần.

Kết quả:

  • Với wp-config.phptrong web root, một yêu cầu /wp-config.phpsẽ tải xuống tệp cấu hình WordPress.
  • Với wp-config.phpbên ngoài web root, yêu cầu /wp-config.phptải xuống một tệp hoàn toàn vô hại. Các wp-config.phptập tin thực sự không thể được tải xuống.

Vì vậy, rõ ràng là việc di chuyển ra wp-config.phpngoài web root có lợi ích bảo mật thực sự trong thế giới thực .


Cách di chuyển wp-config.phpđến bất kỳ vị trí nào trên máy chủ của bạn

WordPress sẽ tự động xem một thư mục phía trên cài đặt WordPress cho wp-config.phptệp của bạn , vì vậy nếu đó là nơi bạn đã di chuyển nó, bạn đã hoàn tất!

Nhưng nếu bạn đã chuyển nó đi nơi khác thì sao? Dễ dàng. Tạo một cái mới wp-config.phptrong thư mục WordPress với đoạn mã sau:

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(Hãy chắc chắn thay đổi đường dẫn trên thành đường dẫn thực tế của wp-config.phptệp được di chuyển của bạn .)

Nếu bạn gặp vấn đề với open_basedir, chỉ cần thêm đường dẫn mới vào lệnh open_basedirtrong cấu hình PHP của bạn:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

Đó là nó!


Chọn các đối số trái ngược nhau

Mọi đối số chống lại việc di chuyển wp-config.phpbên ngoài web gốc đều dựa trên các giả định sai.

Đối số 1: Nếu PHP bị tắt, họ đã tham gia

Cách duy nhất ai đó sẽ thấy nội dung của [ wp-config.php] là nếu họ phá vỡ máy chủ của bạn Trình thông dịch PHP, nếu điều đó xảy ra, bạn đã gặp rắc rối: họ có quyền truy cập trực tiếp vào máy chủ của bạn.

SAI : Kịch bản tôi mô tả ở trên là kết quả của việc cấu hình sai, không phải là sự xâm nhập.

Luận điểm 2: Vô tình vô hiệu hóa PHP là rất hiếm, và do đó không đáng kể

Nếu kẻ tấn công có đủ quyền truy cập để thay đổi trình xử lý PHP, thì bạn đã bị lừa. Những thay đổi ngẫu nhiên rất hiếm khi xảy ra theo kinh nghiệm của tôi và trong trường hợp đó, thật dễ dàng để thay đổi mật khẩu.

SAI : Kịch bản tôi mô tả ở trên là kết quả của một lỗi trong một phần mềm máy chủ chung, ảnh hưởng đến cấu hình máy chủ chung. Điều này hầu như không "hiếm" (và bên cạnh đó, bảo mật có nghĩa là đáng lo ngại về kịch bản hiếm gặp).

WTF : Thay đổi mật khẩu sau khi xâm nhập hầu như không giúp ích gì nếu thông tin nhạy cảm được chọn trong quá trình xâm nhập. Thực sự, chúng ta vẫn nghĩ rằng WordPress chỉ được sử dụng cho viết blog thông thường và những kẻ tấn công chỉ quan tâm đến sự đào tẩu? Hãy lo lắng về việc bảo vệ máy chủ của chúng tôi, không chỉ khôi phục nó sau khi có người vào.

Luận điểm 3: Từ chối truy cập wp-config.phplà đủ tốt

Bạn có thể hạn chế quyền truy cập vào tệp thông qua cấu hình máy chủ ảo hoặc .htaccess- hạn chế quyền truy cập bên ngoài vào tệp theo cách tương tự như việc di chuyển bên ngoài gốc tài liệu.

SAI : Hãy tưởng tượng máy chủ của bạn mặc định cho một máy chủ ảo là: không có PHP, không .htaccess, allow from all(hầu như không bình thường trong môi trường sản xuất). Nếu cấu hình của bạn bằng cách nào đó được đặt lại trong một hoạt động thông thường - như giả sử, cập nhật bảng điều khiển - mọi thứ sẽ trở lại trạng thái mặc định và bạn sẽ tiếp xúc.

Nếu mô hình bảo mật của bạn không thành công khi cài đặt vô tình được đặt lại thành mặc định, bạn cần bảo mật hơn.

WTF : Tại sao mọi người đặc biệt khuyên dùng ít lớp bảo mật hơn? Những chiếc xe đắt tiền không chỉ có ổ khóa; họ cũng có báo động, cố định và theo dõi GPS. Nếu cái gì đó đáng để bảo vệ, hãy làm nó đúng.

Luận điểm 4: Truy cập trái phép không phải wp-config.phplà vấn đề lớn

Thông tin cơ sở dữ liệu thực sự là thứ nhạy cảm duy nhất trong [ wp-config.php].

SAI : Các khóa xác thực và muối có thể được sử dụng trong bất kỳ số lần tấn công chiếm quyền điều khiển nào.

WTF : Ngay cả khi thông tin cơ sở dữ liệu là thứ duy nhất wp-config.php, bạn sẽ cảm thấy sợ hãi khi kẻ tấn công chạm tay vào chúng.

Đối số 5: Di chuyển wp-config.phpbên ngoài web root thực sự làm cho máy chủ kém an toàn hơn

Bạn vẫn phải cho phép WordPress truy cập [ wp-config.php], vì vậy bạn cần mở rộng open_basedirđể bao gồm thư mục phía trên thư mục gốc.

SAI : Giả sử wp-config.phplà vào httpdocs/, chỉ cần di chuyển nó đến ../phpdocs/và đặt thành open_basedirchỉ bao gồm httpdocs/phpdocs/. Ví dụ:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

(Hãy nhớ luôn luôn bao gồm /tmp/hoặc tmp/thư mục người dùng của bạn , nếu bạn có.)


Kết luận: các tệp cấu hình phải luôn luôn được đặt bên ngoài web root

Nếu bạn quan tâm đến bảo mật, bạn sẽ di chuyển ra wp-config.phpngoài web root của mình.


1
Nếu bạn có một lỗi trong apache, linux hoặc bộ não của quản trị viên, bạn là một người nướng bánh mì trong mọi trường hợp. Trong kịch bản của bạn, bạn không thể giải thích được tại sao nhiều khả năng xảy ra việc cấu hình sai xảy ra ở thư mục gốc của trang web sau đó ở bất kỳ nơi nào khác trên máy chủ. Một apache được định cấu hình sai có thể có thể truy cập /../config.php dễ dàng như /config.php
Đánh dấu Kaplun

1
Bạn không phải là "bánh mì nướng trong mọi trường hợp." Nó là rất có thể xảy ra , và thậm chí có thể chứng minh , đó là một lỗi sẽ cho kết quả trong thư mục gốc web reset tạo vật với mặc định của nó, trong trường hợp bạn không phải là "bánh mì nướng" - bạn wp-config.phpvẫn an toàn. Và nó cực kỳ không thể thực hiện được - đến mức về cơ bản là không thể - rằng một lỗi sẽ dẫn đến việc root web được đặt lại tùy ý vào thư mục chính xác mà bạn đặt wp-config.php.
Aaron Adams

1
@IanDunn Thật ra, thật dễ dàng để di chuyển wp-config.phpđến một vị trí tùy ý. Tôi đã thêm chỉ dẫn vào câu trả lời của mình; nó chỉ liên quan đến việc tạo một hình nộm wp-config.phptrong thư mục WordPress tham chiếu vị trí của cái thật.
Aaron Adams

3
Phản ứng này là tại chỗ. Công ty lưu trữ web của tôi đã có một lỗi ổ đĩa. Khi tất cả đã được nói và thực hiện, họ đã khôi phục hệ thống THAM GIA. Hóa ra họ đã sử dụng một loạt các tập lệnh cPanel / WHM để xây dựng lại các tệp httpd.conf đã làm không chính xác. May mắn là tôi đã có wp-config.php bên ngoài root doc, nhưng nếu tôi không có nội dung thì sẽ có. Có hiếm, nhưng như đã lưu ý các trường hợp hiếm là những gì bạn cần phải lo lắng. Ngoài ra, nói rằng "dân gian có đầu óc đơn giản sẽ bị mất" là một lý do tồi để có bảo mật LESS.
Lance Cleveland

1
Đó là một điểm tốt, Aaron. Tôi vẫn còn một chút hoài nghi về những lý do tôi đã đề cập trong chủ đề này và chủ đề bình luận khác, nhưng bạn đã thuyết phục tôi rằng nó có nhiều công đức hơn tôi nghĩ ban đầu. Ít nhất, nếu được thực hiện đúng cách, tôi không nghĩ nó sẽ làm tổn thương gì. Tôi vẫn có một vấn đề với thực tế là hầu hết mọi người quảng cáo nó dường như không hiểu lý do của nó và cách họ dạy nó thường dẫn đến thư mục trên httpdocs bị lộ, nhưng bạn đã giúp giải quyết những vấn đề đó trong câu trả lời của bạn.
Ian Dunn

40

Điều lớn nhất là wp-config.phpchứa một số thông tin nhạy cảm: tên người dùng / mật khẩu cơ sở dữ liệu của bạn, v.v.

Vì vậy, ý tưởng: di chuyển nó ra bên ngoài tài liệu gốc và bạn không phải lo lắng về bất cứ điều gì. Kẻ tấn công sẽ không bao giờ có thể truy cập tệp đó từ nguồn bên ngoài.

Tuy nhiên, đây là chà: wp-config.phpkhông bao giờ thực sự in bất cứ điều gì lên màn hình. Nó chỉ định nghĩa các hằng số khác nhau được sử dụng trong suốt quá trình cài đặt WP của bạn. Do đó, cách duy nhất ai đó sẽ thấy nội dung của tệp đó là nếu họ phá vỡ trình thông dịch PHP của máy chủ của bạn - họ lấy .phptệp để hiển thị dưới dạng văn bản thuần túy. Nếu điều đó xảy ra, bạn đã gặp rắc rối: họ có quyền truy cập trực tiếp vào máy chủ của bạn (và có thể là quyền root) và có thể làm bất cứ điều gì họ muốn.

Tôi sẽ tiếp tục và nói rằng không có lợi ích gì khi di chuyển ra wp-configngoài tài liệu gốc từ góc độ bảo mật - vì những lý do trên và những điều sau:

  1. Bạn có thể hạn chế quyền truy cập vào tệp thông qua cấu hình máy chủ ảo hoặc .htaccess - hạn chế hiệu quả quyền truy cập bên ngoài vào tệp theo cùng cách di chuyển bên ngoài gốc tài liệu
  2. Bạn có thể đảm bảo quyền truy cập tệp nghiêm ngặt wp-configđể ngăn chặn bất kỳ người dùng nào không có đủ đặc quyền đọc tệp ngay cả khi họ có quyền truy cập (giới hạn) vào máy chủ của bạn thông qua SSH.
  3. Thông tin nhạy cảm của bạn, cài đặt cơ sở dữ liệu, chỉ được sử dụng trên một trang web duy nhất. Vì vậy, ngay cả khi kẻ tấn công có được quyền truy cập vào thông tin đó, trang web duy nhất mà nó sẽ ảnh hưởng sẽ là bản cài đặt WordPress chứa wp-config.phptệp. Quan trọng hơn, người dùng cơ sở dữ liệu đó chỉ có quyền đọc và ghi vào cơ sở dữ liệu của cài đặt WP đó và không có gì khác - không có quyền truy cập để cấp quyền cho người dùng khác. Có nghĩa là, theo cách khác, nếu kẻ tấn công có quyền truy cập vào cơ sở dữ liệu của bạn, thì đó chỉ là vấn đề khôi phục từ bản sao lưu (xem điểm 4) và thay đổi người dùng cơ sở dữ liệu
  4. Bạn sao lưu thường xuyên. Thường là một thuật ngữ tương đối: nếu bạn đăng 20 bài viết mỗi ngày, tốt hơn bạn nên sao lưu mỗi ngày hoặc mỗi vài ngày. Nếu bạn đăng một lần một tuần, sao lưu một lần một tuần có khả năng là đủ.
  5. Bạn có trang web của mình dưới sự kiểm soát phiên bản ( như thế này ), có nghĩa là ngay cả khi kẻ tấn công có được quyền truy cập, bạn có thể dễ dàng phát hiện các thay đổi mã và cuộn chúng lại. Nếu kẻ tấn công có quyền truy cập wp-config, có lẽ chúng đã nhầm với thứ khác.
  6. Thông tin cơ sở dữ liệu thực sự là nội dung nhạy cảm duy nhất wp-configvà vì bạn cẩn thận với nó (xem điểm 3 và 4), đó không phải là vấn đề lớn. Muối và như vậy có thể được thay đổi bất cứ lúc nào. Điều duy nhất xảy ra là nó vô hiệu hóa đăng nhập cookie của người dùng.

Đối với tôi, di chuyển wp-configra khỏi tài liệu gốc của tài liệu an ninh bằng cách che khuất - đó là rất nhiều người rơm.


2
Vâng, đó là khá nhiều những gì tôi đã nghĩ. Tôi rất vui khi biết tôi không phải là người duy nhất :) Tôi muốn để lại câu hỏi mở cho một hoặc hai ngày khác trong trường hợp ai đó có một cuộc tranh luận hấp dẫn, nhưng cho đến nay đây có vẻ như là câu trả lời đúng cho tôi.
Ian Dunn

3
Sửa lỗi nhỏ: Không có lợi ích bảo mật nào khi di chuyển tệp wp-config.php ra khỏi thư mục gốc. Có những lợi ích khác, không liên quan đến bảo mật và chỉ áp dụng cho các thiết lập bất thường.
Otto

4
Chỉ để có được một huyền thoại có thể được gỡ lỗi - là không thể, một cái gì đó có thể đi sai phía máy chủ - trong trường hợp đó mã php được in ra màn hình?
Stephen Harris

3
@IanDunn Nhưng những câu trả lời hay nhất ủng hộ việc chuyển nó ra khỏi hệ thống phân cấp đó hoàn toàn thành một thứ riêng biệt, điều này giải quyết mối quan tâm của bạn về nhật ký, v.v ... Câu trả lời này không trả lời tiêu đề câu hỏi của bạn "đang di chuyển ... thực sự có lợi", nó chỉ nói các biện pháp bảo mật khác là có lợi, và cố gắng trấn an bạn không lo lắng về an ninh. Mọi người đều nghĩ rằng ngôi nhà của họ an toàn cho đến khi họ bị trộm. Sau đó, họ làm một công việc tốt hơn. Một số người không bao giờ bị đánh cắp, mặc dù bảo mật của họ thấp, nhưng điều đó không có nghĩa là lời khuyên tốt để có bảo mật thấp hơn.
AndrewC

4
Đây là những điểm tốt, nhưng vấn đề lớn nhất của tôi với chúng là chúng là những lý lẽ khắc phục, không phải là những lý lẽ phòng ngừa. Hầu hết trong số này nói về việc đó không phải là vấn đề lớn vì A) bạn cho rằng ai đó đã xử lý người dùng db chính xác và B) bạn có bản sao lưu. Điều gì xảy ra khi bạn đang sử dụng một cái gì đó như thương mại điện tử hoặc lưu trữ thông tin nhạy cảm trong cơ sở dữ liệu của bạn? Sau đó, bạn đang say sưa.
Goldentoa11

25

Tôi nghĩ Max là một câu trả lời am hiểu và đó là một mặt của câu chuyện. Các WordPress Codex có tư vấn nhiều hơn :

Ngoài ra, hãy đảm bảo rằng chỉ bạn (và máy chủ web) có thể đọc tệp này (nó thường có nghĩa là quyền 400 hoặc 440).

Nếu bạn sử dụng máy chủ có .htaccess, bạn có thể đặt tệp này vào tệp đó (ở trên cùng) để từ chối quyền truy cập vào bất kỳ ai lướt qua nó:

<files wp-config.php>
order allow,deny
deny from all
</files>

Lưu ý rằng việc đặt quyền 400 hoặc 440 trên wp-config.php có thể ngăn các plugin ghi hoặc sửa đổi nó. Ví dụ, một trường hợp chính hãng sẽ là các plugin lưu đệm (W3 Total Cache, WP Super Cache, v.v.) Trong trường hợp đó, tôi sẽ sử dụng 600 (quyền mặc định cho các tệp trong /home/userthư mục).


5
Max là câu trả lời. +1 cho anh ấy. Tôi chỉ đơn giản là cố gắng để mở rộng nó.
it_me

1
Aahan Krish, bạn đã đập vào mắt con bò. Cảm ơn đã bổ sung.
Max Yudin

Vì vậy, nếu bạn sử dụng htaccess để từ chối các yêu cầu HTTP đến wp-config.php, thì điều đó không đạt được kết quả tương tự như việc di chuyển nó ra bên ngoài gốc tài liệu, nhưng không để lộ nhật ký / sao lưu / vv?
Ian Dunn

4
@IanDunn Phụ thuộc vào gốc của tài liệu là gì (1) Nếu wordpress được lưu trữ trong một thư mục trong public_html, di chuyển ra wp-config.phpngoài thư mục có nghĩa là nó sẽ nằm trong public_htmlthư mục. Trong trường hợp này, bạn sẽ phải sử dụng các quy tắc htaccess để từ chối các yêu cầu HTTP đối với wp-config.php. (2) Nếu WordPress được cài đặt trực tiếp trong public_htmlthư mục, sẽ tăng một cấp => bạn sẽ chuyển nó vào /home/userthư mục. Trong trường hợp này, bạn khá an toàn vì tệp nằm ngoài thư mục gốc. Bạn vẫn có thể đặt quyền của tệp thành 600 (hoặc thậm chí nghiêm ngặt hơn 440 hoặc 400).
it_me

@IanDunn Như tôi đã nói, đây là hiểu biết cơ bản của tôi, và tôi không phải là chuyên gia bảo mật. :)
it_me

17

Ai đó yêu cầu chúng tôi tỏa sáng, và tôi sẽ trả lời ở đây.

Có, có những lợi ích bảo mật từ việc cô lập wp-config.php của bạn khỏi thư mục gốc của trang web của bạn.

1- Nếu trình xử lý PHP của bạn bị hỏng hoặc sửa đổi theo một cách nào đó, thông tin DB của bạn sẽ không bị lộ. Và vâng, tôi đã thấy điều này xảy ra một vài lần trên các máy chủ được chia sẻ trong quá trình cập nhật máy chủ. Có, trang web sẽ bị hỏng trong khoảng thời gian đó, nhưng mật khẩu của bạn sẽ còn nguyên vẹn.

2- Thực tiễn tốt nhất luôn khuyên bạn nên cách ly các tệp cấu hình khỏi các tệp dữ liệu. Vâng, thật khó để làm điều đó với WordPress (hoặc bất kỳ ứng dụng web nào), nhưng việc di chuyển nó lên có một chút cô lập.

3- Ghi nhớ lỗ hổng PHP-CGI, nơi mọi người có thể chuyển? -S vào một tệp và xem nguồn. http://www.kb.cert.org/vuls/id/520827

Cuối cùng, đó là những chi tiết nhỏ, nhưng chúng giúp giảm thiểu rủi ro. Đặc biệt nếu bạn đang ở trong một môi trường được chia sẻ, nơi mọi người có thể truy cập cơ sở dữ liệu của bạn (tất cả những gì họ cần là một người dùng / vượt qua).

Nhưng đừng để những phiền nhiễu nhỏ (tối ưu hóa sớm) xuất hiện trước những gì thực sự cần thiết để có được một trang web an toàn đúng cách:

1- Luôn cập nhật

2- Sử dụng mật khẩu mạnh

3- Hạn chế truy cập (thông qua quyền). Chúng tôi có một bài viết về nó ở đây:

http://blog.sucuri.net/2012/08/wordpress-security-cuting-ENC-the-bs.html

cảm ơn,


Này các bạn, cảm ơn vì đã thêm suy nghĩ của bạn. Tôi nghĩ rằng chúng tôi đã đạt được hầu hết các điểm trong các câu trả lời khác và nhận xét của họ. 1) Có, điều này là có thể, nhưng hiếm; 2) Có, điều này có lợi ích, nhưng chúng là tối thiểu; 3) Vâng, điều này là có thể, nhưng loại lỗ hổng đó khó có thể xảy ra lần nữa và bảo vệ chống lại nó giống như chơi trò đánh cá, hoặc khiến mọi người tháo giày ra tại sân bay vì một số kẻ ngốc đã giấu bom trong anh ta giày một lần. Đó là phản động và không có lợi ích trong tương lai.
Ian Dunn

Trong các cuộc thảo luận khác nhau, câu hỏi đã được tinh chỉnh từ "Có lợi ích gì không?" thành "Ok, có một số lợi ích, nhưng chúng có vượt quá rủi ro không?" Rủi ro chính mà tôi đề cập đến là việc bạn phải mở rộng phạm vi openbase_dir để cho phép PHP truy cập các tập lệnh bên ngoài web root. Nhiều thiết lập lưu trữ - bao gồm cả các thiết lập sử dụng Plesk, rất nhiều - lưu trữ nhật ký, sao lưu, các khu vực FTP riêng được cho là tách biệt với root web, v.v. trong thư mục phía trên web root. Vì vậy, việc cấp quyền truy cập PHP vào thư mục đó có thể là một lỗ hổng nghiêm trọng.
Ian Dunn

15

Chắc chắn là có.

Khi bạn di chuyển wp-config.php bên ngoài thư mục công cộng, bạn sẽ bảo vệ nó khỏi việc đọc bằng trình duyệt khi trình xử lý php bị thay đổi (hoặc vô tình!).

Đọc thông tin đăng nhập / mật khẩu DB của bạn là có thể khi máy chủ hầu như không bị lây nhiễm thông qua lỗi của quản trị viên què. Tính phí cho quản trị viên và nhận được một máy chủ lưu trữ đáng tin cậy và có xu hướng tốt hơn. Mặc dù điều đó có thể đắt hơn.


4
Nếu kẻ tấn công có đủ quyền truy cập để thay đổi trình xử lý PHP, thì bạn đã bị lừa. Những thay đổi ngẫu nhiên rất hiếm khi xảy ra theo kinh nghiệm của tôi và trong trường hợp đó, thật dễ dàng để thay đổi mật khẩu. Trước những điều đó, bạn có còn nghĩ rằng nó đáng để mạo hiểm để lộ nhật ký / sao lưu / vv vì open_basedirphạm vi mở rộng không?
Ian Dunn

1
Tôi chưa bao giờ có -rwxquyền truy cập vào các thư mục cao hơn public_htmlvì vậy tôi chưa bao giờ quen thuộc open_basedir. Nhật ký của tôi là trong thư mục riêng biệt, vì vậy sao lưu. Tôi nghĩ đó là những gì tất cả các máy chủ chia sẻ có.
Max Yudin

Chủ nhà khác nhau rất nhiều; không có cấu trúc thư mục tiêu chuẩn. Plesk (một trong những bảng điều khiển phổ biến nhất cho các máy chủ được chia sẻ) đặt nhật ký vào /var/www/vhosts/example.com/statistic/logs và gốc tài liệu là /var/www/vhosts/example.com/httpdocs. Di chuyển wp-config.php sang /var/www/vhosts/example.com/wp-config.php sẽ yêu cầu cấp quyền truy cập tập lệnh vào toàn bộ thư mục example.com.
Ian Dunn

Vì tò mò, nhật ký và bản sao lưu của bạn được lưu ở đâu, nếu không có trong thư mục của tên miền? Họ có được truy cập thông qua một bảng điều khiển hoặc một cái gì đó?
Ian Dunn

1
Vâng, thông qua một bảng điều khiển.
Max Yudin

8

Tôi chỉ muốn làm rõ, để tranh luận, việc di chuyển tệp wp_config.php của bạn không nhất thiết có nghĩa là bạn phải di chuyển nó chỉ vào thư mục mẹ. Giả sử bạn có cấu trúc như / root / html, trong đó html chứa cài đặt WP và tất cả nội dung HTML của bạn. Thay vì di chuyển wp_config.php sang / root, bạn có thể di chuyển nó sang một cái gì đó như / root / safe ... nằm ngoài thư mục html và cũng không nằm trong thư mục gốc của máy chủ. Tất nhiên, bạn cũng cần đảm bảo rằng php cũng có thể chạy trong thư mục bảo mật này.

Vì WP không thể được cấu hình để tìm wp_config.php trong thư mục anh chị em như / root / safe, bạn phải thực hiện một bước bổ sung. Tôi đã để lại wp_config.php trong / root / html và cắt bỏ các phần nhạy cảm (đăng nhập cơ sở dữ liệu, muối, tiền tố bảng) và chuyển chúng sang một tệp riêng gọi là config.php. Sau đó, bạn thêm includelệnh PHP vào wp_config.php của bạn, như thế này:include('/home/content/path/to/root/secure/config.php');

Đây thực chất là những gì tôi đã làm trong thiết lập của mình. Bây giờ, dựa trên các cuộc thảo luận ở trên, tôi vẫn đang đánh giá xem nó là cần thiết hay thậm chí là một ý tưởng tốt. Nhưng tôi chỉ muốn thêm rằng cấu hình trên là có thể. Nó không để lộ các bản sao lưu của bạn và các tệp gốc khác, và miễn là thư mục bảo mật không được thiết lập với URL công khai của chính nó, nó không thể duyệt được.

Hơn nữa, bạn có thể giới hạn quyền truy cập vào thư mục bảo mật bằng cách tạo tệp .htaccess trong đó với:

order deny,allow
deny from all
allow from 127.0.0.1

Này Michael, cảm ơn vì đã chia sẻ điều đó. Bạn đã thử nó trong một môi trường thực tế để xác minh nó hoạt động, mặc dù? Tôi nghĩ rằng lệnh open_basedirnày chiếm toàn bộ một cây , vì vậy để truy cập /root/securetừ đó /root/html, bạn phải đặt open_basedirthành /root.
Ian Dunn

Để thực hiện ý tưởng của bạn, tôi nghĩ rằng bạn cần phải thiết lập cấu trúc thư mục như /root/httpdocs/config/accessible, nơi lưu httpdocsgiữ nhật ký, sao lưu, v.v; configgiữ wp-config.phpaccessiblegiữ WordPress và tất cả nội dung. Bạn sẽ phải sửa đổi cấu hình vhost, v.v. để ánh xạ lại tài liệu gốc accessible. Mặc dù vậy, tôi không thấy bất kỳ lợi ích nào khi chỉ từ chối các yêu cầu HTTP đối với wp-config trong thiết lập mặc định.
Ian Dunn

1
Theo php.net/manual/en/ini.core.php#ini.open-basingir : "Trong Windows, hãy tách các thư mục bằng dấu chấm phẩy. Trên tất cả các hệ thống khác, hãy tách các thư mục bằng dấu hai chấm. Như một mô-đun Apache, đường dẫn open_basingir từ thư mục mẹ giờ được tự động kế thừa. " Vì vậy, bạn có thể thiết lập nhiều thư mục, không cần chúng ở trong một cây.
Michael

Tôi vừa thử nó và có vẻ như bạn đúng. Mặc dù vậy, tôi vẫn không chắc chắn lợi ích bảo mật này có được gì khi chỉ đơn giản là từ chối quyền truy cập vào tệp qua Apache.
Ian Dunn

@IanDunn giải quyết tốt trong câu trả lời của Aaron Adams
AndrewC

4

Có rất nhiều chủ đề và plugin được viết xấu ngoài đó cho phép các atatckers tiêm mã (hãy nhớ vấn đề bảo mật với Timthumb). Nếu tôi là kẻ tấn công, tại sao tôi phải tìm kiếm wp-config.php? Đơn giản chỉ cần tiêm mã này:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Bạn có thể cố gắng ẩn wp-config.php của bạn. Miễn là WordPress làm cho tất cả các thông tin nhạy cảm có thể truy cập được trên toàn cầu, việc ẩn wp-config.php không có lợi ích gì.

Phần xấu trong wp-config.php không phải là nó chứa dữ liệu nhạy cảm. Phần xấu là xác định dữ liệu nhạy cảm là hằng số có thể truy cập toàn cầu.

Cập nhật

Tôi muốn làm rõ các vấn đề với define()và tại sao nên xác định dữ liệu nhạy cảm là một hằng số toàn cầu.

Có rất nhiều cách để tấn công một trang web. Script tiêm chỉ là một cách để tấn công một trang web.

Giả sử máy chủ có một lỗ hổng cho phép kẻ tấn công truy cập vào kết xuất bộ nhớ. Kẻ tấn công sẽ tìm thấy trong bộ nhớ kết xuất tất cả các giá trị của tất cả các biến. Nếu bạn xác định hằng số truy cập toàn cầu, nó phải ở trong bộ nhớ cho đến khi tập lệnh kết thúc. Tạo một biến thay vì hằng số, rất có thể bộ thu gom rác sẽ ghi đè (hoặc miễn phí) bộ nhớ sau khi biến không còn cần thiết nữa.

Cách tốt hơn để bảo vệ dữ liệu nhạy cảm là xóa chúng ngay lập tức sau khi sử dụng:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

Sau khi sử dụng dữ liệu nhạy cảm, việc gán nullsẽ ghi đè lên dữ liệu trong bộ nhớ. Kẻ tấn công phải lấy kết xuất bộ nhớ ngay lúc $db_conchứa dữ liệu nhạy cảm. Và đó là một khoảng thời gian rất ngắn trong ví dụ trên (nếu lớp Database_Handler không lưu một bản sao của nó).


Câu trả lời này không trực tiếp giải quyết câu hỏi. Bất kỳ tác giả plugin nào cũng có thể có một ngày thực địa với WordPress nếu họ thuyết phục bạn cài đặt mã của họ và có mục đích xấu. Nó không khác gì tự nguyện cài đặt virus trên hệ thống của bạn. Đối số để không di chuyển wp-config.php là vô nghĩa. Điều này giống như nói rằng việc cố tình cài đặt bom xe trong xe hơi của bạn làm cho việc đặt báo thức ô tô trở nên vô dụng. Về mặt kỹ thuật có đúng nhưng WTF?!?
Lance Cleveland

2
Không, nó không phải là vô nghĩa. Câu hỏi là: Tôi có thể bảo vệ tài khoản cơ sở dữ liệu bằng cách ẩn wp-config.php. Và câu trả lời là rõ ràng: Không. Cũng giống như khi bạn hỏi 'Tôi có thể bảo vệ xe của tôi chống lại bom xe bằng báo động ô tô không?' Không có lợi ích nào khác bằng cách ẩn wp-config của bạn để bảo vệ quyền truy cập cơ sở dữ liệu hoặc quyền truy cập ftp. Cả hai đều trong phạm vi toàn cầu. Tôi chắc chắn có nhiều cách hơn để những kẻ tấn công có thể truy cập vào các vars toàn cầu mà không cần tiêm mã.
Ralf912

Tôi không thấy "tôi có thể bảo vệ tài khoản cơ sở dữ liệu bằng cách ẩn wp-config.php" trong câu hỏi ban đầu không. Câu hỏi ban đầu là "có ý nghĩa gì khi di chuyển wp-config.php". Câu trả lời là hoàn toàn có, IMO. Nó giống như hỏi bạn có nên khóa cửa trước khi ra ngoài không. Nói rằng "ai đó có thể dễ dàng phá vỡ một cửa sổ và đi vào bằng mọi cách, vậy tại sao phải bận tâm" không trả lời điểm cơ bản của câu hỏi. IMO câu hỏi được đặt ra là, "Có đáng để nỗ lực thêm để di chuyển wp-config.php không? BẤT K Profit lợi ích nào khi làm như vậy?". Đúng. Ít nhất thì nó cũng tránh được những tin tặc lười biếng.
Lance Cleveland

2
Một trong những thực tiễn bảo mật tốt nhất phổ biến nhất ... Bạn đã bỏ lỡ một điểm rất quan trọng (rất, rất): Kẻ tấn công quan tâm đến điều gì? Và đó không phải là cách bạn tạo kiểu cho wp-config.php. Kẻ tấn công được xen vào các giá trị bạn đã xác định trong wp-config. Lấy ví dụ của bạn với cửa trước: Ẩn wp-config của bạn giống như khi bạn khóa cửa trước, nhưng lưu trữ tất cả số vàng của bạn không được bảo vệ trong vườn. Tất cả các giá trị được xác định trong wp-config được xác định toàn cục . Vì vậy, tất cả chúng đều có thể truy cập bên ngoài wp-config. Ngay cả khi bạn ẩn wp-config, các giá trị vẫn hiện diện.
Ralf912

1
Tôi nghĩ rằng những người tranh luận về việc di chuyển nó đang cố gắng bảo vệ chống lại các kịch bản trong đó wp-config.php có thể được hiển thị bằng văn bản thuần túy thông qua một yêu cầu HTTP, thay vì các kịch bản có thể được hiển thị với mã PHP khác đang chạy trên máy chủ.
Ian Dunn

-1

Ngoài các lợi ích bảo mật, nó cũng cho phép bạn giữ phiên bản WordPress của mình dưới sự kiểm soát phiên bản trong khi vẫn giữ các tệp WordPress cốt lõi dưới dạng mô hình con / bên ngoài. Đây là cách Mark Jaquith đã thiết lập dự án WordPress-Skeleton của mình. Xem https://github.com/markjaquith/WordPress-Skeleton#assumptions để biết chi tiết.


8
Anh ta đã thiết lập nó trong thư mục gốc, không nằm ngoài nó, vì vậy nó không liên quan đến câu hỏi này. Kỹ thuật mà câu hỏi được hỏi về chỉ định rằng bạn di chuyển wp-config.phpmột thư mục phía trên thư mục gốc của vhost , không chỉ một thư mục phía trên thư mục cài đặt WordPress. Toàn bộ vấn đề là đưa nó ra ngoài thư mục có thể được đọc bởi các yêu cầu HTTP.
Ian Dunn
Licensed under cc by-sa 3.0 with attribution required.