Làm cách nào tôi có thể ngăn chặn cuộc tấn công DDOS trên Amazon EC2?


46

Một trong những máy chủ tôi sử dụng được lưu trữ trên đám mây Amazon EC2. Cứ sau vài tháng chúng ta lại có một cuộc tấn công DDOS vào máy chủ này. Điều này làm chậm máy chủ xuống vô cùng. Sau khoảng 30 phút, và đôi khi khởi động lại sau, mọi thứ trở lại bình thường.

Amazon có các nhóm bảo mật và tường lửa, nhưng tôi nên có gì khác trên máy chủ EC2 để giảm thiểu hoặc ngăn chặn một cuộc tấn công?

Từ những câu hỏi tương tự tôi đã học được:

  • Giới hạn tốc độ yêu cầu / phút (hoặc giây) từ một địa chỉ IP cụ thể thông qua một cái gì đó như bảng IP (hoặc có thể là UFW?)
  • Có đủ tài nguyên để sống sót sau một cuộc tấn công như vậy - hoặc -
  • Có thể xây dựng ứng dụng web để nó co giãn / có bộ cân bằng tải đàn hồi và có thể nhanh chóng mở rộng để đáp ứng nhu cầu cao như vậy)
  • Nếu sử dụng mySql, hãy thiết lập các kết nối mySql để chúng chạy tuần tự để các truy vấn chậm sẽ không làm hỏng hệ thống

Tôi còn thiếu gì nữa? Tôi rất thích thông tin về các công cụ cụ thể và các tùy chọn cấu hình (một lần nữa, sử dụng Linux tại đây) và / hoặc bất cứ thứ gì dành riêng cho Amazon EC2.

ps: Lưu ý về việc theo dõi DDOS cũng sẽ được hoan nghênh - có lẽ với nagios? ;)


Ngăn chặn nó là gần như không thể nhưng bạn chắc chắn có thể giảm lỗ hổng của bạn.
Belmin Fernandez

1
Rất đúng. Và tôi sẽ rất vui với câu trả lời thảo luận về việc giảm thiểu tổn thương :)
cwd

Để biết cách ngăn chặn nó, người ta sẽ cần biết thêm về bản chất của cuộc tấn công. Đó có phải là một trận lụt không? Có một trang web đắt tiền đã bị tấn công? đó có phải là một số dịch vụ khác?
hầm

Tôi nghĩ đó là một trang web nhưng không chắc chắn. Tôi cũng sẽ hoan nghênh những lời khuyên trên màn hình và điều tra những điều này. Một số nhật ký truy cập đã bị xóa - tôi cần tìm gì khác?
cwd

và thực tế, nếu khởi động lại khắc phục sự cố, thì tôi không biết nó có thể là gì, ngoại trừ có lẽ máy chủ của bạn bị rò rỉ tài nguyên ở đâu đó. Khởi động lại chắc chắn không thể tự dừng DDoS. Làm thế nào để bạn biết đây là một DDoS?
hầm

Câu trả lời:


36

DDOS (hoặc thậm chí là DOS), về bản chất, là sự cạn kiệt tài nguyên. Bạn sẽ không bao giờ có thể loại bỏ các nút thắt cổ chai, vì bạn chỉ có thể đẩy chúng ra xa hơn.

Trên AWS, bạn thật may mắn vì thành phần mạng rất mạnh - sẽ rất ngạc nhiên khi biết rằng liên kết ngược dòng đã bão hòa. Tuy nhiên, CPU, cũng như I / O của đĩa, dễ tràn ngập hơn.

Cách hành động tốt nhất sẽ là bắt đầu một số giám sát (cục bộ như SAR, từ xa với Nagios và / hoặc ScoutApp) và một số phương tiện ghi nhật ký từ xa (Syslog-ng). Với thiết lập như vậy, bạn sẽ có thể xác định tài nguyên nào bị bão hòa (ổ cắm mạng do lũ Syn; CPU do các truy vấn hoặc trình thu thập dữ liệu SQL xấu; ram do lỗi). Đừng quên để phân vùng nhật ký của bạn (nếu bạn không bật tính năng ghi nhật ký từ xa) trên một tập EBS (để sau này nghiên cứu nhật ký).

