Este documento se encuentra disponible también en formato PDF

Seguridad en nivel de red

Subseccion

Seguridad en nivel de red

Los ataques a nivel de red siguen siendo bastante frecuentes. Aunque las pilas TCP/IP de los distintos sistemas operativos son cada vez más robustas, todavía son frecuentes los ataques de denegación de servicio en servidores NT y Unix debidos al empleo de generadores de datagramas IP erróneos o complicados de procesar.

Es también frecuente el empleo de herramientas automatizadas de escaneo y comprobación de vulnerabilidades en redes, así como la utilización de programas especifícos que explotan una determinada vulnerabilidad de un servidor o servicio concreto para atacarlo.

En esta sección vamos a tratar sobre todo las medidas que creemos que se deben establecer en las organizaciones mediante el filtrado de diversos protocolos en los routers de acceso, para así evitar el acceso desde fuera a estos servicios. Estas medidas no serán efectivas contra ataques internos, salvo que se apliquen medidas internas concretas en aquellas organizaciones que tienen un direccionamiento plano de red para su red física, pero permitirán como mínimo reducir ciertos problemas como el SPAM o los ataques contra servicios bien conocidos como NFS, NetBios, etc. Además permitirán que incluso si los usuarios finales activan esos servicios en sus máquinas, éstos no serán accesibles desde el exterior, evitando así múltiples problemas.

Filtrado de paquetes

Aunque la seguridad a nivel de sistema sigue teniendo una importancia vital, los fallos en varios servicios TCP/IP y la existencia de protocolos defectuosos hace imprescindible el uso de filtros en el nivel de red, que permitan a una organización restringir el acceso externo a estos servicios. De esta forma, sólo aquellos servicios que deban estar accesibles desde fuera del área local serán permitidos a través de filtros en los routers. Además es importante que estos filtros determinen las condiciones de acceso a los servicios permitidos. Aunque el filtrado es difícil de implementar correctamente, queremos dar algunos consejos que ayudarán a las organizaciones a implementar sus propios filtros en función a sus necesidades y a su topología de red concreta. En particular, se recomienda encarecidamente que se filtren los siguientes servicios si no es necesario su acceso desde fuera de una organización concreta:



Nombre Puerto Tipo de conexión Servicio
echo 7 tcp/udp Eco:  Devuelve los datos que se reciben
systat 11 tcp Información del sistema
netstat 15 tcp Información sobre la red
chargen 19 tcp/udp Generador de caracteres continuo
SMTP 25 tcp Puerto de correo
domain 53 tcp/udp Servidor de Nombres (DNS)
bootp 67 udp Arranque de estaciones remotas sin disco
tftp 69 udp Arranque de equipos remotos, carga de configuraciones
link 87 udp  
supdup 95 udp  
sunrpc 111 tcp/udp Servicio de RPC (portmapper)
news 119 tcp Servidores de News (deberían estar ya filtrados en todos los routers de las organizaciones afiliadas a RedIRIS)
NetBios 137-139 udp/tcp Servicios NetBios sobre TCP/IP (Windows)
snmp 161 udp Gestión remota de equipos mediante SNMP
xdmpc 177 udp Llegada de correo
exec 512 tcp Ejecución remota de comandos (rexec)
login 513 tcp Acceso remoto a un sistema (rlogin)
shell 514 tcp Shell remoto
biff 512 udp  
who 513 udp Información sobre los usuarios que hay conectados en un equipo remoto
syslog 514 udp Almacenamiento de los logs de los sistemas en remoto
uucp 540 tcp Envío de ficheros y mensajes mediante uucp, actualmente en desuso
route 520 udp Información sobre enrutamientos
openwin 2000 tcp  
NFS 2049 tcp/udp Sistema de ficheros remotos de Sun y Unix en general
X-Windows 6000 +n tcp Servidor X-Windows



CHARGEN y ECHO: Puertos 11 y 19 (TCP/UDP)

