Hướng dẫn an toàn DeFi: Làm thế nào để phòng thủ hiệu quả trước các cuộc tấn công của hacker trong thời đại AI?

Tiêu đề gốc: Cách Ngăn Chặn Mất Tiền Do Các Cuộc Tấn Công DeFi
Tác giả gốc: sysls, openforage
Dịch bởi: AididiaoJP, Foresight News

Tác giả gốc:律动BlockBeats

Nguồn gốc bài viết:

Chuyển thể: 火星财经

Giới thiệu

Khi hiểu rõ về hàng loạt các vụ tấn công hacker vào các giao thức DeFi, tôi đã cảm thấy sợ hãi về các “các thể hành động quốc gia”. Họ có kỹ năng xuất sắc, nguồn lực dồi dào, và chơi trò chơi dài hạn cực kỳ; những phản diện siêu cấp này tập trung vào việc rà soát từng góc của giao thức và hạ tầng của bạn để tìm lỗ hổng, trong khi các nhóm giao thức bình thường lại bị phân tán chú ý vào sáu bảy lĩnh vực kinh doanh khác nhau.

Tôi không tự nhận là chuyên gia an ninh, nhưng tôi đã từng lãnh đạo các nhóm trong môi trường rủi ro cao (bao gồm quân đội và lĩnh vực tài chính với nguồn vốn lớn), có nhiều kinh nghiệm trong việc suy nghĩ và lập kế hoạch ứng phó khẩn cấp.

Tôi chân thành tin rằng, chỉ những người cực kỳ cố chấp mới có thể tồn tại. Không có nhóm nào bắt đầu với ý nghĩ “Tôi sẽ làm lơ, coi nhẹ vấn đề an ninh”; tuy nhiên, các cuộc tấn công hacker vẫn xảy ra. Chúng ta cần làm tốt hơn nữa.

AI có nghĩa là lần này thực sự khác biệt

Các cuộc tấn công hacker không hiếm, nhưng tần suất rõ ràng đang tăng lên. Quý 1 năm 2026 là quý có số vụ tấn công DeFi nhiều nhất từ trước đến nay, và quý 2 mới bắt đầu nhưng đã có khả năng phá vỡ kỷ lục của quý trước.

Giả thuyết cốt lõi của tôi là: AI giảm mạnh chi phí tìm lỗ hổng và mở rộng đáng kể phạm vi tấn công. Con người cần vài tuần để rà soát cấu hình của một trăm giao thức để tìm lỗi cấu hình; trong khi mô hình nền tảng mới nhất chỉ cần vài giờ để hoàn thành.

Điều này chắc chắn sẽ thay đổi hoàn toàn cách chúng ta suy nghĩ và ứng phó với các cuộc tấn công hacker. Những giao thức cũ quen thuộc với các biện pháp an ninh trước khi AI trở nên mạnh mẽ hơn đang ngày càng đối mặt với nguy cơ bị “bị hạ gục” trong chớp mắt.

Suy nghĩ qua mặt và theo cấp bậc

Diện tích bề mặt của các cuộc tấn công hacker thực ra có thể quy về ba: nhóm giao thức, hợp đồng thông minh và hạ tầng, ranh giới niềm tin của người dùng (DSN, mạng xã hội, v.v.).

Khi đã xác định được các bề mặt này, ta xây dựng các lớp phòng thủ chồng lên nhau:

· Phòng ngừa: Nếu thực thi nghiêm ngặt, có thể tối đa hóa khả năng giảm thiểu khả năng bị khai thác.

· Giảm thiểu thiệt hại: Khi phòng ngừa thất bại, giới hạn mức thiệt hại.

· Tạm dừng: Không ai có thể đưa ra quyết định tối ưu dưới áp lực lớn. Khi xác định được cuộc tấn công, ngay lập tức kích hoạt công tắc toàn diện. Đóng băng có thể ngăn chặn thiệt hại thêm và tạo không gian suy nghĩ…

· Thu hồi: Nếu mất quyền kiểm soát các thành phần độc hại hoặc bị tấn công, hãy bỏ đi và thay thế chúng.

· Phục hồi: Thu hồi những gì đã mất. Lập kế hoạch liên hệ với các đối tác có thể đóng băng vốn, thu hồi giao dịch và hỗ trợ điều tra trước.

Nguyên tắc

Những nguyên tắc này hướng dẫn chúng ta thực hiện các hành động cụ thể cho từng lớp phòng thủ.

Sử dụng AI tiên tiến rộng rãi

Sử dụng các mô hình AI tiên tiến để quét mã nguồn và cấu hình của bạn, tìm lỗ hổng, và tiến hành thử nghiệm đỏ quy mô lớn: thử tìm lỗ hổng ở phía frontend xem chúng có thể tiếp cận backend không. Hacker cũng làm như vậy. Những gì bạn phát hiện qua quét phòng thủ, họ đã phát hiện qua quét tấn công từ lâu rồi.

