Tại sao NginX và Lighttpd không bị ảnh hưởng bởi Slowloris?


23

Tôi đang điều tra lỗ hổng của Slowloris và tôi nghĩ rằng tôi hiểu cách thức và lý do tại sao loại tấn công này hoạt động.

Điều tôi không hiểu là tại sao Lighttpd và NginX không bị ảnh hưởng (theo cùng một bài viết như được liên kết ở trên). Họ làm gì để khác biệt?

Câu trả lời:


25

Apache có một lý thuyết về 'Khách hàng tối đa'

Đó là số lượng kết nối đồng thời nó có thể xử lý. IE nếu máy chủ apache có giới hạn 'tối đa máy khách' là 100 và mỗi yêu cầu mất 1 giây để hoàn thành, nó có thể xử lý tối đa 100 yêu cầu mỗi giây.

Một ứng dụng như SlowLoris sẽ làm ngập máy chủ với các kết nối, trong ví dụ của chúng tôi nếu SlowLoris gửi 200 kết nối mỗi giây và Apache chỉ có thể xử lý 100 kết nối mỗi giây, hàng đợi kết nối sẽ tiếp tục lớn hơn và sử dụng hết bộ nhớ trên máy mang đến một hault. Điều này tương tự như cách thức hoạt động của LOIC nặc danh.

NGINX và Lighttpd (Trong số những người khác) không có kết nối tối đa, họ sử dụng các luồng công nhân thay vì vậy, về mặt lý thuyết, không có giới hạn về số lượng kết nối họ có thể xử lý.
Nếu bạn giám sát các kết nối Apache của mình, bạn sẽ thấy rằng phần lớn các kết nối đang hoạt động là dữ liệu 'Gửi' hoặc 'Nhận' từ máy khách. Trong NGINX / Lighttpd, họ chỉ bỏ qua các yêu cầu này và để chúng chạy trên nền, không sử dụng hết tài nguyên hệ thống và nó chỉ phải xử lý các kết nối với thứ gì đó đang diễn ra (Phân tích phản hồi, đọc dữ liệu từ máy chủ phụ trợ, v.v.)

Tôi thực sự đã trả lời một câu hỏi tương tự vào chiều nay, vì vậy thông tin trong đó cũng có thể thú vị với bạn Giảm việc xếp hàng yêu cầu Apache


Câu trả lời hay và rất chi tiết. +1
Oldskool

6
Hiệu chỉnh nhỏ: nginx không sử dụng các luồng công nhân để đạt được số lượng kết nối cao. Từ nginx.org : "Nginx không dựa vào các luồng để xử lý các yêu cầu. Thay vào đó, nó sử dụng kiến ​​trúc theo hướng sự kiện (không đồng bộ) có thể mở rộng hơn nhiều"
Ngày

2
Mặc dù có thể có tác dụng phụ, mục đích của Slowloris không phải là "sử dụng hết bộ nhớ trên máy", mà là làm cạn kiệt dung lượng kết nối tối đa từ chối các kết nối tiếp theo từ thành công.
wulfgarpro

@Day Nginx không sử dụng các luồng công nhân để hỗ trợ hoạt động không đồng bộ của nó. Một sơ đồ kiến ​​trúc ứng dụng hữu ích được cung cấp tại đây: aosabook.org/en/nginx.html#fig.nginx.arch
Terry Burton

13

Nginx thực sự dễ bị tấn công Slowloris. Nguồn lực khan hiếm là số lượng kết nối công nhân đồng thời tối đa. Số này có thể được tính là worker_connections * worker_ Processes và bằng 512 trong cấu hình nginx mặc định. Vì vậy, khá dễ dàng để gỡ xuống nginx không được bảo vệ bằng các công cụ như goloris .


goloristrông giống như công cụ tôi cần để đảm bảo việc triển khai / thiết lập của tôi hoạt động như mong đợi!
Alexis Wilke

8

Nhận xét của valyala nên được chấp nhận là câu trả lời.

Hầu hết các máy chủ nginx sử dụng các cấu hình mặc định và do đó dễ bị tấn công Slowloris. Tôi đã sử dụng Slowloris để gỡ xuống một số trang web nginx của bạn tôi chỉ bằng máy tính xách tay của tôi và thường chỉ mất chưa đầy 5 phút (bạn bè của tôi đã thách tôi làm như vậy).

Như valyala đã nói, về mặt kỹ thuật, nginx không dễ bị làm chậm, nhưng các cấu hình mặc định giới hạn số lượng kết nối tối đa, do đó, khi các kết nối vượt quá số đó, nginx sẽ bỏ yêu cầu mới, dẫn đến việc từ chối dịch vụ.

Các cách đã biết để bảo vệ nginx khỏi Slowloris bao gồm giới hạn số lượng kết nối từ cùng một IP và tăng cấu hình worker_connections. Cuộc tấn công vẫn có thể hoạt động, nhưng nó khó hơn (có thể mất hơn 5 phút ?: D)

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.