Comment faire fonctionner un serveur sur le port 80 en tant qu'utilisateur normal sous Linux?

Je cherche une solution sur Google depuis assez longtemps, mais je n’ai pas trouvé de réponse.

Je suis sous Ubuntu Linux et souhaite utiliser un serveur sur le port 80, mais en raison du mécanisme de sécurité d'Ubuntu, l'erreur suivante apparaît:

java.net.BindException: Autorisation refusée: 80

Je pense qu'il devrait être assez simple pour désactiver ce mécanisme de sécurité afin que le port 80 soit disponible pour tous les utilisateurs ou pour attribuer les privilèges requis à l'utilisateur actuel pour accéder au port 80.

Réponse courte: vous ne pouvez pas. Les ports inférieurs à 1024 ne peuvent être ouverts que par root. Comme indiqué dans commentaire - vous pouvez utiliser CAP_NET_BIND_SERVICE , mais cette approche, appliquée à java bin, fera que tout programme java sera exécuté avec ce paramètre, ce qui est indésirable, si ce n’est un risque pour la sécurité.

La réponse longue: vous pouvez rediriger les connexions sur le port 80 vers un autre port que vous pouvez ouvrir en tant qu'utilisateur normal.

Exécuter en tant que root:

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

Comme les périphériques en boucle (tels que localhost) n'utilisent pas les règles de préroutage, si vous devez utiliser localhost, etc., ajoutez également cette règle ( merci @Francesco ):

# iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080

REMARQUE: La solution ci-dessus ne convient pas aux systèmes multi-utilisateurs, car tout utilisateur peut ouvrir le port 8080 (ou tout autre port haut que vous décidez d'utiliser), interceptant ainsi le trafic. (Crédits à CesarB ).

EDIT: selon la question de commentaire - pour supprimer la règle ci-dessus:

# iptables -t nat --line-numbers -n -L

Cela produira quelque chose comme:

Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:8080 redir ports 8088
2    REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 redir ports 8080

La règle qui vous intéresse est nr. 2, donc pour le supprimer:

# iptables -t nat -D PREROUTING 2

Utilisez authbind .

Cela fonctionne même avec Java si vous activez la pile Java uniquement pour IPv4. J'utilise:

authbind --deep $JAVA_HOME/bin/java -Djava.net.preferIPv4Stack=true …

Si votre système le prend en charge, vous pourriez peut-être utiliser des fonctionnalités. Voir les capacités man, celle dont vous avez besoin serait CAP_NET_BIND_SERVICE.

Sur les nouvelles Debian / Ubuntu, vous pouvez exécuter:

sudo apt-get install libcap2-bin 
sudo setcap 'cap_net_bind_service=+ep' /path/to/program

Une autre solution consiste à configurer votre application de sorte qu'elle puisse se connecter au port 80. En tant que root, procédez comme suit:

chown root ./myapp
chmod +S ./myapp

Gardez à l'esprit que cela, à moins que cela ne soit absolument correct, vous exposera à des failles de sécurité, car votre application communiquera avec le réseau et fonctionnera avec les privilèges root complets. Si vous prenez cette solution, vous devriez consulter le code source d’Apache ou de Lighttpd ou quelque chose de similaire, où ils utilisent les privilèges root pour ouvrir le port, puis abandonnent immédiatement ces privilèges et "deviennent" des utilisateurs avec des privilèges inférieurs. un pirate de l'air ne peut pas s'emparer de tout votre ordinateur.

Mise à jour: comme on le voit dans cette question , il apparaît que les noyaux Linux depuis la version 2.6.24 ont une nouvelle capacité qui vous permet de marquer un exécutable (mais pas un script, bien entendu) comme ayant la CAP_NET_BIND_SERVICEcapacité " ". Si vous installez le paquet debian "libcap2-bin", vous pouvez le faire en lançant la commande

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

J'utilise simplement Nginx devant. Il peut aussi fonctionner sur localhost.

• apt-get install nginx

.. ou ..

• pkg_add -r nginx

.. ou ce qui convient à votre système d'exploitation.

Tout ce dont vous avez besoin dans nginx.conf, si vous utilisez localhost, est:

serveur {
        écoutez 80;
        nom_serveur some.domain.org;
        emplacement / {
            proxy_set_header Host $ host;
            proxy_set_header X-Real-IP $ remote_addr;
            proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for;
            proxy_pass http://127.0.0.1:8081;
        }
}

Approche proposée par Sunny et CesarB:

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

fonctionne bien mais présente un petit inconvénient: cela n’empêche pas l’utilisateur de se connecter directement au port 8080 au lieu de 80.

Considérez le scénario suivant lorsque cela peut être un problème.

Disons que nous avons un serveur qui accepte les connexions HTTP sur le port 8080 et les connexions HTTPS sur le port 8181.

Nous utilisons iptables pour établir les redirections suivantes:

80  ---> 8080
443 ---> 8181

Supposons maintenant que notre serveur décide de rediriger l'utilisateur d'une page HTTP vers une page HTTPS. Si nous ne réécrivions pas soigneusement la réponse, elle serait redirigée vers https://host:8181/. À ce stade, nous sommes foutus:

• Certains utilisateurs marqueraient l' https://host:8181/URL d'un signet et nous aurions besoin de la conserver pour éviter de casser leurs signets.
• Les autres utilisateurs ne pourraient pas se connecter car leurs serveurs proxy ne prennent pas en charge les ports SSL non standard.

J'utilise l'approche suivante:

iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark 1
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8181
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -m mark --mark 1 -j ACCEPT
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 8181 -m mark --mark 1 -j ACCEPT

Combinée à la règle REJECT par défaut sur la chaîne INPUT, cette approche empêche les utilisateurs de se connecter directement aux ports 8080 et 8181.

Traditionnellement sous Unix, seul root peut se lier aux ports bas (<1024).

La méthode la plus simple consiste à exécuter votre serveur sur un port élevé (par exemple, 8080) et à utiliser une simple règle iptables pour transférer les connexions du port 80 au port 8080. Notez que vous perdez ainsi la protection supplémentaire offerte par le ports bas; n'importe quel utilisateur de votre ordinateur peut se connecter au port 8080.

Si votre système le prend en charge, vous pourriez peut-être utiliser des fonctionnalités. Vous voyez man capabilities, celui dont vous avez besoin serait CAP_NET_BIND_SERVICE. Non, je ne les ai jamais utilisées moi-même et je ne sais pas si elles fonctionnent vraiment :-)

