Netstat PDF

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 State
tcp 0 0 *:printer *:* LISTEN
tcp 0 0 bigcat:8000 *:* LISTEN
tcp 0 0 *:time *:* LISTEN
tcp 0 0 *:x11 *:* LISTEN
tcp 0 0 *:http *:* LISTEN
tcp 0 0 bigcat:domain *:* LISTEN
tcp 0 0 bigcat:domain *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 *:631 *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 1 dsl-78-199-139.s:1174 64.152.100.93:nntp SYN_SENT
tcp 0 0 dsl-78-199-139.s:1172 207.153.203.114:http ESTABLISHED
tcp 1 0 dsl-78-199-139.s:1199 www.xodiax.com:http CLOSE_WAIT
tcp 0 0 dsl-78-199-139.sd:http 63.236.92.144:34197 TIME_WAIT
tcp 400 0 bigcat:1152 bigcat:8000 CLOSE_WAIT
udp 0 0 *:32768 *:*
udp 0 0 bigcat:domain *:*
udp 0 0 bigcat:domain *:*
udp 0 0 *:631 *:*
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--
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
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:37 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 1 169.254.179.139:1174 64.152.100.93:119 SYN_SENT
tcp 0 1 169.254.179.139:1175 64.152.100.93:119 SYN_SENT
tcp 0 1 169.254.179.139:1173 64.152.100.93:119 SYN_SENT
tcp 0 0 169.254.179.139:1172 207.153.203.114:80 ESTABLISHED
tcp 1 0 169.254.179.139:1199 216.26.129.136:80 CLOSE_WAIT
tcp 0 0 169.254.179.139:80 63.236.92.144:34197 TIME_WAIT
tcp 400 0 127.0.0.1:1152 127.0.0.1:8000 CLOSE_WAIT
tcp 6648 0 127.0.0.1:1162 127.0.0.1:8000 CLOSE_WAIT
tcp 553 0 127.0.0.1:1164 127.0.0.1:8000 CLOSE_WAIT
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:*
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--
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 0 0 0.0.0.0:37 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* 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 0 0 192.168.1.1:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* 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--
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 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* 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 0 1 169.254.179.139:1174 64.152.100.93:119 SYN_SENT
tcp 0 1 169.254.179.139:1175 64.152.100.93:119 SYN_SENT
tcp 0 1 169.254.179.139:1173 64.152.100.93:119 SYN_SENT
tcp 0 0 169.254.179.139:1172 207.153.203.114:80 ESTABLISHED
tcp 1 0 169.254.179.139:1199 216.26.129.136:80 CLOSE_WAIT
tcp 0 0 169.254.179.139:80 63.236.92.144:34197 TIME_WAIT
tcp 400 0 127.0.0.1:1152 127.0.0.1:8000 CLOSE_WAIT
tcp 6648 0 127.0.0.1:1162 127.0.0.1:8000 CLOSE_WAIT
tcp 553 0 127.0.0.1:1164 127.0.0.1:8000 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--
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 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:*
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
Local Address Foreign Address State PID/Program name
*:printer *:* LISTEN 988/inetd
bigcat:8000 *:* LISTEN 1064/junkbuster
*:time *:* LISTEN 988/inetd
*:x11 *:* LISTEN 1462/X
*:http *:* LISTEN 1078/httpd
bigcat:domain *:* LISTEN 956/named
bigcat:domain *:* LISTEN 956/named
*:ssh *:* LISTEN 972/sshd
*:631 *:* LISTEN 1315/cupsd
*:smtp *:* LISTEN 1051/master
--5--
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--
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 0:00 named -u named
957 ? S 0:00 \_ named -u named
1051 ? S 0:30 /usr/libexec/postfix/master
1703 ? S 0:00 \_ tlsmgr -l -t fifo -u -c
1704 ? S 0:00 \_ qmgr -l -t fifo -u -c
1955 ? S 0:00 \_ pickup -l -t fifo -c
1863 ? S 0:00 \_ trivial-rewrite -n rewrite -t unix -u -c
2043 ? S 0:00 \_ cleanup -t unix -u -c
2049 ? S 0:00 \_ local -t unix
2062 ? S 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 FD TYPE DEVICE SIZE NODE NAME
cupsd 1315 root 0u IPv4 3734 TCP *:631 (LISTEN)
--7--
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
USER PID ACCESS COMMAND

631/tcp root 1315 f.... 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
Local Address Foreign Address State PID/Program name
*:32768 *:* 956/named
bigcat:domain *:* 956/named
bigcat:domain *:* 956/named
*:631 *:* 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--
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--

Netstat PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Netstat PDF

Cargado por

Copyright:

Formatos disponibles

Ciclo formativo: Administracin de Sistemas Informticos

Mdulo: Redes de rea Local

Echemos un vistazo a las primeras lneas.

La segunda lnea es un poco distinta:

Mirando a /etc/services, podemos decir que el puerto 37 es un servidor de tiempo. El

El servidor web en el puerto 80 no supone un gran riesgo de seguridad por s mismo.

Las dos lneas siguientes son interesantes:

Las ltimas tres entradas:

Estas de nuevo escuchan en todas las interfaces disponibles.

El siguiente grupo son las conexiones establecidas. Para nuestros propsitos, el

Aqu tenemos nueve conexiones en total.

Las tres primeras corresponden a nuestra interfaz externa conectndose a un puerto

Las ltimas lneas son las correspondientes a UDP:

El primero, el puerto 32678 es nuevo, y no tiene un nombre de servicio asociado en

2.- PROPIETARIOS DE PUERTOS Y PROCESOS

tcpwrapper: una aplicacin para seguridad en Internet que permite a los

La ltima entrada pertenece al servidor de correo SMTP de bigcat. En muchas

$ /bin/ps ax |grep 1051 |grep -v grep

find es, posiblemente, la utilidad de bsqueda de ficheros ms flexible, pero no utiliza

USER PID ACCESS COMMAND

En realidad, no necesitbamos toda esa informacin, pero al menos ahora vemos

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

También podría gustarte