Seguridad en Unix y redes - Algunas órdenes importantes

La orden ifconfig

La orden ifconfig se utiliza para configurar correctamente los interfaces de red de nuestro sistema Unix; habitualmente con ifconfig se indican parámetros como la dirección IP de la máquina, la máscara de la red local o la dirección de broadcast. Si como parámetros se recibe únicamente un nombre de dispositivo, ifconfig nos muestra su configuración en este momento:

anita:/# ifconfig nei0 nei0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.3 netmask ffffff00 broadcast 192.168.0.255 ether 0:20:18:72:45:ad anita:/#

Ya hemos dicho que aquí no vamos a hablar de la configuración de estos dispositivos, sino de sus consideraciones de seguridad. Podemos utilizar ifconfig para detectar un funcionamiento anómalo de la tarjeta de red; este `funcionamiento anómalo' suele ser la causa (siempre en cuanto a seguridad se trata) de uno de los tres siguientes problemas:

• Dirección IP incorrecta.
  Es posible que alguien esté realizando un ataque de tipo IP Spoofing utilizando nuestro sistema: si utilizamos la dirección IP de otro equipo, las peticiones que irían a él van a llegar a nosotros14.2. Estamos suplantando su identidad, hecho que un atacante puede aprovechar para capturar todo tipo de información (desde claves hasta correo electrónico).
• Dirección MAC incorrecta.
  Esto puede denotar un ataque similar al anterior, pero más elaborado: estamos suplantando la identidad de otro equipo no sólo a nivel de IP, sino a nivel de dirección MAC. Cuando esto sucede, casi con toda seguridad se acompaña de un IP Spoof para conseguir una suplantación que no sea tan fácil de detectar como el IP Spoof a secas.
• Tarjeta en modo promiscuo.
  Alguien ha instalado un sniffer en nuestro sistema y ha puesto la tarjeta de red en modo promiscuo, para capturar todas las tramas que ésta `ve'. Es un método muy utilizado por atacantes que han conseguido privilegio de superusuario en la máquina (es necesario ser root para situar a la tarjeta en este modo de operación) y se está dedicando a analizar el tráfico de la red en busca de logins y claves de usuarios de otros equipos.

La orden route

Este comando se utiliza para configurar las tablas de rutado del núcleo de nuestro sistema. Generalmente en todo equipo de una red local tenemos al menos tres rutas: la de loopback, utilizando el dispositivo de bucle interno (lo, lo0...), la de red local (localnet), que utiliza la tarjeta de red para comunicarse con equipos dentro del mismo segmento de red, y una default que también utiliza la tarjeta para enviar a un router o gateway paquetes que no son para equipos de nuestro segmento. Si no se especifica ningún parámetro, route muestra la configuración actual de las tablas de rutado14.3:

andercheran:~# route Kernel routing table Destination Gateway Genmask Flags MSS Window Use Iface localnet * 255.255.0.0 U 1500 0 16 eth0 loopback * 255.0.0.0 U 3584 0 89 lo default atlas.cc.upv.es * UG 1500 0 66 eth0 andercheran:~#

Si route nos muestra una configuración sospechosa (esto es, las tablas no son las que en el sistema hemos establecido como administradores, aunque todo funcione correctamente) esto puede denotar un ataque de simulación: alguien ha desviado el tráfico por un equipo que se comporta de la misma forma que se comportaría el original, pero que seguramente analiza toda la información que pasa por él. Hemos de recalcar que esto suele ser transparente al buen funcionamiento del equipo (no notamos ni pérdida de paquetes, ni retardos excesivos, ni nada sospechoso), y que además el atacante puede modificar los ficheros de arranque del sistema para, en caso de reinicio de la máquina, volver a tener configuradas las rutas a su gusto; estos ficheros suelen del tipo /etc/rc.d/rc.inet1 o /etc/rc?.d/Sinet.

---

También es posible que alguien esté utilizando algún elemento utilizado en la conexión entre nuestro sistema y otro (un router, una pasarela...) para amenazar la integridad de nuestro equipo; si queremos comprobar el camino que siguen los paquetes desde que salen de la máquina hasta que llegan al destino, podemos utilizar la orden traceroute. Sin embargo, este tipo de ataques es mucho más difícil de detectar, y casi la única herramienta asequible para evitarlos es la criptografía.

La orden netstat

