Bảo mật & quyền riêng tư

Bảo vệ các instance Ollama tự host trước truy cập không xác thực

Ollama thiếu cơ chế API key gốc, khiến các máy chủ bị lộ dễ bị rò rỉ dữ liệu. Tìm hiểu năm phương pháp để bảo mật hạ tầng LLM cục bộ cho mục đích sử dụng nhóm.

Illustration of a secure server rack with digital locks
Ảnh minh họa tạo riêng cho bài viết

Bài được dịch tự động từ bản gốc tiếng Anh.

Các máy chủ mô hình ngôn ngữ lớn (LLM) tự host ngày càng phổ biến trong môi trường phát triển, nhưng cấu hình mặc định thường thiếu các biện pháp kiểm soát bảo mật cơ bản. Một phân tích gần đây chỉ ra rằng Ollama, một công cụ phổ biến để chạy mô hình cục bộ, không có cơ chế xác thực tích hợp sẵn, khiến hàng nghìn instance bị lộ trên internet công khai. Các đội ngũ chia sẻ tài nguyên GPU phải triển khai các lớp bảo vệ bên ngoài để ngăn chặn truy cập trái phép và rò rỉ dữ liệu.

Chuyện gì đã xảy ra

Theo mặc định, Ollama lắng nghe trên localhost, điều này an toàn cho laptop dùng một người. Vấn đề nảy sinh khi quản trị viên thay đổi thiết lập host thành 0.0.0.0 để cho phép đồng nghiệp truy cập vào một máy chủ GPU trung tâm. Cấu hình này mở mọi endpoint API cho bất kỳ ai có thể tiếp cận địa chỉ mạng, bao gồm các chức năng pull, delete, create và push mô hình. Không có xác thực, bất kỳ người dùng nào kết nối đều có toàn quyền kiểm soát tài nguyên máy chủ và dữ liệu được lưu trữ.

Các nhà nghiên cứu bảo mật đã ghi nhận quy mô của sự lộ diện này. Vào tháng Giêng, các cuộc quét bởi SentinelOne và Censys đã xác định khoảng 175.000 máy chủ Ollama mở trên internet tại 130 quốc gia. Gần một nửa số instance này lưu trữ các mô hình có khả năng gọi công cụ (tool-calling), làm tăng nguy cơ bị lạm dụng tự động. Tình hình trở nên tồi tệ hơn vào tháng Năm khi Cyera tiết lộ CVE-2026-7482, còn được biết đến với tên Bleeding Llama. Lỗ hổng này cho phép kẻ tấn công rò rỉ bộ nhớ máy chủ, bao gồm biến môi trường và API key, thông qua hai yêu cầu không cần xác thực.

Mặc dù bản vá đã được phát hành trong phiên bản 0.17.1 vào tháng Hai, nhiều máy chủ vẫn chưa được vá vì ghi chú phát hành không đánh dấu rõ ràng đây là bản cập nhật bảo mật. Tính đến phiên bản 0.40.3 vào tháng Mười năm 2026, Ollama vẫn chưa bao gồm hệ thống API key phía máy chủ. Các maintainer đã tuyên bố họ không có kế hoạch thêm xác thực gốc, thay vào đó khuyến nghị người dùng dựa vào mạng riêng ảo (VPN) hoặc reverse proxy để bảo vệ.

Chi tiết chính

  • Ollama không có xác thực API key gốc, phụ thuộc vào cách ly mạng để đảm bảo an toàn.
  • Khoảng 175.000 máy chủ được tìm thấy bị lộ trên internet vào đầu năm 2026.
  • CVE-2026-7482 cho phép rò rỉ bộ nhớ thông qua các yêu cầu tạo và push mô hình không cần xác thực.
  • Lỗ hổng đã được vá trong phiên bản 0.17.1, nhưng việc áp dụng bản vá vẫn không đồng nhất.
  • Thiết lập OLLAMA_HOST=0.0.0.0 sẽ lộ tất cả các endpoint API, bao gồm cả các thao tác phá hủy.
  • Quy tắc công bố cổng (port publishing) của Docker có thể bỏ qua các cấu hình tường lửa cục bộ như ufw.

Bối cảnh

