Linux дээрх Transmission: гарах урсгалыг процессын эзэмшигчээр хязгаарлах

Transmission-ийн орох портыг хаах нь VPN бодлого биш. Торрент клиент пирүүд болон трекерүүд рүү гарах холболт нээж, нэрийг шийдвэрлэж, алсын удирдлагын сонсогчийг барьж болох бөгөөд эдгээр урсгал бүр таны төлөвлөөгүй интерфейсээр гарч болно. Таван шалгалтыг дараалан хийж, хязгаар гэж клиентийн тохиргоог бус firewall дүрмийг үзээрэй. Сүүлийн хоёр шалгалтыг ихэвчлэн алгасдаг бөгөөд туннель унах үед баталгаа хадгалагдах эсэхийг яг тэдгээр шийддэг.

Дамжуулалтыг эзэмшдэг процессыг нэрлээрэй

Ширээний програмын болон системийн демон өөр өөр бүртгэлээр ажилладаг бөгөөд эзэмшигчээр тодорхойлогдох дүрэм програмын нэр биш бүртгэлийг дагадаг. Дүрэм бичихээс өмнө аль нь ажиллаж байгааг тодруулаарай. Тусдаа үйлчилгээний бүртгэл бодлогод нарийн субъект өгдөг бол ширээний хэрэглэгч өөрийн таних тэмдгийг хөтөч, редактор болон сессийн бусад бүх зүйлтэй хуваалцдаг. UID-г баталгаажуулж, багц дахь бүртгэлийн нэр нь ашиглагдаж байгаа нэр гэж бүү таамаглаарай.

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

Бүртгэл хараахан байхгүй бол энэ зорилгоор үүсгэж, түүнд өөр юу ч ажиллуулахгүй байгаарай. Бүртгэл болон UID-г дүрмийн тайлбарт бичээрэй, учир нь субъектгүй дүрэм бол хэн ч аюулгүй засаж чадахгүй дүрэм юм.

Сонсох талбаруудыг замаасаа тусгаарлаарай

Transmission 4.x нь пиерийн сонсох хаягуудыг rpc-bind-address тохиргооноос тусдаа баримтжуулдаг бөгөөд энэ ялгаа чухал. RPC тохиргоо нь зөвхөн алсын удирдлагын сонсогчийг удирддаг тул түүнийг өөрчлөх нь пиерийн урсгалд зам сонгохгүй. Хоёр тохиргоог нэг гэж унших нь гаднаасаа болгоомжтой харагдах тохиргоо хэрхэн алдагдсаар байгаагийн хамгийн түгээмэл шалтгаан юм. Мөн баримт бичигт пиерийн сонсох хаяг хүчингүй үед нөөц зам тайлбарладаг, өөрөөр хэлбэл хүртээмжгүй хаяг бол баримтжуулсан нөөц тохиолдол, баталгаатай татгалзал биш.

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

Клиентийн удирдлагуудыг зориулалтын дагуу ашиглаж, баталгааг firewall-д хийгээрэй. Сонсох тохиргоо хэрэгтэй хэвээр байж болох ч трекертэй холбоо, локал илрүүлэлт эсвэл шилжүүлсэн хайлт бүгд туннелээр гардаг гэдгийг нотлохгүй. Хоёулаа зөрчилдвөл firewall шийднэ.

Эзэмшигчийн тохирлыг зөв гинжид бичээрэй

Netfilter-ийн эзэмшигчийн тохирлын гарын авлага нь локалаар үүсгэсэн пакетуудыг сокет файлыг эзэмшдэг хэрэглэгч эсвэл бүлэгт хэрхэн хамааруулдгийг тайлбарладаг. Энэ хамааруулалт дамжуулсан урсгалд үйлчлэхгүй бөгөөд нэмэлт бүлгүүдийн тохирол тодорхой сонголт шаарддаг. Бодитоор ашиглаж байгаа өргөтгөлийн гарын авлагыг уншаарай, олдсон эхний жишээг биш.

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

Дараалал нь тохирол шиг л чухал. Гинжийн дээд хэсэгт өргөн зөвшөөрөл доод хэсгийн нарийн татгалзлыг хүчингүй болгодог тул дүрэм нэмээд найдахын оронд бүх гинжийг хянаарай. Хост IPv6 ажиллуулж байвал хоёр хаягийн гэр бүлийг хоёуланг нь оруулаарай, учир нь зөвхөн v4 бодлого хэн ч хянадаггүй замыг нээлттэй үлдээдэг. Дүрмүүдийг клиент болон туннелийн дахин эхлэлтийн турш суулгасан байлгаарай.

tun0 алга болоход юу болохыг шийдээрэй

Гэмтлийн бодлого бол дасгалын гол нь. Туннель алга болж, мөн тэр дэгээ дүрмүүдийг хасвал клиент өөр зүйл зогсоох хүртэл физик интерфейсийг ашиглах эрхтэй. Аюулгүй загвар дүрмүүдийг хадгалж, тэднийг татгалзахыг зөвшөөрдөг бөгөөд хязгаарыг туннелийн эрүүл мэндээс хараат бус болгодог нь энэ юм. Дүрмүүдийг мөн устгадаг буулгах дэгээ нь гэмтлийн бодлогын яг эсрэг зүйл.

ip link show tun0
iptables -S OUTPUT

Үүнийг санаатайгаар туршаарай: туннелийг зогсоож, орхиход аюулгүй дамжуулалт эхлүүлж, ямар нэг зүйл гарч байгаа эсэхийг ажиглаарай. Дараа нь туннелийг буцааж, зорьсон зам дахин ажиллаж байгааг баталгаажуулаарай.

Дүрэм харж чадахгүй замуудыг хамааруулаарай

Нэрийн шийдвэрлэлтийг тусдаа шийдвэрлэгч процесс гүйцэтгэж болох бөгөөд нэрийн орон зай эсвэл тусгай гарц нь хуваалцах болон ачаалах замууд нь үүнд зориулагдсан бол өөр хязгаар өгч чадна. DNS-ийг аль бүрэлдэхүүн эзэмшиж, ижил гарах дүрмийг дагаж байгаа эсэхийг шийдээрэй. Дараа нь RPC-г хараарай: хэрэв rpc-whitelist ашиглагдаж байвал зөвшөөрөгдсөн удирдлагын сүлжээ нь гэрээний хэсэг, харин өргөн RFC1918 хүрээ тийм биш.

ss -tunp | grep -i transmission

Интерфейсийн тоолуурууд ажиглалтыг баталж болох ч байтуудыг аль процесс үүсгэснийг нотолж чадахгүй. Орхих зөвшөөрөлтэй дамжуулалт хийгээрэй: эхлээд ажиллаж байгаа замаар, дараа нь эхлэх үед туннельгүйгээр, улмаар тасалдал, дахин холболт болон шинээр үүсгэсэн интерфейсээр. Шинэ оролдлого болон өмнө нь нээлттэй байсан холболтыг хоёуланг нь туршаарай, учир нь дүрэм хуучин сокетод хэрэглэгдээгүй байж болно. Огноо, бүртгэл болон үр дүнг туршилттай хамт бичээрэй.

Бүх гинжийг цэвэрлэдэг жишээг буулгах нь нэг нүхийг хэд хэдэн нүхээр солих тул дүрмүүдийг устгахын оронд нэмээрэй. Таван шалгалт бүгд тэнцвэл баталгаа тодорхой: клиентийн урсгал туннелээр гарна эсвэл огт гарахгүй, мөн үүнийг хэрэгжүүлдэг дүрэм туннелийн өөрийн гэмтлийг ч давна.