Sử dụng các kỹ năng như pashov, nemesis, cùng các nền tảng AI như Cantina (Apex) và Zellic (V12), để quét mã nguồn nhanh chóng trước khi gửi kiểm toán đầy đủ.

Thời gian và ma sát là hàng rào phòng thủ tốt

Thêm nhiều bước và khóa thời gian cho bất kỳ thao tác nào có thể gây thiệt hại. Bạn cần đủ thời gian để can thiệp và đóng băng khi phát hiện bất thường.

Trước đây, lý do phản đối khóa thời gian và thiết lập nhiều bước là gây ma sát cho nhóm giao thức. Giờ đây, bạn không cần quá lo lắng: AI có thể dễ dàng thực hiện các bước này trong nền mà không gây phiền hà.

Bất biến

Hợp đồng thông minh có thể xây dựng phòng thủ bằng cách ghi lại các “sự thật” không thể thay đổi: nếu các sự thật này bị phá vỡ, toàn bộ logic của giao thức sẽ sụp đổ.

Thông thường, bạn chỉ có một số ít các bất biến. Cần cẩn thận nâng chúng lên cấp độ mã nguồn; việc ép buộc nhiều bất biến trong từng hàm sẽ trở nên khó quản lý.

Cân bằng quyền lực

Nhiều cuộc tấn công bắt nguồn từ các ví bị tấn công. Bạn cần cấu hình sao cho: ngay cả khi multi-sig bị tấn công, có thể nhanh chóng hạn chế thiệt hại và đưa giao thức trở lại trạng thái có thể điều hành được.

Điều này đòi hỏi cân bằng giữa quản trị (quyết định mọi thứ) và khả năng cứu hộ (phục hồi sự ổn định có thể quản lý, nhưng không thể thay thế hoặc đảo ngược quản trị).

Chắc chắn sẽ có vấn đề

Từ đầu, hãy giả định: dù bạn thông minh đến đâu, bạn vẫn sẽ bị tấn công. Hợp đồng thông minh hoặc các phụ thuộc của bạn có thể thất bại. Bạn có thể bị tấn công xã hội, nâng cấp mới có thể tạo ra lỗ hổng bạn chưa lường trước.

Khi suy nghĩ như vậy, các giới hạn về tốc độ giảm thiểu thiệt hại và các bộ cắt đứt (circuit breaker) của giao thức sẽ trở thành bạn đồng hành tốt nhất. Giới hạn thiệt hại trong khoảng 5-10%, rồi đóng băng, sau đó lập kế hoạch ứng phó. Không ai có thể đưa ra quyết định tối ưu trong cơn bão lửa.

Thời điểm tốt nhất để lập kế hoạch chính là ngay bây giờ

Trước khi bị tấn công, hãy nghĩ về các phương án ứng phó của bạn. Cố gắng mã hóa các quy trình và tập luyện cùng nhóm để không bị lúng túng khi xảy ra sự cố. Trong thời đại AI, điều này đòi hỏi kỹ năng và thuật toán có thể trình bày nhanh chóng lượng lớn thông tin, chia sẻ tóm tắt và dạng dài cho nhóm cốt lõi của bạn.

Bạn không cần hoàn hảo, nhưng bạn phải tồn tại. Không hệ thống nào từ ngày đầu đã bất khả xâm phạm; qua nhiều vòng lặp, bạn sẽ trở nên phản xương (anti-fragile) bằng cách rút ra bài học.

Việc không bị tấn công không có nghĩa là bạn không thể bị tấn công. Điểm an toàn tối đa thường chính là điểm nguy hiểm nhất.

Biện pháp phòng ngừa

Thiết kế hợp đồng thông minh

Khi xác định các bất biến, hãy nâng chúng thành kiểm tra thời gian chạy. Cân nhắc kỹ xem những bất biến nào thực sự đáng để bắt buộc thực thi.

Đây chính là mô hình FREI-PI (Yêu cầu chức năng, Hiệu ứng, Tương tác, Bất biến giao thức): ở cuối mỗi hàm liên quan đến giá trị, xác nhận lại các bất biến quan trọng mà hàm cam kết duy trì. Nhiều cuộc tấn công qua CEI (Checks-Effects-Interactions) như tấn công đòn bẩy (flash loan), thanh lý qua oracle, hoặc rút tiền qua nhiều hàm đều có thể bị bắt giữ bởi kiểm tra bất biến ở cuối hàm.

Kiểm thử tốt

Kiểm thử đục trạng thái (Stateful fuzzing) tạo ra các chuỗi gọi ngẫu nhiên dựa trên toàn bộ bề mặt công khai của giao thức, và xác nhận bất biến ở mỗi bước. Hầu hết các lỗ hổng trong môi trường sản xuất là qua nhiều giao dịch, và kiểm thử đục trạng thái gần như là cách duy nhất đáng tin cậy để phát hiện các đường đi này trước hacker.

Sử dụng kiểm thử bất biến để xác nhận rằng thuộc tính luôn đúng trong tất cả các chuỗi gọi mà bộ sinh đục trạng thái tạo ra. Kết hợp xác minh hình thức, có thể chứng minh rằng thuộc tính luôn đúng trong mọi trạng thái có thể đến được. Các bất biến của bạn chắc chắn nên chấp nhận xử lý này.