Để hiểu rõ rủi ro, cần biết cách Ollama xử lý kết nối mạng. Theo mặc định, nó bind vào 127.0.0.1, nghĩa là chỉ các process trên cùng máy mới có thể giao tiếp với nó. Khi thay đổi thành 0.0.0.0, nó chấp nhận kết nối từ bất kỳ interface mạng nào. Trong môi trường container hóa, Docker quản lý các quy tắc iptables riêng, có thể ghi đè lên cài đặt tường lửa cấp host. Điều này có nghĩa là một quy tắc chặn traffic trên cổng 11434 có thể không ngăn được truy cập nếu container công bố cổng đó ra toàn cục.

Lỗ hổng Bleeding Llama khai thác các endpoint API cụ thể quản lý file mô hình. Bằng cách gửi một file GGUF được chỉnh sửa kỹ lưỡng tới endpoint create và sau đó push nó tới registry bên ngoài, kẻ tấn công có thể kích hoạt các đọc bộ nhớ làm lộ dữ liệu nhạy cảm. Loại tấn công này khả thi vì máy chủ tin tưởng mọi yêu cầu đến mà không xác minh danh tính hay ý định của người gửi. Bảo mật các endpoint này là yếu tố then chốt cho bất kỳ thiết lập đa người dùng nào.

Tại sao điều này quan trọng

Đối với các đội ngũ vận hành phần mềm riêng, việc thiếu xác thực gốc tạo ra những rủi ro vận hành đáng kể. Không có kiểm soát truy cập cấp người dùng, quản trị viên không thể theo dõi ai đang sử dụng tài nguyên GPU hoặc giới hạn mức tiêu thụ. Một script chạy mất kiểm soát hoặc một tác nhân độc hại duy nhất có thể chiếm dụng phần cứng, làm gián đoạn công việc của tất cả những người khác. Hơn nữa, việc không thể thu hồi quyền truy cập cho từng người dùng có nghĩa là xâm phạm một credential hoặc thiết bị có thể dẫn đến xâm phạm toàn bộ máy chủ.

Quyền riêng tư dữ liệu là một mối lo ngại lớn khác. Các máy chủ bị lộ có thể làm rò rỉ mã độc quyền, prompt nội bộ và API key được lưu trong biến môi trường. Đối với các công ty xử lý dữ liệu khách hàng nhạy cảm hoặc sở hữu trí tuệ, sự lộ diện này vi phạm các nguyên tắc bảo mật cơ bản. Triển khai các biện pháp kiểm soát truy cập phù hợp đảm bảo rằng chỉ nhân sự được ủy quyền mới có thể tương tác với các mô hình và hành động của họ có thể được kiểm toán.

Bạn có thể làm gì

  • Xác minh máy chủ của bạn không bị lộ bằng cách chạy lệnh curl từ một mạng bên ngoài để kiểm tra danh sách mô hình.
  • Cập nhật Ollama lên phiên bản 0.17.1 hoặc mới hơn để vá các lỗ hổng rò rỉ bộ nhớ đã biết.
  • Sử dụng SSH tunnel hoặc Tailscale cho các đội nhỏ để giữ Ollama bind vào localhost trong khi vẫn cho phép truy cập từ xa.
  • Triển khai một reverse proxy như Caddy hoặc Nginx để thực thi xác thực dựa trên token và chặn các endpoint quản trị.
  • Cân nhắc sử dụng Open WebUI làm front-end để quản lý tài khoản người dùng và tạo API key cho từng người dùng.
  • Đánh giá các giải pháp proxy chuyên dụng như LoLLMs Hub hoặc LiteLLM để giới hạn tốc độ nâng cao và theo dõi mức sử dụng.

"Trong ngắn hạn, chúng tôi không có kế hoạch thêm hệ thống API key vào chính máy chủ Ollama."

Phần kết:

Tin khác

Bảo mật & quyền riêng tư

Mã khai thác công khai nhắm vào lỗ hổng root trước xác thực trên AnyDesk Linux

Các nhà nghiên cứu đã công bố một mã khai thác hoạt động được cho lỗ hổng tràn bộ đệm heap nghiêm trọng trên AnyDesk Linux, cho phép truy cập root mà không cần sự phê duyệt của người dùng. Nhà cung cấp đã vá lỗi này vào tháng 6 nhưng chỉ cung cấp thông tin bảo

Tất cả tin