Buy Me a Coffee

Câu hỏi

Một trong những phương pháp bảo mật phổ biến nhất hiện nay là chuyển wp-config.php vào thư mục lớn hơn một lớp so với thư mục chứa gốc tài liệu (document root) của vhost’s. Thực sự tôi không biết lý do thỏa đáng cho việc này, nhưng tôi cho rằng nó có tác dụng làm giảm nguy cơ bị mã độc bên trong webroot đọc mật khẩu cơ sở dữ liệu.

Nhưng bạn vẫn phải cho phép WordPress truy cập nó. Vì vậy bạn cần mở rộng open_basedir để chứa thư mục có gốc tài liệu (document root). Điều này chẳng phải đi ngược lại hoàn toàn mục đích ban đầu và tạo cơ hội cho những kẻ tấn công tiếp cận nhật kí máy chủ (server logs), các bản sao lưu (backups), v.v. hay sao?

Hay là kĩ thuật này chỉ có tác dụng ngăn chặn trường hợp mà wp-config.php hiển thị dưới dạng văn bản thuần túy (plain-text) đối với ai yêu cầu http://example.com/wp-config.php, thay vì được phân tích cú pháp bằng công cụ PHP? Trường hợp này có vẻ như rất hiếm khi xảy ra. Và nó cũng sẽ không bù lại được những nhược điểm của việc để lộ nhật ký/ sao lưu/ v.v đối với các yêu cầu HTTP.

Có thể một số hosting setups cho phép chuyển nó ra ngoài gốc tài liệu mà không để lộ các file khác. Nhưng không phải mọi setups đều làm được như vậy.

Kết luận:

Sau nhiều lần lật đi lật lại vấn đề trên, có hai câu trả lời mà tôi nghĩ là đáng tin cậy. Aaron Adams lập luận rất tốt để ủng hộ cho việc chuyển wp-config, còn chrisguitarguy lập luận phản đối điều này. Đây là hai câu trả lời bạn nên đọc nếu bạn mới làm quen với chủ đề này mà không muốn đọc lại toàn bộ nội dung. Những câu trả lời còn lại đều thừa hoặc không chính xác.

Ian Dunn

Thực sự nó không cần thiết để thêm vào việc bạn chọn câu trả lời nào và bác bỏ tất cả những câu trả lời còn lại cho câu hỏi của bạn. Bạn có thể thấy bên dưới, đó là nhiệm vụ của hệ thống voting. Nó giúp bầu chọn câu trả lời có ý nghĩa đối với mọi người. Trong khi đó thì người đặt câu hỏi nên xem những câu trả lời được chấp nhận và bầu chọn câu trả lời của riêng mình.

– Kzqai

Tôi không làm điều này đối với 99% những câu hỏi mà tôi đã hỏi. Nhưng tôi thấy đây là một trường hợp đặc biệt và cần phải làm như vậy. Có 8 câu trả lời cho câu hỏi của tôi, và một số khá dài hoặc phức tạp. Và một số câu trả lời nhận được nhiều upvote mặc dù chúng chứa thông tin không chính xác, hoặc là không đóng góp gì vào việc trả lời câu hỏi. Tôi nghĩ gợi ý một kết luận bán thẩm quyền sẽ có ích cho những người đọc chủ đề này lần đầu tiên. Như bình thường, người đọc tự do có lựa chọn của riêng mình, tôi chỉ đưa ra gợi ý theo quan điểm của cá nhân tôi.

– Ian Dunn

@Kzqai: Hệ thống bầu chọn (stackexchange voting) là một quá trình dân chủ. Và người tham gia thường 1) Không nắm rõ người đặt câu hỏi chính xác đang muốn hỏi gì hay đang tìm cách giải quyết gì, 2) Không hiểu được giá trị của các câu trả lời. Sau khi có hồi đáp cho câu hỏi và mọi người đã vote, thì vô cùng hữu ích nếu người đặt câu hỏi cho biết những câu trả lời nào đã giúp ích cho họ. Nói cho cùng thì người đặt câu hỏi là người duy nhất hiểu rõ. Và tôi mong rằng sẽ có nhiều người làm như vậy. Vâng, mọi người bình chọn cho câu trả lời có ý nghĩa đối với họ. Nhưng hãy để cho người đặt ra câu hỏi có lời chốt cuối cùng về câu trả lời có ý nghĩa cho anh ta.

– Mac

Câu trả lời chính xác nhất

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

Câu trả lời cho câu hỏi trên rõ ràng là “có”.

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

Cho phép tôi đưa ra một ví dụ rất thực tế từ chính máy chủ của tôi. Và việc chuyển wp-config.php ra khỏi web root đã thực sự ngăn chặn nội dung của nó khỏi bị đánh cắp.

