Transmission Linuxon: kimenő forgalom kényszerítése a folyamat tulajdonosa szerint

A Transmission bejövő portjának blokkolása nem VPN-szabály. A torrent kliens kimenő kapcsolatokat nyit a peer-ek és a trackerek felé, neveket old fel, és távoli vezérléshez figyelőt tarthat, és ezek mindegyike olyan interfészen léphet ki, amelyet nem szándékozott. Vegye sorra az öt ellenőrzést, és tekintse határnak a tűzfalszabályt, nem a kliens beállításait. Az utolsó két ellenőrzést szokták kihagyni, és ezek döntik el, hogy a garancia akkor is áll-e, amikor az alagút leesik.

Nevezze meg az átvitelt birtokló folyamatot

Az asztali alkalmazás és a rendszerdémon különböző fiókok alatt fut, a tulajdonos alapú szabály pedig a fiókot követi, nem a program nevét. Szabály írása előtt derítse ki, melyik fut. A külön szolgáltatásfiók pontos alanyt ad a szabálynak, míg az asztali felhasználó megosztja identitását a böngészőkkel, szerkesztőkkel és a munkamenet minden mással. Erősítse meg az UID-et, ne feltételezze, hogy a csomag fiókneve az használt.

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

Ha a fiók még nem létezik, hozza létre erre a célra, és ne adjon neki semmi mást futtatni. Írja a fiókot és az UID-et a szabály megjegyzésébe, mert az alany nélküli szabály olyan szabály, amelyet senki sem tud biztonságosan szerkeszteni.

Válassza külön a figyelő mezőket az útvonaltól

A Transmission 4.x a peer-figyelő címeket a rpc-bind-address beállítástól elkülönítve dokumentálja, és ez a különbség számít. Az RPC-beállítás csak a távoli vezérlés figyelőjét szabályozza, így módosítása nem választ útvonalat a peer-forgalomnak. A két beállítás egyként olvasása a leggyakoribb oka annak, hogy egy gondosnak látszó konfiguráció mégis szivárog. Ugyanez a dokumentáció leír egy tartalék esetet, amikor a peer-figyelő cím érvénytelen, azaz az elérhetetlen cím dokumentált tartalék eset, nem garantált elutasítás.

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

Használja a kliens vezérlőit arra, amikre valók, és tegye a garanciát a tűzfalba. A figyelő beállítás még hasznos lehet, de nem bizonyítja, hogy a trackerekkel való kapcsolat, a helyi felfedezés vagy egy delegált keresés mind az alagúton keresztül lép ki. Amikor a kettő ellentmond, a tűzfal dönt.

Írja a tulajdonos-egyezést a megfelelő láncba

A Netfilter tulajdonos-egyezésről szóló kézikönyve elmagyarázza, hogyan rendelődnek a helyben létrehozott csomagok a socket-fájl tulajdonos felhasználójához vagy csoportjához. Ez a hozzárendelés nem terjed ki a továbbított forgalomra, a kiegészítő csoportok egyeztetése pedig kifejezett kapcsolót igényel. Azt a kiterjesztést olvassa, amelyet valóban használ, ne az első talált példát.

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

A sorrend ugyanolyan fontos, mint az egyeztetés. A lánc elején lévő széles engedély hatástalanítja a későbbi pontos tiltást, ezért nézze át a teljes láncot, ne csak adjon hozzá egy szabályt és reménykedjen. Ha a gazdagép IPv6-ot futtat, vegye be mindkét címcsaládot, mert a csak v4 politikája nyitva hagy egy utat, amelyet senki sem figyel. Tartsa a szabályokat telepítve a kliens és az alagút újraindításai alatt is.

Döntse el, mi történik, amikor a tun0 eltűnik

A hibaüzemi politika a gyakorlat lényege. Ha az alagút eltűnik, és ugyanaz a hook eltávolítja a szabályokat, a kliens szabadon használhatja a fizikai interfészt, amíg valami más meg nem állítja. A biztonságos tervezés megtartja a szabályokat és hagyja, hogy elutasítsanak, és ez teszi a határt az alagút egészségétől függetlenné. Az a leszerelő hook, amely a szabályokat is törli, a hibaüzemi politika pontos ellentéte.

ip link show tun0
iptables -S OUTPUT

Tesztelje szándékosan: állítsa le az alagutat, indítson egy átvitelt, amelyet biztonságos elhagyni, és figyelje, hogy kimegy-e valami. Utána hozza vissza az alagutat, és erősítse meg, hogy a szándékolt útvonal ismét működik.

Fedje le azokat az útvonalakat, amelyeket a szabály nem lát

A névfeloldást külön feloldó folyamat végezheti, egy névtér vagy dedikált átjáró pedig további határt adhat, ha a megosztási és indítási útvonalai erre készültek. Döntse el, melyik komponens birtokolja a DNS-t, és követi-e ugyanazt a kimenő szabályt. Utána nézze meg az RPC-t: ha a rpc-whitelist használatban van, a jóváhagyott felügyeleti hálózat része a szerződésnek, a széles RFC1918-tartomány viszont nem.

ss -tunp | grep -i transmission

Az interfész-számlálók alátámaszthatnak egy megfigyelést, de nem bizonyíthatják, melyik folyamat termelte a bájtokat. Végezzen egy átvitelt, amelyet szabad elhagyni: először a működő útvonalon, majd induláskor alagút nélkül, aztán megszakításon, újracsatlakozáson és frissen létrehozott interfészen keresztül. Tesztelje az új próbálkozást és a már nyitva lévő kapcsolatot is, mert a szabály esetleg nem érvényesült a régebbi socketre. Jegyezze fel a dátumot, a fiókot és az eredményt a teszttel együtt.

A teljes láncot kiürítő példa beillesztése egy lyukat több lyukra cserél, ezért adjon hozzá szabályokat ahelyett, hogy törölné őket. Ha mind az öt ellenőrzés átmegy, a garancia egyértelmű: az ügyfél forgalma az alagúton keresztül távozik vagy egyáltalán nem, és az ezt kikényszerítő szabály túlél az alagút saját hibáján.