Es muy importante para evitar ataques de denegación de servicio por puertos UDP (http://www.cert.org/advisories/CA-96.01.UDP_service_denial.html), filtrar a nivel de router o firewall los servicios "chargen" y "echo" y en general todos los servicios UDP que operen por debajo del puerto 900, con excepción de aquellos que se necesiten explícitamente.

Sistema de nombres de dominio (DNS): Puerto 53 (TCP/UDP)

Es necesario filtrar el acceso desde el exterior a todos los equipos excepto a los servidores de DNS primarios y secundarios establecidos en una organización. 3.1

TFTPD: Puerto 69 (UDP)

En general cualquier servicio UDP que responde a un paquete de entrada puede ser víctima de un ataque de denegación de servicio (DoS). Un acceso no restringido al servicio TFTP permite a sitios remotos recuperar una copia de cualquier fichero "word-readable", entre los que se pueden incluir ficheros críticos como ficheros de configuración de routers y ficheros de claves. Es por ello, que aquellas organizaciones que no necesiten usar este servicio deberían filtrarlo y aquellas que necesiten usarlo, lo configuren adecuadamente teniendo en cuenta las medidas de seguridad a nivel de aplicación.

Comandos r de BSD UNIX: Puertos 512, 513 y 514 (TCP)

Los comandos r incrementan el peligro de que sean interceptados contraseñas en texto plano cuando se presenta un ataque utilizando sniffers de red, pero lo más importante es que son una fuente bastante frecuente de ataques y vulnerabilidades. Filtrando los puertos 512, 513 y 514 (TCP) en el hardware de red se evitará que personas ajenas a su organización puedan explotar estos comandos, pero no lo evitará a personas de su propia organización. Para ellos, aconsejamos el uso de otras herramientas como el ssh, uso de versiones seguras de los comandos "r" (Wietse Venema's logdaemon), uso de tcp_wrapper para proporcionar una monitorización del acceso a estos servicios, etc...

SunRPC y NFS: Puertos 111 y 2049 (TCP/UDP)

Filtrar el tráfico NFS evitará que sitios ajenos a su organización accedan a sistemas de archivos exportados por máquinas de su red, pero como ocurría en el caso anterior, no se evitará que se realicen ataques desde dentro del área local. La mayoría de las implementaciones NFS emplean el protocolo UDP, por lo que es posible, en algunos casos, el envío de peticiones NFS falsificando la dirección origen de los paquetes (IP-spoofing
http://www.cert.org/advisories/CA-1996-21.html. Es por tanto muy aconsejable la instalación de las últimas versiones actualizadas de los servidores y clientes NFS que tienen en cuenta estas características.

SMTP Puerto 25 (TCP)

Es importante configurar el router de manera que todas las conexiones SMTP procedentes de fuera de una organización pasen a una estafeta central y que sea desde ésta desde donde se distribuya el correo internamente. Este tipo de filtros permitirá que no existan puertos 25 descontrolados dentro de una organización, ya que suelen ser foco de importantes problemas de seguridad, además de un registro centralizado de información, que podrá ayudar a la hora de detectar el origen de intentos de ataque. El administrador del sistema o el responsable de seguridad sólo se tendrá que preocupar de tener actua lizado este servidor para evitar ataques aprovechando vulnerabilidades o fallos bien conocidos en los mismos. Para obtener más información sobre diseño de un servicio de correo electrónico puede consultar la siguiente página:
http://www.rediris.es/mail/coord/sendmail/estafeta.html.

NetBios. Puertos 137, 138 y 139 (TCP/UDP)

Estos puertos son los empleados en las redes Microsoft (Windows para Trabajo en Grupo, dominios NT, y LANManager), tanto para la autenticación de usuarios como para la compartición de recursos (impresoras y discos). Es frecuente el permitir el acceso global a uno de estos dispositivos, ignorando que es posible el acceso a estos recursos desde cualquier dirección de Internet.

SNMP Puerto 161 (UDP/TCP)

Muchos equipos disponen en la actualidad de gestión SNMP incorporada. Dado que estas facilidades de gestión no suelen necesitar accesos externos, se deben establecer filtros a nivel de router que eviten que se pueda obtener información sobre los dispositivos (routers, hubs, switches) desde el exterior o incluso se gestionen los equipos en remoto.

Filtros de datagramas IP

Por otro lado, para prevenir los ataques basados en bombas ICMP, se deben filtrar los paquetes de redirección ICMP y los paquetes de destino ICMP inalcanzables. Además, y dado que actualmente el campo de opciones de los paquetes IP apenas se utiliza, se pueden filtrar en la totalidad de las organizaciones los paquetes de origen enrutado (source routed packets). Estos paquetes indican el camino de vuelta que ha de seguir el paquete, lo cual es algo inseguro, ya que alguno de los puntos intermedios por los que pase el paquete puede estar comprometido.

Si una organización determinada no necesita proveer de otros servicios a usuarios externos deberían filtrarse igualmente esos otros servicios. Por poner un ejemplo, filtrar conexiones POP e IMAP a todos los sistemas excepto a los que deben ser accesibles desde el exterior. Esta misma regla es aplicable a otros servicios como WWW, SMTP, NTP, etc...).

Con el protocolo IP que actualmente está mayoritariamente en uso, es casi imposible eliminar el problema del IP-spoofing (falsificación de la IP). Sin embargo, se pueden tomar algunas medidas que reducirán el número de paquetes de este tipo que entran y existen en una red local. Actualmente, el mejor modo de realizar esto es restringir la entrada en el interfaz externo (filtro de entrada), no permitiendo que un paquete entre a nuestra red si tiene la dirección origen de la red interna. De la misma forma, se deberán filtrar los paquetes salientes que tengan una dirección origen distinta a la correspondiente a la red interna (con esto último se evitarán ataque de IP-spoofing originados desde nuestra red). La combinación de estos dos filtros prevendrán que un atacante de fuera de nuestra red envíe paquetes simulando hacerlo desde dentro de nuestra red, así como que paquetes generados dentro de nuestra red parezcan haber sido generados fuera de la mismas.

En la entrada al interfaz interno de una organización se deben filtrar los bloques de paquetes con las siguientes direcciones:

  • Redes Broadcast: Para evitar que su organización sea utilizada como intermediaria en un ataque de denegación de servicio de tipo smurf (http://www.cert.org/advisories/CA-1998-01.html) es necesario bloquear el tráfico ICMP a las direcciones de broadcast (bits dedicados a hosts todos a uno) y de red (bits dedicados a hosts todos iguales a cero).
  • Su área local.
  • Números de red privada reservados: No se debe recibir tráfico desde o hacia las siguientes direcciones a través de los routers puesto que se trata de redes privadas reservadas:

    • 10.0.0.0 - 10.255.255.255 10/8 (reservada)
    • 127.0.0.0 - 127.255.255.255 127/8 (loopback)
    • 172.16.0.0 - 172.31.255.255 172.16/12 (reservada)
    • 192.168.0.0 - 192.168.255.255 192.168/16 (reservada)

Configuración de las pilas TCP/IP en equipos finales

Gran parte de los ataques de denegación de servicio (DoS) se producen debido a fallos en las implantaciones de las pilas TCP/IP en los sistemas operativos. Así, son famosos los ataques de denegación de servicio mediante el envío de datagramas IP con información ICMP errónea, que provocan el reinicio del equipo, o los ataques mediante inundación SYN y FIN, impidiendo el normal funcionamiento de los servidores. En la medida de lo posible, se debe revisar la configuración de estos sistemas, en especial la configuración de ``reenvío de datagramas IP'' (ip-forwarding), que permite que un sistema funcione como un router.

Monitorización de routers y equipos de acceso

Hace algunos años era frecuente el empleo de equipos de acceso (servidores de pools de módems, routers de acceso, etc.) para la conexión a los servidores de las organizaciones desde el domicilio de los usuarios. Con la aparición de Infovía y los proveedores de acceso a Internet, el uso de estos sistemas ha ido disminuyendo, aunque siguen estando operativos en muchas instituciones.

Tanto estos equipos como los routers de interconexión y cualquier dispositivo (switch, concentrador ATM, etc. que disponga de esta opción), deben estar monitorizados. Los syslog deben configurarse para ir enviando los mensajes de la consola a un equipo central donde se deben almacenar durante un periodo razonable de tiempo, de forma que se puedan comprobar los intentos de conexión no autorizados y las caídas que se producen en estos equipos. Esta monitorización es muchas veces muy sencilla de establecer y la recepción y almacenamiento de los registros no requiere mucha carga del procesador.

En instalaciones con mucho equipamiento de red puede ser recomendable el empleo de alguna herramienta de monitorización SNMP de los equipos, de forma que las incidencias que vayan ocurriendo sean notificadas en tiempo real a los administradores de la red.

Es necesaria la instalación de versiones recientes de los sistemas operativos de estos equipos, puesto que muchas instalaciones disponen de versiones antiguas susceptibles a ataques de denegación de servicio que pueden ser fácilmente evitables si se actualizan periódicamente los sistemas.

Separación de las redes y filtros anti-sniffing

Gran parte de los ataques que se producen son debidos a la obtención de las claves empleando un programa de sniffing en una red ethernet. En muchas ocasiones, la separación de las redes y el empleo de switches y routers hace falta para permitir una mayor descongestión del tráfico interno de una organización, pero además es muy necesario para lograr una mayor seguridad dentro de esta.

Las salas de acceso general (bibliotecas, salas de prácticas comunes, aulas de estudiantes, etc.) deben estar separadas mediante puentes (bridges) o conmutadores (switches) del resto de la red, para evitar que se puedan obtener, mediante sniffers, claves de acceso de otros grupos de usuarios. En general los equipos que necesiten el empleo de sistemas inseguros de transmisión de claves deberían estar aislados de la red, de forma que estas claves no se transmitan por toda la organización. Hay que considerar además las posibilidades de gestión y consola remota que disponen muchos hubs y switches: hay que cambiar las claves por defecto que suelen tener estos equipos y deshabilitar la gestión remota de éstos si no se va a hacer uso de ella (SNMP, consolas remotas, servidor de HTTP...). Consulte la ponencia presentada en los Grupos de Trabajo de Barcelona "Implantación de un sistema de securización global a nivel de red", (http://www.rediris.es/rediris/boletin/46-47/ponencia8.html).

Hay que indicar que existen ya versiones de sniffers para los sistemas Windows, siendo posible muchas veces la obtención de contraseñas de acceso a sistemas de ficheros remotos de Netbios, pudiendo modificar fácilmente cualquier aplicación existente en estos servidores. Además en muchos servidores Samba la clave de conexión de Windows coincide con la clave del usuario, por lo que estas medidas anti-sniffing se deben aplicar a cualquier protocolo que circule por la red.



Footnotes

... organización.3.1
Consultar la documentación relativa a la configuración del servidor de DNS en la seguridad de sistemas


IRIS CERT