Variti phát triển khả năng bảo vệ chống lại bot và các cuộc tấn công DDoS, đồng thời tiến hành kiểm tra tải và căng thẳng. Tại hội nghị HighLoad++ 2018, chúng tôi đã nói về cách bảo mật tài nguyên khỏi nhiều kiểu tấn công khác nhau. Tóm lại: cô lập các bộ phận của hệ thống, sử dụng dịch vụ đám mây và CDN và cập nhật thường xuyên. Nhưng bạn vẫn sẽ không thể đối phó với sự bảo vệ nếu không có các công ty chuyên môn :)
Trước khi đọc văn bản, bạn có thể đọc phần tóm tắt ngắn .
Và nếu bạn không thích đọc hoặc chỉ muốn xem video, bản ghi báo cáo của chúng tôi sẽ nằm bên dưới phần spoiler.
Quay video báo cáo
Nhiều công ty đã biết cách thực hiện kiểm tra tải, nhưng không phải tất cả đều thực hiện kiểm tra căng thẳng. Một số khách hàng của chúng tôi cho rằng trang web của họ bất khả xâm phạm vì họ có hệ thống tải cao và hệ thống này bảo vệ tốt khỏi các cuộc tấn công. Chúng tôi cho thấy điều này không hoàn toàn đúng.
Tất nhiên, trước khi tiến hành thử nghiệm, chúng tôi phải xin phép khách hàng, ký tên và đóng dấu, đồng thời với sự trợ giúp của chúng tôi, cuộc tấn công DDoS không thể được thực hiện nhằm vào bất kỳ ai. Việc kiểm tra được thực hiện tại thời điểm do khách hàng chọn, khi lưu lượng truy cập vào tài nguyên của anh ta ở mức tối thiểu và các vấn đề truy cập sẽ không ảnh hưởng đến khách hàng. Ngoài ra, vì luôn có thể xảy ra sự cố trong quá trình thử nghiệm nên chúng tôi thường xuyên liên hệ với khách hàng. Điều này cho phép bạn không chỉ báo cáo kết quả đạt được mà còn có thể thay đổi điều gì đó trong quá trình thử nghiệm. Sau khi hoàn thành quá trình thử nghiệm, chúng tôi luôn lập một báo cáo trong đó chúng tôi chỉ ra những thiếu sót đã phát hiện và đưa ra khuyến nghị để loại bỏ những điểm yếu của trang web.
Chúng tôi đang làm việc như thế nào
Khi thử nghiệm, chúng tôi mô phỏng một mạng botnet. Vì chúng tôi làm việc với những khách hàng không nằm trong mạng của chúng tôi, nên để đảm bảo rằng thử nghiệm không kết thúc trong phút đầu tiên do các giới hạn hoặc biện pháp bảo vệ được kích hoạt, chúng tôi cung cấp tải không phải từ một IP mà từ mạng con của chính chúng tôi. Ngoài ra, để tạo ra tải trọng đáng kể, chúng tôi có máy chủ thử nghiệm khá mạnh của riêng mình.
tiên đề
Quá nhiều không có nghĩa là tốt
Chúng ta có thể khiến tài nguyên bị hỏng càng ít tải thì càng tốt. Nếu bạn có thể khiến trang web ngừng hoạt động với một yêu cầu mỗi giây hoặc thậm chí một yêu cầu mỗi phút thì điều đó thật tuyệt. Vì theo quy luật hèn hạ, người dùng hoặc kẻ tấn công sẽ vô tình rơi vào lỗ hổng đặc biệt này.
Thà thất bại một phần còn hơn thất bại hoàn toàn
Chúng tôi luôn khuyên làm cho hệ thống không đồng nhất. Hơn nữa, cần phân tách chúng ở cấp độ vật lý chứ không chỉ bằng cách đóng gói. Trong trường hợp tách biệt về mặt vật lý, ngay cả khi có sự cố xảy ra trên trang web, khả năng cao là nó sẽ không ngừng hoạt động hoàn toàn và người dùng sẽ tiếp tục có quyền truy cập vào ít nhất một phần chức năng.
Kiến trúc tốt là nền tảng cho sự bền vững
Trên thực tế, khả năng chịu lỗi của tài nguyên và khả năng chống lại các cuộc tấn công và tải của nó phải được đặt ra ở giai đoạn thiết kế, trên thực tế, ở giai đoạn vẽ sơ đồ đầu tiên vào sổ ghi chép. Bởi vì nếu mắc phải những lỗi nghiêm trọng thì sau này có thể sửa được nhưng rất khó.
Không chỉ mã phải tốt mà cấu hình cũng phải tốt
Nhiều người nghĩ rằng một nhóm phát triển tốt là sự đảm bảo cho dịch vụ có khả năng chịu lỗi tốt. Một đội ngũ phát triển tốt thực sự rất cần thiết nhưng cũng phải có những hoạt động tốt, DevOps tốt. Nghĩa là, chúng tôi cần các chuyên gia sẽ cấu hình chính xác Linux và mạng, viết cấu hình chính xác trong nginx, đặt giới hạn, v.v. Nếu không, tài nguyên sẽ chỉ hoạt động tốt khi thử nghiệm và đến một lúc nào đó mọi thứ sẽ bị hỏng trong quá trình sản xuất.
Sự khác biệt giữa kiểm tra tải và căng thẳng
Kiểm tra tải cho phép bạn xác định giới hạn hoạt động của hệ thống. Kiểm tra sức chịu đựng nhằm mục đích tìm ra điểm yếu trong hệ thống và được sử dụng để phá vỡ hệ thống này và xem nó sẽ hoạt động như thế nào khi một số bộ phận nhất định bị hỏng. Trong trường hợp này, bản chất của tải thường không được khách hàng biết trước khi bắt đầu kiểm tra sức chịu đựng.
Đặc điểm nổi bật của tấn công L7
Chúng ta thường chia các loại tải thành các tải ở cấp độ L7 và L3&4. L7 là tải ở cấp ứng dụng, thông thường nó chỉ có nghĩa là HTTP, nhưng chúng tôi muốn nói đến bất kỳ tải nào ở cấp giao thức TCP.
Các cuộc tấn công L7 có một số tính năng đặc biệt nhất định. Đầu tiên, chúng đến trực tiếp với ứng dụng, nghĩa là chúng khó có thể được phản ánh qua các phương tiện mạng. Các cuộc tấn công như vậy sử dụng logic và do đó, chúng tiêu thụ CPU, bộ nhớ, đĩa, cơ sở dữ liệu và các tài nguyên khác rất hiệu quả và ít lưu lượng truy cập.
Lũ lụt HTTP
Trong trường hợp của bất kỳ cuộc tấn công nào, tải sẽ dễ tạo ra hơn là xử lý và trong trường hợp L7, điều này cũng đúng. Không phải lúc nào cũng dễ dàng phân biệt lưu lượng truy cập tấn công với lưu lượng truy cập hợp pháp và hầu hết điều này có thể được thực hiện theo tần suất, nhưng nếu mọi thứ được lên kế hoạch chính xác thì không thể hiểu được từ nhật ký nơi xảy ra cuộc tấn công và nơi có các yêu cầu hợp pháp.
Ví dụ đầu tiên, hãy xem xét một cuộc tấn công HTTP Flood. Biểu đồ cho thấy các cuộc tấn công như vậy thường rất mạnh mẽ; trong ví dụ bên dưới, số lượng yêu cầu cao nhất vượt quá 600 nghìn mỗi phút.
HTTP Flood là cách dễ nhất để tạo tải. Thông thường, phải sử dụng một số loại công cụ kiểm tra tải, chẳng hạn như ApacheBench và đặt yêu cầu cũng như mục tiêu. Với cách tiếp cận đơn giản như vậy, khả năng cao là sẽ chạy vào bộ nhớ đệm của máy chủ nhưng rất dễ dàng vượt qua được. Ví dụ: thêm các chuỗi ngẫu nhiên vào yêu cầu, điều này sẽ buộc máy chủ liên tục phân phát một trang mới.
Ngoài ra, đừng quên tác nhân người dùng trong quá trình tạo tải. Nhiều tác nhân người dùng của các công cụ kiểm tra phổ biến được quản trị viên hệ thống lọc và trong trường hợp này, tải có thể không đến được phần phụ trợ. Bạn có thể cải thiện đáng kể kết quả bằng cách chèn một tiêu đề ít nhiều hợp lệ từ trình duyệt vào yêu cầu.
Đơn giản như các cuộc tấn công HTTP Flood, chúng cũng có những nhược điểm. Thứ nhất, cần một lượng lớn năng lượng để tạo ra tải. Thứ hai, các cuộc tấn công như vậy rất dễ bị phát hiện, đặc biệt nếu chúng đến từ một địa chỉ. Do đó, các yêu cầu ngay lập tức bắt đầu được quản trị viên hệ thống hoặc thậm chí ở cấp nhà cung cấp lọc.
Những gì cần tìm
Để giảm số lượng yêu cầu mỗi giây mà không làm giảm hiệu quả, bạn cần thể hiện một chút trí tưởng tượng và khám phá trang web. Do đó, bạn không chỉ có thể tải kênh hoặc máy chủ mà còn có thể tải các phần riêng lẻ của ứng dụng, chẳng hạn như cơ sở dữ liệu hoặc hệ thống tệp. Bạn cũng có thể tìm kiếm các vị trí trên trang web thực hiện các phép tính lớn: máy tính, trang chọn sản phẩm, v.v. Cuối cùng, điều thường xảy ra là trang web có một số loại tập lệnh PHP tạo ra một trang có vài trăm nghìn dòng. Tập lệnh như vậy cũng tải đáng kể máy chủ và có thể trở thành mục tiêu cho một cuộc tấn công.
Nhìn ở đâu
Tất nhiên, khi chúng tôi quét một tài nguyên trước khi kiểm tra, trước tiên chúng tôi sẽ xem xét chính trang web đó. Chúng tôi đang tìm kiếm tất cả các loại trường đầu vào, tệp nặng - nói chung là mọi thứ có thể gây ra sự cố cho tài nguyên và làm chậm hoạt động của tài nguyên. Các công cụ phát triển tầm thường trong Google Chrome và Firefox trợ giúp tại đây, hiển thị thời gian phản hồi của trang.
Chúng tôi cũng quét các tên miền phụ. Ví dụ: có một cửa hàng trực tuyến nhất định, abc.com và nó có tên miền phụ admin.abc.com. Rất có thể, đây là bảng quản trị có quyền, nhưng nếu bạn đặt tải lên nó, nó có thể gây ra sự cố cho tài nguyên chính.
Trang web có thể có tên miền phụ api.abc.com. Rất có thể, đây là tài nguyên dành cho ứng dụng di động. Bạn có thể tìm thấy ứng dụng này trong App Store hoặc Google Play, cài đặt một điểm truy cập đặc biệt, phân tích API và đăng ký tài khoản thử nghiệm. Vấn đề là mọi người thường nghĩ rằng bất cứ thứ gì được ủy quyền bảo vệ đều miễn nhiễm với các cuộc tấn công từ chối dịch vụ. Người ta cho rằng ủy quyền là CAPTCHA tốt nhất, nhưng thực tế không phải vậy. Thật dễ dàng để tạo 10-20 tài khoản thử nghiệm, nhưng bằng cách tạo chúng, chúng tôi có quyền truy cập vào chức năng phức tạp và rõ ràng.
Đương nhiên, chúng tôi xem xét lịch sử, tại robots.txt và WebArchive, ViewDNS, đồng thời tìm kiếm các phiên bản cũ của tài nguyên. Đôi khi xảy ra trường hợp các nhà phát triển đã triển khai, chẳng hạn như mail2.yandex.net, nhưng phiên bản cũ, mail.yandex.net, vẫn còn. Mail.yandex.net này không còn được hỗ trợ, tài nguyên phát triển không được phân bổ cho nó nhưng nó vẫn tiếp tục tiêu thụ cơ sở dữ liệu. Theo đó, bằng cách sử dụng phiên bản cũ, bạn có thể sử dụng hiệu quả các tài nguyên của phần phụ trợ và mọi thứ đằng sau bố cục. Tất nhiên, điều này không phải lúc nào cũng xảy ra nhưng chúng ta vẫn gặp phải điều này khá thường xuyên.
Đương nhiên, chúng tôi phân tích tất cả các tham số yêu cầu và cấu trúc cookie. Ví dụ: bạn có thể chuyển một số giá trị vào một mảng JSON bên trong cookie, tạo ra nhiều phần lồng nhau và khiến tài nguyên hoạt động trong một thời gian dài một cách vô lý.
Tải tìm kiếm
Điều đầu tiên bạn nghĩ đến khi nghiên cứu một trang web là tải cơ sở dữ liệu, vì hầu hết mọi người đều có một tìm kiếm và thật không may, đối với hầu hết mọi người, nó được bảo vệ kém. Vì lý do nào đó, các nhà phát triển không quan tâm đầy đủ đến việc tìm kiếm. Nhưng có một khuyến nghị ở đây - bạn không nên thực hiện các yêu cầu cùng loại, vì bạn có thể gặp phải tình trạng lưu vào bộ nhớ đệm, như trường hợp tràn HTTP.
Việc thực hiện các truy vấn ngẫu nhiên tới cơ sở dữ liệu cũng không phải lúc nào cũng hiệu quả. Sẽ tốt hơn nhiều nếu bạn tạo danh sách từ khóa có liên quan đến tìm kiếm. Nếu chúng ta quay lại ví dụ về một cửa hàng trực tuyến: giả sử trang web bán lốp ô tô và cho phép bạn đặt bán kính của lốp, loại ô tô và các thông số khác. Theo đó, sự kết hợp của các từ liên quan sẽ buộc cơ sở dữ liệu phải hoạt động trong những điều kiện phức tạp hơn nhiều.
Ngoài ra, bạn nên sử dụng tính năng phân trang: việc tìm kiếm trả về trang áp chót của kết quả tìm kiếm sẽ khó hơn nhiều so với trang đầu tiên. Nghĩa là, với sự trợ giúp của phân trang, bạn có thể đa dạng hóa tải một chút.
Ví dụ dưới đây cho thấy tải tìm kiếm. Có thể thấy, ngay từ giây đầu tiên của cuộc thử nghiệm với tốc độ 10 yêu cầu/giây, trang web đã ngừng hoạt động và không phản hồi.
Nếu không có tìm kiếm?
Nếu không có tìm kiếm, điều này không có nghĩa là trang web không chứa các trường nhập dễ bị tấn công khác. Trường này có thể được ủy quyền. Ngày nay, các nhà phát triển muốn tạo các hàm băm phức tạp để bảo vệ cơ sở dữ liệu đăng nhập khỏi cuộc tấn công bảng cầu vồng. Điều này là tốt, nhưng việc băm như vậy tiêu tốn rất nhiều tài nguyên CPU. Một lượng lớn ủy quyền sai dẫn đến lỗi bộ xử lý và kết quả là trang web ngừng hoạt động.
Sự hiện diện trên trang web của tất cả các loại hình thức nhận xét và phản hồi là lý do để gửi những văn bản rất lớn đến đó hoặc đơn giản là tạo ra một cơn lũ lớn. Đôi khi các trang web chấp nhận các tệp đính kèm, kể cả ở định dạng gzip. Trong trường hợp này, chúng tôi lấy một tệp 1TB, nén nó thành vài byte hoặc kilobyte bằng gzip và gửi nó đến trang web. Sau đó, nó được giải nén và thu được một hiệu ứng rất thú vị.
API nghỉ ngơi
Tôi muốn chú ý một chút đến các dịch vụ phổ biến như Rest API. Việc bảo mật Rest API khó hơn nhiều so với một trang web thông thường. Ngay cả các phương pháp bảo vệ tầm thường chống lại việc sử dụng mật khẩu thô bạo và các hoạt động bất hợp pháp khác cũng không hoạt động đối với Rest API.
Rest API rất dễ bị hỏng vì nó truy cập trực tiếp vào cơ sở dữ liệu. Đồng thời, sự thất bại của dịch vụ này kéo theo những hậu quả khá nghiêm trọng cho doanh nghiệp. Thực tế là Rest API thường không chỉ được sử dụng cho trang web chính mà còn cho ứng dụng di động và một số tài nguyên nội bộ của doanh nghiệp. Và nếu tất cả những điều này thất bại, thì hiệu ứng sẽ mạnh hơn nhiều so với trường hợp trang web đơn giản bị lỗi.
Đang tải nội dung nặng
Nếu chúng tôi được đề nghị thử nghiệm một số ứng dụng một trang, trang đích hoặc trang web danh thiếp thông thường không có chức năng phức tạp, chúng tôi sẽ tìm kiếm nội dung nặng. Ví dụ: hình ảnh lớn mà máy chủ gửi, tệp nhị phân, tài liệu pdf - chúng tôi cố gắng tải xuống tất cả những thứ này. Những thử nghiệm như vậy tải hệ thống tệp tốt và làm tắc nghẽn các kênh, do đó có hiệu quả. Nghĩa là, ngay cả khi bạn không đặt máy chủ xuống, tải xuống một tệp lớn ở tốc độ thấp, bạn sẽ chỉ làm tắc nghẽn kênh của máy chủ mục tiêu và sau đó sẽ xảy ra hiện tượng từ chối dịch vụ.
Một ví dụ về thử nghiệm như vậy cho thấy rằng ở tốc độ 30 RPS, trang web đã ngừng phản hồi hoặc tạo ra lỗi máy chủ thứ 500.
Đừng quên việc thiết lập máy chủ. Bạn thường có thể thấy rằng một người đã mua một máy ảo, cài đặt Apache ở đó, định cấu hình mọi thứ theo mặc định, cài đặt ứng dụng PHP và bạn có thể xem kết quả bên dưới.
Ở đây tải đã đi đến thư mục gốc và chỉ đạt 10 RPS. Chúng tôi đợi 5 phút và máy chủ bị lỗi. Đúng là người ta không hoàn toàn biết lý do tại sao anh ta bị ngã, nhưng có giả định rằng đơn giản là anh ta có quá nhiều trí nhớ nên đã ngừng phản ứng.
Dựa trên sóng
Trong một hoặc hai năm trở lại đây, các cuộc tấn công theo làn sóng đã trở nên khá phổ biến. Điều này là do nhiều tổ chức mua một số phần cứng nhất định để bảo vệ DDoS, đòi hỏi một khoảng thời gian nhất định để tích lũy số liệu thống kê để bắt đầu lọc cuộc tấn công. Tức là họ không lọc đòn tấn công trong 30-40 giây đầu tiên, vì họ tích lũy dữ liệu và học hỏi. Theo đó, trong 30-40 giây này, bạn có thể khởi chạy nhiều thứ trên trang web đến mức tài nguyên sẽ nằm trong một thời gian dài cho đến khi tất cả các yêu cầu được xóa.
Trong trường hợp cuộc tấn công dưới đây, có khoảng thời gian 10 phút, sau đó một phần mới, được sửa đổi của cuộc tấn công sẽ đến.
Nghĩa là, bên phòng thủ đã học được, bắt đầu lọc, nhưng một phần mới, hoàn toàn khác của cuộc tấn công đã xuất hiện và bên phòng thủ bắt đầu học lại. Trên thực tế, tính năng lọc ngừng hoạt động, tính năng bảo vệ trở nên không hiệu quả và trang web không còn khả dụng.
Các cuộc tấn công dạng sóng được đặc trưng bởi giá trị rất cao ở đỉnh điểm, nó có thể đạt tới một trăm nghìn hoặc một triệu yêu cầu mỗi giây, trong trường hợp của L7. Nếu chúng ta nói về L3&4, thì có thể có hàng trăm gigabit lưu lượng truy cập, hoặc theo đó, hàng trăm mpps, nếu bạn tính theo gói.
Vấn đề với các cuộc tấn công như vậy là sự đồng bộ hóa. Các cuộc tấn công đến từ mạng botnet và yêu cầu mức độ đồng bộ hóa cao để tạo ra mức tăng đột biến một lần rất lớn. Và sự phối hợp này không phải lúc nào cũng thành công: đôi khi đầu ra là một loại đỉnh parabol nào đó, trông khá thảm hại.
Không chỉ HTTP
Ngoài HTTP ở L7, chúng tôi muốn khai thác các giao thức khác. Theo quy định, một trang web thông thường, đặc biệt là một trang web lưu trữ thông thường, có các giao thức thư và MySQL gắn liền với nó. Các giao thức thư có mức tải ít hơn so với cơ sở dữ liệu, nhưng chúng cũng có thể được tải khá hiệu quả và khiến CPU trên máy chủ bị quá tải.
Trên thực tế, chúng tôi đã thành công với lỗ hổng SSH 2016. Hiện tại lỗ hổng này đã được sửa cho hầu hết mọi người, nhưng điều này không có nghĩa là không thể gửi tải tới SSH. Có thể. Đơn giản là có một lượng lớn ủy quyền, SSH ngốn gần như toàn bộ CPU trên máy chủ và sau đó trang web bị sập do một hoặc hai yêu cầu mỗi giây. Theo đó, một hoặc hai yêu cầu dựa trên nhật ký này không thể được phân biệt với tải hợp pháp.
Nhiều kết nối mà chúng tôi mở trong máy chủ cũng vẫn có liên quan. Trước đây, Apache đã mắc lỗi này, bây giờ nginx thực sự mắc lỗi này, vì nó thường được cấu hình theo mặc định. Số lượng kết nối mà nginx có thể mở bị hạn chế nên chúng tôi mở số lượng kết nối này, nginx không còn chấp nhận kết nối mới và kết quả là trang web không hoạt động.
Cụm thử nghiệm của chúng tôi có đủ CPU để tấn công bắt tay SSL. Về nguyên tắc, như thực tế cho thấy, đôi khi botnet cũng thích làm điều này. Một mặt, rõ ràng là bạn không thể làm gì nếu không có SSL, vì kết quả, xếp hạng, bảo mật của Google. Mặt khác, SSL không may gặp vấn đề về CPU.
L3&4
Khi chúng ta nói về một cuộc tấn công ở cấp độ L3&4, chúng ta thường nói về một cuộc tấn công ở cấp độ liên kết. Tải như vậy hầu như luôn có thể phân biệt được với tải hợp pháp, trừ khi đó là cuộc tấn công SYN-flood. Vấn đề với các cuộc tấn công SYN-flood đối với các công cụ bảo mật là khối lượng lớn của chúng. Giá trị L3&4 tối đa là 1,5-2 Tbit/s. Loại lưu lượng truy cập này rất khó xử lý ngay cả đối với các công ty lớn, bao gồm cả Oracle và Google.
SYN và SYN-ACK là các gói được sử dụng khi thiết lập kết nối. Do đó, SYN-flood rất khó phân biệt với tải hợp pháp: không rõ liệu đây là SYN đến để thiết lập kết nối hay là một phần của đợt lũ.
UDP-lũ
Thông thường, những kẻ tấn công không có khả năng mà chúng tôi có, vì vậy khả năng khuếch đại có thể được sử dụng để tổ chức các cuộc tấn công. Nghĩa là, kẻ tấn công quét Internet và tìm thấy các máy chủ dễ bị tấn công hoặc được cấu hình không chính xác, chẳng hạn như để phản hồi một gói SYN, hãy phản hồi bằng ba SYN-ACK. Bằng cách giả mạo địa chỉ nguồn từ địa chỉ của máy chủ mục tiêu, có thể tăng sức mạnh lên gấp ba lần với một gói duy nhất và chuyển hướng lưu lượng truy cập đến nạn nhân.
Vấn đề với sự khuếch đại là chúng rất khó bị phát hiện. Các ví dụ gần đây bao gồm trường hợp giật gân về memcached dễ bị tấn công. Thêm vào đó, hiện nay có rất nhiều thiết bị IoT, camera IP, hầu hết cũng được cấu hình theo mặc định và mặc định chúng được cấu hình không chính xác, đó là lý do tại sao những kẻ tấn công thường thực hiện các cuộc tấn công thông qua các thiết bị như vậy.
Lũ SYN khó khăn
SYN-flood có lẽ là kiểu tấn công thú vị nhất theo quan điểm của nhà phát triển. Vấn đề là các quản trị viên hệ thống thường sử dụng tính năng chặn IP để bảo vệ. Hơn nữa, việc chặn IP không chỉ ảnh hưởng đến các quản trị viên hệ thống hoạt động bằng cách sử dụng tập lệnh mà còn ảnh hưởng đến một số hệ thống bảo mật được mua với giá rất cao.
Phương pháp này có thể trở thành thảm họa, vì nếu kẻ tấn công thay thế địa chỉ IP, công ty sẽ chặn mạng con của chính mình. Khi Tường lửa chặn cụm riêng của nó, đầu ra sẽ không tương tác với bên ngoài và tài nguyên sẽ không thành công.
Hơn nữa, việc chặn mạng của chính bạn không khó. Nếu văn phòng của khách hàng có mạng Wi-Fi hoặc nếu hiệu suất của tài nguyên được đo bằng nhiều hệ thống giám sát khác nhau thì chúng tôi sẽ lấy địa chỉ IP của hệ thống giám sát này hoặc Wi-Fi văn phòng của khách hàng và sử dụng nó làm nguồn. Cuối cùng, tài nguyên dường như có sẵn nhưng địa chỉ IP mục tiêu bị chặn. Do đó, mạng Wi-Fi của hội nghị HighLoad, nơi giới thiệu sản phẩm mới của công ty, có thể bị chặn và điều này kéo theo một số chi phí kinh tế và kinh doanh nhất định.
Trong quá trình thử nghiệm, chúng tôi không thể sử dụng tính năng khuếch đại thông qua memcached bằng bất kỳ tài nguyên bên ngoài nào vì có thỏa thuận chỉ gửi lưu lượng truy cập đến các địa chỉ IP được phép. Theo đó, chúng tôi sử dụng khuếch đại thông qua SYN và SYN-ACK, khi hệ thống phản hồi gửi một SYN với hai hoặc ba SYN-ACK và ở đầu ra, cuộc tấn công được nhân lên hai hoặc ba lần.
Dụng cụ
Một trong những công cụ chính mà chúng tôi sử dụng cho khối lượng công việc L7 là Yandex-tank. Đặc biệt, một bóng ma được sử dụng làm súng, ngoài ra còn có một số tập lệnh để tạo hộp mực và phân tích kết quả.
Tcpdump được sử dụng để phân tích lưu lượng mạng và Nmap được sử dụng để phân tích máy chủ. Để tạo tải ở cấp độ L3&4, OpenSSL và một chút phép thuật của chúng tôi với thư viện DPDK được sử dụng. DPDK là một thư viện của Intel cho phép bạn làm việc với giao diện mạng bỏ qua ngăn xếp Linux, từ đó tăng hiệu quả. Đương nhiên, chúng tôi sử dụng DPDK không chỉ ở cấp độ L3&4 mà còn ở cấp độ L7, vì nó cho phép chúng tôi tạo ra luồng tải rất cao, trong phạm vi vài triệu yêu cầu mỗi giây từ một máy.
Chúng tôi cũng sử dụng một số công cụ tạo lưu lượng truy cập và công cụ đặc biệt mà chúng tôi viết cho các thử nghiệm cụ thể. Nếu chúng tôi nhớ lại lỗ hổng trong SSH thì bộ trên không thể bị khai thác. Nếu chúng tôi tấn công giao thức thư, chúng tôi sẽ lấy các tiện ích thư hoặc đơn giản là viết các tập lệnh lên chúng.
Những phát hiện
Để kết luận tôi muốn nói:
- Ngoài việc kiểm tra tải cổ điển, cần tiến hành kiểm tra sức chịu đựng. Chúng tôi có một ví dụ thực tế trong đó nhà thầu phụ của đối tác chỉ thực hiện kiểm tra tải. Nó cho thấy rằng tài nguyên có thể chịu được tải bình thường. Nhưng sau đó, tải bất thường xuất hiện, khách truy cập trang web bắt đầu sử dụng tài nguyên theo cách khác một chút và kết quả là nhà thầu phụ đã bỏ cuộc. Vì vậy, bạn nên tìm kiếm các lỗ hổng ngay cả khi bạn đã được bảo vệ khỏi các cuộc tấn công DDoS.
- Cần phải cách ly một số phần của hệ thống với những phần khác. Nếu bạn có một tìm kiếm, bạn cần phải di chuyển nó đến các máy riêng biệt, tức là thậm chí không phải đến Docker. Bởi vì nếu tìm kiếm hoặc ủy quyền không thành công, ít nhất một cái gì đó sẽ tiếp tục hoạt động. Trong trường hợp cửa hàng trực tuyến, người dùng sẽ tiếp tục tìm sản phẩm trong danh mục, đi từ trang tổng hợp, mua nếu họ đã được ủy quyền hoặc ủy quyền qua OAuth2.
- Đừng bỏ bê tất cả các loại dịch vụ đám mây.
- Sử dụng CDN không chỉ để tối ưu hóa độ trễ mạng mà còn như một phương tiện bảo vệ chống lại các cuộc tấn công làm cạn kiệt kênh và đơn giản là làm tràn vào lưu lượng tĩnh.
- Cần phải sử dụng dịch vụ bảo vệ chuyên dụng. Bạn không thể tự bảo vệ mình khỏi các cuộc tấn công L3&4 ở cấp độ kênh, vì rất có thể bạn không có đủ kênh. Bạn cũng khó có thể chống lại các cuộc tấn công L7 vì chúng có thể rất lớn. Thêm vào đó, việc tìm kiếm các cuộc tấn công nhỏ vẫn là đặc quyền của các dịch vụ đặc biệt, các thuật toán đặc biệt.
- Cập nhật thường xuyên. Điều này không chỉ áp dụng cho kernel mà còn cho daemon SSH, đặc biệt nếu bạn mở chúng ra bên ngoài. Về nguyên tắc, mọi thứ cần phải được cập nhật, vì bạn khó có thể tự mình theo dõi một số lỗ hổng nhất định.
Nguồn: www.habr.com