Esiste un modo per i processi non root di collegarsi a porte "privilegiate" su Linux?

StackOverflow https://stackoverflow.com/questions/413807

Domanda

È molto fastidioso avere questa limitazione nella mia casella di sviluppo, quando non ci saranno mai utenti diversi da me.

Sono a conoscenza di soluzioni alternative standard , ma nessuna di esse fa esattamente ciò che Voglio:

  1. authbind (La versione in Debian testing, 1.0, supporta solo IPv4)
  2. Uso del target REDIRECT di iptables per reindirizzare una porta bassa su una porta alta (la tabella " nat " non è ancora implementata per ip6tables, la versione IPv6 di iptables)
  3. sudo (Correre come root è ciò che sto cercando di evitare)
  4. SELinux (o simile). (Questa è solo la mia casella di sviluppo, non voglio introdurre molta complessità extra.)

Esiste una semplice variabile sysctl per consentire ai processi non root di legarsi a " privilegiato " porte (porte inferiori a 1024) su Linux o sono sfortunato?

EDIT: in alcuni casi, puoi usa le funzionalità per farlo.

È stato utile?

Soluzione

Va ??bene, grazie alle persone che hanno sottolineato il sistema di funzionalità e la capacità CAP_NET_BIND_SERVICE . Se hai un kernel recente, è davvero possibile usarlo per avviare un servizio come non root ma associare le porte basse. La risposta breve è che lo fai: 

setcap 'cap_net_bind_service=+ep' /path/to/program

E quindi in qualsiasi momento il programma verrà eseguito successivamente avrà la capacità CAP_NET_BIND_SERVICE . setcap si trova nel pacchetto debian libcap2-bin .