Esta orden se utiliza para visualizar el estado de diversas estructuras de datos del sistema de red, desde las tablas de rutado hasta el estado de todas las conexiones a y desde nuestra máquina, pasando por las tablas ARP, en función de los parámetros que reciba.

---

En temas referentes a la seguridad, netstat se suele utilizar, aparte de para mostrar las tablas de rutado de ciertos sistemas (con la opción -r, como hemos visto antes), para mostrar los puertos abiertos que escuchan peticiones de red y para visualizar conexiones a nuestro equipo (o desde él) que puedan salirse de lo habitual. Veamos un ejemplo de información mostrada por netstat:
anita:/# netstat -P tcp -f inet -a TCP Local Address Remote Address Swind Send-Q Rwind Recv-Q State

---

---

---

---

---

---

---

*.* *.* 0 0 0 0 IDLE *.sunrpc *.* 0 0 0 0 LISTEN *.* *.* 0 0 0 0 IDLE *.32771 *.* 0 0 0 0 LISTEN *.ftp *.* 0 0 0 0 LISTEN *.telnet *.* 0 0 0 0 LISTEN *.finger *.* 0 0 0 0 LISTEN *.dtspc *.* 0 0 0 0 LISTEN *.lockd *.* 0 0 0 0 LISTEN *.smtp *.* 0 0 0 0 LISTEN *.8888 *.* 0 0 0 0 LISTEN *.32772 *.* 0 0 0 0 LISTEN *.32773 *.* 0 0 0 0 LISTEN *.printer *.* 0 0 0 0 LISTEN *.listen *.* 0 0 0 0 LISTEN *.32774 *.* 0 0 0 0 LISTEN *.* *.* 0 0 0 0 IDLE *.6000 *.* 0 0 0 0 LISTEN *.32775 *.* 0 0 0 0 LISTEN localhost.32777 localhost.32775 32768 0 32768 0 ESTABLISHED localhost.32775 localhost.32777 32768 0 32768 0 ESTABLISHED localhost.32780 localhost.32779 32768 0 32768 0 ESTABLISHED localhost.32779 localhost.32780 32768 0 32768 0 ESTABLISHED localhost.32783 localhost.32775 32768 0 32768 0 ESTABLISHED localhost.32775 localhost.32783 32768 0 32768 0 ESTABLISHED localhost.32786 localhost.32785 32768 0 32768 0 ESTABLISHED localhost.32785 localhost.32786 32768 0 32768 0 ESTABLISHED localhost.32789 localhost.32775 32768 0 32768 0 ESTABLISHED localhost.32775 localhost.32789 32768 0 32768 0 ESTABLISHED localhost.32792 localhost.32791 32768 0 32768 0 ESTABLISHED localhost.32791 localhost.32792 32768 0 32768 0 ESTABLISHED localhost.32810 localhost.6000 32768 0 32768 0 ESTABLISHED localhost.6000 localhost.32810 32768 0 32768 0 ESTABLISHED anita.telnet luisa.2039 16060 0 10136 0 ESTABLISHED anita.telnet bgates.microsoft.com.1068 15928 0 10136 0 ESTABLISHED localhost.32879 localhost.32775 32768 0 32768 0 TIME_WAIT *.* *.* 0 0 0 0 IDLE anita:/#
Por un lado, en este caso vemos que hay bastantes puertos abiertos, esto es, escuchando peticiones: todos los que presentan un estado LISTEN, como telnet, finger o smtp (si es un servicio con nombre en /etc/services se imprimirá este nombre, y si no simplemente el número de puerto). Cualquiera puede conectar a este servicio (como veremos en el siguiente punto) y, si no lo evitamos mediante TCP Wrappers, utilizarlo para enviarle peticiones.

---

Aparte de estos puertos a la espera de conexiones, vemos otro gran número de conexiones establecida entre nuestro sistema y otros (como antes hemos dicho, desde nuestro equipo o hacia él); casi todas las establecidas (estado ESTABLISHED) son de nuestra máquina contra ella misma, lo que a priori no implica consecuencias de seguridad. Otra de ellas es desde un equipo de la red local contra nuestro sistema, lo que también es bastante normal y no debe hacernos sospechar nada14.4; sin embargo, hay una conexión que sí puede indicar que alguien ha accedido a nuestro sistema de forma no autorizada: si nos fijamos, alguien conecta por telnet desde la máquina bgates.microsoft.com. Es raro que tengamos a un usuario allí, por lo que deberíamos monitorizar esta conexión y las actividades que esta persona realice; es muy probable que se trate de alguien que ha aprovechado la inseguridad de ciertos sistemas para utilizarlos como plataforma de ataque contra nuestros Unix.