Oracle và phụ thuộc

Độ phức tạp chính là kẻ thù của an ninh. Mỗi phụ thuộc bên ngoài đều mở rộng phạm vi tấn công. Khi thiết kế nguyên thủy, hãy để người dùng quyết định ai và cái gì được tin tưởng. Nếu không thể loại bỏ hoàn toàn phụ thuộc, hãy đa dạng hóa chúng, để không có điểm lỗi đơn lẻ nào có thể phá hủy toàn bộ giao thức của bạn.

Mở rộng phạm vi kiểm toán để mô phỏng các cách oracle và phụ thuộc có thể thất bại, và áp dụng giới hạn tốc độ đối với các thảm họa có thể xảy ra khi chúng thất bại.

Gần đây, lỗ hổng của KelpDAO là một ví dụ: họ kế thừa cấu hình requiredDVNCount=1 của LayerZero, mà cấu hình này nằm ngoài phạm vi kiểm toán của họ. Kết quả là, bị tấn công là hạ tầng off-chain ngoài phạm vi kiểm toán.

Các bề mặt tấn công

Hầu hết các bề mặt tấn công trong DeFi đã được liệt kê. Kiểm tra từng loại, hỏi xem nó có áp dụng cho giao thức của bạn không, rồi thực thi các biện pháp kiểm soát phù hợp. Phát triển kỹ năng red team, để AI của bạn chủ động tìm lỗ hổng trong giao thức; điều này đã trở thành yêu cầu tối thiểu hiện nay.

Có khả năng cứu hộ nguyên bản

Trong quản trị dựa trên bỏ phiếu, quyền lực ban đầu tập trung vào multi-sig của nhóm, cần thời gian để phân tán. Ngay cả khi token phân bổ rộng, việc ủy quyền thường tập trung vào một số ít ví (đôi khi chỉ một ví). Khi các ví này bị tấn công, trò chơi kết thúc.

Triển khai “ví bảo vệ”, cấp quyền hạn chế chặt chẽ: chỉ có thể tạm dừng giao thức, và trong ngưỡng >=4/7, có thể thay thế các ví bị tổn thương bằng ví dự phòng đã định sẵn trong trường hợp cực đoan. Ví bảo vệ không bao giờ được thực hiện các đề xuất quản trị.

Như vậy, bạn có một lớp cứu hộ luôn có thể khôi phục sự ổn định có thể điều hành của giao thức, mà không có quyền đảo ngược hoặc thay thế quản trị. Xác suất mất >=4/7 ví bảo vệ là cực kỳ thấp (xem xét đa dạng chủ sở hữu), và khi quản trị trưởng thành và phân tán, lớp này có thể dần loại bỏ.

Ví và sơ đồ khóa

Ví multi-sig là yêu cầu tối thiểu, tối thiểu 4/7. Không ai kiểm soát tất cả 7 chìa khóa. Thường xuyên luân phiên các người ký, và thực hiện một cách âm thầm.

Chìa khóa không bao giờ nên liên hệ trực tiếp với thiết bị sử dụng hàng ngày. Nếu bạn dùng thiết bị ký để duyệt web, gửi email hoặc mở Slack, coi như chìa khóa đó đã bị tấn công rồi.

Có nhiều ví multi-sig, mỗi ví có mục đích khác nhau. Giả sử ít nhất một ví đầy đủ sẽ bị tấn công, và bắt đầu lập kế hoạch từ đó. Không ai nên có đủ quyền kiểm soát để phá hủy giao thức, kể cả trong các tình huống cực đoan (bắt cóc, tra tấn, v.v.).

Xem xét phần thưởng

Nếu có nguồn lực, việc đặt một khoản thưởng lỗ hổng cao cho giao thức là rất đáng giá; ngay cả với các giao thức nhỏ hơn, thưởng lỗ hổng nên càng hào phóng càng tốt (ví dụ, ít nhất 7-8 chữ số).

Nếu đối mặt với các tác nhân nhà nước, họ có thể không đàm phán, nhưng bạn vẫn có thể tham gia chương trình “bảo vệ white-hat”, ủy quyền cho các white-hat hành động thay bạn để bảo vệ vốn, và nhận phần trăm nhất định của khoản tiền thưởng (thực tế là do người gửi tiền trả).

Tìm kiếm các kiểm toán viên tốt

Trước đây tôi đã viết, khi các mô hình ngôn ngữ lớn trở nên thông minh hơn, giá trị gia tăng của việc thuê kiểm toán viên sẽ giảm. Tôi vẫn giữ quan điểm đó, nhưng đã có những thay đổi.

Trước hết, các kiểm toán viên tốt luôn đi trước đường cong. Nếu bạn làm những thứ mới mẻ, mã của bạn và các lỗ hổng có thể không nằm trong dữ liệu huấn luyện, việc tăng số token chưa chắc đã giúp phát hiện các lỗ hổng mới. Bạn không muốn trở thành mẫu thử đầu tiên của các lỗ hổng đặc biệt.

