Có thể phục vụ các trang cụ thể dựa trên địa chỉ IP không?

8

Tôi đã trở thành mục tiêu của một cuộc tấn công vũ phu vào hai trang web WordPress mà tôi sở hữu. Kẻ tấn công đang sử dụng thứ XML-RPC cũ để khuếch đại tấn công mật khẩu vũ phu. May mắn thay, chúng tôi có mật khẩu được tạo rất tốt, vì vậy tôi rất nghi ngờ anh ấy sẽ nhận được bất cứ nơi nào.

Tôi vừa sử dụng iptables để chặn yêu cầu của anh ấy mỗi khi anh ấy bật lên lại (luôn từ cùng một nhà cung cấp đám mây ảo), nhưng tôi muốn sửa đổi máy chủ để mỗi khi địa chỉ IP của anh ấy yêu cầu bất kỳ trang nào , anh ấy sẽ nhận được phản hồi cho anh ấy biết để có được một cuộc sống. Hầu hết các yêu cầu là POST, vì vậy tôi lý tưởng nhất là muốn sửa đổi tiêu đề phản hồi để bao gồm một cái gì đó như "Chúc may mắn hơn vào lần tới!" hoặc một cái gì đó thỏa mãn như nhau.

Điều này có thể không? Tôi là một chuyên gia về Apache, vì vậy tôi không chắc việc này sẽ khó thực hiện đến mức nào. Nhưng ngay cả khi tôi phải mất hàng giờ, sự hài lòng sẽ là vô giá.

Để tham khảo, tôi đang chạy Ubuntu 16.04.2 LTS, với Apache 2.4.18 lưu trữ Wordpress 4.7.3.

apache-2.4 http-headers

— Aurelius
nguồn

"Luôn luôn từ cùng một nhà cung cấp đám mây ảo" OVH? Tôi đã nhận thấy rất nhiều kịch bản sử dụng dịch vụ của họ vì một số lý do.

— hd.

Không, online.net ... cho đến nay họ không trả lời một báo cáo lạm dụng nào của tôi. Ngoài ra, lần đầu tiên tôi gửi yêu cầu lạm dụng, tôi phát hiện ra rằng họ tự động chuyển tiếp khiếu nại đến khách hàng. Do đó làm thế nào anh tìm thấy trang web cá nhân của tôi. Làm tốt lắm, online.net ....

— Aurelius

25

Chỉ cần cài đặt fail2ban với nhà tù thích hợp và được thực hiện với nó. Đừng bận tâm để đưa ra một phản ứng tùy chỉnh, vì rất có thể nó sẽ không bao giờ được nhìn thấy.

— EEAA
nguồn

1

Chắc chắn. Nhưng đây chắc chắn là điều tôi luôn muốn làm. Ngay cả khi anh ấy không bao giờ nhìn thấy nó, chỉ có khả năng làm cho tôi cười rất nhiều, tôi gần như khóc.

— Aurelius

14

Chà: 1) IMHO tìm ra cách hiển thị một sự xúc phạm nhỏ nhặt đối với một đứa trẻ kịch bản không có chủ đề ở đây. 2) Làm như vậy vẫn sẽ tiêu tốn tài nguyên apache của bạn, trong khi fail2ban / iptables chặn các yêu cầu ngược dòng để ứng dụng của bạn không bao giờ phải xử lý.

— EEAA

1

Ồ chắc chắn rồi. Nhưng tôi muốn có một niềm vui nho nhỏ trước khi perma-ban. Cho dù đó là nhỏ hay không, tôi chỉ muốn cười, và đây là theo yêu cầu của người mà doanh nghiệp sử dụng máy chủ.

— Aurelius

4

@Aurelius, nếu bạn biết ip và người này không che giấu thì tại sao bạn không làm điều này trong chính ứng dụng, php trong trường hợp này. Chỉ cần xác minh nếu đó là ip xx.xx.xx.xx và nếu nó chỉ giết tập lệnh bằng một phản hồi,die("blah blah");

— Miguel

