Ciclo formativo: Administracin de Sistemas Informticos Mdulo: Redes de rea Local Tutorial de netstat

TUTORIAL DE netstat
Extraido y traducido del Security-Quickstart-HOWTO (Autor: Hal Burgiss) Documento original: http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO/index.html

1.- INTRODUCCIN netstat es una herramienta muy til para comprobar el estado actual de la red (qu servicios estn a la escucha de conexiones entrantes, sobre qu interfaces escuchan, quin est conectado a nuestro equipo, a qu equipos estamos conectados nosotros, etctera). Como ejemplo, comprobemos todos los servicios a la escucha y las conexiones activas para TCP y UDP en nuestro equipo bigcat. En este ejemplo, bigcat es un equipo de escritorio de usuario. bigcat tiene dos tarjetas Ethernet: una para la conexin externa al ISP, y otra para una pequea red local con la direccin 192.168.1.1.
$ netstat -tua Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address tcp 0 0 *:printer *:* tcp 0 0 bigcat:8000 *:* tcp 0 0 *:time *:* tcp 0 0 *:x11 *:* tcp 0 0 *:http *:* tcp 0 0 bigcat:domain *:* tcp 0 0 bigcat:domain *:* tcp 0 0 *:ssh *:* tcp 0 0 *:631 *:* tcp 0 0 *:smtp *:* tcp 0 1 dsl-78-199-139.s:1174 64.152.100.93:nntp tcp 0 1 dsl-78-199-139.s:1175 64.152.100.93:nntp tcp 0 1 dsl-78-199-139.s:1173 64.152.100.93:nntp tcp 0 0 dsl-78-199-139.s:1172 207.153.203.114:http tcp 1 0 dsl-78-199-139.s:1199 www.xodiax.com:http tcp 0 0 dsl-78-199-139.sd:http 63.236.92.144:34197 tcp 400 0 bigcat:1152 bigcat:8000 tcp 6648 0 bigcat:1162 bigcat:8000 tcp 553 0 bigcat:1164 bigcat:8000 udp 0 0 *:32768 *:* udp 0 0 bigcat:domain *:* udp 0 0 bigcat:domain *:* udp 0 0 *:631 *:*

State LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN SYN_SENT SYN_SENT SYN_SENT ESTABLISHED CLOSE_WAIT TIME_WAIT CLOSE_WAIT CLOSE_WAIT CLOSE_WAIT

Probablemente esta salida sea muy diferente de la que obtengas en tu sistema. Observa la diferencia entre Local Address y Foreign Address, y cmo cada una incluye su correspondiente nmero de puerto (o nombre de servicio, si est disponible) despus de los dos puntos :. La direccin local es nuestro extremo de la conexin. El primer grupo con la palabra LISTEN en la ltima columna son servicios que estn corriendo en este sistema. Son servicios que se estn ejecutando en segundo plano en bigcat, y escuchan posibles conexiones entrantes. As, estos servicios tienen un puerto abierto, que es por donde escuchan. Estas conexiones pueden provenir del sistema local (por ejemplo, el propio bigcat) o desde sistemas remotos. Y sta es una informacin muy importante !

--1--

Ciclo formativo: Administracin de Sistemas Informticos Mdulo: Redes de rea Local Tutorial de netstat

Las lneas de debajo son conexiones que han sido establecidas desde este sistema a otros sistemas. Las conexiones pueden estar en varios estados, tal y como indica la palabra de la ltima columna. Aquellas en las que esta columna est vaca son servicios que responden a conexiones UDP. UDP es un protocolo diferente de TCP que se utiliza para conexiones de trfico de red con baja prioridad. Ahora ejecutaremos el mismo comando pero con la opcin -n para suprimir la conversin de nombres y poder ver los nmeros de puerto:
$ netstat -taun Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address tcp 0 0 0.0.0.0:515 0.0.0.0:* tcp 0 0 127.0.0.1:8000 0.0.0.0:* tcp 0 0 0.0.0.0:37 0.0.0.0:* tcp 0 0 0.0.0.0:6000 0.0.0.0:* tcp 0 0 0.0.0.0:80 0.0.0.0:* tcp 0 0 192.168.1.1:53 0.0.0.0:* tcp 0 0 127.0.0.1:53 0.0.0.0:* tcp 0 0 0.0.0.0:22 0.0.0.0:* tcp 0 0 0.0.0.0:631 0.0.0.0:* tcp 0 0 0.0.0.0:25 0.0.0.0:* tcp 0 1 169.254.179.139:1174 64.152.100.93:119 tcp 0 1 169.254.179.139:1175 64.152.100.93:119 tcp 0 1 169.254.179.139:1173 64.152.100.93:119 tcp 0 0 169.254.179.139:1172 207.153.203.114:80 tcp 1 0 169.254.179.139:1199 216.26.129.136:80 tcp 0 0 169.254.179.139:80 63.236.92.144:34197 tcp 400 0 127.0.0.1:1152 127.0.0.1:8000 tcp 6648 0 127.0.0.1:1162 127.0.0.1:8000 tcp 553 0 127.0.0.1:1164 127.0.0.1:8000 udp 0 0 0.0.0.0:32768 0.0.0.0:* udp 0 0 192.168.1.1:53 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:*

State LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN SYN_SENT SYN_SENT SYN_SENT ESTABLISHED CLOSE_WAIT TIME_WAIT CLOSE_WAIT CLOSE_WAIT CLOSE_WAIT

Echemos un vistazo a las primeras lneas. Primera lnea:

tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN

En la primera lnea, la direccin local es 0.0.0.0, lo que significa que todas las interfaces estn disponibles. El puerto local es el 515, o el puerto servidor de impresin estndar, normalmente propiedad del demonio lpd. Podemos ver una lista de los nombres de servicio ms comunes y sus nmeros de puerto asociados en el fichero /etc/services. El hecho de que est escuchando en todas las interfaces es significativo. En este caso podramos hablar de tres interfaces: lo (localhost), eth0 y eth1. As pues, se podra establecer una conexin con la impresora sobre cualquiera de estas interfaces. Si un usuario puede levantar una conexin PPP en nuestro sistema, el demonio de impresin estar escuchando tambin sobre esa interfaz (la ppp0). La direccin remota es tambin 0.0.0.0, lo que significa desde cualquier parte.

--2--

Ciclo formativo: Administracin de Sistemas Informticos Mdulo: Redes de rea Local Tutorial de netstat

Conviene adems apuntar aqu que incluso si este servidor est dicindole al kernel que escuche en todas las interfaces, la salida de netstat no refleja que pudiera haber un cortafuegos que filtrara las conexiones entrantes. Es algo que, por el momento, no podemos asegurar. Obviamente, para ciertos servidores, sta sera una muy deseable opcin. Nadie de fuera de nuestra red local tiene por qu conectarse a nuestro puerto servidor de impresin, por ejemplo. La segunda lnea es un poco distinta:
tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN

Obsrvese que esta vez la Local Address es la direccin del localhost 127.0.0.1. Esto es muy significativo, ya que slo las conexiones locales a esta mquina seran aceptadas. As que slo bigcat puede conectarse al puerto TCP 8000 de bigcat. Las implicaciones de seguridad son obvias. No todos los servidores tienen opciones de configuracin para permitir este tipo de restriccin, pero es una caracterstica muy til para aquellos que lo tienen. El puerto 8000 en este ejemplo es propiedad del proxy web Junkbuster. Con las tres siguientes lneas, volvemos a escuchar sobre todas las interfaces disponibles:
tcp tcp tcp 0 0 0 0 0.0.0.0:37 0 0.0.0.0:6000 0 0.0.0.0:80 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* LISTEN LISTEN LISTEN

Mirando a /etc/services, podemos decir que el puerto 37 es un servidor de tiempo. El puerto 6000 corresponde a X11 y el 80 es el estndar para los servidores HTTP como Apache. No hay nada extrao aqu ya que estos son servicios normalmente disponibles en Linux. Los dos primeros nos son del tipo de servicios a los que te gustara que alguien se conectase. Por eso, deberan ponerse detras de un cortafuegos para que todas las conexiones externas fueran rechazadas. De nuevo, mirando la salida no podemos decir si existe algn cortafuegos, y mucho menos si ha sido correctamente implementado. El servidor web en el puerto 80 no supone un gran riesgo de seguridad por s mismo. HTTP es un protocolo que suele estar abierto para todos los visitantes. Por ejemplo, si queremos alojar nuestra propia pgina web, Apache puede hacerlo por nosotros. Adems, es posible filtrarlo por cortafuegos para que puedan usarlo solamente nuestros clientes LAN como parte de una Intranet. Tambin es obvio que si no tienes una buena razn para ejecutar un servidor web, entonces lo mejor ser que lo deshabilites por completo. Las dos lneas siguientes son interesantes:
tcp tcp 0 0 0 192.168.1.1:53 0 127.0.0.1:53 0.0.0.0:* 0.0.0.0:* LISTEN LISTEN