Ora per le avvertenze:

  1. Sarà necessario almeno un kernel 2.6.24
  2. Questo non funzionerà se il tuo file è uno script. (cioè usa una linea #! per lanciare un interprete). In questo caso, per quanto ho capito, dovresti applicare la capacità all'eseguibile interprete stesso, che ovviamente è un incubo di sicurezza, poiché qualsiasi programma che utilizza quell'interprete avrà la capacità. Non sono riuscito a trovare un modo semplice e pulito per aggirare questo problema.
  3. Linux disabiliterà LD_LIBRARY_PATH su qualsiasi programma con privilegi elevati come setcap o suid . Quindi se il tuo programma usa il suo ... / lib / , potresti dover cercare un'altra opzione come il port forwarding.

Risorse:

Nota: RHEL lo ha aggiunto per la prima volta in v6 .

Altri suggerimenti

Il modo standard è di renderli " setuid " in modo che si avviino come root e quindi buttino via quel privilegio di root non appena si sono collegati alla porta ma prima che inizino ad accettare connessioni ad essa. Puoi vedere buoni esempi di ciò nel codice sorgente di Apache e INN. Mi è stato detto che Lighttpd è un altro buon esempio.

Un altro esempio è Postfix, che utilizza più demoni che comunicano tramite pipe, e solo uno o due di essi (che fanno pochissimo tranne accettare o emettere byte) vengono eseguiti come root e il resto viene eseguito con un privilegio inferiore.

È possibile eseguire un reindirizzamento delle porte. Questo è ciò che faccio per un server delle politiche Silverlight in esecuzione su un box Linux 

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 943 -j REDIRECT --to-port 1300

Puoi configurare un tunnel SSH locale, ad esempio se vuoi che la porta 80 raggiunga la tua app legata a 3000: 

sudo ssh $USERNAME@localhost -L 80:localhost:3000 -N

Questo ha il vantaggio di lavorare con i server di script e di essere molto semplice.

O patch il kernel e rimuovere il segno di spunta.

(Opzione di ultima istanza, non consigliata).

In net / ipv4 / af_inet.c , rimuovi le due righe che leggono 

      if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
              goto out;

e il kernel non controlla più le porte privilegiate.

Le funzionalità dei file non sono ideali, poiché possono rompersi dopo un aggiornamento del pacchetto.

La soluzione ideale, IMHO, dovrebbe essere la capacità di creare una shell con il set CAP_NET_BIND_SERVICE ereditabile.

Ecco un modo un po 'contorto per farlo: 

sg $DAEMONUSER "capsh --keep=1 --uid=`id -u $DAEMONUSER` \
     --caps='cap_net_bind_service+pei' -- \
     YOUR_COMMAND_GOES_HERE"
L'utilità

capsh si trova nel pacchetto libcap2-bin nelle distribuzioni Debian / Ubuntu. Ecco cosa succede:

  • sg cambia l'ID gruppo effettivo in quello dell'utente daemon. Ciò è necessario perché capsh lascia invariato il GID e sicuramente non lo vogliamo.
  • Imposta il bit 'mantieni le capacità sul cambio UID'.
  • Modifica l'UID in $DAEMONUSER
  • Elimina tutti i tappi (in questo momento tutti i tappi sono ancora presenti a causa di --keep = 1 ), ad eccezione di cap_net_bind_service
  • Esegue il comando ('-' è un separatore)

Il risultato è un processo con l'utente e il gruppo specificati e i privilegi cap_net_bind_service .

Ad esempio, una riga dallo script di avvio ejabberd : 

sg $EJABBERDUSER "capsh --keep=1 --uid=`id -u $EJABBERDUSER` --caps='cap_net_bind_service+pei' -- $EJABBERD --noshell -detached"

Altre due semplici possibilità:

Esiste una soluzione vecchia (non alla moda) per il "demone" che si lega su una porta bassa e passa il controllo manuale al demone ". Si chiama inetd (o xinetd). I contro sono:

  • il tuo demone deve parlare su stdin / stdout (se non controlli il demone - se non hai il sorgente - allora questo è forse uno showtopper, anche se alcuni servizi potrebbero avere un flag di compatibilità inetd )
  • un nuovo processo daemon è biforcuto per ogni connessione
  • è un anello in più nella catena

Pro:

  • disponibile su qualsiasi vecchio UNIX
  • una volta che il tuo amministratore di sistema ha impostato la configurazione, sei a posto per il tuo sviluppo (quando ricostruisci il tuo demone, potresti perdere le capacità di setcap? E poi dovrai tornare al tuo amministratore " per favore, signore ... ")
  • il demone non deve preoccuparsi di quella roba di rete, deve solo parlare su stdin / stdout
  • può configurare per eseguire il tuo demone come utente non root, come richiesto

Un'altra alternativa: un proxy hackerato (netcat o anche qualcosa di più robusto ) dalla porta privilegiata ad una porta arbitraria ad alto numero in cui è possibile eseguire il demone di destinazione. (Netcat non è ovviamente una soluzione di produzione, ma "solo la mia scatola di sviluppo", giusto?). In questo modo potresti continuare a utilizzare una versione di rete del tuo server, sarebbe necessario solo root / sudo per avviare il proxy (all'avvio), non fare affidamento su funzionalità complesse / potenzialmente fragili.

La mia "soluzione standard" " usa socat come redirector dello spazio utente: 

socat tcp6-listen:80,fork tcp6:8080

Attenzione che questo non si ridimensiona, il fork è costoso ma è il modo in cui funziona socat.

Aggiornamento 2017:

Usa authbind