Bug

Hãy xem qua mô tả về một bug trong Plesk (được sửa trong 11.0.9 MU#27)

Plesk resets subdomain forwarding after syncing subscription with hosting plan (117199)

Nghe có vẻ vô hại, phải không?

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

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

Khi tôi thực hiện như trên, Plesk đặt lại tên miền phụ thành mặc định: cung cấp nội dung của ~ / httpdocs /, mà không kích hoạt thông dịch (vd: PHP).

Và tôi không hề để ý điều đó trong vòng vài tuần.

Kết quả là:

• Với wp-config.php nằm trong web root, yêu cầu tới /wp-config.php sẽ tải tệp cấu hình WordPress xuống.
• Với wp-config.php ở ngoài web root, yêu cầu tới /wp-config.php đã tải xuống một tệp hoàn toàn vô hại. Tệp wp-config.php thực sự có thể đã không được tải xuống.

Vì vậy, rõ ràng chuyển wp-config.php ra khỏi root web có lợi ích bảo mật thực sự.

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

WordPress sẽ tự động tìm thư mục chứa cài đặt Wordpress cho tệp wp-config.php của bạn. Vì vậy nếu đây là nơi bạn đã chuyển nó đến thì công việc của bạn đã hoàn thành.

Nhưng nếu bạn đã chuyển nó đến chỗ khác thì sao? Rất dễ. Hãy tạo một wp-config.php mới trong thư mục WordPress với code dưới đây:

<?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’);

(Phải nhớ chuyển đường dẫn ở trên chính xác thành đường dẫn của tệp wp-config.php được đặt lại vị trí 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 open_basedir directive 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/”

Vậy là xong.

Xem xét các tranh luận trái chiều

Những người phản đối chuyển wp-config.php ra khỏi web root dựa vào những giả định sai.

Tranh luận 1: Nếu PHP bị vô hiệu hóa thì chúng đã xâm nhập được rồi

Cách duy nhất để một người có thể xem được nội dung của wp-config.php là phá vỡ thông dịch PHP của máy chủ. Nếu điều này xảy ra, bạn đã gặp rắc rối rồi đấy: Họ có thể truy cập trực tiếp vào máy chủ của bạn.

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

Tranh luận 2: Vô hiệu hóa PHP ngẫu nhiên là rất hiếm gặp, vì vậy nó không có ý nghĩa

Nếu kẻ tấn công có đủ quyền truy cập để thay đổi xử lý PHP (PHP handler) của bạn thì bạn đã xong rồi. Theo kinh nghiệm của tôi, thay đổi ngẫu nhiên là rất hiếm, và trong trường hợp đó sẽ dễ dàng để thay đổi mật khẩu.

Sai lầm: 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ủ phổ biến. Nó ảnh hưởng đến cấu hình máy chủ thông thường. Điều này không phải là hiếm (và hơn nữa, bảo mật là giải quyết các kịch bản hiếm xảy ra).

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

Tranh luận 3: Từ chối truy cập vào wp-config.php là đủ

Bạn có thể hạn chế truy cập tệp thông qua cấu hình máy chủ ảo của bạn (virtual host config) hoặc .htaccess. Nó sẽ có hiệu quả hạn chế các truy cập bên ngoài vào tệp, tương đương với việc chuyển ra ngoài gốc tài liệu (document root).

Sai lầm: Hãy tưởng tượng mặc định máy chủ của bạn cho một máy chủ ảo là: no PHP, no .htaccess, allow from all (hầu như không hay bắt gặp trong môi trường production). Nếu bằng cách nào đó, cấu hình của bạn bị reset trong lúc đang hoạt động – ví dụ như cập nhật bảng điều khiển – mọi thứ sẽ trở lại trạng thái mặc định của nó và bạn sẽ bị lộ.

Nếu mô hình bảo mật của bạn gặp rắc rối khi cài đặt vô tình được reset trở về mặc định, bạn cần phải bảo mật hơn.

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

Tranh luận 4: Truy cập trái phép vào tệp wp-config.php không gây ra vấn đề gì

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 lầm: Khóa xác thực và salts có thể được sử dụng trong các vụ tấn công chiếm đoạt thông tin. Ngay cả khi thông tin cơ sở dữ liệu là thứ duy nhất có trong wp-config.php, thì bạn sẽ phải khiếp sợ khi kẻ tấn công tiếp cận được chúng.

Tranh luận 5: Chuyển wp-config.php ra 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 để chứa thư mục có gốc tài liệu (document root).

Sai lầm: Giả sử wp-config.php nằm trong httpdocs /, chỉ cần di chuyển nó đến ../phpdocs/, và cài đặt open_basedir để nó chỉ chứa 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 cho / tmp /, hoặc thư mục tmp / người dùng của bạn vào, nếu có.)