Được chấp nhận là câu trả lời, chủ yếu là vì tôi không biết về fail2ban và vì vậy nói chung điều đó thực sự hữu ích. Câu trả lời của Miguel ở trên, cũng như câu trả lời của BlackWebWolf bên dưới, là cả hai điều tôi sẽ xem xét!

— Aurelius

5

Có một khả năng, và chúng tôi đã làm điều đó khá nhiều, để đảo ngược các cuộc tấn công có thể. Sử dụng iptables để chuyển hướng nhà cung cấp đám mây (phạm vi địa chỉ) sang một cổng khác - và ở đó phục vụ kẻ tấn công phản hồi, ngay cả trong các tiêu đề đơn giản.

Trong Apache, bạn có thể sửa đổi các tiêu đề bằng ví dụ:

Header set GetOut "Better luck next time!"

— BlackWebWolf
nguồn

Hehehe !! Bây giờ đó là những gì tôi đang nói về. Ý tưởng tốt! Tôi sẽ xem xét này.

— Aurelius

5

chiến lược này có thể sẽ phản tác dụng lại, bởi vì nó cho phép kẻ tấn công biết cái gì đang hoạt động và cái gì không, tốt hơn hết là chỉ im lặng chuyển yêu cầu đến không có gì và không vấp bất kỳ cờ cảnh báo nào trong phần mềm tấn công bot của mình. Lý tưởng nhất là trả lại html của trang được yêu cầu, ví dụ. họ không bao giờ biết bạn bắt được chúng, không có gì xảy ra và trang web của bạn an toàn hơn. Chống lại sự thôi thúc muốn cho họ biết, đó luôn là một MISTAKE. Nó chỉ đơn giản là giúp họ gỡ lỗi vấn đề. Trong trường hợp của bạn, chỉ cần chuyển sang phạm vi IP động hơn, v.v., khiến vấn đề trở nên khó giải quyết hơn.

— Lizardx

1

Bạn nói đúng, nó không được đề xuất - nó thậm chí có thể nguy hiểm. Chiến lược với honeypot luôn tốt hơn, nhưng câu hỏi đã rõ ràng - làm thế nào để troll kẻ tấn công :)

— BlackWebWolf 28/03/2017

Tôi thực sự không quan tâm nếu đó là một lỗi - tôi đã cài đặt fail2ban và dù sao anh ta cũng sẽ bị cấm. Tôi rất nghi ngờ anh ấy sẽ thực sự đến bất cứ nơi nào; Theo như tôi biết, các bản phát hành gần đây của WordPress thực sự đã sửa lỗi bảo mật này? Chưa kể, vũ phu buộc mật khẩu dài hơn 20 ký tự .... vâng, không xảy ra trong vòng đời của vũ trụ chúng ta.

— Aurelius

blackwebwolf, nó tương tự như ai đó hỏi cách triển khai phần mở rộng mysql_ không dùng được của php, trong khi người ta có thể trả lời về mặt kỹ thuật câu hỏi đó, câu trả lời đó là sai bởi vì câu trả lời thực sự có nghĩa là làm đúng, ví dụ, trong trường hợp đó, sử dụng mysqli_ hoặc xpdo. Đó chỉ là khái niệm mà nhiều người trong chúng ta đã làm trong quá khứ của chúng ta, rằng phản ứng theo bất kỳ cách nào như troll là bất cứ điều gì khác hơn là một tiêu cực lớn, nên được sửa chữa, bởi vì đó là một sai lầm nghiêm trọng, và nếu một người đã từng phải chịu đựng vì sai lầm đó, người ta sẽ hiểu ngay tại sao câu hỏi sai.

— Lizardx

3

Điều này rất dễ dàng với ModSecurity, đây là mô-đun WAF của bên thứ ba dành cho Apache. Mặc dù nó liên quan đến việc học cú pháp ngôn ngữ quy tắc của nó.

Bạn cũng có thể sử dụng ModSecurity để chỉ hủy kết nối thay vì trả lời.

Nói rằng, cài đặt ModSecurity chỉ cho việc này, khi, như những người khác đã đề xuất, có khả năng các phản hồi sẽ bị bỏ qua có thể là quá mức cần thiết.