Utilisez un proxy inverse (nginx, apache + mod_proxy) ou un proxy inverse en cache (Squid, Varnish) devant vos serveurs d'applications!

Avec un proxy inverse, vous pouvez réaliser beaucoup de choses intéressantes comme:

• L'équilibrage de charge
• Redémarrage de vos serveurs d'applications avec les utilisateurs recevant une page d'erreur sophistiquée
• Accélérer les choses avec le cache
• Paramètres détaillés que vous définissez normalement avec un proxy inverse et non avec un serveur d'applications

Vous pouvez utiliser le programme redir:

sudo redir --lport=80 --laddr=192.168.0.101 --cport 9990 --caddr=127.0.0.1

Utilisez sudo.

Configurez sudo pour que l'utilisateur normal puisse exécuter les commandes appropriées:

/etc/init.d/httpd start

Ou

apachectl stop

Ou

/usr/local/apache2/apachectl restart

Ou

/myapp/myappbin start

(Ou quelque autre commande / script que vous utilisez pour démarrer / arrêter votre serveur Web / application en particulier)

La réponse de sunny est correcte, mais vous pouvez faire face à des problèmes supplémentaires car l'interface de bouclage n'utilise pas la table PREROUTING,

donc les règles iptables à ajouter sont deux:

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

Avec Linux, vous avez deux autres options:

