Este documento se encuentra disponible tambi�n en formato PDF

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