Transmission trên Linux: bắt buộc lưu lượng ra theo chủ sở hữu tiến trình

Chặn cổng vào của Transmission không phải là chính sách VPN. Một ứng dụng torrent mở các kết nối ra tới các ngang hàng và trình theo dõi, phân giải tên và có thể mở một bộ lắng nghe điều khiển từ xa, và mỗi luồng đó đều có thể đi ra qua một giao diện mà bạn không định dùng. Hãy làm lần lượt năm bước kiểm tra và coi quy tắc tường lửa, chứ không phải cài đặt của ứng dụng, là ranh giới. Hai bước kiểm tra cuối là những bước người ta hay bỏ qua, và chúng quyết định liệu bảo đảm có còn đúng khi đường hầm sụp.

Gọi tên tiến trình sở hữu phiên truyền

Ứng dụng máy tính để bàn và dịch vụ hệ thống chạy dưới các tài khoản khác nhau, và một quy tắc dựa trên chủ sở hữu đi theo tài khoản chứ không phải tên chương trình. Hãy xác định cái nào đang chạy trước khi viết bất kỳ quy tắc nào. Một tài khoản dịch vụ chuyên dụng cho chính sách một chủ thể chính xác, trong khi người dùng máy tính để bàn chia sẻ danh tính của mình với trình duyệt, trình soạn thảo và mọi thứ khác trong phiên. Xác nhận UID thay vì giả định rằng tên tài khoản trong gói là tên đang được dùng.

systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon

Nếu tài khoản chưa tồn tại, hãy tạo nó cho mục đích này và không giao cho nó việc gì khác. Ghi tài khoản và UID vào phần chú thích của quy tắc, vì một quy tắc không có chủ thể là quy tắc không ai có thể sửa an toàn.

Tách các trường lắng nghe khỏi tuyến đường

Transmission 4.x ghi tài liệu về địa chỉ lắng nghe ngang hàng tách biệt với rpc-bind-address, và sự khác biệt này quan trọng. Cài đặt RPC chỉ điều khiển bộ lắng nghe điều khiển từ xa, nên đổi nó không chọn tuyến cho lưu lượng ngang hàng. Đọc hai cài đặt như một là lý do phổ biến nhất khiến một cấu hình trông cẩn thận vẫn rò rỉ. Cùng tài liệu đó mô tả một phương án dự phòng khi địa chỉ lắng nghe ngang hàng không hợp lệ, nên một địa chỉ không khả dụng là trường hợp dự phòng đã được ghi nhận, không phải sự từ chối được bảo đảm.

grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

Dùng các điều khiển của ứng dụng đúng với bản chất của chúng, và đặt bảo đảm vào tường lửa. Một cài đặt lắng nghe vẫn có thể đáng dùng, nhưng nó không chứng minh rằng liên lạc với trình theo dõi, khám phá cục bộ hay một tra cứu được ủy thác đều đi ra qua đường hầm. Khi hai bên mâu thuẫn, tường lửa là bên quyết định.

Viết phép khớp chủ sở hữu vào đúng chuỗi

Sổ tay Netfilter về phép khớp chủ sở hữu giải thích cách các gói được tạo cục bộ được quy cho người dùng hoặc nhóm sở hữu tệp socket. Sự quy kết đó không mở rộng sang lưu lượng được chuyển tiếp, và việc khớp nhóm bổ sung cần một tùy chọn rõ ràng. Hãy đọc sổ tay của tiện ích mở rộng bạn thực sự dùng thay vì ví dụ đầu tiên bạn tìm thấy.

iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECT

Thứ tự quan trọng ngang với phép khớp. Một chấp nhận rộng ở đầu chuỗi vô hiệu hóa một từ chối chính xác ở cuối, nên hãy xem lại toàn bộ chuỗi thay vì thêm một quy tắc và hy vọng. Bao gồm cả hai họ địa chỉ nếu máy chủ chạy IPv6, vì chính sách chỉ v4 để mở một đường mà không ai theo dõi. Giữ các quy tắc được cài qua các lần khởi động lại của cả ứng dụng và đường hầm.

Quyết định điều gì xảy ra khi tun0 biến mất

Chính sách khi hỏng chính là điểm cốt lõi. Nếu đường hầm biến mất và cùng một hook xóa các quy tắc, ứng dụng được tự do dùng giao diện vật lý cho tới khi có thứ khác chặn nó. Thiết kế an toàn giữ lại các quy tắc và để chúng từ chối, và chính điều đó làm ranh giới độc lập với sức khỏe của đường hầm. Một hook tháo gỡ cũng xóa các quy tắc là điều ngược lại của chính sách khi hỏng.

ip link show tun0
iptables -S OUTPUT

Hãy thử có chủ đích: dừng đường hầm, khởi động một phiên truyền an toàn để bỏ dở và xem có gì đi ra không. Rồi khôi phục đường hầm và xác nhận tuyến đã định hoạt động trở lại.

Phủ các đường mà quy tắc không thấy

Việc phân giải tên có thể do một tiến trình phân giải riêng đảm nhận, và một namespace hoặc cổng riêng có thể tạo ranh giới khác nếu các đường chia sẻ và khởi động của nó được thiết kế cho việc đó. Hãy quyết định thành phần nào sở hữu DNS và liệu nó có theo cùng quy tắc ra không. Sau đó xem RPC: nếu rpc-whitelist đang được dùng, mạng quản trị đã được phê duyệt là một phần của hợp đồng, còn một dải RFC1918 rộng thì không.

ss -tunp | grep -i transmission

Bộ đếm giao diện có thể củng cố một quan sát, nhưng không thể chứng minh tiến trình nào đã tạo ra các byte. Hãy chạy một phiên truyền mà bạn được phép bỏ dở: trước tiên trên tuyến đang hoạt động, rồi không có đường hầm khi khởi động, rồi qua một lần ngắt, một lần kết nối lại và một giao diện mới tạo. Thử cả một lần mới lẫn một kết nối đã mở sẵn, vì quy tắc có thể chưa được áp cho socket cũ. Ghi lại ngày, tài khoản và kết quả cùng với lần thử.

Dán một ví dụ xóa sạch cả chuỗi là đổi một lỗ hổng lấy nhiều lỗ hổng, nên hãy thêm quy tắc thay vì xóa chúng. Khi cả năm bước kiểm tra đều qua, bảo đảm là rõ ràng: lưu lượng của ứng dụng đi ra qua đường hầm hoặc không đi chút nào, và quy tắc thực thi điều đó sống sót qua chính sự cố của đường hầm.