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.php
bê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:
- 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
).
- Đã 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.php
trong web root, một yêu cầu /wp-config.php
sẽ tải xuống tệp cấu hình WordPress.
- Với
wp-config.php
bên ngoài web root, yêu cầu /wp-config.php
tải xuống một tệp hoàn toàn vô hại. Các wp-config.php
tậ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.php
ngoà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.php
tệ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.php
trong 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.php
tệ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_basedir
trong 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.php
bê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.php
là đủ 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.php
là 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.php
bê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.php
là vào httpdocs/
, chỉ cần di chuyển nó đến ../phpdocs/
và đặt thành open_basedir
chỉ bao gồm httpdocs/
và 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.php
ngoài web root của mình.