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
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
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.
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
Essomba wrote in message <4c343402$0$4556$:
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.
Essomba wrote in message <4c343402$0$4556$426a74cc@news.free.fr>:
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.
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
Essomba writes:
Les ports TCP/IP "standards" sont dans la plage du 1 au 1024.
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.
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.
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
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.
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.
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.