Thứ hai, một lợi ích ít được đánh giá cao là: thuê kiểm toán viên là dùng uy tín của họ để đảm bảo. Nếu họ ký duyệt và bạn bị tấn công, họ sẽ có động lực mạnh mẽ để giúp đỡ. Thiết lập mối quan hệ với những người chuyên nghiệp trong lĩnh vực an ninh là lợi thế lớn.

Thực hành an toàn vận hành

Xem an toàn vận hành như một chỉ số thành công. Tổ chức các buổi diễn tập phishing; thuê (đáng tin cậy) red team thử tấn công xã hội nhóm của bạn. Chuẩn bị ví cứng dự phòng và thiết bị để thay thế toàn bộ multi-sig khi cần. Bạn không muốn vội vàng mua sắm khi ngày G đến.

Biện pháp giảm thiểu

Lối thoát của bạn chính là giới hạn tổn thất

Mức tối đa của giá trị có thể rút ra khỏi giao thức chính là thiệt hại tối đa có thể xảy ra khi khai thác lỗ hổng. Nói cách khác: hàm tạo token không có giới hạn mỗi block chính là tấm séc trống cho mọi lỗ hổng tạo token vô hạn. Hàm rút tiền không có giới hạn tuần chính là tấm séc trống cho mọi số dư tài sản bị hỏng.

Cân nhắc cẩn thận các con số rõ ràng cho lối thoát của bạn. Con số này cần cân bằng giữa mức thiệt hại tối đa bạn chấp nhận và trải nghiệm người dùng cực đoan nhất. Nếu có vấn đề, đây chính là thứ giúp bạn tránh khỏi phá hủy hoàn toàn.

Danh sách trắng (và danh sách đen)

Hầu hết các giao thức đều có danh sách các địa chỉ có thể gọi, giao dịch hoặc nhận, và danh sách các địa chỉ không thể làm điều đó. Ngay cả khi ẩn danh, đây cũng là ranh giới niềm tin, cần được chính thức hóa.

Việc chính thức hóa giúp bạn thiết lập các bộ điều chỉnh hai bước, tạo ra ma sát có ý nghĩa. Kẻ tấn công trước tiên cần thêm vào danh sách trắng (hoặc loại bỏ khỏi danh sách đen), rồi mới có thể hành động. Đồng thời, có cả hai nghĩa là khi kẻ tấn công cố tình đưa ra các vector mới, chúng phải vượt qua hai quy trình: thị trường phải được phép (tích hợp / niêm yết), và hành động đó không bị cấm (xét duyệt an ninh).

Thu hồi

Giám sát thuật toán

Nếu không có ai giám sát, công tắc an toàn vô dụng. Các bộ giám sát off-chain cần liên tục theo dõi các bất biến, và khi phát hiện vấn đề, tự động nâng cấp cảnh báo. Con đường cuối cùng là gửi đến nhóm multi-sig và cung cấp đủ ngữ cảnh để họ ra quyết định trong vài phút.

Dừng lại và hiệu chỉnh lại

Nếu bị tấn công, bạn cần cầm máu trước, chứ không phải đưa ra quyết định trong đếm ngược. Đối với giao thức, đó chính là nút dừng (kill switch) (cũng cần thể hiện trên UI): một nút bấm có thể tạm dừng tất cả các lối đi chuyển giá trị trong một giao dịch. Chuẩn bị một script “tạm dừng tất cả”, liệt kê tất cả các thành phần có thể tạm dừng và đồng bộ tạm dừng chúng.

Chỉ có quản trị mới có thể mở khóa tạm dừng, vì vậy kill switch không thể tạm dừng hợp đồng quản trị. Nếu lớp bảo vệ có thể tạm dừng hợp đồng quản trị, thì lớp bảo vệ bị tấn công có thể vĩnh viễn khóa quá trình phục hồi.

Khởi động phòng chiến tranh của bạn

Đóng băng, cầm máu, rồi đưa tất cả những người bạn tin tưởng (nhóm nhỏ, đã thỏa thuận trước) vào một kênh liên lạc. Bạn muốn giữ quy mô nhỏ để tránh rò rỉ thông tin cho kẻ tấn công, công chúng hoặc các nhà đầu cơ lợi dụng.

Vai trò rõ ràng cho nhóm: một người ra quyết định; một người thực thi các script phòng thủ và tạm dừng; một người phân tích lỗi và nguyên nhân gốc rễ; một người liên hệ với các bên liên quan chính; một người ghi lại các sự kiện, quyết định và thời gian.

Khi mọi người đã rõ vai trò và đã tập luyện, bạn có thể phản ứng theo quy trình, thay vì hoảng loạn trong thời điểm tồi tệ nhất.

Xem xét phản ứng dây chuyền

