Gibt es eine Möglichkeit für Nicht-Root-Prozesse „privilegierte“ Ports auf Linux zu binden?

https://stackoverflow.com/questions/413807

03-07-2019
|

Frage

Es ist sehr ärgerlich, diese Einschränkung auf meiner Entwicklung Feld zu haben, wenn es nicht immer irgendwelche andere Nutzer als ich sein wird.

Ich bin mir dessen bewusst , aber keiner von ihnen genau das tun, was ich möchte:

authbind (Die Version in Debian Testing, 1.0, unterstützt nur IPv4)
Verwenden der iptables Ziel REDIRECT einen niedrigen Port zu einem hohen Port zu umleiten (die "nat" Tabelle noch nicht für ip6tables implementiert, die IPv6-Version von iptables)
sudo (als root laufen zu lassen ist, was ich versuche zu vermeiden)
SELinux (oder ähnliches). (Dies ist nur meine Dev-Box, ich will nicht viel zusätzliche Komplexität einzuführen.)

Gibt es eine einfache sysctl variable nicht-root-Prozesse „privilegierte“ Ports (Ports kleiner als 1024) auf Linux, oder bin ich kein Glück nur zu binden, zu ermöglichen?

EDIT: In einigen Fällen können Sie Verwendung Fähigkeiten dies zu tun.

Lösung

Okay, dank der Menschen, die die Fähigkeiten System und CAP_NET_BIND_SERVICE Fähigkeit hingewiesen. Wenn Sie einen aktuellen Kernel haben, ist es in der Tat möglich, dies zu verwenden, um einen Dienst als Nicht-root zu starten, aber niedrige Ports binden. Die kurze Antwort ist, dass Sie tun:

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

Und dann wird jederzeit program ausgeführt danach wird es die CAP_NET_BIND_SERVICE Fähigkeit. setcap ist im Debian-Paket libcap2-bin.

Nun zu den Einschränkungen:

Sie müssen mindestens ein Kernel 2.6.24
Das wird nicht funktionieren, wenn Ihre Datei ein Skript. (Dh verwendet eine #! Linie einen Dolmetscher zu starten). In diesem Fall, soweit ich verstehe, dann würden Sie die Möglichkeit, an den Interpreter ausführbar selbst anwenden müssen, was natürlich ein Unsicherheitsfaktor, da jedes Programm, das Interpreter wird die Fähigkeit besitzen. Ich war nicht in der Lage, jede saubere, einfache Art und Weise zu finden, um dieses Problem zu arbeiten.
Linux wird LD_LIBRARY_PATH auf jedem program deaktivieren, die Privilegien wie setcap oder suid erhoben hat. Also, wenn Ihr program seine eigene .../lib/ verwendet, können Sie in eine andere Option wie Port-Forwarding suchen.

Ressourcen:

Fähigkeiten (7) man-Seite . Lesen Sie diese lange und hart, wenn du gehst Fähigkeiten in einer Produktionsumgebung zu verwenden. Es gibt einige wirklich schwierigen Details, wie Fähigkeiten über exec vererbt () Anrufe, die hier detailliert beschrieben werden.
setcap Manpage
"Bind Ports unter 1024 ohne root auf GNU / Linux" : Das Dokument, das erste wies mich in Richtung setcap.

Hinweis: RHEL hinzugefügt erste in v6 .

Andere Tipps

Der üblicher Weg ist, sie „setuid“ zu machen, so dass sie als root starten, und dann die Root-Rechte sie wegzuwerfen, sobald sie in den Hafen gebunden haben, aber bevor sie beginnen Verbindungen zu ihnen zu akzeptieren. Sie können für Apache und INN gute Beispiele dafür, dass in den Quellcode sehen. Mir wurde gesagt, dass Lighttpd ein weiteres gutes Beispiel ist.

Ein weiteres Beispiel ist Postfix, die mehrere Daemons verwendet, die durch Rohrleitungen in Verbindung stehen, und nur ein oder zwei von ihnen (die sehr wenig tun, außer Bytes akzeptieren oder emittieren) laufen als Wurzel und den Rest Lauf auf einem niedrigeren Privileg.

Sie können eine Portweiterleitung tun. Dies ist, was ich für einen Silverlight-Policy-Server tun läuft auf einer Linux-Box

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

Sie können Setup einen lokalen SSH-Tunnel, wenn Sie zB Port 80 wollen Ihre App gebunden bis 3000 zu schlagen:

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

Dies hat den Vorteil, mit Skript-Server zu arbeiten, und ist sehr einfach.

oder den Kernel patchen und das Kontroll entfernen.

(Option der letzten Instanz, nicht empfohlen).

In net/ipv4/af_inet.c, entfernen Sie die beiden Linien, die lesen

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

und die Kernel privilegierte Ports nicht mehr überprüfen.

Datei-Funktionen sind nicht ideal, da sie nach einem Paket Update brechen können.

Die ideale Lösung, IMHO sollten die Fähigkeit sein, eine Schale mit vererbbarem CAP_NET_BIND_SERVICE Satz zu erstellen.

Hier ist ein etwas gewundener Weg, dies zu tun:

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

capsh Dienstprogramm kann in libcap2-bin-Paket in Debian / Ubuntu-Distributionen finden. Hier ist, was geht auf:

sg ändert effektive Gruppen-ID zu, dass der Daemon Benutzer. Dies ist notwendig, weil capsh verlässt GID unverändert, und wir wollen es auf jeden Fall nicht.
setzt das Bit 'halten Fähigkeiten auf UID ändern'.
Änderungen UID $DAEMONUSER
Löscht alle Kappen (in diesem Moment alle Kappen sind wegen --keep=1 noch vorhanden), mit Ausnahme vererbbar cap_net_bind_service
Führt Ihren Befehl ( '-' ist ein Separator)

Das Ergebnis ist ein Prozess, mit dem angegebenen Benutzer- und Gruppen und cap_net_bind_service Privilegien.

Als Beispiel wird eine Linie von ejabberd Startskript:

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

Zwei weitere einfache Möglichkeiten:

Es gibt eine alte (unmodern) Lösung für das „einem Dämon, der auf einem niedrigen Port und übergibt die Steuerung an Ihren Daemon bindet“. Es ist inetd (oder xinetd) genannt. Die Nachteile sind:

Ihr Dämon muss auf stdin / stdout sprechen (wenn Sie nicht über den Daemon steuern - wenn Sie die Quelle nicht haben - dann ist dies vielleicht ein Hemmschuh, obwohl einige Dienste eine inetd-Kompatibilitätsflag haben )
ein neuer Dämon-Prozess wird für jede Verbindung gegabelt
es ist ein zusätzliches Glied in der Kette

Vorteile:

auf jedem alten UNIX
, sobald Ihr Sysadmin die Config eingerichtet hat, sind Sie gut über Ihre Entwicklung zu gehen (wenn Sie neu bauen Ihr Dämon, könnten Sie setcap Fähigkeiten verlieren? Und dann werden Sie zu Ihrem Admin gehen müssen zurück „bitte Sir ... ")
Dämon nicht über diese Vernetzung Sachen machen muss, hat nur auf stdin / stdout
kann konfigurieren Sie Ihren Daemon als nicht-Root-Benutzer ausgeführt werden, wie gewünscht

Eine weitere Alternative: ein gehackter-up-Proxy (netcat oder sogar etwas robustere ) von dem privilegiert Port zu einem willkürlich hoch Port, wo Sie Ihr Ziel Daemon ausführen können. (Netcat ist natürlich keine Produktionslösung, sondern „nur meine Dev-Box“, nicht wahr?). Auf diese Weise könnten Sie auch weiterhin eine netzwerkfähige Version des Servers verwenden, wäre Proxy nur root / sudo müssen beginnen (beim Booten), nicht auf komplexe / potenziell fragilen Fähigkeiten verlassen würde.

Meine "Standard Abhilfe" verwendet socat als User-Space-Redirector:

socat tcp6-listen:80,fork tcp6:8080

Beachten Sie, dass dies nicht maßstäblich, Forking ist teuer, aber es ist die Art und Weise socat funktioniert.

Update 2017:

Verwenden Sie authbind

Viel besser als CAP_NET_BIND_SERVICE oder einen angepassten Kernel.

CAP_NET_BIND_SERVICE gewährt Vertrauen auf das binäre, sondern bietet keine Kontrolle über die pro-Port-Zugriff.
authbind gewährt Vertrauen auf die Benutzer / Gruppe und ermöglicht die Kontrolle über Pro-Port-Anschluss, und unterstützt sowohl IPv4 als auch IPv6 (IPv6-Unterstützung als in der letzten Zeit hinzugefügt wurde).
1. Installieren: apt-get install authbind
2. Konfigurieren Sie den Zugriff auf relevante Ports, z.B. 80 und 443 für alle Benutzer und Gruppen:
  
  
  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. Führen Sie Ihren Befehl über authbind
  (Optional --deep oder andere Argumente angeben, finden Sie in der Manpage):
```
authbind --deep /path/to/binary command line args
```
  z.
```
authbind --deep java -jar SomeServer.jar
```

Als Follow-up zu Joshua fabelhafter (= nicht empfohlen, wenn Sie wissen, was Sie tun) Empfehlung, den Kernel zu hacken:

Ich habe geschrieben es zuerst hier .

Einfach. Bei einem normalen oder alten Kernel, nicht wahr.
Wie von anderen darauf hingewiesen wird, kann iptables einen Port weiterleiten.
Wie auch von anderen darauf hingewiesen wird, kann CAP_NET_BIND_SERVICE tun auch den Job.
Natürlich wird CAP_NET_BIND_SERVICE fehlschlagen, wenn Sie Ihr Programm aus einem Skript starten, wenn Sie die Kappe auf dem Shell-Interpreter eingestellt, was sinnlos ist, könnten Sie genauso gut Ihren Service als root ausführen ...
z.B. für Java, müssen Sie es auf die JAVA JVM anwenden

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

Offensichtlich bedeutet, dass dann jedes Java-Programm kann das System Ports binden.
Dito für Mono / .NET.

Ich bin auch ziemlich sicher, dass xinetd ist nicht die beste von Ideen.
Aber da beide Methoden sind Hacks, warum nicht nur die Grenze heben durch die Einschränkung zu heben?
Niemand hat gesagt, Sie einen normalen Kernel laufen haben, so können Sie nur Ihre eigenen laufen.

Sie laden Sie einfach die Quelle für den neuesten Kernel (oder gleichen Sie derzeit haben). Danach gehen Sie zu:

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

Es sehen Sie für diese Zeile

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

und ändern Sie ihn auf

#define PROT_SOCK 0

Wenn Sie nicht über eine unsichere ssh Situation haben wollen, ändern Sie es so weit: #define PROT_SOCK 24

Im Allgemeinen würde ich die niedrigste Einstellung, die Sie benötigen, beispiel 79 für HTTP oder 24, wenn SMTP auf Port 25.

Das ist schon alles.
Kompilieren des Kernels, und installieren Sie es.
Reboot.
Fertig -. So dumm Grenze ist weg, und das funktioniert auch für Skripte

Hier ist, wie Sie einen Kernel kompilieren:

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 ..

Auf den Punkt gebracht, verwenden iptables, wenn Sie sicher sein wollen, kompilieren den Kernel, wenn Sie diese Einschränkung nie sicher sein wollen, stört Sie wieder.

Linux unterstützt Fähigkeiten mehr abgestimmter Berechtigungen als nur „diese Anwendung ausführen zu unterstützen ist als root“. Eine dieser Funktionen ist CAP_NET_BIND_SERVICE, die über die Bindung an einen privilegierten Port (<1024).

Leider weiß ich nicht, wie das nutzen, eine Anwendung als nicht-root ausführen, während noch gibt es CAP_NET_BIND_SERVICE (wahrscheinlich a href mit <= "http://man7.org/linux/man-pages/man8/ setcap.8.html“rel = "nofollow noreferrer"> setcap , aber es ist verpflichtet dafür eine bestehende Lösung zu sein).

Ich weiß, dass dies eine alte Frage, aber jetzt mit dem letzten (> = 4.3) Kern ist schließlich eine gute Antwort auf diesen -. Umgebungs-Fähigkeiten

Die schnelle Antwort ist eine Kopie der letzten (bis jetzt noch nicht freigegebenen) Version von libcap greifen von git und kompilieren sie es. Kopieren Sie die resultierende progs/capsh binäre irgendwo (/usr/local/bin ist eine gute Wahl). Dann, als root, starten Sie Ihr Programm mit

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

Um wir

Deklarieren, dass, wenn wir den Benutzer wechseln, wir unsere aktuellen Fähigkeit Sets behalten möchten
Schalt Benutzer & Gruppen zu 'Ihr-Service-Benutzer-Name'
Hinzufügen der cap_net_bind_service Fähigkeit zu den vererbten & Umgebungssätze
Forking bash -c 'your-command' (seit capsh startet automatisch bash mit den Argumenten nach --)

Es gibt eine Menge los ist unter der Haube hier.

Zum einen laufen wir als root, so standardmäßig wir eine ganze Reihe von Fähigkeiten zu bekommen. Darin enthalten ist die Fähigkeit, uid und gid mit dem setuid und setgid syscalls zu wechseln. Jedoch normalerweise, wenn ein Programm dies tut, verliert es seine Reihe von Funktionen - das ist so, dass die alte Art und Weise Wurzel mit setuid des Fallenlassens noch funktioniert. Die --keep=1 Flag teilt capsh den prctl(PR_SET_KEEPCAPS) syscall auszustellen, die den Abwurf von Funktionen deaktiviert, wenn der Benutzer zu ändern. Die tatsächliche Änderung der Benutzer durch capsh geschieht mit der --user Flagge, die setuid und setgid ausgeführt wird.

Das nächste Problem, das wir lösen müssen, ist, wie Fähigkeiten in einer Weise einzustellen, die Tätigkeit ausgeübt wird, nachdem wir unsere Kinder exec. Die Fähigkeiten-System hat immer eine ‚geerbt‘ Satz von Fähigkeiten, die „über eine execve (2) erhalten eine Reihe von Fähigkeiten“ [ Funktionen (7) ]. Während das klingt wie es unser Problem löst (nur die cap_net_bind_service Fähigkeit auf geerbt, nicht wahr?), Dies gilt eigentlich nur für privilegierte Prozesse - und unser Prozess ist nicht mehr privilegiert, weil wir Benutzer bereits geändert (mit --user Flagge).

Die neue Umgebungsfähigkeitsmenge arbeitet, um dieses Problem - es ist „eine Reihe von Funktionen, die über eine execve erhalten sind (2) ein Programm, das nicht privilegiert ist.“ Indem cap_net_bind_service in dem Umgebungssatz, wenn capsh des exec unser Server-Programm, unser Programm wird diese Fähigkeit erbt und in der Lage sein, die Zuhörer zu binden niedrige Ports.

Wenn Sie interessiert sind, mehr zu lernen, die Fähigkeiten Handbuch Seite erklärt dies im Detail. capsh durch strace Laufen ist auch sehr informativ!

TLDR: Für "die Antwort" (wie ich es sehe), springe hinunter zum >> TLDR << Teil in dieser Antwort

OK, ich habe es herausgefunden (diesmal wirklich), die Antwort auf diese Frage, und diese Antwort von mir ist auch eine Möglichkeit, sich zu entschuldigen für die Förderung der eine andere Antwort (sowohl hier als auch auf twitter), die ich dachte, war ‚das beste‘, aber es nach dem Versuch entdeckt, dass ich darüber irrte. Lernen Sie aus meinem Fehler Kinder: nicht etwas fördern, bis Sie haben es wirklich versucht, sich

Noch einmal, ich überprüfte alle Antworten hier. Ich habe versucht, einige von ihnen (und entschied sich nicht, andere zu versuchen, weil ich einfach nicht die Lösungen mögen). Ich dachte, dass die Lösung mit seinen systemd und Capabilities= Einstellungen zu verwenden CapabilitiesBindingSet= war. mit diesem nach Ringen seit einiger Zeit entdeckte ich, dass dies nicht die Lösung ist , weil:

Capabilities sollen Wurzelprozesse beschränken!

Wie die OP mit Bedacht gesagt, es ist immer am besten zu vermeiden, dass (für alle Daemons, wenn möglich!).

Sie können die Funktionen nutzen bezogene Optionen mit User= und Group= in systemd Unit-Dateien, weil Fähigkeiten sind immer zurückgesetzt, wenn execev (oder was auch immer die Funktion) aufgerufen wird. Mit anderen Worten, wenn systemd Gabeln und seine perms fallen, sind die Fähigkeiten zurückgesetzt. Es gibt keine Möglichkeit, dies zu umgehen, und alles, was die Bindung Logik im Kernel ist einfach um uid = 0, nicht Fähigkeiten. Das bedeutet, dass es unwahrscheinlich ist, dass Fähigkeiten jemals die richtige Antwort auf diese Frage (zumindest in absehbarer Zeit). Übrigens setcap, wie andere schon erwähnt haben, ist keine Lösung. Es dauerte nicht für mich arbeiten, ist es nicht gut mit Skripten funktioniert, und diejenigen zurückgesetzt sowieso, wenn die Datei geändert wird.

In meiner spärlichen Verteidigung, ich Zustand tat (im Kommentar habe ich jetzt gelöscht), dass James' iptables Vorschlag (die OP erwähnt auch), war die „2. beste Lösung“. :-P

>> TLDR <<

Die Lösung ist systemd mit on-the-fly iptables Befehlen zu kombinieren, wie dieser ( von DNSChain genommen):

[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

Hier stellen wir erreichen wie folgt vor:

Der Dämon hört auf 5333, aber Verbindungen auf 53 dank erfolgreich angenommen iptables
Wir können die Befehle in der Unit-Datei selbst enthalten, und somit sparen wir Menschen Kopfschmerzen. systemd reinigt die Firewall-Regeln für uns, dafür zu sorgen, sie zu entfernen, wenn der Daemon nicht ausgeführt wird.
Wir haben nie als root ausführen, und wir machen privilege escalation unmöglich (zumindest systemd behauptet), angeblich auch wenn der Dämon beeinträchtigt wird und setzt uid=0.

iptables ist leider immer noch ein ziemlich hässlich und schwer zu bedienendes Programm. Wenn der Daemon auf eth0:0 hört statt eth0 zum Beispiel die Befehle etwas andere .

systemd ist ein sysvinit Ersatz, der eine Option hat einen Dämon mit spezifischen Fähigkeiten zu starten . Optionen Capabilities =, CapabilityBoundingSet = in systemd.exec (5) manpage.

Port-Weiterleitung aus den meisten Sinn für uns, aber wir liefen in ein Problem, wo unsere Anwendung eine URL lokal lösen würde, die auch umgeleitet werden musste; (Das bedeutet, dass Sie shindig ).

Dies wird auch ermöglicht es Ihnen umgeleitet werden, wenn Sie die URL auf dem lokalen Rechner zugreifen.

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

Aus irgendeinem Grund niemand erwähnen über sysctl net.ipv4.ip_unprivileged_port_start auf den Wert senken Sie benötigen. Beispiel: Wir müssen unsere App auf Port 443 binden

sysctl net.ipv4.ip_unprivileged_port_start=443

Einige mögen sagen, es ist ein potenzielles Sicherheitsproblem: unprivilegierten Benutzer jetzt zu den anderen privilegierten Ports binden können (444-1024). Aber Sie können dieses Problem lösen, leicht mit iptables, die von anderen Ports blockiert:

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

Der Vergleich mit anderen Methoden. Diese Methode:

ab einem gewissen Punkt ist (IMO) noch sicherer als die Einstellung CAP_NET_BIND_SERVICE / setuid-, da eine Anwendung nicht setuid tut überhaupt, auch nur teilweise (Fähigkeiten sind tatsächlich). Um zum Beispiel eine coredump der Fähigkeit-fähige Anwendung fangen Sie sysctl fs.suid_dumpable (was zu weiteren potenziellen Sicherheitsprobleme) müssen sich ändern Auch wenn CAP / suid gesetzt, / proc / PID-Verzeichnis ist im Besitz von root, so dass Ihre Nicht-Root-Benutzern nicht der volle Information / Kontrolle des laufenden Prozesses, zum Beispiel Benutzer nicht in der Lage sein (gemeinsam Fall) bestimmen, welche Verbindungen gehören zur Anwendung über / proc / PID / fd / (netstat -aptn | grep PID).
hat Nachteil Sicherheit: Während der App (oder eine Anwendung, die Ports verwendet 443-1024) aus irgendeinem Grund ausfällt, eine andere App, den Hafen übernehmen könnte. Aber dieses Problem könnte auch auf CAP / suid angewandt werden (falls Sie es auf Dolmetscher eingestellt, zum Beispiel java / NodeJS) und iptables-Umleitung. Verwenden systemd Sockel Methode, dieses Problem auszuschließen. Verwenden Sie authbind Methode nur erlauben spezielle Benutzer verbindlich.
erfordert keine Einstellung CAP / suid jedes Mal, wenn eine neue Version von Anwendung bereitstellen.
erfordert keine Anwendungsunterstützung / Änderung, wie systemd-Buchse Methode.
nicht neuen Kernel benötigen (wenn Version läuft diese sysctl Einstellung unterstützt)
Sie nicht LD_PRELOAD wie authbind / privbind Methode, diese potenziell Leistung beeinträchtigen könnte, Sicherheit, Verhalten (nicht wahr? Nicht getestet). Im Rest authbind ist wirklich flexible und sichere Methode.
Über führt iptables REDIRECT / DNAT Verfahren, da es keine Adressübersetzung erfordern, Verbindungsstatus Tracking etc. Dies ist nur spürbar auf Hochlast-Systeme.

Je nach Situation, würde ich zwischen Sysctl, CAP, authbind und iptables-Umleitung wählen. Und das ist toll, dass wir so viele Möglichkeiten haben.

Beim Start:

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

Dann können Sie an den Port binden an Sie weiter.

Mit systemd, man muss nur ein wenig Ihren Dienst ändern voraktivierten Steckdosen anzunehmen.

Sie können später verwenden systemd Buchse aktivieren.

Keine Fähigkeiten, iptables oder andere Tricks benötigt werden.

Dies ist Inhalt der relevanten systemd Dateien aus diesem Beispiel von einfachen Python HTTP-Server

Datei httpd-true.service

[Unit]
Description=Httpd true 

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

PrivateTmp=yes

Datei httpd-true.socket

[Unit]
Description=HTTPD true

[Socket]
ListenStream=80

[Install]
WantedBy=default.target

Es gibt auch den ‚djb Weg‘. Sie können diese Methode verwenden, um Ihren Prozess als root auf einem beliebigen Port unter tcpserver laufen zu beginnen, dann wird es die Steuerung des Prozesses an den Benutzer übergeben Sie sofort angeben, nachdem der Prozess beginnt.

#!/bin/sh

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

Weitere Informationen finden Sie unter: http://thedjbway.b0llix.net/daemontools/uidgid. html

Mit der privbind Dienstprogramm . es sich um eine nicht privilegierte Anwendung ermöglicht es zu reservierten Ports zu binden

Da die OP ist nur Entwicklung / Tests, weniger als schlanke Lösungen können hilfreich sein:

setcap kann auf einem Skript-Interpreter verwendet werden Fähigkeiten, um Skripts zu gewähren. Wenn setcaps auf dem globalen Interpreter binären nicht akzeptabel ist, eine lokale Kopie des binären machen (jeder Benutzer kann) und bekommen root auf dieser Kopie setcap. Python2 (mindestens) funktioniert mit einer lokalen Kopie des Dolmetschers in Ihrer Entwicklung Baum Skript. Kein suid benötigt wird, so dass der Benutzer root steuern, was Fähigkeiten Benutzer haben Zugriff.

Wenn Sie systemweite Aktualisierungen der Dolmetscher zu verfolgen, verwenden Sie ein Shell-Skript wie das folgende Skript ausführen:

#!/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 $*

Ich habe versucht, die iptables PREROUTING Redirect-Methode. In älterer Kernel scheint es diese Art der Regel nicht für IPv6 unterstützt wurde. Aber anscheinend ist es jetzt in ip6tables v1.4.18 und Linux-Kernel v3.8 unterstützt.

Ich fand auch, dass PREROUTING REDIRECT nicht für Verbindungen innerhalb der Maschine eingeleitet funktioniert. Um conections von der lokalen Maschine zu arbeiten, fügen Sie auch eine OUTPUT-Regel - siehe iptables Port umleiten nicht für localhost arbeiten. Z.B. so etwas wie:

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

Ich fand auch, dass PREROUTING REDIRECT hat auch Auswirkungen auf weitergeleitet Pakete . Das heißt, wenn die Maschine auch Weiterleiten von Paketen zwischen den Schnittstellen (zB wenn es als Wi-Fi-Zugangspunkt zu einem Ethernet-Netzwerk verbunden handelt), dann wird die iptables-Regel auch verbundene Kunden Verbindungen zu Internet Destinationen fangen, und leiten sie zu Die Maschine. Das ist nicht das, was ich wollte, ich wollte nur Verbindungen umgeleitet werden, die an der Maschine selbst gerichtet waren. Ich fand ich machen kann es nur Pakete an die Box adressiert beeinflussen, durch -m addrtype --dst-type LOCAL Zugabe. Z.B. so etwas wie:

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

Eine andere Möglichkeit ist, die TCP-Port-Weiterleitung zu verwenden. Z.B. mit socat:

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

jedoch ein Nachteil bei diesem Verfahren ist die Anwendung, die auf Port 8080 lauscht dann kennt nicht die Quelladresse der eingehenden Verbindungen (beispielsweise für die Protokollierung oder andere Identifikationszwecke).

Antwort bei 2015 / Sep:

ip6tables unterstützt jetzt IPV6 NAT: http: // www.netfilter.org/projects/iptables/files/changes-iptables-1.4.17.txt

Sie müssen Kernel 3.7 +

Beweis:

[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

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow