Cách sử dụng Redis Cache để ngăn chặn các cuộc tấn công DDoS

Nhà phát triển phần mềm tại Avenue Code, Cristiano Guerra, chia sẻ câu chuyện cách công ty anh ta sử dụng Redis Cache để ngăn chặn các cuộc tấn công DdoS.

Năm 2019, tôi làm việc tại một ngân hàng đầu tư ở thành phố Sài Gòn. Hàng ngày, hệ thống của chúng tôi xử lý các giao dịch triệu đô la, và phương châm chung của chúng tôi là "ổn định và an toàn". 

Một trong những biện pháp phòng ngừa mà chúng tôi thực hiện là ngăn chặn các cuộc tấn công DDoS (Từ chối dịch vụ). Mặc dù các nền tảng điện toán đám mây đảm bảo họ sẽ không gặp vấn đề DDoS vì hệ thống của họ mạnh mẽ và có thể mở rộng để xử lý một lượng lớn yêu cầu (với một lượng tiền lớn), chúng tôi không muốn ngân hàng phải chi một khoản tiền khổng lồ nếu họ bị tấn công như vậy.

Ý tưởng 

Chúng tôi đã tổ chức một cuộc họp để thảo luận các ý tưởng và khả năng, và ý tưởng chiến thắng là lưu trữ bộ nhớ cache các phiên truy cập của người dùng với bộ đếm yêu cầu. Người dùng sẽ được phép thực hiện tối đa 50 yêu cầu trong một phút.

Chúng tôi không chọn các con số này một cách tùy tiện. Thay vào đó, chúng tôi theo dõi các phiên truy cập của một số người dùng để xác định thời gian sử dụng trung bình của ứng dụng khách hàng, số lượng yêu cầu được thực hiện bởi mỗi khách hàng, và thời gian cần thiết để thực hiện những yêu cầu đó. Khi người dùng đăng nhập, một token được tạo ra để xác định họ cho đến khi họ đăng xuất. Token này có thể được sử dụng làm khóa cache, không thay đổi cho đến khi đăng xuất, để xác định người dùng này đã thực hiện bao nhiêu yêu cầu trong vòng một phút.

Công cụ

Bộ nhớ cache 

Chúng tôi chọn Redis Cache để đáp ứng nhu cầu lưu trữ bộ nhớ cache của mình vì nó đơn giản để cấu hình một thuộc tính được gọi là Thời gian tồn tại (TTL), còn được gọi là thời gian hết hạn. Sau khi thời gian hết hạn được đạt đến, phiên truy cập của người dùng được lưu trữ trong bộ nhớ cache sẽ tự động xóa và phải được tạo lại, đặt lại bộ đếm. 

Cả Azure và AWS đều cho phép bạn cấu hình TTL trong Redis, và tài liệu hướng dẫn có sẵn cho cả hai nền tảng.

<Hình ảnh>

Middleware

Khi nói đến việc phân tích tất cả các yêu cầu đi qua các API của chúng tôi, chúng ta có thể tự hỏi liệu chúng ta có nên sao chép bộ xác thực của mình trong tất cả các API hay tạo một thư viện và thêm mã của nó vào tất cả các API. Ngoài ra, chúng ta có thể sử dụng cấu hình kết nối trong một tệp JSON để mỗi môi trường có giá trị riêng của nó trong quy trình xây dựng. Tất cả những ý tưởng này đều hợp lệ và có thể được sử dụng cho từng trường hợp. Tuy nhiên, điều chắc chắn là nó sẽ là một middleware.

Đối với những người chưa quen thuộc với middleware, đó là mã nằm ở giữa bất cứ điều gì bạn cần. Trong trường hợp của chúng tôi, nó nằm giữa các yêu cầu đến API. 

Vai trò của middleware sẽ là:

1. Kiểm tra xem người dùng đã có phiên chưa. Nếu chưa, hãy tạo nó với bộ đếm có giá trị ban đầu và giá trị TTL bằng 60.

2. Nếu khóa / phiên đã tồn tại trong bộ nhớ cache, hãy khôi phục giá trị này được liên kết với khóa. 

3. So sánh giá trị với giới hạn tối đa cho phép, trong trường hợp của chúng tôi là 50.

4. Xác định tương lai của yêu cầu, cho dù nó kết thúc hay tiếp tục.

5. Nếu tiến hành, hãy thêm một vào giá trị đếm.

<Hình ảnh>

API Router 

<Hình ảnh>

API này hoạt động như một bộ định tuyến, xác định các API nào khác tham gia giải quyết yêu cầu nhận được. Đóng vai trò là người gác cổng, nó là một phần của cổng, vì tất cả các yêu cầu đều đánh vào nó trước tiên, để lại các API thực sự có quyền truy cập vào dữ liệu hệ thống ở lớp bên trong. Middleware sẽ được cài đặt trên API Router này. 

Chức năng của API Router phụ thuộc nhiều vào quyết định kiến trúc đang ở vị trí, cho dù đó là Sự kiện điều khiển, BFF, hoặc thậm chí cả đơn hình. Nếu việc triển khai không khả thi, có thể đáng để xem xét lại số lượng yêu cầu tối đa trên mỗi đơn vị thời gian xác định. Nếu frontend của bạn thực hiện nhiều yêu cầu trên nhiều API để xây dựng một màn hình, và middleware phải được cài đặt trên tất cả các API, số lượng yêu cầu từ mỗi người dùng luôn luôn cao.

Kết luận

Chúng tôi đã tăng cường bảo mật cho ngân hàng mà chỉ gây ra sự gia tăng nhỏ về chi phí điện toán đám mây và thời gian phản hồi API. Kết quả là, khách hàng của ngân hàng giờ đây có thể tận hưởng dịch vụ thậm chí còn nhanh hơn. 

Ưu điểm

1. Khi sử dụng các công cụ này, tất cả các yêu cầu sẽ đi qua xác thực với bộ nhớ cache trong API Router, tiết kiệm tất cả các API nội bộ, cơ sở dữ liệu, hàng đợi và người tiêu dùng.

2. Trong trường hợp bị tấn công, sẽ có thể xác định đăng nhập, mật khẩu và token nào của người dùng nào đang được sử dụng. Điều này cho phép xử lý kịch bản của từng khách hàng riêng biệt và cảnh báo họ nếu họ có khả năng bị hack.

3. Trong kịch bản tự động mở rộng, tài nguyên duy nhất cần mở rộng là API router, thay vì toàn bộ hệ thống.

<Hình ảnh>

Nhược điểm

1. Truy vấn vào bộ nhớ cache cho mỗi yêu cầu có thể làm tăng nhẹ thời gian phản hồi của hệ thống.

2. Chi phí liên quan đến điện toán đám mây có thể tăng nhẹ.