Ntese de nuevo que la Local Address no es la 0.0.0.0. Eso est bien! El puerto esta vez es el 53, o el puerto DNS utilizado por los demonios servidores de nombres como named. Pero vemos que el demonio servidor de nombres est escuchando solamente por la interfaz lo y por la interfaz que conecta a bigcat con la red local. As pues, el kernel slo permite conexiones del localhost y de la red local. El puerto 53 no estar disponible para las conexiones externas. Este es un buen ejemplo de cmo puede configurarse, en ocasiones, la seguridad para aplicaciones individuales. En este caso, estamos probablemente utilizando un servidor DNS de cach, ya que el servidor de nombres
--3--

Ciclo formativo: Administracin de Sistemas Informticos Mdulo: Redes de rea Local Tutorial de netstat

verdadero, que es responsable de la gestin de las consultas DNS, debera tener abierto el puerto 53 a todo el mundo. Entonces ya estaramos hablando de un riesgo de seguridad que requiere una gestin especial. Las ltimas tres entradas:
tcp tcp tcp 0 0 0 0 0.0.0.0:22 0 0.0.0.0:631 0 0.0.0.0:25 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* LISTEN LISTEN LISTEN

Estas de nuevo escuchan en todas las interfaces disponibles. El puerto 22 es de sshd, el demonio servidor de Secure Shell. Eso es una buena seal! Obsrvese que el servicio para el puerto 631 no tiene un nombre de servicio si miramos la salida del primer ejemplo. Esto nos da una pista de que algo raro esta pasando aqu. (Mirar la siguiente seccin para resonder este enigma). Y por ltimo, el puerto 25, el puerto estndar para el demonio de correo SMTP. La mayora de instalaciones Linux probablemente tendrn un demonio SMTP corriendo, as que no es algo tan raro. Pero, es necesario? El siguiente grupo son las conexiones establecidas. Para nuestros propsitos, el estado de la conexin indicado en la ltima columna no es tan importante. Eso ya est bien explicado en la pgina del manual.
tcp tcp tcp tcp tcp tcp tcp tcp tcp 0 0 0 0 1 0 400 6648 553 1 1 1 0 0 0 0 0 0 169.254.179.139:1174 169.254.179.139:1175 169.254.179.139:1173 169.254.179.139:1172 169.254.179.139:1199 169.254.179.139:80 127.0.0.1:1152 127.0.0.1:1162 127.0.0.1:1164 64.152.100.93:119 64.152.100.93:119 64.152.100.93:119 207.153.203.114:80 216.26.129.136:80 63.236.92.144:34197 127.0.0.1:8000 127.0.0.1:8000 127.0.0.1:8000 SYN_SENT SYN_SENT SYN_SENT ESTABLISHED CLOSE_WAIT TIME_WAIT CLOSE_WAIT CLOSE_WAIT CLOSE_WAIT

Aqu tenemos nueve conexiones en total. Las tres primeras corresponden a nuestra interfaz externa conectndose a un puerto remoto en su puerto 119, el puerto estndar de las news (NNTP). Aqu vemos tres conexiones con el mismo servidor de news. Aparentemente la aplicacin es multi-hebra, ya que est intentando abrir mltiples conexiones con el servidor. Las dos entradas siguientes corresponden a conexiones a un servidor web remoto, como indica el puerto 80 de la quinta columna. Probablementeuna entrada muy comn para la mayora de nosotros. Pero la lnea siguiente est invertida y tiene el puerto 80 en la cuarta columna, lo que quiere decir que alguien se ha conectado al servidor web de bigcat via su interfaz externa, la cara que da a Internet. Las tres ltimas entradas son todas conexiones del localhost al localhost. O sea, que aqu nos estamos conectando a nosotros mismos. Si recordamos que el puerto 8000 es el proxy web de bigcat, podemos decir que tenemos un navegador conectado localmente al proxy. El proxy abrir despus una conexin externa consigo mismo, que es probablemente lo que esta sucediendo con las lneas cuatro y cinco.