Molto meglio di CAP_NET_BIND_SERVICE o di un kernel personalizzato.

  • CAP_NET_BIND_SERVICE garantisce l'attendibilità al file binario ma fornisce no controllo sull'accesso per porta.

  • Authbind dà fiducia al utente / gruppo e fornisce il controllo sull'accesso per porta e supporta sia IPv4 che IPv6 (il supporto IPv6 è stato aggiunto di recente).

    1. Installa: apt-get install authbind

    2. Configura l'accesso alle porte pertinenti, ad es. 80 e 443 per tutti gli utenti e gruppi:

        

      sudo touch / etc / authbind / byport / 80
        sudo touch / etc / authbind / byport / 443
        sudo chmod 777 / etc / authbind / byport / 80
        sudo chmod 777 / etc / authbind / byport / 443

    3. Esegui il tuo comando tramite authbind
      (facoltativamente specificando --deep o altri argomenti, vedi la pagina man): 

      authbind --deep /path/to/binary command line args

      es. 

      authbind --deep java -jar SomeServer.jar

Come seguito alla favolosa raccomandazione di Joshua (= non consigliata a meno che tu non sappia cosa fai) di hackerare il kernel:

L'ho pubblicato per la prima volta qui .

Semplice. Con un kernel normale o vecchio, non lo fai.
Come sottolineato da altri, iptables può inoltrare una porta.
Come sottolineato anche da altri, CAP_NET_BIND_SERVICE può anche fare il lavoro.
Naturalmente CAP_NET_BIND_SERVICE fallirà se avvii il tuo programma da uno script, a meno che tu non imposti il ??limite sull'interprete della shell, il che è inutile, potresti anche eseguire il tuo servizio come root ...
per esempio. per Java, devi applicarlo a JAVA JVM 

sudo /sbin/setcap 'cap_net_bind_service=ep' /usr/lib/jvm/java-8-openjdk/jre/bin/java

Ovviamente, ciò significa che qualsiasi programma Java può associare le porte di sistema.
Dito per mono / .NET.

Sono anche abbastanza sicuro che xinetd non sia la migliore delle idee.
Ma poiché entrambi i metodi sono hack, perché non alzare il limite alzando la restrizione?
Nessuno ha detto che devi eseguire un kernel normale, quindi puoi semplicemente eseguire il tuo.

Devi solo scaricare il sorgente per l'ultimo kernel (o lo stesso che hai attualmente). Successivamente, vai a: 

/usr/src/linux-<version_number>/include/net/sock.h:

Qui cerchi questa linea 

/* Sockets 0-1023 can't be bound to unless you are superuser */
#define PROT_SOCK       1024

e modificalo in 

#define PROT_SOCK 0

se non vuoi avere una situazione ssh insicura, la modifichi in questo modo:     #define PROT_SOCK 24

In genere, utilizzerei l'impostazione più bassa di cui hai bisogno, ad esempio 79 per http o 24 quando utilizzo SMTP sulla porta 25.

Questo è già tutto.
Compilare il kernel e installarlo.
Reboot.
Terminato: quello stupido limite è ANDATO e funziona anche per gli script.

Ecco come si compila un kernel:

https://help.ubuntu.com/community/Kernel/Compile 

# You can get the kernel-source via package linux-source, no manual download required
apt-get install linux-source fakeroot

mkdir ~/src
cd ~/src
tar xjvf /usr/src/linux-source-<version>.tar.bz2
cd linux-source-<version>

# Apply the changes to PROT_SOCK define in /include/net/sock.h

# Copy the kernel config file you are currently using
cp -vi /boot/config-`uname -r` .config

# Install ncurses libary, if you want to run menuconfig
apt-get install libncurses5 libncurses5-dev

# Run menuconfig (optional)
make menuconfig

# Define the number of threads you wanna use when compiling (should be <number CPU cores> - 1), e.g. for quad-core
export CONCURRENCY_LEVEL=3
# Now compile the custom kernel
fakeroot make-kpkg --initrd --append-to-version=custom kernel-image kernel-headers

# And wait a long long time

cd ..

In poche parole, usa iptables se vuoi rimanere sicuro, compila il kernel se vuoi essere sicuro che questa restrizione non ti disturbi mai più.

Linux supporta capacità per supportare permessi più dettagliati rispetto al solo " questa applicazione è esegui come root " ;. Una di queste funzionalità è CAP_NET_BIND_SERVICE che riguarda l'associazione a una porta privilegiata (< 1024).