La orden ping

El comando ping se utiliza generalmente para testear aspectos de la red, como comprobar que un sistema está encendido y conectado; esto se consigue enviando a dicha máquina paquetes ICMP (de tipo ECHO/SMALL>_REQUEST), tramas que causarán que el núcleo del sistema remoto responda con paquetes ICMP, pero esta vez de tipo ECHO/SMALL>_RESPONSE. Al recibirlos, se asume que la máquina está encendida:

anita:~# ping luisa luisa is alive anita:~#

En otras variantes de Unix (el ejemplo anterior es sobre Solaris) la orden ping produce un resultado con más información:

luisa:~# ping -c 1 anita PING anita (192.168.0.3): 56 data bytes 64 bytes from 192.168.0.3: icmp_seq=0 ttl=255 time=0.2 ms
luisa ping statistics
1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.2 ms luisa:~#

Aunque un simple ping resulta inofensivo en la mayoría de situaciones, existen casos en los que se puede utilizar como un arma - efectiva - para atacar sistemas; por ejemplo, uno de los ataques más conocidos es el Ping Flood, consistente en saturar una línea lenta con un número de paquetes ICMP suficientemente grande. Esta saturación causará una degradación del servicio importante, incluso la desconexión del sistema si se ataca una línea telefónica (un objetivo muy habitual para los piratas). En este último caso, el de conexiones telefónicas, otro ataque común - no directamente relacionado con ping, pero en el que se usa esta herramienta como base - consiste en enviar una trama `especial' a un módem, obligándole a finalizar la llamada: los módems conmutan a modo comando cuando reciben la orden `+++', y muchos de ellos lo hacen también al recibir remotamente esta secuencia de control. Así, podemos conectar a un puerto donde se ofrezca determinado servicio (como FTP o SMTP) en un host con un módem de estas características y colgar el módem remoto sin levantarnos de la silla, simplemente enviando la cadena `+++' seguida de una orden de colgado como `ATH0':

luisa:~# telnet XXX.XXX.X.XX 21 Trying XXX.XXX.X.XX... Connected to XXX.XXX.X.XX. Escape character is '^]'. 220 gema FTP server (Version wu-2.4.2-academ[BETA-15](1) Fri Oct 22 00:38:20 CDT 1999) ready. USER +++ATH0 ^] telnet> close Connection closed. luisa:~# telnet XXX.XXX.X.XX Trying XXX.XXX.X.XX... telnet: Unable to connect to remote host: Network is unreachable luisa:~#

Bien pero, >dónde entra ping en este ataque? Muy sencillo: al conectar a un servicio para enviar la cadena de caracteres, lo habitual es que el sistema remoto registre la conexión, aunque luego su módem cuelgue. En cambio, muy pocos sistemas registran en los logs un simple ping, por lo que esta orden se convierte en un mecanismo que algunos piratas utilizan para no dejar rastro de sus acciones; esto se consigue de una forma muy sencilla: en la utilidad ping de la mayoría de Unices existe un parámetro que permite especificar el contenido del paquete enviado (por ejemplo, `-p' en Linux), por lo que simplemente hemos de insertar (en hexadecimal) la cadena `+++ATH0' en la trama que enviamos al sistema remoto:

luisa:~# ping -c 1 XXX.XXX.X.XX PING XXX.XXX.X.XX (XXX.XXX.X.XX): 56 data bytes 64 bytes from XXX.XXX.X.XX: icmp_seq=0 ttl=255 time=0.2 ms
XXX.XXX.X.XX ping statistics
1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 6.5/6.5/6.5 ms luisa:~# ping -p 2b2b2b415448300d XXX.XXX.X.XX PING XXX.XXX.X.XX (XXX.XXX.X.XX): 56 data bytes ^C
XXX.XXX.X.XX ping statistics
1 packets transmitted, 0 packets received, 100% packet loss luisa:~# telnet XXX.XXX.X.XX Trying XXX.XXX.X.XX... telnet: Unable to connect to remote host: Network is unreachable luisa:~#