Nếu cuộc tấn công đi qua các trang web, nhật ký truy cập (hoặc tương đương) có thể rất hữu ích.


Bạn có thể muốn kiểm tra phần "dựa trên tải" của serverfault.com/a/531942/87017
Pacerier

24

Bạn cũng có thể cách ly thêm các thể hiện EC2 của mình bằng cách đặt chúng phía sau Bộ cân bằng tải đàn hồi và chỉ chấp nhận lưu lượng truy cập từ phiên bản ELB. Điều này đặt thêm trách nhiệm lên Amazon để quản lý các cuộc tấn công DDOS.

Tôi cho rằng bạn vẫn sẽ mở SSH cho tất cả mọi người, vì vậy có khả năng bạn vẫn sẽ thấy một số lưu lượng truy cập giả mạo ở đó, trừ khi bạn có thể khóa cổng đó thành một số IP tĩnh. Bạn có thể thay đổi cổng SSHd thành một cái gì đó tối nghĩa hơn (nghĩa là một cái gì đó ngoài 22) để giảm thêm các lần truy cập DDOS (hầu hết các bot chỉ kiểm tra các cổng đã biết).

Tôi cũng sẽ đề cập đến fail2ban, có thể theo dõi nhật ký và sửa đổi tạm thời các bảng ip của bạn để chặn các IP cụ thể (ví dụ: nếu đã có 6 lần thất bại để SSH vào máy chủ của bạn từ một địa chỉ IP duy nhất, nó có thể chặn IP đó trong 30 vài phút hoặc lâu hơn). Hãy nhớ rằng (như Jordan đã bình luận một cách khéo léo) fail2ban có lẽ không phù hợp để chặn lưu lượng truy cập (ví dụ: từ ELB) vì nó sẽ chặn IP của proxy, không nhất thiết phải là IP từ xa gốc.

Tôi chưa sử dụng nó, nhưng Apache mod_evasive cũng có thể đáng để điều tra; tuy nhiên, nó có thể có điểm yếu tương tự như fail2ban khi nói đến chặn dựa trên IP.


+1 cảm ơn bạn. thực sự tôi đã đóng ssh;)
cwd

1
Lưu ý rằng nếu bạn đứng sau ELB, fail2ban sẽ không hoạt động - bởi vì nó thường hoạt động bằng cách chặn IP trong iptables. Nhưng IP luôn luôn là ELB của bạn. Tôi nhận ra rằng sau khi cố gắng thêm fail2ban vào thiết lập của mình. Nó không hoạt động nếu người dùng chỉ truy cập thông qua ELB.
Jordan Reiter

5

Nếu bạn đang sử dụng Apache, tôi khuyên bạn nên sử dụng mod_security . Được đóng gói bởi hầu hết các nhà cung cấp, các quy tắc cốt lõi được thực hiện một công việc tuyệt vời.

Một bước làm cứng khác là giới hạn các yêu cầu ở cấp độ máy chủ web. Nginx ., Apache có thể điều tiết và hạn chế các yêu cầu đến.


tuyệt vời - những người trông giống như lựa chọn tuyệt vời cảm ơn!
cwd

2

Giải pháp tôi sử dụng để chặn IP hoạt động xấu thời gian thực ra khỏi AWS và các giải pháp khác là ... Trong Tường lửa CSF của tôi trong cấu hình cho Danh sách chặn của LFD, tôi sử dụng một danh sách được tìm thấy ở đây - http://myip.ms/browse/blacklist/ Danh sách đen_IP_Blacklist_IP_Addresses_Live_Database_Real-time

Tải xuống Danh sách đen cho Tường lửa CSF » http://myip.ms/files/blacklist/csf/latest_blacklist.txt

Không còn lưu lượng truy cập AWS đáng ghét.


1
Điều này không trả lời câu hỏi.
kasperd

2

Tôi thiên vị, vì tôi làm việc cho một mạng phân phối nội dung với tư cách là một kỹ sư bảo mật Presales.