Sfortunatamente non so come sfruttarlo per eseguire un'applicazione come non root pur continuando a dargli CAP_NET_BIND_SERVICE (probabilmente usando setcap , ma ci sarà sicuramente una soluzione esistente per questo).

So che questa è una vecchia domanda, ma ora con i kernel recenti (> = 4.3) c'è finalmente una buona risposta a questo: le capacità ambientali.

La risposta rapida è prendere una copia dell'ultima versione (non ancora rilasciata) di libcap da git e compilarlo. Copia il binario progs / capsh risultante da qualche parte ( / usr / local / bin è una buona scelta). Quindi, come root, avvia il tuo programma con 

/usr/local/bin/capsh --keep=1 --user='your-service-user-name' \
    --inh='cap_net_bind_service' --addamb='cap_net_bind_service' \ 
    -- -c 'your-program'

In ordine, siamo

  • Dichiarando che quando cambiamo utente, vogliamo mantenere i nostri attuali set di capacità
  • Cambio utente & amp; gruppo in "nome-utente-di-servizio"
  • Aggiunta della funzionalità cap_net_bind_service all'eredità & amp; ambient ambient
  • Forking bash -c 'your-command' (poiché capsh avvia automaticamente bash con gli argomenti dopo - )

Qui c'è molto da fare sotto il cofano.

In primo luogo, stiamo eseguendo come root, quindi per impostazione predefinita, otteniamo un set completo di funzionalità. Incluso in questo è la possibilità di cambiare uid & amp; gid con i syscalls setuid e setgid . Tuttavia, normalmente quando un programma fa questo, perde il suo insieme di capacità - questo è così che il vecchio modo di far cadere root con setuid funziona ancora. Il flag --keep = 1 indica a capsh di emettere prctl (PR_SET_KEEPCAPS) syscall, che disabilita il rilascio di funzionalità quando si cambia utente. L'effettiva modifica degli utenti con capsh avviene con il flag --user , che esegue setuid e setgid .

Il prossimo problema che dobbiamo risolvere è come impostare le capacità in modo che continuino dopo che exec i nostri figli. Il sistema di funzionalità ha sempre avuto un insieme di funzionalità "ereditate", che è " un insieme di funzionalità conservate in un execve (2) " [ capacità (7) ]. Anche se sembra che risolva il nostro problema (basta impostare la funzionalità cap_net_bind_service su ereditato, giusto?), Questo in realtà si applica solo ai processi privilegiati e il nostro processo non è più privilegiato, perché abbiamo già cambiato utente ( con il flag --user ).

Il nuovo set di funzionalità ambientali risolve questo problema: si tratta di un set di funzionalità che vengono conservate in un execve (2) di un programma non privilegiato. " Inserendo cap_net_bind_service nel set ambientale, quando capsh exec è il nostro programma server, il nostro programma erediterà questa capacità e sarà in grado di associare gli ascoltatori a porte basse.

Se sei interessato a saperne di più, le funzionalità pagina del manuale spiega questo in dettaglio. Anche l'esecuzione di capsh attraverso strace è molto istruttiva!

TLDR: per " la risposta " (come lo vedo io), passa al > > TLDR < < parte in questa risposta.

OK, l'ho capito (davvero questa volta), la risposta a questa domanda, e questa mia risposta è anche un modo per scusarmi per aver promosso un'altra risposta (sia qui che su Twitter) che pensavo fosse" il migliore ", ma dopo averlo provato, ho scoperto che mi sbagliavo. Impara dai miei errori bambini: non promuovere qualcosa fino a quando non l'hai provato tu stesso!

Ancora una volta, ho esaminato tutte le risposte qui. Ho provato alcuni (e ho scelto di non provare altri perché semplicemente non mi piacevano le soluzioni). Ho pensato che la soluzione fosse usare systemd con le sue impostazioni Capabilities = e CapabilitiesBindingSet = . Dopo aver lottato con questo per un po 'di tempo, ho scoperto che questa non è la soluzione because:

Le funzionalità hanno lo scopo di limitare i processi di root!

Come saggiamente affermato dall'OP, è meglio sempre evitarlo (se possibile per tutti i tuoi demoni!).

Non è possibile utilizzare le opzioni relative alle funzionalità con Utente = e Group = nei file di unità systemd , poiché le funzionalità sono SEMPRE ripristina quando viene chiamato execev (o qualunque sia la funzione). In altre parole, quando systemd esegue il fork e ne elimina i permessi, le funzionalità vengono ripristinate. Non c'è modo di aggirare questo, e tutta quella logica di legame nel kernel è di base attorno a uid = 0, non alle capacità. Ciò significa che è improbabile che le capacità siano mai la risposta giusta a questa domanda (almeno in qualunque momento presto). Per inciso, setcap , come altri hanno già detto, non è una soluzione. Non ha funzionato per me, non funziona bene con gli script e questi vengono ripristinati comunque ogni volta che il file cambia.

Nella mia scarsa difesa, ho dichiarato (nel commento che ho ora eliminato), che iptables di James suggerimento (che cita anche il PO), era la "seconda migliore soluzione". :-P

> > TLDR < <

La soluzione è combinare systemd con comandi al volo iptables , come questo ( tratto da DNSChain ): 

[Unit]
Description=dnschain
After=network.target
Wants=namecoin.service

[Service]
ExecStart=/usr/local/bin/dnschain
Environment=DNSCHAIN_SYSD_VER=0.0.1
PermissionsStartOnly=true
ExecStartPre=/sbin/sysctl -w net.ipv4.ip_forward=1
ExecStartPre=-/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=-/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStartPre=/sbin/iptables -A INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=/sbin/iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStopPost=/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStopPost=/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
User=dns
Group=dns
Restart=always
RestartSec=5
WorkingDirectory=/home/dns
PrivateTmp=true
NoNewPrivileges=true
ReadOnlyDirectories=/etc

# Unfortunately, capabilities are basically worthless because they're designed to restrict root daemons. Instead, we use iptables to listen on privileged ports.
# Capabilities=cap_net_bind_service+pei
# SecureBits=keep-caps

[Install]
WantedBy=multi-user.target

Qui realizziamo quanto segue:

  • Il demone è in ascolto su 5333, ma le connessioni sono accettate correttamente su 53 grazie a iptables
  • Possiamo includere i comandi nel file unitario stesso, e quindi possiamo salvare il mal di testa alle persone. systemd pulisce le regole del firewall per noi, assicurandoci di rimuoverle quando il demone non è in esecuzione.
  • Non eseguiamo mai come root e rendiamo impossibile l'escalation dei privilegi (almeno pretende systemd ), presumibilmente anche se il demone è compromesso e imposta uid = 0 .

iptables è purtroppo ancora un'utilità piuttosto brutta e difficile da usare. Se il demone sta ascoltando eth0: 0 anziché eth0 , ad esempio, i comandi sono leggermente diverso .

systemd è una sostituzione sysvinit che ha un'opzione per lanciare un demone con capacità specifiche . Opzioni Capacità =, CapabilityBoundingSet = nella systemd.exec (5) .

Il reindirizzamento delle porte ha avuto più senso per noi, ma abbiamo riscontrato un problema in cui la nostra applicazione avrebbe risolto localmente un URL che doveva anche essere reinstradato; (ciò significa che shindig ).

Ciò consentirà anche di essere reindirizzati quando si accede all'URL sul computer locale. 

iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A OUTPUT -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080

Per qualche motivo nessuno menziona la riduzione di sysctl net.ipv4.ip_unprivileged_port_start al valore necessario. Esempio: dobbiamo associare la nostra app alla porta 443. 