Para evitar los problemas relacionados con los paquetes ICMP que sistemas remotos puedan enviar a nuestra máquina puede ser conveniente filtrar dicho protocolo mediante un cortafuegos (incluso situado en el propio equipo); si no tenemos esta posibilidad, al menos es interesante registrar las tramas de este tipo que llegan hasta nuestra máquina, con programas como icmpinfo (si hacemos esto, hemos de tener cuidado con las negaciones de servicio ocasionadas por una cantidad de logs excesiva en el disco duro).

---

Ah, si es nuestro módem el que presenta el problema que acabamos de comentar, podemos solucionarlo mediante la cadena de inicialización `s2=255'.

La orden traceroute

Esta orden se utiliza para imprimir la ruta que los paquetes siguen desde nuestro sistema hasta otra máquina; para ello utiliza el campo TTL (Time To Live) del protocolo IP, inicializándolo con valores bajos y aumentándolo conforme va recibiendo tramas ICMP de tipo TIME/SMALL>_EXCEEDED. La idea es sencilla: cada vez que un paquete pasa por un router o una pasarela, esta se encarga de decrementar el campo TTL en una unidad; en el caso de que se alcance un valor 0, se devuelve un paquete TIME/SMALL>_EXCEEDED y se descarta la trama. Así, traceroute inicializa a 1 este campo, lo que ocasiona que el primer router encontrado ya devuelva el mensaje de error; al recibirlo, lo inicializa a 2, y ahora es el segundo router el que descarta el paquete y envía otro mensaje de error, y así sucesivamente. De esta forma se va construyendo la ruta hasta un determinado host remoto:

luisa:~# traceroute www.altavista.com traceroute to altavista.com (204.152.190.70), 30 hops max, 40 byte packets 1 annex4.net.upv.es (158.42.240.191) 156.251 ms 144.468 ms 139.855 ms 2 zaurac-r.net.upv.es (158.42.240.250) 159.784 ms 149.734 ms 149.809 ms 3 atlas.cc.upv.es (158.42.1.10) 149.881 ms 149.717 ms 139.853 ms 4 A1-0-3.EB-Valencia1.red.rediris.es (130.206.211.185) 149.863 ms 150.088 ms 149.523 ms 5 A0-1-2.EB-Madrid00.red.rediris.es (130.206.224.5) 189.749 ms 159.698 ms 180.138 ms 6 A6-0-0-1.EB-Madrid0.red.rediris.es (130.206.224.74) 179.518 ms 159.678 ms 189.897 ms 7 194.69.226.13 (194.69.226.13) 259.752 ms 249.664 ms 259.83 ms 8 * * 195.219.101.1 (195.219.101.1) 290.772 ms 9 195.219.96.34 (195.219.96.34) 1680.33 ms 1660.36 ms 1669.83 ms 10 * 195.66.225.76 (195.66.225.76) 1660.68 ms 1650.33 ms 11 core1-linx-oc3-1.lhr.above.net (216.200.254.81) 2009.88 ms 1970.32 ms * 12 iad-lhr-stm4.iad.above.net (216.200.254.77) 2050.68 ms * * 13 sjc-iad-oc12-2.sjc.above.net (216.200.0.22) 2440.89 ms 2170.29 ms 2579.81 ms 14 pao-sjc-oc12-2.pao.above.net (207.126.96.65) 2441.19 ms 2140.32 ms * 15 mibh-above-oc3.pao.mibh.net (216.200.0.10) 2200.57 ms * * 16 * * www.altavista.com (204.152.190.70) 1810.56 ms luisa:~#

traceroute se utiliza para realizar pruebas, medidas y administración de una red; introduce mucha sobrecarga, lo que evidentemente puede acarrear problemas de rendimiento, llegando incluso a negaciones de servicio por el elevado tiempo de respuesta que el resto de aplicaciones de red pueden presentar. Además, se trata de un programa contenido en un fichero setuidado, por lo que es interesante resetear el bit de setuid de forma que sólo el root pueda ejecutar la orden: hemos de pensar que un usuario normal rara vez tiene que realizar pruebas sobre la red, por lo que el bit setuid de traceroute no es más que un posible problema para nuestra seguridad; aunque con ping sucede lo mismo (es un fichero setuidado), que un usuario necesite ejecutar traceroute es menos habitual que que necesite ejecutar ping (de cualquier forma, también podríamos resetear el bit setuid de ping).