Linux-da Transmission: çıxışı proses sahibinə görə məcburi et
Cüt port bütün hekayə deyil. Firewall qaydasını müştəri hesabı ilə məhdudlaşdırın, hər iki ünvan ailəsini əhatə edin və tunel bağlıykən sınaqdan keçirin.
Transmission-un giriş portunu bloklamaq VPN siyasəti deyil. Torrent müştərisi həmyaşıdlara və izləyicilərə çıxan bağlantılar açır, adları həll edir və uzaqdan idarəetmə üçün dinləyici aça bilər və bunların hər biri nəzərdə tutmadığınız interfeysdən çıxa bilər. Beş yoxlamanı sıra ilə keçin və sərhəd kimi müştərinin ayarlarını deyil, firewall qaydasını götürün. Son iki yoxlama insanların atladığı yoxlamalardır və tunel düşəndə zəmanətin qalıb-qalmayacağına onlar qərar verir.
Köçürmənin sahibi olan prosesi adlandırın
Masaüstü tətbiqi və sistem demonu müxtəlif hesablar altında işləyir və sahibə əsaslanan qayda proqram adını deyil, hesabı izləyir. Hər hansı qayda yazmazdan əvvəl hansının işlədiyini öyrənin. Xüsusi xidmət hesabı siyasətə dəqiq subyekt verir, masaüstü istifadəçisi isə kimliyini brauzerlər, redaktorlar və sessiyadakı hər şeylə bölüşür. Paketdəki hesab adının istifadə olunan olduğunu fərz etmək əvəzinə UID-ni təsdiqləyin.
systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon
Hesab hələ yoxdursa, onu bu məqsəd üçün yaradın və ona işlədəcək başqa bir şey verməyin. Hesabı və UID-ni qaydanın şərhinə yazın, çünki subyekti olmayan qayda heç kimin təhlükəsiz redaktə edə bilmədiyi qaydadır.
Dinləyici sahələrini marşrutdan ayırın
Transmission 4.x həmyaşıd dinləmə ünvanlarını rpc-bind-address ayarından ayrı sənədləşdirir və bu fərq vacibdir. RPC ayarı yalnız uzaqdan idarəetmə dinləyicisini idarə edir, ona görə də onu dəyişmək həmyaşıd trafiki üçün marşrut seçmir. İki ayarı bir kimi oxumaq, diqqətli görünən konfiqurasiyanın hələ də sızmasının ən çox yayılmış səbəbidir. Eyni sənəd həmyaşıd dinləmə ünvanı etibarsız olduqda geri dönüş yolunu təsvir edir, yəni əlçatmaz ünvan sənədləşdirilmiş geri dönüş halıdır, zəmanətli imtina deyil.
grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json
Müştərinin idarəetmə vasitələrini olduqları kimi istifadə edin və zəmanəti firewall-a qoyun. Dinləyici ayarı hələ də faydalı ola bilər, lakin izləyicilərlə əlaqənin, yerli aşkarlamanın və ya həvalə edilmiş sorğunun hamısının tuneldən çıxdığını sübut etmir. İkisi ziddiyyət təşkil edəndə qərarı firewall verir.
Sahib uyğunluğunu düzgün zəncirə yazın
Netfilter-ın sahib uyğunluğu təlimatı yerli yaradılan paketlərin socket faylının sahibi olan istifadəçiyə və ya qrupa necə aid edildiyini izah edir. Bu aidiyyət ötürülən trafikə şamil olunmur və əlavə qrupların uyğunlaşdırılması açıq seçim tələb edir. Tapdığınız ilk nümunə yerinə həqiqətən istifadə etdiyiniz uzantının təlimatını oxuyun.
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
Sıra uyğunluq qədər vacibdir. Zəncirin əvvəlində geniş qəbul sonrakı dəqiq imtinanı ləğv edir, buna görə də qayda əlavə edib ümid etmək yerinə bütün zənciri nəzərdən keçirin. Ana maşın IPv6 işlədirsə hər iki ünvan ailəsini daxil edin, çünki yalnız v4 siyasəti heç kimin izləmədiyi bir yolu açıq qoyur. Qaydaları həm müştərinin, həm də tunelin yenidən başladılmaları boyunca quraşdırılmış saxlayın.
tun0 yox olduqda nə olacağına qərar verin
Nasazlıq siyasəti məşqin özəyidir. Tunel yox olur və eyni qarmaq qaydaları götürürsə, müştəri başqa bir şey onu dayandırana qədər fiziki interfeysdən istifadə etməkdə sərbəstdir. Təhlükəsiz dizayn qaydaları saxlayır və onların imtina etməsinə imkan verir, sərhədi tunelin sağlamlığından asılı olmayan edən də budur. Qaydaları da silən sökmə qarmağı nasazlıq siyasətinin tam əksidir.
ip link show tun0
iptables -S OUTPUT
Bunu qəsdən sınayın: tuneli dayandırın, buraxılması təhlükəsiz olan köçürmə başladın və nəyinsə çıxıb-çıxmadığını izləyin. Sonra tuneli geri qaytarın və nəzərdə tutulan yolun yenidən işlədiyini təsdiqləyin.
Qaydanın görə bilmədiyi yolları əhatə edin
Ad həlli ayrı həlledici proses tərəfindən idarə oluna bilər və ad məkanı və ya ayrılmış şlüz, paylaşma və yükləmə yolları bunun üçün layihələndirilibsə, başqa sərhəd təmin edə bilər. DNS-in hansı komponentə aid olduğuna və eyni çıxış qaydasına tabe olub-olmadığına qərar verin. Sonra RPC-yə baxın: rpc-whitelist istifadə olunursa, təsdiqlənmiş idarəetmə şəbəkəsi müqavilənin bir hissəsidir, geniş RFC1918 diapazonu isə deyil.
ss -tunp | grep -i transmission
İnterfeys sayğacları müşahidəni təsdiqləyə bilər, lakin baytları hansı prosesin yaratdığını sübut edə bilməz. Buraxmağınıza icazə verilən köçürmə edin: əvvəlcə işləyən yolda, sonra başlanğıcda tunelsiz, daha sonra fasilə, yenidən qoşulma və yeni yaradılmış interfeys vasitəsilə. Həm yeni cəhdi, həm də artıq açıq olan bağlantını sınayın, çünki qayda köhnə socket-ə tətbiq olunmamış ola bilər. Tarixi, hesabı və nəticəni sınaqla birlikdə qeyd edin.
Bütün zənciri təmizləyən nümunəni yapışdırmaq bir deşiyi bir neçə deşiklə dəyişir, buna görə də qaydaları silmək yerinə əlavə edin. Beş yoxlamanın hamısı keçəndə zəmanət aydındır: müştərinin trafiki tuneldən çıxır və ya heç çıxmır və bunu məcbur edən qayda tunelin öz nasazlığını da yaşayır.