(En inglés) En linux, tienes que ser root para poder escuchar puertos TCP o UDP por debajo de 1024. El límite de 1024 es una medida de seguridad obsoleta y hoy solo te da una falsa sensación de seguridad y contribuye a que haya agujeros de seguridad (el límite de 1024 te fuerza a ejecutar todos los demonios de red con privilegio de superusuario). Por tanto, este límite debería eliminarse, tan pronto como sea posible.
En mi windows es mucho más fácil, cualquier persona del mundo puede escuchar en mis puertos por debajo de 1024 (y por encima también). Además, para ponérmelo más fácil, recien instalado ya trae varios servicios vulnerables escuchando puertos por defecto.
A lo usuarios de lunix les queda mucho por aprender, lunix todavía no está preparado para el escritorio...
#10:
#0 Porque los puertos por debajo del 1024 son los asignados por la IANA para los servicios estándar de los protocolos de Internet, mientras que los puertos por encima del 1023 son los usados por los clientes para abrir conexión con un servidor. Cualquier usuario sin privilegios te podría secuestrar el servidor web si le permites a cualquiera escuchar en esos puertos.
Y tu noticia está como unos 10 años obsoleta. Desde que se incluyeron las "capabilities" en el kernel, no es necesario que un programa servidor sea root para escuchar en esos puertos, basta con darle esa "capability" específica. Otra cosa es que no se use, así que ya ves tú la demanda que hay, que mucha gente ni siquiera sabe que eso existe.
En mi windows es mucho más fácil, cualquier persona del mundo puede escuchar en mis puertos por debajo de 1024 (y por encima también). Además, para ponérmelo más fácil, recien instalado ya trae varios servicios vulnerables escuchando puertos por defecto.
A lo usuarios de lunix les queda mucho por aprender, lunix todavía no está preparado para el escritorio...
#0 Porque los puertos por debajo del 1024 son los asignados por la IANA para los servicios estándar de los protocolos de Internet, mientras que los puertos por encima del 1023 son los usados por los clientes para abrir conexión con un servidor. Cualquier usuario sin privilegios te podría secuestrar el servidor web si le permites a cualquiera escuchar en esos puertos.
Y tu noticia está como unos 10 años obsoleta. Desde que se incluyeron las "capabilities" en el kernel, no es necesario que un programa servidor sea root para escuchar en esos puertos, basta con darle esa "capability" específica. Otra cosa es que no se use, así que ya ves tú la demanda que hay, que mucha gente ni siquiera sabe que eso existe.
Que conste que hace poco me hice la misma pregunta, y esto es lo que pensé.
Más que por seguridad, debe ser por una cuestión práctica, por hacer una partición [puertos importantes puertos de los demás] Casuística :
1.- PericoDeLosPalotes arranca un servidor en el puerto 80.
2.- root decide que es hora de poner en marcha la web, y no puede por culpa de PericoDeLosPalotes.
______
1.- root arranca un servidor POP3 en el 110.
2.- Anacleto quiere su programa en Java escuchando en el 110, y no entiende por qué tiene que estar ocupado.
No es tan difícil. Si no tienes ningún servicio importante, elige un puerto mayor a 1024.
#9 ¿Y necesita el Señor root ser el que inicie el servidor web? No sé, sería mucho marrón que alguien de fuera le quite su tarjeta de identificación y vaya al almacen de material a llevarse todos los bolis.
Mejor sería que el señor root contratase al becario www-data para que se encargue del servicio web. Así si le roban la tarjeta sólo podrán acceder al aseo y poco más.
Pues esto es así porque para ser UNIX o POSIX o lo que sea se debe cumplir esa condición. Si no le gusta que modifique el kernel para que no se comporte así. Dudo que haya que modificar más de una linea de código.
Como os ha dicho ya #10 y se me olvidó mencionar en #5, todo eso se puede evitar con la "capability" CAP_NET_BIND_SERVICE. No se como funciona ni es algo que se utilice mucho, en parte porque al fin y al cabo, que sea root quien invoque los daemons y estos luego hagan un drop privileges tampoco es nada tan molesto, de ahi que se siga haciendo.
Cualquier sistema Linux por defecto sigue funcionando de la forma tradicional, con los puertos reservados, con su daemon de identd y con demás historias porque hay software que espera ese comportamiento de un sistema UNIX.
Y no #7, me leí el artículo completo en su momento y no dá ningún argumento más que "en java no puedo hacer drop de los privilegios".
Si no te gusta usar esos puertos, usa los otros, o retoca el kernel a tu gusto. Puedes hacer lo que te de la gana, siempre sepas hacerlo claro. Linux permite hacer barbaridades. Cierto, y que. Cual es el problema.
Windows no te permite hacer barbaridades, claro. No te permite hacer casi nada. Son filosofías distintas.
si no le gusta por el tema de los exploits, hay una manera muy sencilla de hacer que los demonios corran en modo usuario desde el principio... lo único que hace falta es un pequeño programa (este sí de root) que redirija todo lo que llega por el socket S1 (< 1024) hacia el socket S2 (>= 1024), donde el demonio está escuchando.
el programa redirector es tan tremendamente sencillo que dudo que pueda tener vulnerabilidades...
#12 y aún así, dejar los privilegios se podría conseguir en Java con JNI, no?
"this does not work if the daemon is written in Java, which is quite popular for web servers [...] If a malicious user can login to a normal unprivileged account, it might be possible to exploit some security hole and gain superuser access. [...] if you allow untrusted users to login to a Linux machine, you should not use that machine for anything else and the daemons running on that machine should not be trusted"
*clonk*
Lo siento, es que me acabo de imaginar un Tomcat escrito en Java, luego un agujero fantasma en un sistema con sólo el ssh instalado sin nada más y... me he caído de la silla
En serio, por mucho que quede por mejorar en el modelo de seguridad de *NIX, hacía tiempo que no leía semejante sarta de chorradas juntas.
De todas maneras el articulo asume con error que un usuario se siente seguro al saber que no se puede ejecutar nada por debajo del puerto 1024. Quien se sienta seguro unicamente con eso, le digo que mejor apága y vamonos...
No creo que sea ningun problema ejecutar demonios como superusuario. Es algo que ocurre en otros sistemas como windows xp, aunque no se llamen demonios, los protocolos de red se ejecutan siempre como administrador.
1.- Tocar capabilities (editado : no hay visto a #12) ?
2.- fork+setid ?
3.- Usar una jaula bsd (y si compromenten al root, será el root de la jaula diferente al root
del sistema).
4.- Virtualizar (y hacer analogía con 3).
5.- Usar cosas como accessfs (para no usar #1).
#10 yo veo puertos por encima del 1024 asignados por la IANA :
el límite de 1024 te fuerza a ejecutar todos los demonios de red con privilegio de superusuario
En efecto, pero una vez hecho, se puede pasa a un usuario sin privilegios, con lo que no es cierto eso de ejecutar todos los demonios de red con privilegio de superusuario.
And this does not work if the daemon is written in Java, which is quite popular for web servers.
Comentarios
Vaya mierda de linux.
En mi windows es mucho más fácil, cualquier persona del mundo puede escuchar en mis puertos por debajo de 1024 (y por encima también). Además, para ponérmelo más fácil, recien instalado ya trae varios servicios vulnerables escuchando puertos por defecto.
A lo usuarios de lunix les queda mucho por aprender, lunix todavía no está preparado para el escritorio...
Como me aburria me he puesto a buscarlo.
Váyase al fichero include/net/sock.h y modifique:
#define PROT_SOCK 1024
a su gusto
La voto errónea. Chuck Norris también puede escuchar esos puertos
#0 Porque los puertos por debajo del 1024 son los asignados por la IANA para los servicios estándar de los protocolos de Internet, mientras que los puertos por encima del 1023 son los usados por los clientes para abrir conexión con un servidor. Cualquier usuario sin privilegios te podría secuestrar el servidor web si le permites a cualquiera escuchar en esos puertos.
Y tu noticia está como unos 10 años obsoleta. Desde que se incluyeron las "capabilities" en el kernel, no es necesario que un programa servidor sea root para escuchar en esos puertos, basta con darle esa "capability" específica. Otra cosa es que no se use, así que ya ves tú la demanda que hay, que mucha gente ni siquiera sabe que eso existe.
Que conste que hace poco me hice la misma pregunta, y esto es lo que pensé.
Más que por seguridad, debe ser por una cuestión práctica, por hacer una partición [puertos importantes puertos de los demás] Casuística :
1.- PericoDeLosPalotes arranca un servidor en el puerto 80.
2.- root decide que es hora de poner en marcha la web, y no puede por culpa de PericoDeLosPalotes.
______
1.- root arranca un servidor POP3 en el 110.
2.- Anacleto quiere su programa en Java escuchando en el 110, y no entiende por qué tiene que estar ocupado.
No es tan difícil. Si no tienes ningún servicio importante, elige un puerto mayor a 1024.
#9 ¿Y necesita el Señor root ser el que inicie el servidor web? No sé, sería mucho marrón que alguien de fuera le quite su tarjeta de identificación y vaya al almacen de material a llevarse todos los bolis.
Mejor sería que el señor root contratase al becario www-data para que se encargue del servicio web. Así si le roban la tarjeta sólo podrán acceder al aseo y poco más.
salu2
Pues esto es así porque para ser UNIX o POSIX o lo que sea se debe cumplir esa condición. Si no le gusta que modifique el kernel para que no se comporte así. Dudo que haya que modificar más de una linea de código.
Como os ha dicho ya #10 y se me olvidó mencionar en #5, todo eso se puede evitar con la "capability" CAP_NET_BIND_SERVICE. No se como funciona ni es algo que se utilice mucho, en parte porque al fin y al cabo, que sea root quien invoque los daemons y estos luego hagan un drop privileges tampoco es nada tan molesto, de ahi que se siga haciendo.
Cualquier sistema Linux por defecto sigue funcionando de la forma tradicional, con los puertos reservados, con su daemon de identd y con demás historias porque hay software que espera ese comportamiento de un sistema UNIX.
Y no #7, me leí el artículo completo en su momento y no dá ningún argumento más que "en java no puedo hacer drop de los privilegios".
#6 Barbaridades o virguerias
#13 el que inicia el proceso es root, pero despues de iniciado, la permisología cambia.
Si no te gusta usar esos puertos, usa los otros, o retoca el kernel a tu gusto. Puedes hacer lo que te de la gana, siempre sepas hacerlo claro. Linux permite hacer barbaridades. Cierto, y que. Cual es el problema.
Windows no te permite hacer barbaridades, claro. No te permite hacer casi nada. Son filosofías distintas.
Visto en http://programming.reddit.com/info/5zli6/comments/
si no le gusta por el tema de los exploits, hay una manera muy sencilla de hacer que los demonios corran en modo usuario desde el principio... lo único que hace falta es un pequeño programa (este sí de root) que redirija todo lo que llega por el socket S1 (< 1024) hacia el socket S2 (>= 1024), donde el demonio está escuchando.
el programa redirector es tan tremendamente sencillo que dudo que pueda tener vulnerabilidades...
#12 y aún así, dejar los privilegios se podría conseguir en Java con JNI, no?
"this does not work if the daemon is written in Java, which is quite popular for web servers [...] If a malicious user can login to a normal unprivileged account, it might be possible to exploit some security hole and gain superuser access. [...] if you allow untrusted users to login to a Linux machine, you should not use that machine for anything else and the daemons running on that machine should not be trusted"
*clonk*
Lo siento, es que me acabo de imaginar un Tomcat escrito en Java, luego un agujero fantasma en un sistema con sólo el ssh instalado sin nada más y... me he caído de la silla
En serio, por mucho que quede por mejorar en el modelo de seguridad de *NIX, hacía tiempo que no leía semejante sarta de chorradas juntas.
De todas maneras el articulo asume con error que un usuario se siente seguro al saber que no se puede ejecutar nada por debajo del puerto 1024. Quien se sienta seguro unicamente con eso, le digo que mejor apága y vamonos...
#17 "programa redirector"
¿Algo así como iptables?... pues va a ser que no hace falta ni programa
No creo que sea ningun problema ejecutar demonios como superusuario. Es algo que ocurre en otros sistemas como windows xp, aunque no se llamen demonios, los protocolos de red se ejecutan siempre como administrador.
1.- Tocar capabilities (editado : no hay visto a #12) ?
2.- fork+setid ?
3.- Usar una jaula bsd (y si compromenten al root, será el root de la jaula diferente al root
del sistema).
4.- Virtualizar (y hacer analogía con 3).
5.- Usar cosas como accessfs (para no usar #1).
#10 yo veo puertos por encima del 1024 asignados por la IANA :
http://www.iana.org/assignments/port-numbers
#4 #6 Ya sé que da pereza leer un artículo en inglés, pero creo que da una razón más fundamentada que la que decís.
el límite de 1024 te fuerza a ejecutar todos los demonios de red con privilegio de superusuario
En efecto, pero una vez hecho, se puede pasa a un usuario sin privilegios, con lo que no es cierto eso de ejecutar todos los demonios de red con privilegio de superusuario.
And this does not work if the daemon is written in Java, which is quite popular for web servers.
Chorradas, pues pon el apache a escuchar en el puerto 1025, que en linux tenemos la suerte de poder modificar nuestros programas.
#23 ¿Non queres karma? Pois dúas cuncas.
#25 pues sí, un NAT ni más ni menos, pero en local...
#26 y después esto: http://ghe.livejournal.com/19070.html
¿Qué? Del título sólo he entendido las preposiciones.
¿Y el 80? Tengo un httpd corriendo sin privilegios en ese puerto... que alguien me explique.
¿a alguien se le ocurre una explicación de por qué me han votado negativo el comentario #17?
He leído: linux bla bla bla bla bla bla bla. Menéalo!
#22 porque te da exactamente igual lo del puerto bla bla bla bla? como a mi?
Y sabes por qué te he votado yo negativo?