— Barry Pollard
nguồn

2

Tôi sẽ đi với fail2ban và bỏ yêu cầu từ các địa điểm lạm dụng đã biết. Và nếu bạn cảm thấy rằng nhà cung cấp dịch vụ của kẻ tấn công không có lỗi, hãy báo cáo các cuộc tấn công đến địa chỉ email lạm dụng của họ.

Nếu bạn muốn dành thời gian để làm một cái gì đó sẽ làm chậm kẻ tấn công, bạn có thể muốn thử làm một cái bạt . Đầu tiên bạn phải biết các cuộc tấn công đến từ đâu. Sau đó, bạn có thể sử dụng apache để chuyển hướng yêu cầu từ ip (phạm vi?) Đến một tập lệnh cụ thể. Điều này có thể làm điều khó khăn mặc dù tôi đã không thử nó. Sau đó, chỉ cần thực hiện một tập lệnh, ví dụ, in ra một dấu chấm (hoặc một cái gì đó từ / dev / null) cứ sau 15 giây để giữ cho kết nối của kẻ tấn công mở vô thời hạn.

Vì kẻ tấn công rất có thể sử dụng các tập lệnh để tấn công trang web của bạn, nên có thể mất thời gian để nhận thấy rằng các cuộc tấn công đã bị đình trệ, vì các kết nối dường như đang hoạt động, sẽ không có thời gian chờ và yêu cầu không bị từ chối ngay tại chỗ.

Vấn đề là bạn dành thời gian và tài nguyên của mình cho một thứ có lẽ sẽ không hữu ích như mối quan tâm quan trọng hơn: bảo mật thông tin đăng nhập của bạn. Thật khó để tấn công khi bạn không biết nơi nào để tấn công. Hãy xem xét một số điều sau đây:

hạn chế quyền truy cập vào trang đăng nhập (chỉ phạm vi intranet? ip của bạn? vpn? khác?).
thêm reCaptcha hoặc câu hỏi xác minh khác để đăng nhập.
sử dụng xác thực đa yếu tố .
ẩn trang đăng nhập của bạn. Nếu có thể, đừng liên kết với nó từ trang chính của bạn và không sử dụng / đăng nhập hoặc vị trí rõ ràng khác.

— cộng đồng
nguồn

Cảm ơn bạn về thông tin! Vì vậy, để xóa mọi thứ, A) hai người dùng có thể đăng nhập đã tạo mật khẩu dài được tạo ngẫu nhiên. B) Có một loại captcha trên trang đăng nhập. C) Tôi đang cố gắng để .htaccess hoạt động để ngăn truy cập vào trang đó. Tuy nhiên, có vẻ như các tiêu chuẩn cho .htaccess đã thay đổi nhiều lần - tôi vẫn thấy các cú pháp khác nhau ở mọi nơi và cho đến nay htaccess hầu như không hoạt động.

— Aurelius

Ngoài ra, tôi đã báo cáo tất cả các cuộc tấn công lên online.net mà không có phản hồi nào.

— Aurelius

Một số mẹo hữu ích cho htaccess: stackoverflow.com/questions/6441578/ (Tôi khuyên bạn nên xác thực tiêu hóa).

Nhìn vào các bình luận trên trang này, digest dường như không phải là một ý tưởng tuyệt vời? httpd.apache.org/docs/2.4/mod/mod_auth_digest.html

— Aurelius

1

Bạn đã cho tôi ở đó. Có, tôi nhớ rằng từ khi tôi sử dụng xác thực digest và sau đó chúng tôi không có https ở mọi nơi. Lý do tại sao chúng tôi không sử dụng mật khẩu htacces là vì đó không phải là giải pháp lâu dài. Bạn có thể sử dụng nó để ẩn thứ gì đó một tuần trước khi xuất bản, nhưng để sử dụng hàng ngày, bạn không muốn có một cấp mật khẩu khác. Nó thậm chí không an toàn hơn nhiều. Khi tài nguyên ở vị trí không hiển thị trên Internet công cộng, thì chúng ta đang đi đúng hướng.