Al auditar uno de mis sistemas, encontré un proceso sin nombre escuchando en localhost, puerto 52698.
# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 972/sshd
tcp 0 0 127.0.0.1:52698 0.0.0.0:* LISTEN 13940/0
tcp 0 0 0.0.0.0:5666 0.0.0.0:* LISTEN 1043/nrpe
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1128/mysqld
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 616/rpcbind
tcp6 0 0 :::22 :::* LISTEN 972/sshd
tcp6 0 0 ::1:52698 :::* LISTEN 13940/0
tcp6 0 0 :::443 :::* LISTEN 2354/apache2
tcp6 0 0 :::111 :::* LISTEN 616/rpcbind
tcp6 0 0 :::80 :::* LISTEN 2354/apache2
Al intentar obtener información sobre el proceso en /proc, obtuve esto:
/proc/13940# ls -l exe
lrwxrwxrwx 1 root root 0 May 16 06:25 exe -> /usr/sbin/sshd
/proc/13940# cat cmdline
sshd: ubuntu@pts/0
Parece que el proceso sshd abrió esto por alguna razón. ¿Esto es normal? ¿Por qué sshd abre este puerto de escucha?
Respuesta1
Puede serreenvío de puerto remoto. Alguien usó -Rflag mientras ingresaba a su sistema. Verman ssh:
-R [bind_address:]port:host:hostport
Especifica que el puerto dado en el host remoto (servidor) se reenviará al host y al puerto dados en el lado local. Esto funciona asignando un socket para escucharpuertoen el lado remoto, y cada vez que se realiza una conexión a este puerto, la conexión se reenvía a través del canal seguro y se realiza una conexión aanfitriónpuertoPuerto hostdesde la máquina local.
Nota: funciona con puertos TCP, no con UDP.
Creo que el usuario que creó el túnel también es propietario de /proc/13940. Esa es una pista si necesitas investigarla más a fondo.
Respuesta2
En este caso específico, creo que es el reenvío X11. Debe haberlo habilitado usando los indicadores -X o -Y, o las opciones correspondientes en .ss/config. Intente desactivarlo e iniciar sesión nuevamente, y estoy casi seguro de que desaparecerá.