Giả định kẻ tấn công của bạn cực kỳ tinh vi. Lỗ hổng đầu tiên có thể chỉ là mồi nhử, hoặc là hạt giống cho các cuộc tấn công tiếp theo. Tấn công có thể là để dụ bạn làm những việc hoàn toàn sai lệch, từ đó kích hoạt lỗ hổng thực sự.

Phải có quá trình tạm dừng được nghiên cứu kỹ, hoàn toàn kiểm soát được, và không thể bị lợi dụng. Tạm dừng nên là toàn bộ hệ thống bị đóng băng: bạn không muốn bị dụ dỗ tạm dừng một thành phần rồi mở ra thành phần khác. Khi đã xác định nguyên nhân gốc và vector tấn công, hãy khám phá các bề mặt lộ ra xung quanh và phản ứng dây chuyền, rồi sửa tất cả cùng lúc.

Thay thế người kế nhiệm đã được cam kết trước

Chỉ khi biết trước người kế nhiệm, việc luân chuyển mới an toàn. Tôi thích ý tưởng về danh sách người kế nhiệm đã đăng ký trước: giúp kẻ tấn công khó hơn trong việc thay thế các bảo vệ / ví quản trị còn khỏe mạnh bằng các ví đã bị tấn công. Điều này phù hợp với nguyên tắc “danh sách trắng / đen” trong các biện pháp giảm thiểu.

Đăng ký một địa chỉ người kế nhiệm cho từng vai trò quan trọng. Nguyên tắc cấp bách duy nhất có thể thực hiện việc luân chuyển là “Thay thế vai trò X bằng người kế nhiệm của nó”. Điều này cũng giúp bạn đánh giá người kế nhiệm trong thời gian bình thường: từ từ, thực hiện thẩm định, gặp mặt người đề xuất.

Thử nghiệm cẩn thận trước khi nâng cấp

Khi đã xác định nguyên nhân gốc và phạm vi ảnh hưởng, bạn cần phát hành bản nâng cấp. Đây có thể là đoạn mã nguy hiểm nhất bạn sẽ triển khai: viết trong áp lực, nhắm vào các hacker đã chứng minh hiểu rõ giao thức của bạn và có thể tìm ra lỗ hổng.

Không phát hành vội vàng mà chưa đủ thử nghiệm. Nếu không có thời gian kiểm toán, hãy dựa vào mối quan hệ white-hat, hoặc tổ chức cuộc thi trong 48 giờ trước khi triển khai để có một cuộc kiểm tra đối kháng mới.

Phục hồi

Hành động nhanh

Tiền bị đánh cắp có nửa đời bán rã; khi lỗ hổng đã lộ, chúng sẽ nhanh chóng vào các đường dây rửa tiền. Chuẩn bị sẵn các nhà cung cấp phân tích on-chain như Chainalysis để theo dõi các địa chỉ hacker, và khi chúng chuyển chéo chuỗi, thông báo cho các sàn giao dịch để đánh dấu và theo dõi.

Chuẩn bị danh sách các tổ chức tuân thủ, quản trị cầu nối chéo chuỗi, quản trị kho bạc, và các bên thứ ba có quyền quản lý có thể đóng băng tin nhắn chéo chuỗi hoặc các khoản gửi tạm thời.

Đàm phán

Vâng, điều này rất đau đớn, nhưng bạn vẫn nên cố gắng đàm phán với hacker. Nhiều thứ trong đời có thể giải quyết qua đàm phán. Cung cấp thưởng white-hat có thời hạn, và công khai tuyên bố nếu họ hoàn trả đầy đủ trước hạn, sẽ không bị pháp luật truy cứu.

Nếu đối mặt với các tác nhân nhà nước, khả năng đàm phán thấp, nhưng bạn vẫn có thể tham gia chương trình “bảo vệ white-hat”, ủy quyền cho white-hat hành động thay bạn để bảo vệ vốn, và nhận phần trăm nhất định của khoản thưởng (thực tế do người gửi tiền trả).

Tìm kiếm kiểm toán viên tốt

Trước đây tôi đã viết, khi các mô hình ngôn ngữ lớn trở nên thông minh hơn, giá trị gia tăng của việc thuê kiểm toán viên sẽ giảm. Tôi vẫn giữ quan điểm đó, nhưng đã có những thay đổi.

Trước hết, các kiểm toán viên tốt luôn đi trước đường cong. Nếu bạn làm những thứ mới, mã của bạn và các lỗ hổng có thể không nằm trong dữ liệu huấn luyện, việc tăng token chưa chắc đã giúp phát hiện các lỗ hổng mới. Bạn không muốn trở thành mẫu thử đầu tiên của các lỗ hổng đặc biệt.

Thứ hai, một lợi ích ít được đánh giá cao là: thuê kiểm toán viên là dùng uy tín của họ để đảm bảo. Nếu họ ký duyệt và bạn bị tấn công, họ sẽ có động lực mạnh mẽ để giúp đỡ. Thiết lập mối quan hệ với các chuyên gia an ninh là lợi thế lớn.

Thực hành an toàn vận hành

