Transmission su Linux: imporre l'uscita per proprietario del processo

Bloccare la porta in entrata di Transmission non è una politica VPN. Un client torrent apre connessioni in uscita verso peer e tracker, risolve nomi e può esporre un listener di controllo remoto, e ognuno di questi flussi può uscire da un'interfaccia che non avevate previsto. Affrontate i cinque controlli in ordine e considerate il confine la regola del firewall, non le impostazioni del client. Gli ultimi due controlli sono quelli che si saltano, e sono quelli che decidono se la garanzia tiene quando il tunnel cade.

Nominare il processo proprietario del trasferimento

L'applicazione desktop e il demone di sistema girano con account diversi, e una regola basata sul proprietario segue l'account invece del nome del programma. Scoprite quale dei due è in esecuzione prima di scrivere qualsiasi regola. Un account di servizio dedicato dà alla politica un soggetto preciso, mentre un utente desktop condivide la propria identità con browser, editor e tutto il resto della sessione. Confermate l'UID invece di dare per scontato che il nome dell'account fornito dal pacchetto sia quello in uso.

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

Se l'account non esiste ancora, createlo per questo scopo e non affidategli nient'altro. Scrivete l'account e l'UID nel commento della regola, perché una regola senza soggetto è una regola che nessuno può modificare in sicurezza.

Separare i campi di ascolto dalla rotta

Transmission 4.x documenta gli indirizzi di ascolto dei peer separatamente da rpc-bind-address, e la differenza conta. L'impostazione RPC controlla soltanto il listener di controllo remoto, quindi cambiarla non sceglie una rotta per il traffico dei peer. Leggere le due impostazioni come una sola è la ragione più comune per cui una configurazione dall'aria accurata continua a perdere. La stessa documentazione descrive un ripiego quando un indirizzo di ascolto dei peer non è valido, quindi un indirizzo non disponibile è un caso di ripiego documentato, non un rifiuto garantito.

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

Usate i controlli del client per quello che sono e mettete la garanzia nel firewall. Un'impostazione di ascolto può ancora valere la pena, ma non dimostra che il contatto con i tracker, la scoperta locale o una risoluzione delegata escano tutti dal tunnel. Quando le due cose sono in disaccordo, è il firewall a decidere.

Scrivere la corrispondenza del proprietario nella catena giusta

Il manuale Netfilter sulla corrispondenza del proprietario spiega come i pacchetti generati localmente vengano attribuiti all'utente o al gruppo proprietario del file socket. Questa attribuzione non si estende al traffico inoltrato, e la corrispondenza dei gruppi supplementari richiede un'opzione esplicita. Leggete il manuale dell'estensione che state davvero usando invece del primo esempio che trovate.

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

L'ordine conta quanto la corrispondenza. Un'accettazione ampia più in alto nella catena annulla un rifiuto preciso più in basso, quindi esaminate l'intera catena invece di aggiungere una regola e sperare. Includete entrambe le famiglie di indirizzi se l'host esegue IPv6, perché una politica solo v4 lascia aperto un percorso che nessuno sorveglia. Mantenete le regole installate attraverso i riavvii sia del client sia del tunnel.

Decidere cosa succede quando tun0 sparisce

La politica di guasto è il punto dell'esercizio. Se il tunnel sparisce e lo stesso hook rimuove le regole, il client è libero di usare l'interfaccia fisica finché qualcos'altro non lo ferma. Il progetto sicuro conserva le regole e le lascia rifiutare, ed è questo che rende il confine indipendente dalla salute del tunnel. Un hook di smontaggio che cancella anche le regole è l'opposto di una politica di guasto.

ip link show tun0
iptables -S OUTPUT

Provatelo di proposito: fermate il tunnel, avviate un trasferimento che potete abbandonare senza rischi e osservate se qualcosa esce. Poi riportate il tunnel e confermate che il percorso previsto funziona di nuovo.

Coprire i percorsi che la regola non vede

La risoluzione dei nomi può essere gestita da un processo resolver separato, e un namespace o un gateway dedicato possono fornire un altro confine se i loro percorsi di condivisione e di avvio sono progettati. Decidete quale componente possiede il DNS e se segue la stessa regola di uscita. Poi guardate RPC: se è in uso rpc-whitelist, la rete di gestione approvata fa parte del contratto, e un ampio intervallo RFC1918 no.

ss -tunp | grep -i transmission

I contatori di interfaccia possono corroborare un'osservazione, ma non possono dimostrare quale processo ha prodotto i byte. Eseguite un trasferimento che vi è consentito abbandonare: prima sul percorso funzionante, poi senza tunnel all'avvio, quindi attraverso un'interruzione, una riconnessione e un'interfaccia creata da poco. Provate sia un nuovo tentativo sia una connessione già aperta, perché la regola potrebbe non essere stata applicata al socket più vecchio. Annotate la data, l'account e il risultato insieme alla prova.

Incollare un esempio che svuota l'intera catena scambia un buco con diversi, quindi aggiungete regole invece di cancellarle. Quando tutti e cinque i controlli passano, la garanzia è esplicita: il traffico del client esce dal tunnel o non esce affatto, e la regola che lo impone sopravvive al guasto del tunnel stesso.