Kết luận: Các file cấu hình nên luôn luôn được đặt ngoài web root.

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

Câu trả lời của Aaron Adams

Nếu bạn gặp phải lỗi trong apache, linux hoặc đầu não của admin, bạn sẽ khốn đốn trong bất cứ trường hợp nào. Trong các tình huống mà bạn đưa ra, bạn không giải thích tại sao nhiều khả năng là lỗi cấu hình sai xảy ra ở thư mục gốc của trang web chứ không phải là ở bất kì chỗ nào khác trên máy chủ. Một apache sai cấu hình có thể truy cập /../config.php dễ dàng như đối với /config.php. – Mark Kaplun

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

Vấn đề lớn nhất ở đây là wp-config.php chứa các 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 ngoài gốc tài liệu, 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ừ một nguồn bên ngoài.

Tuy nhiên, đây là vấn đề: wp-config.php không bao giờ in bất cứ thứ gì lên màn hình. Nó chỉ xác định 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 đó xem nội dung của tệp là: nếu họ phá vỡ thông dịch PHP của máy chủ – họ để tệp .php 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ể có root permissions) và có thể làm bất cứ điều gì họ thích.

Tôi sẽ bảo vệ quan điểm cho rằng không có lợi ích gì khi di chuyển wp-config ra ngoài gốc tài liệu trong vấn đề 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 – giới hạn hiệu quả quyền truy cập bên ngoài vào tệp. Nó có tác dụng tương tự như khi di chuyển ra 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 trên 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 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 duy nhất mà nó sẽ ảnh hưởng là cài đặt WordPress mà tệp wp-config.php thuộc về. 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 bản cài đặt WP này và không có thêm quyền gì khác – không có quyền truy cập để cấp quyền cho người dùng khác. Nghĩa là, nói 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ì nó chỉ đơn giản là một vấn đề về 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. Điều này mang tính chất tương đối: nếu bạn đăng 20 bài mỗi ngày, bạn nên sao lưu mỗi ngày hoặc vài ngày một lần. Nếu bạn đăng một lần một tuần, sao lưu một lần một tuần là có thể đủ.
5. Trang web của bạn hoạt động có kiểm soát phiên bản (như thế này). Điều đó có nghĩa là ngay cả khi kẻ tấn công có quyền truy cập, bạn có thể dễ dàng phát hiện ra các thay đổi mã và sửa lại chúng. Nếu kẻ tấn công truy cập vào wp-config, thì họ chỉ có thể gây rối cái khác.
6. Thông tin cơ sở dữ liệu thực sự là thứ nhạy cảm duy nhất trong wp-config, và bởi vì bạn phải cẩn thận với nó (xem điểm 3 và 4), đó không phải là một vấn đề lớn. Salts 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 (logged in users’ cookies).

Đối với tôi, chuyển wp-config ra khỏi gốc tài liệu là bảo mật bằng cách che giấu (security by obscurity) – giống như kiểu người rơm.

Câu trả lời của chrisguitarguy

Đây đúng là những gì mà tôi nghĩ. Tôi rất vui vì biết rằng tôi không phải là người duy nhất nghĩ như vậy. Tôi định để câu hỏi một vài ngày chỉ khi có ý kiến phản đối. Nhưng đây có vẻ là câu trả lời đúng đối với tôi. – Ian Dunn 

Sửa lại một chút: chuyển tệp wp-config.php ra khỏi gốc tài liệu không mang lại lợi ích gì cho việc bảo mật. Có các lợi ích khác không liên quan gì đến bảo mật và chỉ áp dụng được với các unusual setups (cài đặt không phổ biến). – Otto

Cảm ơn vì lời nhắc nhé. Tôi đã sửa lại rồi. – chrisguitarguy

Tôi nghĩ câu trả lời của Max cho thấy anh ta rất hiểu biết, và đó là một khía cạnh của câu chuyện. WordPress Codex sẽ cho bạn nhiều lời khuyên hơn:

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

Nếu bạn dùng máy chủ .htaccess, bạn có thể cho code dưới đây vào tệp đó (đặt ở trên cùng) để từ chối quyền truy cập của những người đang lướt web:

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

Chú ý rằng cài đặt 400 hoặc 440 permission trên wp-config.php có thể chặn plugin viết hay sửa nó. Ví dụ một trường hợp thực tế là plugin bộ nhớ đệm (caching plugin) ((W3 Total Cache, WP Super Cache, v.v.). Trong trường hợp này tôi sử dụng 600 (permission mặc định cho các tệp trong thư mục home hoặc user)

Câu trả lời của its_me