Xem an toàn vận hành như một chỉ số thành công. Tổ chức các buổi diễn tập phishing; thuê (đáng tin cậy) red team thử tấn công xã hội nhóm của bạn. Chuẩn bị ví cứng dự phòng và thiết bị để thay thế toàn bộ multi-sig khi cần. Bạn không muốn vội vàng mua sắm khi ngày G đến.

Biện pháp giảm thiểu

Lối thoát của bạn chính là giới hạn tổn thất

Mức tối đa của giá trị có thể rút ra khỏi giao thức chính là thiệt hại tối đa có thể xảy ra khi khai thác lỗ hổng. Nói cách khác: hàm tạo token không có giới hạn mỗi block chính là tấm séc trống cho mọi lỗ hổng tạo token vô hạn. Hàm rút tiền không có giới hạn tuần chính là tấm séc trống cho mọi số dư tài sản bị hỏng.

Cân nhắc cẩn thận các con số rõ ràng cho lối thoát của bạn. Con số này cần cân bằng giữa mức thiệt hại tối đa bạn chấp nhận và trải nghiệm người dùng cực đoan nhất. Nếu có vấn đề, đây chính là thứ giúp bạn tránh khỏi phá hủy hoàn toàn.

Danh sách trắng (và danh sách đen)

Hầu hết các giao thức đều có danh sách các địa chỉ có thể gọi, giao dịch hoặc nhận, và danh sách các địa chỉ không thể làm điều đó. Ngay cả khi ẩn danh, đây cũng là ranh giới niềm tin, cần được chính thức hóa.

Việc chính thức hóa giúp bạn thiết lập các bộ điều chỉnh hai bước, tạo ra ma sát có ý nghĩa. Kẻ tấn công trước tiên cần thêm vào danh sách trắng (hoặc loại bỏ khỏi danh sách đen), rồi mới có thể hành động. Đồng thời, có cả hai nghĩa là khi kẻ tấn công cố tình đưa ra các vector mới, chúng phải vượt qua hai quy trình: thị trường phải được phép (tích hợp / niêm yết), và hành động đó không bị cấm (xét duyệt an ninh).

Thu hồi

Giám sát thuật toán

Nếu không có ai giám sát, công tắc an toàn vô dụng. Các bộ giám sát off-chain cần liên tục theo dõi các bất biến, và khi phát hiện vấn đề, tự động nâng cấp cảnh báo. Con đường cuối cùng là gửi đến nhóm multi-sig và cung cấp đủ ngữ cảnh để họ ra quyết định trong vài phút.

Dừng lại và hiệu chỉnh lại

Nếu bị tấn công, bạn cần cầm máu trước, chứ không phải đưa ra quyết định trong đếm ngược. Đối với giao thức, đó chính là nút dừng (kill switch) (cũng cần thể hiện trên UI): một nút bấm có thể tạm dừng tất cả các lối đi chuyển giá trị trong một giao dịch. Chuẩn bị một script “tạm dừng tất cả”, liệt kê tất cả các thành phần có thể tạm dừng và đồng bộ tạm dừng chúng.

Chỉ có quản trị mới có thể mở khóa tạm dừng, vì vậy kill switch không thể tạm dừng hợp đồng quản trị. Nếu lớp bảo vệ có thể tạm dừng hợp đồng quản trị, thì lớp bảo vệ bị tấn công có thể vĩnh viễn khóa quá trình phục hồi.

Khởi động phòng chiến tranh của bạn

Đóng băng, cầm máu, rồi đưa tất cả những người bạn tin tưởng (nhóm nhỏ, đã thỏa thuận trước) vào một kênh liên lạc. Bạn muốn giữ quy mô nhỏ để tránh rò rỉ thông tin cho kẻ tấn công, công chúng hoặc các nhà đầu cơ lợi dụng.

Vai trò rõ ràng cho nhóm: một người ra quyết định; một người thực thi các script phòng thủ và tạm dừng; một người phân tích lỗi và nguyên nhân gốc rễ; một người liên hệ với các bên liên quan chính; một người ghi lại các sự kiện, quyết định và thời gian.

Khi mọi người đã rõ vai trò và đã tập luyện, bạn có thể phản ứng theo quy trình, thay vì hoảng loạn trong thời điểm tồi tệ nhất.

Xem xét phản ứng dây chuyền

Giả định kẻ tấn công của bạn cực kỳ tinh vi. Lỗ hổng đầu tiên có thể chỉ là mồi nhử, hoặc là hạt giống cho các cuộc tấn công tiếp theo. Tấn công có thể là để dụ bạn làm những việc hoàn toàn sai lệch, từ đó kích hoạt lỗ hổng thực sự.

Phải có quá trình tạm dừng được nghiên cứu kỹ, hoàn toàn kiểm soát được, và không thể bị lợi dụng. Tạm dừng nên là toàn bộ hệ thống bị đóng băng: bạn không muốn bị dụ dỗ tạm dừng một thành phần rồi mở ra thành phần khác. Khi đã xác định nguyên nhân gốc và vector tấn công, hãy khám phá các bề mặt lộ ra xung quanh và phản ứng dây chuyền, rồi sửa tất cả cùng lúc.

