port privilégiés

Le
Essomba
Bonjour,

juste une question en passant.

Les ports TCP/IP "standards" sont dans la plage du 1 au 1024. Hors ces
ports sont privilégiés. Le corollaire est donc que pour lancer un
serveur, on doit le lancer en root.
N'est-ce pas une faille de sécurité ? On va me dire qu'il y a des
mécanismes de séparation des privilèges. Mais ça augmente la taille du
code est donc par là même le risque de failles.
D'ailleurs pourquoi ces ports sont ils privilégiés ? Pour éviter que
n'importe quel utilisateur transforme une machine commune en serveur web
? Et dans ce cas, pourquoi ne pas avoir un utilisateur spécial qui peut
lancer les démons qui écoutent sur ces ports ? Enfin, peut-on changer
"simplement" ce comportement ?

Merci!

Laurent
--
Remplacez yahou par yahoo et com par fr pour me répondre en direct

Laurent
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bastien Durel
Le #22335661
Le Wed, 07 Jul 2010 10:00:05 +0200, Essomba a écrit :
Enfin, peut-on changer "simplement" ce
comportement ?



Bonjour,

À mon sens, le plus "simple" en cas de défiance vis-à-vis du code
serveur, et d'utiliser un "wrapper" comme tcpserver(1) ou inetd(8) qui
s'occupera d'ouvrir le port et de transférer la connexion. Ou de demander
à iptables via REDIRECT ...
Sinon, il y a le système des "capabilities(7)" : voir
CAP_NET_BIND_SERVICE, mais je ne sais trop comment ça marche.

--
Bastien
Nicolas George
Le #22335691
Essomba wrote in message
D'ailleurs pourquoi ces ports sont ils privilégiés ? Pour éviter que
n'importe quel utilisateur transforme une machine commune en serveur web



Il y a un peu de ça. Imagine quelqu'un (pas root) sur une machine avec plein
d'utilisateurs, qui réserve plein de mémoire et lance plein de connexions
SSH locales. Il y a une chance pas négligeable que sshd finisse par se faire
tuer par l'OOM-killer. Si ça arrive, si le port 22 n'était pas privilégié,
l'attaquant pourrait lancer un faux sshd à son nom et choper les mots de
passe des gens qui essaient de se connecter.
vm666
Le #22336141
Essomba
Les ports TCP/IP "standards" sont dans la plage du 1 au 1024.



Non, pas "standards".

Le corollaire est donc que pour lancer un serveur, on doit le lancer en r oot.
N'est-ce pas une faille de sécurité ?



Pourquoi donc?

D'ailleurs pourquoi ces ports sont ils privilégiés ?



C'est historique. Ça n'a plus de sens depuis que tout le monde a une
station de travail personnelle.

Pour éviter que n'importe quel utilisateur transforme une machine
commune en serveur web ?



Voila.

Et dans ce cas, pourquoi ne pas avoir un utilisateur spécial qui
peut lancer les démons qui écoutent sur ces ports ?



Qu'est-ce que ça changerait? Les daemons qui écoutent sur ces por ts
ont souvent besoin d'autres privilèges. Par exemple, un MTA prend
l'identité des utilisateurs pour aller écrire dans leur boite aux
lettres, un serveur telnet doit lancer un shell sous l'identité
de l'utilisateur. etc

Enfin, peut-on changer "simplement" ce comportement ?



Non. Ou alors, en utilisant les outils de base comme sudo, mais ça ne
change pas vraiment le comportement...

--
Le Vengeur Masqué se vengera!
vm666
Le #22336131
Nicolas George
Si ça arrive, si le port 22 n'était pas privilégié,
l'attaquant pourrait lancer un faux sshd à son nom et choper les mot s de
passe des gens qui essaient de se connecter.



Mauvais exemple car l'attaquant n'aura pas la clé privée du serve ur SSH.

--
Le Vengeur Masqué se vengera!
Nicolas George
Le #22336121
Vengeur Masqué wrote in message
Mauvais exemple car l'attaquant n'aura pas la clé privée du serveur SSH.



Effectivement. Mais le nombre d'utilisateurs qui font attention à ça...
vm666
Le #22336751
Nicolas George
Effectivement. Mais le nombre d'utilisateurs qui font attention à ça...



openssh fait attention pour eux et bloque tout. On peut espérer que
celui qui sera capable de taper "ssh-keygen -R ..." aura une petite
idée de ce qu'il fait.
Les autres clients ssh sont certainement moins paranoïaques.

--
Le Vengeur Masqué se vengera!
Benoit Izac
Le #22337471
Bonjour,

le 07/07/2010 à 10:00, Essomba a écrit dans le message

Les ports TCP/IP "standards" sont dans la plage du 1 au 1024.



0 à 1023 inclus :
--
Benoit Izac
Nicolas George
Le #22337661
Benoit Izac wrote in message
0 à 1023 inclus



Il n'y a pas de port 0.
Luc.Habert.00__arjf
Le #22337791
Essomba :

Les ports TCP/IP "standards" sont dans la plage du 1 au 1024.



En fait, il y a aussi des protocoles assez standard qui utilisent des ports
au-delà. Là, comme ça, je pense à dictd et X11.

Hors



Or

ces ports sont privilégiés. Le corollaire est donc que pour lancer un
serveur, on doit le lancer en root. N'est-ce pas une faille de sécurité ?



Beaucoup de serveurs ont besoin des droits de root (genre ssh). Pour les
autres, si ils sont bien écrits, ils vont faire un setuid vers un user dédié
juste après avoir ouvert leur socket.

On va me dire qu'il y a des mécanismes de séparation des privilèges.



Ça, c'est pour un serveur qui a besoin des droits de root pour fonctionner,
et va se couper en petits morceaux pour ne garder les droits que sur le
minimum de code. Pour un serveur qui n'a pas besoin des droits, c'est juste
faire un setuid après le bind, c'est vraiment pas la mer à boire.

Mais ça augmente la taille du code est donc par là même le risque de
failles.



Bah pas vraiment. Soit le serveur a besoin des droits de root pour autre
chose, et alors, le gain obtenu par la réduction de la taille du code
priviligé compense la perte due à l'augmentation de la complexité, soit,
comme je le disais plus haut, il y a juste à abandonner ses privilèges, ce
qui n'est pas bien complexe.

D'ailleurs pourquoi ces ports sont ils privilégiés ? Pour éviter que
n'importe quel utilisateur transforme une machine commune en serveur web ?



Plutôt pour certifier auprès de l'extérieur qu'on parle bien à un truc
controllé par l'admin de la machine. De nos jours, ça se fait bien plus
fiablement avec de la crypto (les clefs de ssh), mais à l'époque où la
crypto n'était pas répendue/interdite, c'était un moyen low-tech mieux que
rien. Par exemple, le bon vieux rlogind (ancêtre de ssh) permettait les
logins sans mot de passe à condition que le client vienne d'un port < 1024
(le client rlogin était setuid, allouait un port client < 1024, et indiquait
le login de l'utilisateur qui le lançait).

Et dans ce cas, pourquoi ne pas avoir un utilisateur spécial qui peut
lancer les démons qui écoutent sur ces ports ?



Bah tu peux en imaginer plein des utilisateurs spéciaux de ce type, donc
faire à l'arrache un utilisateur spécial juste pour ça, ça ne tient pas la
root. L'idée d'origine d'unix, c'était qu'on les unifiait tous en root, et
qu'on pouvait en déléguer des pouvoirs à des utilisateurs/groupes via des
bits s. Ça parait élégant, mais c'est en pratique assez merdique à mettre en
oeuvre. Depuis, il y a le système des capabalities qui a été inventé pour
ça, mais ça n'a jamais pris. Bref, c'est la mémerde, mais comme ça marche à
peu près, on s'en contente.
Luc.Habert.00__arjf
Le #22337801
X-Censorship:
Reply-To:
Organization:
Subject: Re: port privilégiés
From: (Luc Habert)
Expires:
Followup-To:
Newsgroups: fr.comp.os.linux.configuration

Essomba :

Les ports TCP/IP "standards" sont dans la plage du 1 au 1024.



En fait, il y a aussi des protocoles assez standard qui utilisent des ports
au-delà. Là, comme ça, je pense à dictd et X11.

Hors



Or

ces ports sont privilégiés. Le corollaire est donc que pour lancer un
serveur, on doit le lancer en root. N'est-ce pas une faille de sécurité ?



Beaucoup de serveurs ont besoin des droits de root (genre ssh). Pour les
autres, si ils sont bien écrits, ils vont faire un setuid vers un user dédié
juste après avoir ouvert leur socket.

On va me dire qu'il y a des mécanismes de séparation des privilèges.



Ça, c'est pour un serveur qui a besoin des droits de root pour fonctionner,
et va se couper en petits morceaux pour ne garder les droits que sur le
minimum de code. Pour un serveur qui n'a pas besoin des droits, c'est juste
faire un setuid après le bind, c'est vraiment pas la mer à boire.

Mais ça augmente la taille du code est donc par là même le risque de
failles.



Bah pas vraiment. Soit le serveur a besoin des droits de root pour autre
chose, et alors, le gain obtenu par la réduction de la taille du code
priviligé compense la perte due à l'augmentation de la complexité, soit,
comme je le disais plus haut, il y a juste à abandonner ses privilèges, ce
qui n'est pas bien complexe.

D'ailleurs pourquoi ces ports sont ils privilégiés ? Pour éviter que
n'importe quel utilisateur transforme une machine commune en serveur web ?



Plutôt pour certifier auprès de l'extérieur qu'on parle bien à un truc
controllé par l'admin de la machine. De nos jours, ça se fait bien plus
fiablement avec de la crypto (les clefs de ssh), mais à l'époque où la
crypto n'était pas répendue/interdite, c'était un moyen low-tech mieux que
rien. Par exemple, le bon vieux rlogind (ancêtre de ssh) permettait les
logins sans mot de passe à condition que le client vienne d'un port < 1024
(le client rlogin était setuid, allouait un port client < 1024, et indiquait
le login de l'utilisateur qui le lançait).

Et dans ce cas, pourquoi ne pas avoir un utilisateur spécial qui peut
lancer les démons qui écoutent sur ces ports ?



Bah tu peux en imaginer plein des utilisateurs spéciaux de ce type, donc
faire à l'arrache un utilisateur spécial juste pour ça, ça ne tient pas la
root. L'idée d'origine d'unix, c'était qu'on les unifiait tous en root, et
qu'on pouvait en déléguer des pouvoirs à des utilisateurs/groupes via des
bits s. Ça parait élégant, mais c'est en pratique assez merdique à mettre en
oeuvre. Depuis, il y a le système des capabalities qui a été inventé pour
ça, mais ça n'a jamais pris. Bref, c'est la mémerde, mais comme ça marche à
peu près, on s'en contente.
Publicité
Poster une réponse
Anonyme