Cách giới hạn truy cập giữa hai văn phòng kết nối qua VPN

Đường hầm site-to-site trả lời một câu hỏi, liệu hai văn phòng có trao đổi được gói tin hay không, và để ngỏ câu quan trọng: thiết bị chi nhánh nào được tới dịch vụ trung tâm nào. Coi đường hầm là tin cậy lẫn nhau chính là cách một laptop khách rơi vào cùng đường đi với máy chủ tài chính. Giải pháp không phải đường hầm tốt hơn, mà là một danh sách cho phép rõ ràng được áp dụng sau khi giải mã. Hướng dẫn này đưa danh sách đó từ định nghĩa đến một lần từ chối đã chứng minh.

Hãy làm theo thứ tự này và đừng mở rộng tuyến đường hầm cho đến khi các bước chính sách bên dưới đạt.

Viết ma trận trước khi chạm vào cổng

Một hàng hữu ích nêu ba thứ: nhóm nguồn, máy chủ hoặc mạng dịch vụ đích, và giao thức cùng cổng mà ứng dụng thực sự dùng. Chi nhánh và trung tâm dữ liệu không phải là mục. DNS riêng và dịch vụ xác thực chỉ có hàng riêng khi ứng dụng không thể hoạt động nếu thiếu chúng.

Nhóm nguồn theo vai trò chứ không theo sự tiện lợi của mạng con: nhân viên, khách, quản trị. Khi cả ba dùng chung một LAN phẳng, cổng không thể phân biệt họ ở tầng mạng, nên kiểm soát danh tính hoặc phân đoạn phải đến trước. Sau đó ghi ma trận bằng văn bản với người sở hữu và ngày rà soát trên mỗi hàng.

Thực thi tại nơi gói tin được giải mã

Các quy tắc cho phép IKE và ESP chỉ dựng đường hầm bên ngoài. Lưu lượng bên trong đến rõ ràng trên giao diện đường hầm, và đó chính là nơi đặt danh sách cho phép: một chuỗi chuyển tiếp trên thiết bị giải mã, bỏ mặc định, một quy tắc cho mỗi hàng của ma trận. Trên cổng Linux, điều đó nghĩa là chuyển tiếp được bật và các quy tắc lọc nằm trên thiết bị đường hầm, không phải trên liên kết vật lý, như hướng dẫn chuyển tiếp của strongSwan giải thích.

Bộ chọn lưu lượng là quyết định định tuyến, không phải quyết định cấp quyền. Một bộ chọn rộng bao trùm cả hai mạng con có thể đúng cho định tuyến trong khi tường lửa vẫn chỉ cho phép TCP 443 tới một máy chủ. Bộ chọn được thương lượng cho đường hầm và mô tả thứ gì có thể vào trong nó, không phải thứ mà một thiết bị cụ thể có thể dùng. Đừng bao giờ mở rộng quy tắc tường lửa chỉ vì bộ chọn rộng.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT và các mạng con chồng lấn thay đổi quy tắc

Khi cổng chi nhánh dịch mọi máy chủ sang một địa chỉ duy nhất trước đường hầm, mọi hàng dựa trên nguồn đều sụp vào địa chỉ duy nhất đó. Hoặc ngừng dịch lưu lượng đường hầm, hoặc chấp nhận rằng các quy tắc phải dựa vào thứ khác, chẳng hạn địa chỉ nguồn gốc được ghi lại trước khi dịch. Đầu xa cũng gặp vấn đề tương tự, vì máy chủ đích thấy địa chỉ sau NAT chứ không phải địa chỉ gốc.

Các dải chồng lấn là cái bẫy khác. Hai văn phòng cùng dùng 192.168.1.0/24 không thể mô tả trong một bảng chính sách mà không ánh xạ một phía, và ánh xạ không thay thế cho việc đánh địa chỉ không trùng nhau. Sửa kế hoạch trước khi viết những quy tắc mà sau này phải gỡ ra.

Chứng minh một lần từ chối, không chỉ thành công

Chỉ thử ứng dụng được cho phép chứng minh rất ít, vì một quy tắc dễ dãi ở đâu đó phía trên cho cùng kết quả.

Từ một thiết bị chi nhánh thông thường, hãy tới dịch vụ dự định và xác nhận toàn bộ phiên hoạt động. Sau đó thử một đích phải giữ đóng, ví dụ cổng quản trị trên một máy chủ mà chi nhánh không có việc gì, và đọc bộ đếm hoặc bản ghi nhật ký đã loại nó. Tắt bộ quy tắc để kiểm tra xem nó có hoạt động không làm mất hiệu lực bài thử và để cổng mở trong khi bạn nhìn.

Giữ danh sách sống

Ứng dụng di chuyển, và một quy tắc sống lâu hơn ứng dụng của nó trở thành lỗ hổng không ai sở hữu. Gắn ngày rà soát vào hàng, và đổi phạm vi bộ chọn cùng quy tắc tường lửa trong cùng bước bảo trì khi một dịch vụ đổi địa chỉ.

Các hạn chế ở cấp máy chủ vẫn quan trọng phía sau đường hầm: tường lửa của chính máy chủ chỉ nên chấp nhận dải chi nhánh cho dịch vụ mà nó công bố. Hai lớp khớp nhau dễ kiểm toán hơn một lớp được tin hoàn toàn.