Thay thế người kế nhiệm đã được cam kết trước

Chỉ khi biết trước người kế nhiệm, việc luân chuyển mới an toàn. Tôi thích ý tưởng về danh sách người kế nhiệm đã đăng ký trước: giúp kẻ tấn công khó hơn trong việc thay thế các bảo vệ / ví quản trị còn khỏe mạnh bằng các ví đã bị tấn công. Điều này phù hợp với nguyên tắc “danh sách trắng / đen” trong các biện pháp giảm thiểu.

Đăng ký một địa chỉ người kế nhiệm cho từng vai trò quan trọng. Nguyên tắc cấp bách duy nhất có thể thực hiện việc luân chuyển là “Thay thế vai trò X bằng người kế nhiệm của nó”. Điều này cũng giúp bạn đánh giá người kế nhiệm trong thời gian bình thường: từ từ, thực hiện thẩm định, gặp mặt người đề xuất.

Trong quá trình nâng cấp, cần thử nghiệm cẩn thận

Khi đã xác định nguyên nhân gốc và phạm vi ảnh hưởng, bạn cần phát hành bản nâng cấp. Đây có thể là đoạn mã nguy hiểm nhất bạn sẽ triển khai: viết trong áp lực, nhắm vào các hacker đã chứng minh hiểu rõ giao thức của bạn và có thể tìm ra lỗ hổng.

Không vội vàng phát hành nếu chưa đủ thử nghiệm. Nếu không có thời gian kiểm toán, hãy dựa vào mối quan hệ white-hat, hoặc tổ chức cuộc thi trong 48 giờ trước khi triển khai để có một cuộc kiểm tra đối kháng mới.

Phục hồi

Hành động nhanh

Tiền bị đánh cắp có nửa đời bán rã; khi lỗ hổng đã lộ, chúng sẽ nhanh chóng vào các đường dây rửa tiền. Chuẩn bị sẵn các nhà cung cấp phân tích on-chain như Chainalysis để theo dõi các địa chỉ hacker, và khi chúng chuyển chéo chuỗi, thông báo cho các sàn giao dịch để đánh dấu và theo dõi.

Chuẩn bị danh sách các tổ chức tuân thủ, quản trị cầu nối chéo chuỗi, quản trị kho bạc, và các bên thứ ba có quyền quản lý có thể đóng băng tin nhắn chéo chuỗi hoặc các khoản gửi tạm thời.

Đàm phán

Vâng, điều này rất đau đớn, nhưng bạn vẫn nên cố gắng đàm phán với hacker. Nhiều thứ trong đời có thể giải quyết qua đàm phán. Cung cấp thưởng white-hat có thời hạn, và công khai tuyên bố nếu họ hoàn trả đầy đủ trước hạn, sẽ không bị pháp luật truy cứu.

Nếu đối mặt với các tác nhân nhà nước, khả năng đàm phán thấp, nhưng bạn vẫn có thể tham gia chương trình “bảo vệ white-hat”, ủy quyền cho white-hat hành động thay bạn để bảo vệ vốn, và nhận phần trăm nhất định của khoản thưởng (thực tế do người gửi tiền trả).

Tìm kiếm kiểm toán viên tốt

Trước đây tôi đã viết, khi các mô hình ngôn ngữ lớn trở nên thông minh hơn, giá trị gia tăng của việc thuê kiểm toán viên sẽ giảm. Tôi vẫn giữ quan điểm đó, nhưng đã có những thay đổi.

Trước hết, các kiểm toán viên tốt luôn đi trước đường cong. Nếu bạn làm những thứ mới, mã của bạn và các lỗ hổng có thể không nằm trong dữ liệu huấn luyện, việc tăng token chưa chắc đã giúp phát hiện các lỗ hổng mới. Bạn không muốn trở thành mẫu thử đầu tiên của các lỗ hổng đặc biệt.

Thứ hai, một lợi ích ít được đánh giá cao là: thuê kiểm toán viên là dùng uy tín của họ để đảm bảo. Nếu họ ký duyệt và bạn bị tấn công, họ sẽ có động lực mạnh mẽ để giúp đỡ. Thiết lập mối quan hệ với các chuyên gia an ninh là lợi thế lớn.

Thực hành an toàn vận hành

Xem an toàn vận hành như một chỉ số thành công. Tổ chức các buổi diễn tập phishing; thuê (đáng tin cậy) red team thử tấn công xã hội nhóm của bạn. Chuẩn bị ví cứng dự phòng và thiết bị để thay thế toàn bộ multi-sig khi cần. Bạn không muốn vội vàng mua sắm khi ngày G đến.

Biện pháp giảm thiểu

Lối thoát của bạn chính là giới hạn tổn thất

Mức tối đa của giá trị có thể rút ra khỏi giao thức chính là thiệt hại tối đa có thể xảy ra khi khai thác lỗ hổng. Nói cách khác: hàm tạo token không có giới hạn mỗi block chính là tấm séc trống cho mọi lỗ hổng tạo token vô hạn. Hàm rút tiền không có giới hạn tuần chính là tấm séc trống cho mọi số dư tài sản bị hỏng.