--4--

Ciclo formativo: Administracin de Sistemas Informticos Mdulo: Redes de rea Local Tutorial de netstat

Puesto que indicamos las opciones -t y -u en el comando netstat, hemos obtenido las conexiones TCP y UDP. Las ltimas lneas son las correspondientes a UDP:
udp udp udp udp 0 0 0 0 0 0 0 0 0.0.0.0:32768 192.168.1.1:53 127.0.0.1:53 0.0.0.0:631 0.0.0.0:* 0.0.0.0:* 0.0.0.0:* 0.0.0.0:*

Las tres ltimas entradas tienen puertos que nos resultan familiares por lo dicho anteriormente. Son servidores que estn escuchando para conexiones TCP y UDP. En este caso, los mismos servidores utilizando dos protocolos diferentes. El primero, el puerto 32678 es nuevo, y no tiene un nombre de servicio asociado en /etc/services. As pues, a primera vista podra ser sospechoso y nos podra picar la curiosidad. Vase la explicacin de la seccin siguiente. Podemos extraer alguna conclusin de esta situacin hipottica? Para la mayora, estos servicios y conexiones parecen bastantes normales en Linux. No parece haber un nmero excesivo de servicios corriendo, pero eso no significa mucho porque no sabemos si todos esos servicios son realmente necesarios o no. Sabemos que netstat no puede decirnos si alguno de esos servicios est eficazmente filtrado por un cortafuegos, as que no hay modo de conocer hasta donde llega nuestra seguridad. Adems no sabemos realmente si todos los servicios a la escucha son verdaderamente necesarios. Esto es algo que vara bastante de una instalacin a otra. Por ejemplo, tiene bigcat una impresora conectada? Aparentemente s, o sino estara corriendo un riesgo completamente innecesario. 2.- PROPIETARIOS DE PUERTOS Y PROCESOS En la seccin anterior, hemos aprendido mucho de lo que est pasando en las tareas de red de bigcat. Pero supongamos que vemos algo que no somos capaces de reconocer y queremos saber quin arranc ese servicio en particular. O que queremos detener un servicio en particular y, solo mirando la salida del netstat, no tenemos claro cul es. La opcin -p nos da el PID del proceso y el nombre del programa que arranc el proceso en la ltima columna. Echemos un vistazo a los servicios TCP de nuevo (para ganar espacio, se han suprimido las tres primeras columnas). Tendremos que ejecutar el comando como root para obtener toda la informacin disponible:
# netstat -tap Active Internet connections (servers and established) Local Address Foreign Address State *:printer *:* LISTEN bigcat:8000 *:* LISTEN *:time *:* LISTEN *:x11 *:* LISTEN *:http *:* LISTEN bigcat:domain *:* LISTEN bigcat:domain *:* LISTEN *:ssh *:* LISTEN *:631 *:* LISTEN *:smtp *:* LISTEN

PID/Program name 988/inetd 1064/junkbuster 988/inetd 1462/X 1078/httpd 956/named 956/named 972/sshd 1315/cupsd 1051/master

--5--

Ciclo formativo: Administracin de Sistemas Informticos Mdulo: Redes de rea Local Tutorial de netstat

Sobre esto, ya conocemos algo. Pero vemos ahora que el demonio de la impresora, en el puerto 515, est siendo iniciado via inetd con un PID de 988. inetd es una situacin especial. A inetd se le conoce como el super servidor, debido a que es su funcin principal es crear sub-servicios. Si miramos la primera lnea, inetd est escuchando en el puerto 515 para servicios de impresora. Si una conexin viene para este puerto, inetd la intercepta y luego genera el demonio apropiado, como el demonio de impresora en este caso. La configuracin que indica a inetd cmo manejar todo esto suele estar en /etc/inetd.conf. As es que si queremos detener un servicio controlado por inetd, entonces deberemos escarbar en la configuracin de inetd (o quiz la de xinetd). Adems, el servicio time tambin ha sido iniciado via inetd. Eso nos dice que estos dos servicios pueden ser protegidos tambin por tcpwrappers, lo que supone uno de los beneficios de utilizar inetd para controlar ciertos servicios de sistema.
tcpwrapper: una aplicacin para seguridad en Internet que permite a los usuarios desactivar ciertos programas que exponen a los sistemas ante trfico poco seguro de Internet, adems de realizar pruebas para verificar los cambios. El tcpwrapper (tcpd) viene ya incluido en algunas distribuciones de Linux.

