TUTORIAL DE netstat

Ciclo formativo: Administración de Sistemas Informáticos
Módulo: 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.- INTRODUCCIÓN
netstat es una herramienta muy útil para comprobar el estado actual de la red (qué
servicios están a la escucha de conexiones entrantes, sobre qué interfaces escuchan,
quién está conectado a nuestro equipo, a qué equipos estamos conectados nosotros,
etcétera).
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 conexión externa al
ISP, y otra para una pequeña red local con la dirección 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 cómo cada una incluye su
correspondiente número de puerto (o nombre de servicio, si está disponible) después de
los dos puntos “:”. La dirección local es nuestro extremo de la conexión.
El primer grupo con la palabra LISTEN en la última columna son servicios que están
corriendo en este sistema. Son servicios que se están 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 información
muy importante !
--1--
Ciclo formativo: Administración de Sistemas Informáticos
Módulo: Redes de Área Local
Tutorial de netstat
Las líneas 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á vacía son servicios que
responden a conexiones UDP. UDP es un protocolo diferente de TCP que se utiliza para
conexiones de tráfico de red con baja prioridad.
Ahora ejecutaremos el mismo comando pero con la opción -n para suprimir la conversión
de nombres y poder ver los números 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 líneas.
Primera línea:
tcp
0
0 0.0.0.0:515
0.0.0.0:*
LISTEN
En la primera línea, la dirección local es 0.0.0.0, lo que significa que todas las interfaces
están disponibles. El puerto local es el 515, o el puerto servidor de impresión estándar,
normalmente propiedad del demonio lpd. Podemos ver una lista de los nombres de
servicio más comunes y sus números de puerto asociados en el fichero /etc/services.
El hecho de que esté escuchando en todas las interfaces es significativo. En este caso
podríamos hablar de tres interfaces: lo (localhost), eth0 y eth1. Así pues, se podría
establecer una conexión con la impresora sobre cualquiera de estas interfaces. Si un
usuario puede levantar una conexión PPP en nuestro sistema, el demonio de impresión
estará escuchando también sobre esa interfaz (la ppp0). La dirección remota es también
0.0.0.0, lo que significa “desde cualquier parte”.
--2--
Ciclo formativo: Administración de Sistemas Informáticos
Módulo: Redes de Área Local
Tutorial de netstat
Conviene además apuntar aquí que incluso si este servidor está diciéndole 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 sería una muy deseable
opción. Nadie de fuera de nuestra red local tiene por qué conectarse a nuestro puerto
servidor de impresión, por ejemplo.
La segunda línea es un poco distinta:
tcp
0
0 127.0.0.1:8000
0.0.0.0:*
LISTEN
Obsérvese que esta vez la Local Address es la dirección del localhost 127.0.0.1. Esto es
muy significativo, ya que sólo las conexiones locales a esta máquina seran aceptadas. Así
que sólo bigcat puede conectarse al puerto TCP 8000 de bigcat. Las implicaciones de
seguridad son obvias. No todos los servidores tienen opciones de configuración para
permitir este tipo de restricción, pero es una característica muy útil para aquellos que lo
tienen. El puerto 8000 en este ejemplo es propiedad del proxy web Junkbuster.
Con las tres siguientes líneas, 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 estándar para los servidores HTTP como
Apache. No hay nada extraño aquí ya que estos son servicios normalmente disponibles
en Linux.
Los dos primeros nos son del tipo de servicios a los que te gustaría que alguien se
conectase. Por eso, deberían ponerse detras de un cortafuegos para que todas las
conexiones externas fueran rechazadas. De nuevo, mirando la salida no podemos decir si
existe algún 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 página web, Apache puede hacerlo por nosotros.
Además, es posible filtrarlo por cortafuegos para que puedan usarlo solamente nuestros
clientes LAN como parte de una Intranet. También es obvio que si no tienes una buena
razón para ejecutar un servidor web, entonces lo mejor será que lo deshabilites por
completo.
Las dos líneas 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
Nótese 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 sólo
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 cómo 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: Administración de Sistemas Informáticos
Módulo: Redes de Área Local
Tutorial de netstat
verdadero, que es responsable de la gestión de las consultas DNS, debería tener abierto
el puerto 53 a todo el mundo. Entonces ya estaríamos hablando de un riesgo de
seguridad que requiere una gestión 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 señal!
Obsérvese 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 sección para resonder este enigma).
Y por último, el puerto 25, el puerto estándar para el demonio de correo SMTP. La
mayoría de instalaciones Linux probablemente tendrán un demonio SMTP corriendo, así
que no es algo tan raro. Pero, ¿es necesario?
El siguiente grupo son las conexiones establecidas. Para nuestros propósitos, el
estado de la conexión indicado en la última columna no es tan importante. Eso ya está
bien explicado en la página 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 conectándose a un puerto
remoto en su puerto 119, el puerto estándar de las news (NNTP). Aquí vemos tres
conexiones con el mismo servidor de news. Aparentemente la aplicación es multi-hebra,
ya que está intentando abrir múltiples 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 común para la
mayoría de nosotros.
Pero la línea 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á después una conexión externa consigo mismo, que es
probablemente lo que esta sucediendo con las líneas cuatro y cinco.
--4--
Ciclo formativo: Administración de Sistemas Informáticos
Módulo: 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 líneas 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 están 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 podría ser sospechoso y nos podría picar la
curiosidad. Véase la explicación de la sección siguiente.
¿Podemos extraer alguna conclusión de esta situación hipotética? Para la mayoría, estos
servicios y conexiones parecen bastantes normales en Linux. No parece haber un
número 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. Además no sabemos
realmente si todos los servicios a la escucha son verdaderamente necesarios. Esto es algo
que varía bastante de una instalación a otra. Por ejemplo, ¿tiene bigcat una impresora
conectada? Aparentemente sí, o sino estaría corriendo un riesgo completamente
innecesario.
2.- PROPIETARIOS DE PUERTOS Y PROCESOS
En la sección 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 quién arrancó ese servicio en particular. O que queremos detener un
servicio en particular y, solo mirando la salida del netstat, no tenemos claro cuál es.
La opción -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 información 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
--5--
PID/Program name
988/inetd
1064/junkbuster
988/inetd
1462/X
1078/httpd
956/named
956/named
972/sshd
1315/cupsd
1051/master
Ciclo formativo: Administración de Sistemas Informáticos
Módulo: 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 situación
especial. A inetd se le conoce como el super servidor, debido a que es su función
principal es crear sub-servicios. Si miramos la primera línea, inetd está escuchando en el
puerto 515 para servicios de impresora. Si una conexión viene para este puerto, inetd la
intercepta y luego genera el demonio apropiado, como el demonio de impresora en este
caso. La configuración que indica a inetd cómo 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 configuración de inetd (o quizá la de xinetd). Además,
el servicio time también ha sido iniciado via inetd. Eso nos dice que estos dos servicios
pueden ser protegidos también por tcpwrappers, lo que supone uno de los beneficios de
utilizar inetd para controlar ciertos servicios de sistema.
tcpwrapper: una aplicación para seguridad en Internet que permite a los
usuarios desactivar ciertos programas que exponen a los sistemas ante tráfico
poco seguro de Internet, además de realizar pruebas para verificar los cambios.
El tcpwrapper (tcpd) viene ya incluido en algunas distribuciones de Linux.
No estábamos seguros del servicio que utilizaba el puerto 631 porque no teníamos un
nombre de servicio estándar, 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 impresión 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 impresión.
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, podríamos
buscar en el sistema de ficheros utilizando herramientas como los comandos locate o
find. Una vez encontrado, podríamos 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: Administración de Sistemas Informáticos
Módulo: Redes de Área Local
Tutorial de netstat
Ejecutar ps con la opción --forest (o la opción 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 reseñar. 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 también
está generando sub-procesos, bero no como “hebras”. Cada subproceso posee su propia
tarea específica. 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 búsqueda de ficheros más flexible, pero no utiliza
una base de datos como lo hace locate, así que es mucho más lento:
$ find / -name master
/usr/libexec/postfix/master
Si lsof está instalado, es otro comando útil para encontrar quién 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: Administración de Sistemas Informáticos
Módulo: Redes de Área Local
Tutorial de netstat
Esto nos dice otra vez que el demonio de impresión cupsd es propietario del puerto 631,
sólo que hemos utilizado otro modo de averiguarlo. Y todavía existe otra forma de hacerlo
con fuser, que debería estar instalado:
# fuser -v -n tcp 631
631/tcp
USER
root
PID
1315
ACCESS
f....
COMMAND
cupsd
Ver las páginas de manual para la sintaxis de los comandos fuser y lsof.
Otro sitio donde para buscar dónde 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
podría 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 patrón de búsqueda. ¿Necesitamos encontrar dónde
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 necesitábamos toda esa información, pero al menos ahora vemos
exactamente qué script lo está iniciando. Recordemos también que no todos los servicios
se inician de esta manera. Algunos pueden ser iniciados mediante inetd, o xinetd.
El sistema de ficheros /proc guarda, además, todo lo que queremos saber sobre los
procesos que se están ejecutando. Podemos preguntárselo para obtener más información
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 extraño número de puerto, el 32768, que además 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 opción -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 tráfico. En este caso, es la versión
BIND 9.x. O sea, que no tenemos por qué preocuparnos. Aquí, el puerto sin privilegios es
--8--
Ciclo formativo: Administración de Sistemas Informáticos
Módulo: Redes de Área Local
Tutorial de netstat
el que named utiliza para hablar con otros servidores de nombres para búsquedas de
nombres y direcciones, y no debería estar filtrado por cortafuegos.
Por tanto, no encontramos grandes sorpresas en esta situación hipotética.
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 algún tipo.
Estos usan puertos asignados aleatoriamente sin ningún significado lógico 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 cuáles servicios RPC están corriendo (portmap debe estar
ejecutándose para que esto funcione).
NOTA
Si sospechas que alguien entró en tu sistema, no confíes 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--