sysctl net.ipv4.ip_unprivileged_port_start=443

Alcuni potrebbero dire che esiste un potenziale problema di sicurezza: gli utenti non privilegiati ora possono legarsi alle altre porte privilegiate (444-1024). Ma puoi risolvere facilmente questo problema con iptables, bloccando altre porte: 

iptables -I INPUT -p tcp --dport 444:1024 -j DROP
iptables -I INPUT -p udp --dport 444:1024 -j DROP

Confronto con altri metodi. Questo metodo:

  • da un certo punto (IMO) è ancora più sicuro dell'impostazione di CAP_NET_BIND_SERVICE / setuid, dal momento che un'applicazione non è affatto impostata, anche parzialmente (le capacità in realtà lo sono). Ad esempio, per individuare un coredump di applicazioni abilitate alla funzionalità, è necessario modificare sysctl fs.suid_dumpable (che porta a un altro potenziale problema di sicurezza) Inoltre, quando è impostato CAP / suid, la directory / proc / PID è di proprietà di root, quindi l'utente non root non avrà le informazioni / il controllo completi del processo in esecuzione, ad esempio, l'utente non sarà in grado (nel caso comune) di determinare quali connessioni appartengono all'applicazione tramite / proc / PID / fd / (netstat -aptn | grep PID).
  • presenta uno svantaggio di sicurezza: mentre l'app (o qualsiasi app che utilizza le porte 443-1024) è inattiva per qualche motivo, un'altra app potrebbe prendere la porta. Ma questo problema potrebbe essere applicato anche a CAP / suid (nel caso in cui sia impostato su interprete, ad esempio java / nodejs) e iptables-redirect. Utilizzare il metodo systemd-socket per escludere questo problema. Utilizzare il metodo authbind per consentire solo l'associazione utente speciale.
  • non richiede l'impostazione di CAP / suid ogni volta che si distribuisce una nuova versione dell'applicazione.
  • non richiede supporto / modifica dell'applicazione, come il metodo systemd-socket.
  • non richiede la ricostruzione del kernel (se la versione in esecuzione supporta questa impostazione sysctl)
  • non funziona come LD_PRELOAD come il metodo authbind / privbind, ciò potrebbe potenzialmente influire su prestazioni, sicurezza, comportamento (no? non è stato testato). Nel resto authbind è un metodo davvero flessibile e sicuro.
  • esegue in modo eccessivo il metodo REDIRECT / DNAT di iptables, poiché non richiede la traduzione dell'indirizzo, il monitoraggio dello stato della connessione, ecc. Ciò è evidente solo sui sistemi ad alto carico.

A seconda della situazione, sceglierei tra sysctl, CAP, authbind e iptables-redirect. E questo è fantastico che abbiamo così tante opzioni.

All'avvio: 

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Quindi puoi associare alla porta a cui inoltri.

Con systemd, è sufficiente modificare leggermente il servizio per accettare socket preattivati.

Successivamente puoi utilizzare systemd socket activ .

Non sono necessarie funzionalità, iptables o altri trucchi.

Questo è il contenuto dei file systemd rilevanti da questo esempio di server http python

File httpd-true.service 

[Unit]
Description=Httpd true 

[Service]
ExecStart=/usr/local/bin/httpd-true
User=subsonic

PrivateTmp=yes

File httpd-true.socket 

[Unit]
Description=HTTPD true

[Socket]
ListenStream=80

[Install]
WantedBy=default.target

C'è anche il 'modo djb'. È possibile utilizzare questo metodo per avviare il processo come root in esecuzione su qualsiasi porta in tcpserver, quindi passerà il controllo del processo all'utente specificato immediatamente dopo l'avvio del processo. 

#!/bin/sh

UID=`id -u yourusername`
GID=`id -g yourusername`
exec tcpserver -u $UID -g $GID -RHl0 0 portnumber   /path/to/your/process &