• Vous pouvez essayer SELinux ( http://www.nsa.gov/selinux/ )
• Vous pouvez essayer grsecurity ( http://www.grsecurity.net/ )

Les deux extensions du noyau Linux permettent d’accorder des droits d’accès sur un niveau de grain très fin. Cela vous permettrait d'accorder à ce processus d'ouvrir le port 80, mais il n'hériterait d'aucun des autres droits root.

D'après ce que j'ai entendu, grsecurity est beaucoup plus simple à utiliser mais SELinux est plus sécurisé.

Une solution consiste à utiliser iptables pour exécuter PAT sur les paquets du port 80. Vous pouvez l’utiliser pour router les paquets vers le port local 8080, par exemple. Assurez-vous de régler les paquets sortants sur le port 80.

D'après mon expérience, les fonctionnalités d'autorisation détaillées de Linux ne sont pas compilées dans les noyaux standard en raison de problèmes de sécurité.

Si vous essayez de faire cela pour qu'une commande exécutée par l'utilisateur puisse utiliser le port 80, vos seules solutions sont alors les astuces iptables ou la définition de l'exécutable setuid-to-root.

La manière dont Apache effectue cette opération (elle se connecte au port 80 mais s'exécute en tant que personne autre que root) consiste à s'exécuter en tant que root, à se lier au port, puis à changer la propriété du processus en utilisateur non privilégié après le port. est installé. Si l'application que vous écrivez peut être exécutée par la racine, vous pouvez lui demander de changer de propriétaire en utilisateur non privé après la configuration des ports. Mais s'il s'agit uniquement d'un utilisateur moyen à exécuter à partir de la ligne de commande, vous devrez utiliser l'une des autres solutions.

Lorsque j'ai plusieurs applications de service Web (scripts python, moteurs tomcat, ...) que je ne souhaite pas exécuter en tant que root, je configure généralement un serveur Web Apache devant elles. Apache écoute le port 80 et Tomcat écoute le 8080.

Dans apache: s config:

ProxyPass /webapp http://localhost:8080/webapp
ProxyPassReverse /webapp http://localhost:8080/webapp

Voir la documentation mod-proxy pour plus d'informations: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

Je pense que la meilleure solution est de sgid votre application et dès que son port est lié, il devrait abandonner les privilèges en passant à un autre utilisateur.

Certains systèmes hôtes ne permettent pas d'utiliser le module NAT, 'iptables' ne résout pas le problème dans ce cas.

Que diriez-vous de xinetd?

Dans mon cas (Ubuntu 10.04)

# apt-get install xinetd
# touch /etc/xinetd.d/my_redirect
# vim /etc/xinetd.d/my_redirect

Collez la configuration:

service my_redirector_80
{
 disable = no
 socket_type = stream
 protocol = tcp
 user = root
 wait = no
 port = 80
 redirect = localhost 8080
 type = UNLISTED
}

Ensuite:

# service xinetd restart

http://docs.codehaus.org/display/JETTY/port80 explique mieux.

Par ailleurs, FreeBSD et Solaris (tout le monde se souvient de ça ?) Vous permettent de le faire (liaison vers des ports bas) sans élévation de privilèges (c'est-à-dire, utiliser des programmes pour passer à la racine). Puisque vous avez spécifié Linux, je publie simplement ceci comme un avis à l'intention des autres utilisateurs susceptibles de trouver cette question.

Nécromancie.

Facile. Avec un noyau normal ou ancien, ce n'est pas le cas.
Comme l'ont souligné d'autres personnes, iptables peut transférer un port.
Comme d'autres l'ont également souligné, CAP_NET_BIND_SERVICE peut également faire le travail.
Bien sûr, CAP_NET_BIND_SERVICE échouera si vous lancez votre programme à partir d'un script. Sauf si vous définissez une limite sur l'interpréteur de shell, ce qui ne sert à rien, vous pourriez aussi bien exécuter votre service en tant que root ...
par exemple pour Java, vous devez l'appliquer à la JVM JAVA

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

Cela signifie évidemment que tout programme Java peut lier des ports système.
Dito pour mono / .NET.

Je suis également convaincu que xinetd n'est pas la meilleure des idées.
Mais puisque les deux méthodes sont des bidouilles, pourquoi ne pas simplement lever la limite en levant la restriction?
Personne n'a dit que vous devez exécuter un noyau normal, vous pouvez donc utiliser le vôtre.

Vous venez de télécharger le code source du dernier noyau (ou du même logiciel que vous avez actuellement). Ensuite, vous allez à:

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

Là vous cherchez cette ligne

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

et le changer en

#define PROT_SOCK 0

si vous ne voulez pas avoir une situation ssh non sécurisée, vous la changez en ceci: #define PROT_SOCK 24

En règle générale, j'utiliserais le paramètre le plus bas dont vous avez besoin, par exemple 79 pour http ou 24 lorsque vous utilisez SMTP sur le port 25.

C'est déjà tout.
Compilez le noyau et installez-le.
Redémarrer.
Terminé - cette limite stupide est GONE, et cela fonctionne également pour les scripts.

Voici comment vous compilez un noyau:

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

En bref, utilisez iptables si vous voulez rester en sécurité, compilez le noyau si vous voulez être sûr que cette restriction ne vous dérange plus.