En sistemas Unix, se deniega el enlace al puerto tcp < 1024 desde un proceso sin privilegios de root.
¿Cuál fue la razón inicial y sigue siendo válida?
Por ejemplo, el servidor http no necesita privilegios de root para servir la página html.
¿Qué proceso/protocolo necesita un usuario de Unix para asegurarse de que se ejecuta con privilegios de root?
Gracias
Respuesta1
Se supone que ese rango de puertos no está definido por el programador.
Esreservado por la IANA,
Los puertos conocidos son los del 0 al 1023.
Los puertos DCCP conocidos NO DEBEN usarse sin el registro de la IANA. El procedimiento de registro se define en [RFC4340], Sección 19.9.
Para opiniones diferentes, consulte,
A partir de unahilo de preguntas de linux(lea en el enlace para obtener más contexto)
El límite del puerto 1024 en realidad se muerde en la cola. Obliga a una práctica demoníaca que podría abrir agujeros de seguridad que hagan que el límite sea ineficaz como medida de seguridad.
- ElLas 20 principales vulnerabilidades de SANSnotas
Varios de los servicios centrales del sistema proporcionan interfaces remotas a los componentes del cliente a través de llamadas a procedimientos remotos (RPC). En su mayoría, están expuestos a través de puntos finales de canalización con nombre accesibles a través del protocolo CIFS (Common Internet File System), puertos TCP/UDP bien conocidos y, en ciertos casos, puertos TCP/UDP efímeros. Históricamente, ha habido muchas vulnerabilidades en los servicios que pueden ser explotadas por usuarios anónimos. Cuando se explotan, estas vulnerabilidades otorgan al atacante los mismos privilegios que tenía el servicio en el host.
- ElLas 20 principales vulnerabilidades de SANSnotas
Hoy en día, protocolos comoBitTorrentySkypese han movido a través de puertos efímeros al espacio no reservado y no se molestan en acceder a la raíz. El objetivo esno sólo pasar por alto esta antigua seguridad de puerto reservado; Los protocolos actuales quierenevita incluso el perímetro de la red(Skype es un buen ejemplo de ello). Las cosas irán más allá a medida que aumenten el ancho de banda y la disponibilidad de la red, cuando probablemente todos los usuarios de computadorasejecutar un servidor web por sí mismos-- ytal vez,sin saberlo, serparte de un red de robots.
Necesitamos la seguridad que desean estos viejos métodos,
pero ahora será necesario lograrla con métodos más nuevos.
Respuesta2
Bueno, el pensamiento original, según recuerdo de los días de BSD Unix, era que se esperaba que los puertos <1024 estuvieran reservados para "servicios bien conocidos", y la suposición seguía siendo que los servidores serían relativamente raros y que las personas con privilegios de root serían se presume que es "confiable" de alguna manera. Por lo tanto, debía tener el privilegio de vincular un socket para escuchar en un puerto que representaría un servicio de red al que accederían otros usuarios.
Los puertos 1024-4999 estaban pensados para usarse como puertos "efímeros" que representarían el lado del cliente de una conexión TCP. Los puertos 5000+ estaban destinados a servidores no raíz.
Obviamente, todas esas suposiciones desaparecieron con bastante rapidez. Consulte la lista de reserva de números de puerto TCP de la IANA para ver qué tan alto han llegado las cosas.
Una solución a este problema fue la idea del mapeador de puertos RPC. En lugar de reservar un puerto TCP para cada servicio, el servicio se iniciaría en un puerto aleatorio y le indicaría al demonio portmapper dónde estaba escuchando. Los clientes preguntarían al mapeador de puertos "¿dónde está escuchando el servicio X" y procederían desde allí? No recuerdo qué mecanismos de seguridad existían para proteger los servicios RPC conocidos de la suplantación.
No estoy seguro de que hoy en día haya una buena razón para todo esto, pero como en la mayoría del mundo *nix, las cosas tienden a acumularse en lugar de reinventarse por completo.
¿Alguien leyó a Vernor Vinge? Lo recuerdo escribiendo en una de sus novelas sobre un sistema informático en un futuro lejano que incorporaba capas y capas de código del pasado antiguo, con el tiempo todavía representado por el número de segundos transcurridos desde alguna fecha antigua (1/1/1970). para ser exacto). Probablemente no esté muy lejos.
Respuesta3
En los viejos tiempos, los usuarios habituales solían iniciar sesión en máquinas Unix. Por lo tanto, no querrás que un usuario promedio configure un servicio ftp falso o algo así.
Hoy en día, el uso típico es que solo el administrador y algunas otras personas de confianza inician sesión en un servidor, por lo que si el modelo se rehizo hoy, la restricción <1024 podría no estar presente.
Respuesta4
Tiene sentido que los servicios que aceptan contraseñas del sistema se ejecuten en puertos privilegiados; esto significa que los usuarios con cuentas shell no pueden configurar servicios "falsos" en el mismo puerto para capturar los detalles de inicio de sesión de las personas, ni negar el acceso configurando servicios no funcionales en los mismos puertos.
Si tenía una casilla multiusuario y un usuario sin privilegios pudo configurar un demonio ssh fraudulento, es posible que pueda capturar las contraseñas de otros usuarios y obtener acceso a sus cuentas (por supuesto, tendría que hacerlo mientras el el demonio ssh legítimo estaba inactivo, tal vez por mantenimiento o durante el inicio o apagado del sistema)
Las cosas que no aceptan contraseñas del sistema no importan mucho, aunque existen importantes problemas de seguridad al compartir cosas como servidores web entre usuarios en una máquina multiusuario (como han descubierto los proveedores de alojamiento compartido).