Per ulteriori informazioni, vedere: http://thedjbway.b0llix.net/daemontools/uidgid. html

Utilizza l'utilità privbind : consente a un'applicazione senza privilegi di collegarsi a porte riservate.

Dato che il PO è solo sviluppo / test, possono essere utili soluzioni meno che eleganti:

setcap può essere utilizzato sull'interprete di uno script per garantire funzionalità agli script. Se setcaps sul binario dell'interprete globale non è accettabile, crea una copia locale del binario (qualsiasi utente può) e ottieni root per setcap su questa copia. Python2 (almeno) funziona correttamente con una copia locale dell'interprete nell'albero di sviluppo degli script. Non è necessario alcun aiuto in modo che l'utente root possa controllare a quali funzionalità gli utenti hanno accesso.

Se è necessario tenere traccia degli aggiornamenti dell'interprete dell'intero sistema, utilizzare uno script shell come il seguente per eseguire lo script: 

#!/bin/sh
#
#  Watch for updates to the Python2 interpreter

PRG=python_net_raw
PRG_ORIG=/usr/bin/python2.7

cmp $PRG_ORIG $PRG || {
    echo ""
    echo "***** $PRG_ORIG has been updated *****"
    echo "Run the following commands to refresh $PRG:"
    echo ""
    echo "    $ cp $PRG_ORIG $PRG"
    echo "    # setcap cap_net_raw+ep $PRG"
    echo ""
    exit
}

./$PRG $*

Ho provato il metodo iptables PREROUTING REDIRECT. Nei kernel precedenti sembra che questo tipo di regola non sia supportato per IPv6 . Ma a quanto pare ora è supportato in ip6tables v1.4.18 e kernel Linux v3.8.

Ho anche scoperto che PREROUTING REDIRECT non funziona per le connessioni avviate all'interno della macchina. Per lavorare per le connessioni dal computer locale, aggiungi anche una regola OUTPUT: vedi reindirizzamento della porta iptables non funzionante per localhost . Per esempio. qualcosa come: 

iptables -t nat -I OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080

Ho anche scoperto che PREROUTING REDIRECT influenza anche i pacchetti inoltrati . Cioè, se la macchina inoltra anche pacchetti tra le interfacce (ad es. Se agisce come un punto di accesso Wi-Fi collegato a una rete Ethernet), la regola iptables rileverà anche le connessioni dei client collegati a destinazioni Internet e li reindirizzerà a la macchina. Non è quello che volevo, volevo solo reindirizzare le connessioni dirette alla macchina stessa. Ho scoperto che posso influire solo sui pacchetti indirizzati al box, aggiungendo -m addrtype --dst-type LOCAL . Per esempio. qualcosa come: 

iptables -A PREROUTING -t nat -p tcp --dport 80 -m addrtype --dst-type LOCAL -j REDIRECT --to-port 8080

Un'altra possibilità è utilizzare il port forwarding TCP. Per esempio. utilizzando socat : 

socat TCP4-LISTEN:www,reuseaddr,fork TCP4:localhost:8080

Tuttavia, uno svantaggio di questo metodo è che l'applicazione in ascolto sulla porta 8080 non conosce l'indirizzo di origine delle connessioni in entrata (ad esempio per la registrazione o altri scopi di identificazione).

Risposta al 2015 / settembre:

ip6tables ora supporta IPV6 NAT: http: // www.netfilter.org/projects/iptables/files/changes-iptables-1.4.17.txt

Avrai bisogno del kernel 3.7+

La prova: 

[09:09:23] root@X:~ ip6tables -t nat -vnL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REDIRECT   tcp      eth0   *       ::/0                 ::/0                 tcp dpt:80 redir ports 8080
    0     0 REDIRECT   tcp      eth0   *       ::/0                 ::/0                 tcp dpt:443 redir ports 1443

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 6148 packets, 534K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 6148 packets, 534K bytes)
 pkts bytes target     prot opt in     out     source               destination
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top