Cân nhắc cẩn thận các con số rõ ràng cho lối thoát của bạn. Con số này cần cân bằng giữa mức thiệt hại tối đa bạn chấp nhận và trải nghiệm người dùng cực đoan nhất. Nếu có vấn đề, đây chính là thứ giúp bạn tránh khỏi phá hủy hoàn toàn.

Danh sách trắng (và danh sách đen)

Hầu hết các giao thức đều có danh sách các địa chỉ có thể gọi, giao dịch hoặc nhận, và danh sách các địa chỉ không thể làm điều đó. Ngay cả khi ẩn danh, đây cũng là ranh giới niềm tin, cần được chính thức hóa.

Việc chính thức hóa giúp bạn thiết lập các bộ điều chỉnh hai bước, tạo ra ma sát có ý nghĩa. Kẻ tấn công trước tiên cần thêm vào danh sách trắng (hoặc loại bỏ khỏi danh sách đen), rồi mới có thể hành động. Đồng thời, có cả hai nghĩa là khi kẻ tấn công cố tình đưa ra các vector mới, chúng phải vượt qua hai quy trình: thị trường phải được phép (tích hợp / niêm yết), và hành động đó không bị cấm (xét duyệt an ninh).

Thu hồi

Giám sát thuật toán

Nếu không có ai giám sát, công tắc an toàn vô dụng. Các bộ giám sát off-chain cần liên tục theo dõi các bất biến, và khi phát hiện vấn đề, tự động nâng cấp cảnh báo. Con đường cuối cùng là gửi đến nhóm multi-sig và cung cấp đủ ngữ cảnh để họ ra quyết định trong vài phút.

Dừng lại và hiệu chỉnh lại

Nếu bị tấn công, bạn cần cầm máu trước, chứ không phải đưa ra quyết định trong đếm ngược. Đối với giao thức, đó chính là nút dừng (kill switch) (cũng cần thể hiện trên UI): một nút bấm có thể tạm dừng tất cả các lối đi chuyển giá trị trong một giao dịch. Chuẩn bị một script “tạm dừng tất cả”, liệt kê tất cả các thành phần có thể tạm dừng và đồng bộ tạm dừng chúng.

Chỉ có quản trị mới có thể mở khóa tạm dừng, vì vậy kill switch không thể tạm dừng hợp đồng quản trị. Nếu lớp bảo vệ có thể tạm dừng hợp đồng quản trị, thì lớp bảo vệ bị tấn công có thể vĩnh viễn khóa quá trình phục hồi.

Khởi động phòng chiến tranh của bạn

Đóng băng, cầm máu, rồi đưa tất cả những người bạn tin tưởng (nhóm nhỏ, đã thỏa thuận trước) vào một kênh liên lạc. Bạn muốn giữ quy mô nhỏ để tránh rò rỉ thông tin cho kẻ tấn công, công chúng hoặc các nhà đầu cơ lợi dụng.

Vai trò rõ ràng cho nhóm: một người ra quyết định; một người thực thi các script phòng thủ và tạm dừng; một người phân tích lỗi và nguyên nhân gốc rễ; một người liên hệ với các bên liên quan chính; một người ghi lại các sự kiện, quyết định và thời gian.

Khi mọi người đã rõ vai trò và đã tập luyện, bạn có thể phản ứng theo quy trình, thay vì hoảng loạn trong thời điểm tồi tệ nhất.

Xem xét phản ứng dây chuyền

Giả định kẻ tấn công của bạn cực kỳ tinh vi. Lỗ hổng đầu tiên có thể chỉ là mồi nhử, hoặc là hạt giống cho các cuộc tấn công tiếp theo. Tấn công có thể là để dụ bạn làm những việc hoàn toàn sai lệch, từ đó kích hoạt lỗ hổng thực sự.

Phải có quá trình tạm dừng được nghiên cứu kỹ, hoàn toàn kiểm soát được, và không thể bị lợi dụng. Tạm dừng nên là toàn bộ hệ thống bị đóng băng: bạn không muốn bị dụ dỗ tạm dừng một thành phần rồi mở ra thành phần khác. Khi đã xác định nguyên nhân gốc và vector tấn công, hãy khám phá các bề mặt lộ ra xung quanh và phản ứng dây chuyền, rồi sửa tất cả cùng lúc.

Thay thế người kế nhiệm đã được cam kết trước

Chỉ khi biết trước người kế nhiệm, việc luân chuyển mới an toàn. Tôi thích ý tưởng về danh sách người kế nhiệm đã đăng ký trước: giúp kẻ tấn công khó hơn trong việc thay thế các bảo vệ / ví quản trị còn khỏe mạnh bằng các ví đã bị tấn công. Điều này phù hợp với nguyên tắc “danh sách trắng / đen” trong các biện pháp giảm thiểu.

Đăng ký một địa chỉ người kế nhiệm cho từng vai trò quan