No estbamos seguros del servicio que utilizaba el puerto 631 porque no tenamos un nombre de servicio estndar, lo que quiere decir que posiblemente hay algo que no es normal o que est fuera de lugar. Ahora vemos que pertenece a cupsd, que es uno de los diferentes demonios de impresin disponibles en Linux. Este parece ser la interfaz web para controlar el servicio de impresora. El demonio cupsd es, de hecho, un poco diferente de otros servicios de impresin. La ltima entrada pertenece al servidor de correo SMTP de bigcat. En muchas distribuciones, ste suele ser sendmail. Pero no es el caso. El comando es master, que a lo mejor no nos suena de nada. Como tenemos el nombre del programa, podramos buscar en el sistema de ficheros utilizando herramientas como los comandos locate o find. Una vez encontrado, podramos averiguar a qu paquete pertenece. Pero con el PID disponible, podemos observar la salida de ps y ver si nos puede servir de ayuda:
$ /bin/ps ax |grep 1051 |grep -v grep 1051 ? S 0:24 /usr/libexec/postfix/master

Aqu hemos tomado un atajo combinando ps con grep. Parece que el fichero pertenece a postfix, que es, efectivamente, un paquete servidor de correo similar a sendmail.

--6--

Ciclo formativo: Administracin de Sistemas Informticos Mdulo: Redes de rea Local Tutorial de netstat

Ejecutar ps con la opcin --forest (o la opcin corta -f ) nos puede ayudar a determinar qu procesos son padres o hijos de otro proceso. He aqu un ejemplo:
$ /bin/ps -axf 956 ? S 957 ? S 958 ? S 959 ? S 960 ? S 961 ? S 1051 ? S 1703 ? S 1704 ? S 1955 ? S 1863 ? S 2043 ? S 2049 ? S 2062 ? S

0:00 named -u named 0:00 \_ named -u named 0:46 \_ named -u named 0:47 \_ named -u named 0:00 \_ named -u named 0:11 \_ named -u named 0:30 /usr/libexec/postfix/master 0:00 \_ tlsmgr -l -t fifo -u -c 0:00 \_ qmgr -l -t fifo -u -c 0:00 \_ pickup -l -t fifo -c 0:00 \_ trivial-rewrite -n rewrite -t unix -u -c 0:00 \_ cleanup -t unix -u -c 0:00 \_ local -t unix 0:00 \_ smtpd -n smtp -t inet -u -c

Aqu tenemos un par de cosas que resear. Ahora tenemos dos demonios conocidos: named y postfix (smtpd). Ambos son sub-procesos generadores. En el caso de named, lo que vemos son hebras, varios sub-procesos que siempre generan. Postfix tambin est generando sub-procesos, bero no como hebras. Cada subproceso posee su propia tarea especfica. Vale la pena hacer notar que los procesos hijos dependen de sus procesos padre. Entonces, matando el PID padre, mataremos todos los procesos hijos. Si todo esto no ha arrojado mucha luz, podemos intentarlo con el comando locate:
$ locate /master /etc/postfix/master.cf /var/spool/postfix/pid/master.pid /usr/libexec/postfix/master /usr/share/vim/syntax/master.vim /usr/share/vim/vim60z/syntax/master.vim /usr/share/doc/postfix-20010202/html/master.8.html /usr/share/doc/postfix-20010202/master.cf /usr/share/man/man8/master.8.gz

find es, posiblemente, la utilidad de bsqueda de ficheros ms flexible, pero no utiliza una base de datos como lo hace locate, as que es mucho ms lento:
$ find / -name master /usr/libexec/postfix/master

Si lsof est instalado, es otro comando til para encontrar quin es propietario de los procesos o los puertos:
# lsof -i :631 COMMAND PID USER cupsd 1315 root FD 0u TYPE DEVICE SIZE NODE NAME IPv4 3734 TCP *:631 (LISTEN)

