R-services

Los R-services pertenecen a una etapa en la que una red de hosts Unix administrados en común podía tratar el origen como parte de la identidad. rlogin abría sesiones, rsh ejecutaba órdenes y servicios como rusers publicaban actividad. La autenticación podía descansar en un hostname resuelto, un puerto de origen reservado y una entrada en hosts.equiv o .rhosts.

Ese modelo importa hoy precisamente porque sus supuestos ya no son una frontera fiable. DNS puede cambiar, un host confiado puede quedar comprometido y el contenido viaja sin un canal criptográfico moderno. Enumerar estos servicios consiste en reconstruir la relación completa entre origen, nombre, usuario y archivo de confianza. El puerto abierto solo indica dónde empezar a preguntar.

Los ejemplos usan TARGET_IP, TRUSTED_HOST, USERNAME y COMMAND como placeholders.

Nmap identifica listeners en 512, 513 y 514 TCP. rpcinfo localiza rusers cuando se publica mediante ONC RPC. Los clientes rlogin, rsh, rexec, rwho y rusers son la validación del protocolo. Su disponibilidad y opciones cambian entre paquetes, por lo que hay que conservar versión y ayuda local.

Netcat puede recoger un banner, pero no construye el intercambio completo de autenticación de estos servicios. Usa el cliente nativo para la conclusión.

Los puertos solo sugieren el servicio. -sV hace que Nmap negocie o compare el banner para confirmar el protocolo:

nmap -sV -p 512,513,514 TARGET_IP

Una respuesta en esos puertos puede pertenecer a otra aplicación o a un wrapper que aplique controles adicionales. Conserva producto, banner y transporte observados.

rusers suele publicarse mediante ONC RPC. rpcinfo -p permite encontrar su número de programa, versión, transporte y puerto antes de usar el cliente:

rpcinfo -p TARGET_IP

/etc/hosts.equiv define relaciones de confianza globales. ~/.rhosts las define para una cuenta. Una línea puede combinar hostname y usuario remoto:

TRUSTED_HOST USERNAME

Según la implementación, omitir el usuario puede implicar el mismo nombre de cuenta en ambos sistemas. Entradas con +, netgroups o reglas amplias cambian el conjunto de orígenes aceptados y deben interpretarse dentro de la sintaxis concreta del host.

Las implementaciones clásicas validan que la resolución inversa de la IP de origen produzca un nombre y que su resolución directa vuelva a la misma IP. También pueden exigir que el cliente use un puerto de origen inferior a 1024. Esa condición presupone que solo root puede abrirlo, algo que pierde valor si otro sistema controlado puede emitir tráfico con ese origen o si la red acepta spoofing.

El hostname inicia la hipótesis. Para cerrarla hay que confirmar qué daemon escucha, qué dirección observa, cómo resuelve ese origen, con qué cuenta evalúa la petición y qué archivo de confianza consulta.

rusers -al solicita información ampliada de las sesiones que el servicio decide publicar:

rusers -al TARGET_IP

El output puede incluir usuario, terminal, origen y tiempo de inactividad. Describe sesiones anunciadas, no credenciales, y puede estar desactualizado si los datos proceden de difusiones o caché.

rwho obtiene información de hosts que ejecutan rwhod. Su utilidad depende de que los datagramas lleguen al segmento desde el que se consulta. Un resultado vacío no descarta sesiones en el host.

Los clientes rlogin y rsh varían entre sistemas y pueden no estar instalados. Consulta primero su ayuda local. En una implementación clásica, -l USERNAME selecciona el usuario remoto:

rlogin -l USERNAME TARGET_IP

rsh -l USERNAME TARGET_IP id

rexec no usa .rhosts como rsh. Envía usuario, contraseña y comando al servicio. -l selecciona el usuario y, si el cliente lo admite, la contraseña se solicita sin incluirla en los argumentos:

rexec -l USERNAME TARGET_IP COMMAND

Estos protocolos no protegen el contenido con cifrado moderno. En la red quedan expuestos datos de sesión, comandos y, en rexec, credenciales. El tráfico y el resultado también quedan ligados a la identidad, al origen y a la resolución de nombres observada por el servidor. Registra esos elementos junto a la respuesta. Un acceso correcto no prueba que otra cuenta herede la misma confianza.

Además de hosts.equiv y .rhosts, revisa el daemon real, su unidad de servicio o configuración inetd/xinetd, wrappers TCP, PAM y resolución DNS. Los permisos laxos sobre .rhosts pueden hacer que una implementación ignore el archivo. Otros servidores lo aceptarán y ampliarán la confianza de la cuenta.

Una entrada + puede confiar en cualquier host o usuario según su posición. Un netgroup amplía la regla a los miembros que devuelva NIS. La exposición efectiva exige combinar esa regla con el usuario solicitado, el hostname que el servidor atribuye al origen, el puerto de origen y cualquier control de PAM o TCP Wrappers. Comprueba esas capas antes de resumir la relación como “trusted host”.

El script NSE rusers consulta el servicio de usuarios. Para rlogin, rsh y rexec, los clientes nativos o implementaciones compatibles permiten observar el fallo exacto. No trates una respuesta de 512/tcp, 513/tcp o 514/tcp como prueba de que todos los R-services están habilitados.

El trust puede depender de nombre canónico, forward y reverse DNS, usuario remoto, usuario local, archivo global, .rhosts, permisos del archivo y puerto de origen reservado. Una entrada HOST USER solo adquiere significado al reconstruir qué daemon consulta ese archivo y qué identidad intenta establecer. El acceso por rexec usa usuario y contraseña y no comparte exactamente la semántica de rsh/rlogin.

Un rechazo puede provenir de resolución inconsistente, archivo inseguro que el daemon ignora, usuario local ausente, PAM, TCP wrappers, source port o trust no coincidente. Repite una variable y conserva stderr del cliente y logs del servidor cuando existan.

Si el trust concede ejecución, valida primero identidad y directorio con una orden sin estado como id. No escribas .rhosts ni hosts.equiv durante enumeración. Una relación amplia puede permitir movimiento lateral o suplantación desde un host confiado comprometido. Documenta ambos extremos y la condición exacta, no solo «rsh abierto».

Los daemons, inetd/xinetd, auth logs y red pueden registrar conexión, usuario y comando. Cierra procesos, elimina archivos transferidos por la prueba y deja constancia de que no se modificó el trust.

La selección de clientes y comprobaciones se encuentra en herramientas y automatización. La checklist controla origen, resolución e identidad. La cheatsheet reúne la sintaxis ya contextualizada.

• Linux man-pages: ruserok(3)
• Linux man-pages: hosts.equiv(5)
• Oracle Solaris: rlogin(1)