Tuy nhiên, tận dụng giải pháp giảm thiểu Ddos trên mạng phân phối nội dung đảm bảo rằng bạn không bao giờ cạn kiệt tài nguyên tại nguồn gốc. Nó tương tự như đặt một bộ cân bằng tải F5 trước trang web của bạn, nhưng lan rộng đến hàng ngàn địa điểm trên khắp thế giới.

Một cdn tốt sẽ cho phép bạn che giấu nguồn gốc bằng danh sách trắng mà bạn cài đặt trên tường lửa aws. Vì vậy, khi những kẻ tấn công thực hiện trinh sát của chúng trên Amazon, địa chỉ IP của bạn sẽ trống rỗng vì mọi thứ sẽ bị chặn.

Vì vậy, các cuộc tấn công Ddos bị chặn khi lưu lượng truy cập vào một nút càng gần càng tốt với kẻ tấn công. Điều này đảm bảo bạn giảm thiểu các cuộc tấn công Ddos ở xa tài sản bạn đang cố gắng bảo vệ.

Một cdn tốt cũng có thể thực hiện kiểm tra sức khỏe và lưu lượng dự phòng đến các vị trí khác, ví dụ như một cái tôi khác trên ass, Azure, không gian rack, lớp mềm, dc vật lý, v.v. Nó cũng cần có WAF để đảm bảo bạn có thể chặn các cuộc tấn công cạn kiệt của lớp ứng dụng như RUDY, Slowpost, Slowloris cũng như sqli, xss, rfi, lfi, v.v.

Theo mặc định, cdn cũng chặn các cuộc tấn công lớp mạng như giọt nước mắt, tấn công icmp, synflood, v.v ... Một cdn có thể giảm thiểu các cuộc tấn công Ddos vì trey có khả năng lớn để chấp nhận các yêu cầu, lọc lưu lượng truy cập xấu và truyền lưu lượng tốt. Vì vậy, các cuộc tấn công khuếch đại như các cuộc tấn công thể tích ntp, DNS, ssdp, Chargeen và snmp có thể bị chặn.

Cuộc tấn công lớn nhất mà tôi thấy cho đến nay là 321gbps vào tháng 7 năm 2014. Trong cuộc tấn công này cũng có một cuộc tấn công giao thức DNS ở tốc độ 20gbps. Vì vậy, bạn sẽ cần đảm bảo cơ sở hạ tầng DNS của mình cũng có khả năng phục hồi để chịu được số lượng lớn yêu cầu.

Từ mô tả bạn cung cấp, có vẻ như bạn đã bị tấn công kiệt sức, nơi kẻ tấn công đã mở ra rất nhiều luồng để tất cả các luồng được tiêu thụ trên máy chủ web, máy chủ ứng dụng hoặc tường lửa. Nó tương tự như thứ gì đó như Slowpost, Slowloris hoặc RUDY.

Để ngăn chặn các cuộc tấn công cạn kiệt lớp ứng dụng, bạn sẽ cần phải có tường lửa ứng dụng web (WAF). Một tường lửa mạng điển hình (bao gồm tường lửa amazons và tường lửa thế hệ tiếp theo) sẽ không thể chặn nó. Những bức tường lửa được gửi trong những ngày này chỉ có thể chặn khoảng 30% tất cả các cuộc tấn công trong những ngày này (tháng 11 năm 2014).



0

Cấu hình tường lửa máy chủ là cấu hình tốt nhất tôi từng thấy để giảm thiểu DDoS trong máy ảo dựa trên phần mềm trong EC2. Nếu bạn kết hợp tính năng nhật ký hệ thống, nó có thể bảo vệ chống lại môi trường cân bằng tải.

http://configserver.com/cp/csf.html


Chào mừng bạn đến với Lỗi Máy chủ! Trong khi về mặt lý thuyết có thể trả lời câu hỏi, tốt hơn là nên bao gồm các phần thiết yếu của câu trả lời ở đây và cung cấp liên kết để tham khảo.
Scott Pack
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.