Lamvt – Vũ Thành Lâm – bắt đầu Code 2005 Freelancer từ 2006 với hàng ngàn dự án lớn nhỏ cho nước ngoài và hàng trăm dự án web cho Việt Nam.
SEO thành công rất nhiều dự án lớn, độ khó cao.
MOD (Moderator) và Admin (Administraror) của nhiều diễn đàn về SEO và CODE web MMO tại Việt Nam
Dạy Lập trình Thiết kế Web và SEO Miễn phí 17++ Năm (Từ 2006 đến Nay)
Contents
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.
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.
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.
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.
@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.
Câu trả lời cho câu hỏi trên rõ ràng là “có”.
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.
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:
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.
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ự.
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.
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.
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.
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.
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.
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.
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.
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:
Đố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
Dù bạn dùng phiên bản WordPress với lưu lượng truy cập cao hay một blog nhỏ trên máy chủ chia...
VR PLUS (https://vrplus.vn/ ) Là một trong những dự án do Lamvt thực hiện trong thời gian gần đây. Như...
Trong một năm qua, chúng tôi đã xuất bản khoảng 79 bài viết SEO trên blog Ahrefs. Các bài viết...
Khám phá kĩ thuật viết nội dung SEO Nếu không có SEO, nội dung của bạn có thể bị chìm...
Các website về lĩnh vực làm đẹp cần phải có một thiết kế (design) hấp dẫn và bắt mắt. Điều...
Như đã nói, phần mềm chỉnh sửa video đang ngày càng chứng tỏ được tầm quan trọng của mình, nhất...
Nhiều bạn thắc mắc là sau khi cài đặt Plugin cho Google AMP thì làm thế nào để kiểm tra,...
Các trang web giáo dục và các trang web của chính phủ có một lợi thế hơn trong bảng xếp...
Nội dung là một trong 3 tiêu chí quan trọng để google đánh giá thứ hạng tìm kiếm cho website...
Thẻ <span> </span> Thẻ <span> là thẻ khá đặc biệt trong HTML, theo mặc định thì thẻ <span> được thêm...