Transmission op Linux: uitgaand verkeer afdwingen per proceseigenaar

Het inkomende poort van Transmission blokkeren is geen VPN-beleid. Een torrentclient opent uitgaande verbindingen naar peers en trackers, lost namen op en kan een listener voor externe bediening openzetten, en elk daarvan kan via een interface naar buiten gaan die u niet bedoelde. Werk de vijf controles op volgorde af en beschouw de firewallregel, niet de instellingen van de client, als de grens. De laatste twee controles zijn degene die men overslaat, en zij bepalen of de garantie standhoudt wanneer de tunnel wegvalt.

Benoem het proces dat de overdracht bezit

De desktoptoepassing en de systeemdaemon draaien onder verschillende accounts, en een regel op basis van de eigenaar volgt het account in plaats van de programmanaam. Zoek uit welke van de twee draait voordat u een regel schrijft. Een toegewijd serviceaccount geeft het beleid een precies subject, terwijl een desktopgebruiker zijn identiteit deelt met browsers, editors en al het andere in de sessie. Bevestig de UID in plaats van aan te nemen dat de accountnaam uit het pakket de gebruikte is.

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

Bestaat het account nog niet, maak het dan voor dit doel aan en geef het niets anders te draaien. Schrijf het account en de UID in het commentaar bij de regel, want een regel zonder subject is een regel die niemand veilig kan bewerken.

Scheid de listenervelden van de route

Transmission 4.x documenteert peer-luisteradressen apart van rpc-bind-address, en dat verschil is belangrijk. De RPC-instelling beheert alleen de listener voor externe bediening, dus het wijzigen ervan kiest geen route voor peer-verkeer. Deze twee instellingen als één lezen is de meest voorkomende reden waarom een zorgvuldig ogende configuratie toch lekt. Dezelfde documentatie beschrijft een terugval wanneer een peer-luisteradres ongeldig is, dus een niet-beschikbaar adres is een gedocumenteerd terugvalgeval, geen gegarandeerde weigering.

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

Gebruik de bedieningselementen van de client waarvoor ze zijn en leg de garantie in de firewall. Een listenerinstelling kan nog steeds de moeite waard zijn, maar ze bewijst niet dat trackercontact, lokale ontdekking of een gedelegeerde opzoeking allemaal via de tunnel naar buiten gaan. Als de twee het oneens zijn, beslist de firewall.

Schrijf de eigenaar-match in de juiste keten

De Netfilter-handleiding over de eigenaar-match legt uit hoe lokaal gegenereerde pakketten worden toegewezen aan de gebruiker of groep die eigenaar is van het socketbestand. Die toewijzing strekt zich niet uit tot doorgestuurd verkeer, en het matchen van aanvullende groepen vereist een expliciete optie. Lees de handleiding van de extensie die u werkelijk gebruikt in plaats van het eerste voorbeeld dat u vindt.

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

De volgorde is even belangrijk als de match. Een brede acceptatie eerder in de keten maakt een precieze weigering later ongedaan, dus herzie de hele keten in plaats van een regel toe te voegen en te hopen. Neem beide adresfamilies op als de host IPv6 draait, want een beleid dat alleen v4 dekt laat een pad open dat niemand in het oog houdt. Houd de regels geïnstalleerd bij herstarts van zowel de client als de tunnel.

Beslissen wat er gebeurt als tun0 verdwijnt

Het faalbeleid is het punt van de oefening. Als de tunnel verdwijnt en dezelfde hook verwijdert de regels, mag de client de fysieke interface gebruiken tot iets anders hem tegenhoudt. Het veilige ontwerp houdt de regels en laat ze weigeren, en dat maakt de grens onafhankelijk van de gezondheid van de tunnel. Een teardown-hook die ook de regels verwijdert, is het tegenovergestelde van een faalbeleid.

ip link show tun0
iptables -S OUTPUT

Test het bewust: stop de tunnel, start een overdracht die u veilig kunt laten vallen en kijk of er iets naar buiten gaat. Breng de tunnel daarna terug en bevestig dat het bedoelde pad weer werkt.

Dek de paden af die de regel niet ziet

Naamresolutie kan door een apart resolverproces worden afgehandeld, en een namespace of toegewijde gateway kan een andere grens bieden als de share- en bootstrap-paden daarop zijn ontworpen. Beslis welke component DNS bezit en of die dezelfde uitgaande regel volgt. Kijk dan naar RPC: als rpc-whitelist in gebruik is, maakt het goedgekeurde beheernetwerk deel uit van het contract, en een breed RFC1918-bereik niet.

ss -tunp | grep -i transmission

Interfacetellers kunnen een waarneming ondersteunen, maar ze kunnen niet bewijzen welk proces de bytes heeft geproduceerd. Voer een overdracht uit die u mag laten vallen: eerst op het werkende pad, dan zonder tunnel bij het opstarten, en vervolgens door een onderbreking, een herverbinding en een vers aangemaakte interface heen. Test zowel een nieuwe poging als een verbinding die al open stond, want de regel is mogelijk niet op de oudere socket toegepast. Noteer de datum, het account en het resultaat bij de test.

Een voorbeeld plakken dat de hele keten leegmaakt, ruilt één gat voor meerdere, dus voeg regels toe in plaats van ze te wissen. Als alle vijf controles slagen, is de garantie expliciet: het verkeer van de client gaat via de tunnel naar buiten of helemaal niet, en de regel die dat afdwingt overleeft het falen van de tunnel zelf.