Xuất NFS khóa vào một địa chỉ VPN: điều nó không chứng minh
Một quy tắc xuất kiểm tra gói tin đến từ đâu; AUTH_SYS khai báo một UID cục bộ và Kerberos xác thực người dùng. Hãy quyết định dịch vụ tệp của bạn cần loại nào.
Một máy chủ xuất một thư mục tới một địa chỉ VPN, việc gắn kết thành công và thiết kế được ghi lại là đã xác thực. Điều mà quy tắc đó thực sự giới hạn là nơi các gói tin dường như xuất phát. Việc người điều hành thao tác tệp có đúng là người họ tự nhận hay không phụ thuộc vào kiểu bảo mật của NFS, và ở hầu hết các lần xuất kiểu này không ai thay đổi nó so với mặc định.
Ba danh tính có thể xuất hiện trong một yêu cầu
Peer VPN mang một danh tính đã đăng ký như chứng chỉ máy khách hoặc khóa peer. Gói IP bên trong mang một địa chỉ nguồn. Thao tác tệp mang thông tin xác thực người dùng mà cơ chế NFS của nó cung cấp. Một thiết kế coi địa chỉ là đại diện cho cả ba đã âm thầm giả định đúng phần cần được kiểm chứng.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
Việc viết ba dòng đó là toàn bộ bài tập. Phần lớn cuộc tranh luận về việc một lần xuất có an toàn hay không sụp đổ khi rõ kiểm soát nào nằm ở dòng nào.
Quyền sở hữu địa chỉ là một chi tiết triển khai
Một cổng có thể gán địa chỉ đường hầm cho một peer được chấp nhận, hoặc cấp quyền cho một mạng con được định tuyến cho nó. Việc triển khai sau đó có từ chối một gói tin mà nguồn bên trong thuộc về máy khách khác hay không là một thuộc tính của việc triển khai đó, và nên kiểm tra thay vì giả định.
Mã máy chủ không gian người dùng của Community truyền thống OpenVPN ví dụ có thể từ chối một nguồn gắn với máy khách khác trước khi gói tin được chuyển qua thiết bị TUN. Đó là một kiểm tra quyền sở hữu địa chỉ có giá trị thực, và nó vẫn không phải là xác thực người dùng NFS, vì nó không nói gì về việc tài khoản nào thực hiện thao tác.
Việc dịch nguồn bào mòn ngay cả điều đó. Một cổng NAT có thể trình bày mọi máy khách như một địa chỉ, và khi đó một quy tắc xuất không thể phân biệt những người phía sau nó. Độ chính xác bề ngoài của quy tắc sau đó trở thành một hư cấu được sơ đồ duy trì. Nếu việc xuất quan trọng, hãy giữ việc đánh địa chỉ minh bạch thay vì để một trình dịch quyết định ai được tính là ai.
Hãy đọc kiểu bảo mật trước khi tin vào lần xuất
Hướng dẫn NFS của Red Hat tách sec=sys, vốn dùng UID và GID UNIX cục bộ qua AUTH_SYS, khỏi các chế độ Kerberos. krb5 thêm xác thực người dùng, krb5i thêm bảo vệ toàn vẹn và krb5p thêm bảo vệ riêng tư cho lưu lượng.
Thông tin xác thực AUTH_SYS chứa các trường như UID của người gọi và mã nhóm, và RFC 5531 cảnh báo rõ rằng kiểu này tự nó không cung cấp bảo mật và phụ thuộc vào bảo vệ bên ngoài. Chạy nó trong VPN cung cấp bảo vệ cho việc truyền tải và không thay đổi gì trong khẳng định bên trong gói tin.
exportfs -v
showmount -e nfs.example.internalHãy đọc kiểu trong đầu ra đó trước khi đọc danh sách máy khách. Một lần xuất trông có vẻ bị hạn chế có thể chỉ bị hạn chế bởi địa chỉ trong khi mọi người gọi vẫn khai báo bất kỳ UID nào họ muốn.
Chọn mô hình, rồi giữ lại các quyền
Chọn mô hình xác thực dịch vụ tệp phù hợp với những máy khách bạn thực sự quản trị. Kerberos đòi hỏi một danh tính và việc triển khai dịch vụ phía sau, nên thay đổi một tùy chọn gắn kết không phải là di trú và sẽ chỉ thất bại cho đến khi có miền Kerberos, các principal và các tệp keytab.
Dưới cả hai mô hình, hãy giữ các quyền xuất và việc phân quyền hệ thống tệp vốn giới hạn những gì principal đã xác thực được làm. Xác thực cho bạn biết ai đang hỏi; phân quyền quyết định câu trả lời có nên là có. Gộp hai điều đó vào một thiết lập là cách một cuộc di trú cuối cùng cấp nhiều hơn cấu hình cũ.
Dùng quy tắc địa chỉ cho mục đích thực sự của nó
Việc giới hạn dịch vụ trong đường đi và các nguồn đã phê duyệt vẫn đáng làm, kể cả chính sách đầu vào của máy chủ khi điểm cuối VPN và máy chủ NFS dùng chung một máy. Các quy tắc chuyển tiếp lưu lượng không quản lý những yêu cầu hướng tới một dịch vụ chạy cục bộ trên cùng máy chủ. Khoảng trống đó giải thích một số lượng đáng ngạc nhiên các lần xuất lẽ ra phải riêng tư. Hãy kiểm tra rõ ràng chính sách đầu vào cục bộ thay vì giả định các quy tắc đường hầm bao phủ nó.
Hãy kiểm tra rằng một giao diện khác hoặc một cổng có dịch nguồn không thể bất ngờ thỏa mãn quy tắc, và coi đó là lý do để xác lập nguồn gốc chứ không phải là khẳng định rằng làm giả địa chỉ bảo đảm một lần gắn kết hoạt động.
Hãy chạy ba trường hợp chấp nhận thay vì một. Bắt đầu với một máy khách đã phê duyệt hành động như người dùng đã phê duyệt, sau đó lặp lại từ một peer chưa từng được phê duyệt, rồi thử một việc mà người dùng đã phê duyệt vẫn chưa được phép làm. Sau đó hỏi điều gì thay đổi nếu một máy khách được cấp quyền bị xâm phạm, vì xác thực vận chuyển không làm mọi tiến trình trên máy đó trở nên đáng tin. Một chứng chỉ bị đánh cắp và một tài khoản cục bộ tò mò là những vấn đề khác nhau với các kiểm soát khác nhau.