Tor triển khai phòng thủ proof-of-work cho dịch vụ onion
(blog.torproject.org)- Tor 0.4.8 triển khai cơ chế phòng thủ ưu tiên xử lý lưu lượng mạng đã được xác minh khi dịch vụ onion bị tấn công DoS
- Trong cấu trúc dịch vụ onion che giấu địa chỉ IP, việc giới hạn tốc độ dựa trên IP là không đầy đủ, nên cần một phương thức câu đố phía máy khách không làm tổn hại quyền riêng tư
- Khi dịch vụ chịu áp lực, máy khách phải chứng minh khối lượng công việc bằng các phép tính câu đố ngày càng khó hơn, và mức độ đó sẽ quyết định mức ưu tiên kết nối
- Thời gian giải ban đầu của người dùng thông thường là khoảng 5ms trên máy tính nhanh và tối đa 30ms trên phần cứng chậm, nên đa số thiết bị đều có thể xử lý được
- Khi lưu lượng tấn công tăng lên, khối lượng công việc yêu cầu có thể tăng tới khoảng 1 phút, khiến các nỗ lực kết nối hàng loạt trở nên tốn kém hơn, trong khi người dùng hợp lệ vẫn có cơ hội truy cập ngay cả khi tắc nghẽn
Cơ chế phòng thủ PoW cho dịch vụ onion trong Tor 0.4.8
- Tor đã chính thức giới thiệu cơ chế phòng thủ proof-of-work (PoW) cho dịch vụ onion cùng với bản phát hành Tor 0.4.8
- Mục tiêu là kiềm chế các cuộc tấn công DoS đồng thời ưu tiên lưu lượng đã được xác minh
- Nhà vận hành dịch vụ onion được khuyến nghị cập nhật lên phiên bản 0.4.8
- Dịch vụ onion che giấu địa chỉ IP để bảo vệ quyền riêng tư của người dùng nên có thể dễ bị tấn công DoS, và chỉ dựa vào giới hạn tốc độ truyền thống theo IP thì chưa thể bảo vệ đầy đủ
Câu đố phía máy khách và xử lý ưu tiên
- Về cơ bản, PoW hoạt động như một hệ thống vé mặc định bị tắt, nhưng khi mạng bị căng thẳng thì sẽ tạo ra hàng đợi ưu tiên
- Trước khi truy cập dịch vụ onion, máy khách phải giải một câu đố nhỏ để chứng minh đã thực hiện một khối lượng công việc nhất định
- Câu đố càng khó thì đồng nghĩa đã thực hiện càng nhiều công việc
- Dịch vụ onion xác định mức ưu tiên kết nối dựa trên mức độ nỗ lực mà máy khách thể hiện
- Nếu kẻ tấn công làm ngập dịch vụ onion bằng nhiều yêu cầu, nỗ lực tính toán cần thiết để truy cập trang
.onionsẽ tăng lên- Các nỗ lực kết nối hàng loạt sẽ đòi hỏi nhiều tài nguyên tính toán hơn
- Khi khối lượng công việc tăng, khả năng sinh lợi của kẻ tấn công sẽ giảm đi
Ảnh hưởng mà người dùng thông thường cảm nhận được
- Người dùng thông thường thường chỉ gửi ít yêu cầu trong một lần, nên gánh nặng giải câu đố vẫn ở mức mà đa số thiết bị có thể xử lý được
- Thời gian giải ban đầu khoảng 5ms trên máy tính nhanh
- Tối đa 30ms trên phần cứng chậm
- Khi lưu lượng tấn công tăng, khối lượng công việc có thể tăng tới khoảng 1 phút
- Quá trình này không hiển thị với người dùng, và trải nghiệm chờ lời giải PoW tương tự như chờ một kết nối mạng chậm
- Nếu các trang lớn áp dụng cách này, có thể giảm tác động tiêu cực của các cuộc tấn công có chủ đích lên tốc độ mạng, đồng thời giúp cân bằng tải khi lưu lượng tăng đột biến, từ đó khiến việc truy cập dịch vụ onion ổn định và đáng tin cậy hơn
1 bình luận
Ý kiến trên Hacker News
Thú vị. Nhìn vào đề xuất thì kỳ vọng khá rõ ràng: mục tiêu không phải là chặn botnet lớn, mà là phòng thủ trước script kiddie hoặc botnet quy mô nhỏ
Ngay cả khi đang bị tấn công DoS, người dùng thật sự muốn truy cập vẫn có thể đi qua, nhưng có thể phải bỏ ra một mức công sức nhất định
Việc chọn https://github.com/tevador/equix làm thuật toán proof-of-work cũng thú vị
Không phải kiểu như Bitcoin, nơi chỉ cần xuống dưới một giá trị mục tiêu tĩnh là thành công; thay vào đó client “đấu giá” bằng nỗ lực proof-of-work, và càng bỏ nhiều công sức thì mức ưu tiên càng cao. Phần mô tả nói nó giống proof-of-stake ở chỗ thay vì ký quỹ coin thì ký quỹ bằng công việc
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...
Phiên bản này cũng tốt, nhưng tôi nghĩ sẽ tốt hơn nếu bổ sung chuyển giao giá trị
Hơn nữa, proof-of-work chỉ là phép tính không cần thiết và lãng phí. Tính toán không miễn phí, và từng watt dùng cho proof-of-work đều làm cuộc khủng hoảng khí hậu hiện nay tệ hơn
Với tư cách là người sống ở nơi trong vài ngày tới sẽ lên tới mức cảm nhận 120 độ, thực tế 109 độ, nói một cách lịch sự thì tôi muốn bảo bất kỳ ai đề xuất proof-of-work là ý tưởng hay cho bất cứ thứ gì hãy biến đi
Nó không thú vị, mà là ví dụ trắng trợn nhất trên Trái Đất về tiêu dùng phô trương
Bài viết tốt hơn, tức là phần chi tiết kỹ thuật thực sự, nằm ở https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
Hàm proof-of-work được chọn có vẻ là equi-X
Tôi ngạc nhiên là thứ như vậy không được đưa vào sớm hơn, và vì chưa đọc đề xuất [0] đủ kỹ nên chưa biết liệu nó có làm tăng dữ liệu ảnh hưởng tới tính ẩn danh của người dùng hay không. Dù vậy, nếu nó chỉ được gắn theo cặp người dùng-dịch vụ và không được lưu ở đâu cả thì có vẻ ổn
Tôi cũng tò mò nó sẽ giảm tải cho dịch vụ được proxy và cho chính node lần lượt ở mức nào. Vì truy cập được phân tán qua nhiều node, có lẽ phía dịch vụ sẽ hưởng lợi nhiều hơn
[0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
Tốt. Có lẽ sắp tới sẽ không còn cần CDN chống DDoS nữa. Chỉ cần cung cấp API dưới dạng dịch vụ Onion là được
Cách này từng được đề xuất trước đây để chống spam email
Cloudflare cũng có thể làm vậy. Mỗi lần truy cập một trang bận rộn, bạn sẽ phải chạy các phép tính vô dụng trong vài giây đến vài phút. Tác động tổng thể có lẽ là hút cạn pin trên toàn thế giới
http://www.hashcash.org/
Thú vị là nó đã trở thành nguồn cảm hứng cho khai thác proof-of-work của Bitcoin
Vì nó còn sẽ phun khí nhà kính vào khí quyển nữa
Tôi tự hỏi điều gì ngăn kẻ lạm dụng lấy danh tính mới và tiếp tục DDoS khi proof-of-work bắt đầu có tác dụng
Sửa: có vẻ proof-of-work được thiết lập theo đơn vị “dịch vụ” bị tấn công, chứ không phải theo client
Do tính ẩn danh hoặc khả năng tự do tạo danh tính mới, kẻ tấn công có thể dùng tấn công Sybil để làm cạn kiệt dung lượng và gây từ chối dịch vụ
Tôi tự hỏi liệu có cách nào giải quyết tấn công Sybil một cách thanh nhã hơn ở đây không. Ví dụ, nhiều CPU có một cặp khóa riêng cho từng bộ xử lý, và có thể xác minh bằng chứng chỉ gốc CA của bên phát hành như Intel, AMD, v.v. Nếu gắn bằng chứng công việc với chữ ký liên tiếp và cho phép xác minh song song, thì mọi bằng chứng công việc sẽ trở nên duy nhất theo từng CPU, khiến botnet không thể song song hóa được
Có vẻ họ đang nhắm vào bộ nhớ để tăng chi phí của botnet. Dường như cũng có nhiều cách khác để giảm kịch bản tấn công này. Có lẽ có thể áp dụng cùng logic cho điện thoại dùng eSIM. Về sau, xác thực mạng di động dùng mật mã khóa công khai, nên có lẽ cũng có thể có bằng chứng duy nhất
Đây chỉ là ý nghĩ thoáng qua, nên rất có thể tôi đang bỏ sót những vấn đề hiển nhiên của cách này
Lý do chọn thuật toán dùng nhiều bộ nhớ là để ngăn dùng phần cứng chuyên dụng, tức ASIC
Theo hướng tương tự, liệu có thể để server nắm nhiều pool IP và buộc client trả về bằng chứng port knocking không? Ví dụ như đưa một token, yêu cầu gửi đến IP:port này, rồi chờ một phản hồi duy nhất mà tôi có thể xác minh. Có thể gọi đây là bằng chứng độ trễ. Mức dùng CPU thấp và có thể phân tán tải qua nhiều máy và cổng. Nhược điểm hiển nhiên là cần nhiều IP và có khả năng nhiều server. Cũng có thể triển khai trên cùng một máy, nhưng khi đó tải CPU chỉ chuyển sang các kết nối cổng mà thôi
Tôi có một ý tưởng để giảm lưu lượng hoặc làm mạng Tor nhanh hơn. Cần có thể dùng mạng như một CDN. Nếu muốn công khai một tệp, ta có thể gửi các mảnh tệp cho những node được phép, và khi có yêu cầu tệp thì có thể trỏ tới các node đó
Tất nhiên cần cẩn thận để mạng Tor không trở thành “phương án thay thế torrent ẩn danh” và làm hỏng mục đích của nó
Đề xuất hiện tại nói về “ưu tiên lưu lượng mạng đã được xác minh”. Vì việc đó thực sự giúp mạng, sẽ khá thú vị nếu chia sẻ “mảnh tệp” có thể nâng mức ưu tiên lưu lượng. Khi đó nó sẽ là bằng chứng đóng góp băng thông thay vì “bằng chứng công việc”
Dù vậy, tôi vẫn chưa rõ điều này giảm lưu lượng mạng như thế nào. Dù sao thì vẫn phải giao tiếp với các node CDN
Nhìn vào mục tiêu và giới hạn mà đề xuất này đặt ra, nó có vẻ hợp lý, và có lẽ sẽ đạt được mục tiêu đó. Như đã nói, nó sẽ hiệu quả với botnet nhỏ, nhưng botnet lớn vẫn có thể áp đảo tài nguyên sẵn có của từng client
Cá nhân tôi không thích bằng chứng công việc. Ở đây nó gần giống phi đối xứng như một cơ chế phòng thủ, có thể nhanh chóng khiến phần cứng cũ trở nên lỗi thời, và xét trên toàn bộ các thiết bị bị ảnh hưởng thì có khả năng tiêu tốn khá nhiều điện. Nếu được áp dụng ở quy mô lớn, đây sẽ là một gánh nặng môi trường đáng kể
Từ góc nhìn của kẻ tấn công, việc đẩy độ khó lên cao như vậy tự thân cũng có thể xem là thành công. Nếu người dùng phải chạy thiết bị ở 100% và chờ 1 phút, trong nhiều trường hợp họ sẽ đơn giản là rời đi
Dù vậy, đây là một cách khá tốt để giảm nhẹ tấn công DoS mà không làm tổn hại tính ẩn danh của người dùng, nên từ góc nhìn đó, bất chấp nhược điểm, nó là một giải pháp tốt. Miễn là nó chỉ tồn tại trong Tor thì không có vấn đề lớn, nhưng nếu áp dụng cho web thông thường thì tôi cho là sẽ là thảm họa hoàn toàn
Bài viết nói chênh lệch thời gian giải giữa server cao cấp và điện thoại cấu hình thấp chỉ 6 lần. Tôi không hiểu điều đó có thể xảy ra như thế nào. Server có thể có nhiều RAM và nhiều CPU hơn điện thoại rất nhiều, vượt xa 6 lần, và CPU cũng có khả năng nhanh hơn
Ngoài ra, nếu là DDoS thì công việc của server song song hóa tốt đến mức khó xử, còn công việc của client thì không nhất thiết song song hóa được
Dù chênh lệch là 6 lần, hay thậm chí chỉ 1 lần, bài viết nói khi phát hiện DDoS thì thời gian giải là 1 phút. Đến lúc đó chẳng phải dịch vụ về cơ bản đã sập rồi sao?
Điểm cốt lõi của phần thời gian giải 1 phút khi phát hiện DDoS là biến kiểu DoS dễ thực hiện trước đây, introduction flooding, thành lỗi cục bộ hoặc giảm tốc độ. Đó là cải thiện từng bước cho một vấn đề khó