--7--

Ciclo formativo: Administracin de Sistemas Informticos Mdulo: Redes de rea Local Tutorial de netstat

Esto nos dice otra vez que el demonio de impresin cupsd es propietario del puerto 631, slo que hemos utilizado otro modo de averiguarlo. Y todava existe otra forma de hacerlo con fuser, que debera estar instalado:
# fuser -v -n tcp 631 631/tcp USER root PID 1315 ACCESS f.... COMMAND cupsd

Ver las pginas de manual para la sintaxis de los comandos fuser y lsof. Otro sitio donde para buscar dnde ha sido iniciado un servicio es en el directorio init.d, en el cual residen los scripts init (en sistemas Sys Vinit). Algo como ls -l /etc/init.d nos podra mostrar una lista de ellos. Generalmente, el propio nombre del script nos da una pista de qu servicio(s) inicia, aunque no tiene por qu coincidir exactamente con el Nombre de Programa proporcionado por netstat. O podemos utilizar grep para buscar dentro de los ficheros mediante un patrn de bsqueda. Necesitamos encontrar dnde se est iniciando rpc.statd y no vemos un script con ese nombre?
# grep rpc.statd /etc/init.d/* /etc/init.d/nfslock: [ -x /sbin/rpc.statd ] || exit 0 /etc/init.d/nfslock: daemon rpc.statd /etc/init.d/nfslock: killproc rpc.statd /etc/init.d/nfslock: status rpc.statd /etc/init.d/nfslock: /sbin/pidof rpc.statd >/dev/null 2>&1; STATD="$?"

En realidad, no necesitbamos toda esa informacin, pero al menos ahora vemos exactamente qu script lo est iniciando. Recordemos tambin que no todos los servicios se inician de esta manera. Algunos pueden ser iniciados mediante inetd, o xinetd. El sistema de ficheros /proc guarda, adems, todo lo que queremos saber sobre los procesos que se estn ejecutando. Podemos preguntrselo para obtener ms informacin de cada proceso. Necesitas saber la ruta absoluta del comando que inici un proceso?
# ls -l /proc/1315/exe lrwxrwxrwx 1 root root 0 July 4 19:41 /proc/1315/exe -> /usr/sbin/cupsd

Para finalizar, tenermos una o dos cabos sueltos en los servicios UDP a la escucha. Recordemos que tenemos un extrao nmero de puerto, el 32768, que adems no tiene un nombre de servicio asociado:
# netstat -aup Active Internet connections (servers and established) Local Address Foreign Address State *:32768 *:* bigcat:domain *:* bigcat:domain *:* *:631 *:*

PID/Program name 956/named 956/named 956/named 1315/cupsd

Ahora, incluyendo el PID/Nombre de Programa con la opcin -p, vemos que ste pertenece a named, el demonio servidor de nombres. Versiones recientes de BIND utilizan un puerto sin privilegios para cierto tipo de trfico. En este caso, es la versin BIND 9.x. O sea, que no tenemos por qu preocuparnos. Aqu, el puerto sin privilegios es
--8--

Ciclo formativo: Administracin de Sistemas Informticos Mdulo: Redes de rea Local Tutorial de netstat

el que named utiliza para hablar con otros servidores de nombres para bsquedas de nombres y direcciones, y no debera estar filtrado por cortafuegos. Por tanto, no encontramos grandes sorpresas en esta situacin hipottica. Si todo esto falla, y no puedes encontrar el propietario de un proceso para un puerto abierto, piensa que puede ser un servicio RPC (Remote Procedure Call) de algn tipo. Estos usan puertos asignados aleatoriamente sin ningn significado lgico ni coherencia, y son normalmente controlados por el demonio portmap. En algunos casos, pueden no revelar el proceso propietario mediante netstat o lsof. Podemos intentar detener portmap, y luego mirar si el misterioso servicio ha desaparecido. O podemos utilizar rpcinfo -p localhost para ver cules servicios RPC estn corriendo (portmap debe estar ejecutndose para que esto funcione). NOTA Si sospechas que alguien entr en tu sistema, no confes en la salida de netstat ni en la de ps. Es muy posible que stos, y otros componentes del sistema, hayan sido forzados de modo que su salida no es fiable.

FIN

--9--