Linux Firewalls Guía Avanzada

inux Robert L Zi~ler

Prt'lll

ndice de contenido

Acerca del autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX Acerca de los revisores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... ... .. . . . . .. .. . . . . . XIII Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .... .. . . . . . . . . . . . . . . . . . XV

CONSIDERACIONES PREVIAS

1 Conceptos bsicos subyacentes a los flrewalls de filtrado de paquetes.............................................................................................. 3 El modelo de referencia TCP /IP para redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Puertos de servicio: la puerta a los programas en su sistema . . . . . . . . . . . . . . 6 Paquetes: mensajes de red IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Resumen............................................................................................... 16

11 FILTRADO DE PAQUETES Y MEDIDAS BSICAS DE SEGURIDAD ---- --- ---- ---- --- ----

2 Concepto del filtrado de paquetes . . . .. . . . . . . . . . .. .. ... . . . ... . ....... .. . . . . . . . . . . . . 17 Un Firewall de filtrado de paquetes ..... ................................................ 20 Eleccin de una directiva predeterminada de filtrado de paquetes . . . . . 23 Rechazar frente a denegar un paquete ................................................ 23 Cmo filtrar los paquetes entrantes . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . 24 Cmo filtrar paquetes salientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Servicios de red privados frente a pblicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Resumen............................................................................................... 59

3 Creacin e instalacin de un flrewall ........................................... 61 ipchains: El programa de administracin de firewall de Llnux . . . . . . . . . . . . 62 Inicializacin del firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Cmo filtrar los mensajes de estado y de control ICMP ...................... 75 Cmo proteger los servicios en los puertos no privilegiados asignados . . 80 Cmo habilitar los servicios bsicos necesarios de Internet . . . . . . . . . . . . . . . 86 Cmo habilitar servicios TCP habituales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Cmo habilitar servicios UDP habituales ....... ..... .............................. .. . 115 Cmo registrar los paquetes entrantes denegados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Cmo denegar todo tipo de acceso a sitios problemticos . . . . . . . . . . . . . . . . . 123 Cmo habilitar el acceso LAN ............................................................... 123 Instalacin del firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Resumen . . . . . . . . . . . . . . . . . . . . . . . . .. . . .. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

VI ndice de contenido

4 Redes de permetro, t'"trewalls mltiples y problemas con las LAN ..................................................................................................... 129 Cuestiones de seguridad relacionadas con las LAN . . . .. .. .. . . .. .. . . .. .. . . . . . . . . 131 Opciones de configuracin para una LAN particular segura . . . . . . . . . . . . . . . 132 Opciones de configuracin para una mayor o menor LAN segura .. .. .. 136 Un firewall formal de exploracin de subred .. .. .. .. .. .. .. .. .. .. . . . .. .. .. . .. . . . . . . 149 Resumen . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . .. . 232

5 Depuracin de las reglas del t1rewall . . . . . .. .. .. . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 233 Sugerencias generales sobre la programacin de firewalls .................. 233 Cmo listar las reglas del firewall . . .. . ... .. .. .. .. . . .. . . . .. . . . . .. .......................... 235 Comprobacin de las reglas de entrada, salida y reenvo .... ................ 242 Cmo comprobar un paquete concreto con las reglas de firewall ..... 247 Comprobacin de los puertos abiertos . . . . . .. .. . . . .. .. . .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Depuracin de SSH: un ejemplo de la vida real ................................... 253 Resumen ............................................................................................... 256

IIJ SllPERVISI(JN Y sE

ndice de contenido VII

Documentacin en lnea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 Sitios web generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Libros .................................................................................................... 362

8 Ejemplos de firewalls y secuencias de comandos compatibles .. 363 ipchains rc.firewall para un sistema individual o para una LAN parti-

cular del Captulo 3 .......................................................................... 364 ipfwadm rc.firewall para un sistema individual o para una LAN parti-

cular del Captulo 3 .......................................................................... 381 Optimizacin de las reglas de firewall ................................................. 398 Secuencias de comandos compatibles de propsito especial ............. 428 DHCP: compatibilidad del firewall con una direccin IP dinmica y

servidores de nombres ..................................................................... 431

C Glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

ndice alfabtico.............................................................................................. 453

Acerca del autor

Robert L. Ziegler se gradu en la Universidad de Wisconsin-Madison con una li-cenciatura de grado medio en Psicologa, adems de terminar las licenciaturas de Ale-mn y Filosofa. Despus de dedicarse a la educacin y a las carreras estudiadas, de-cidi hacer de su carrera un hobby y estudi un master en Ciencias de la computa-cin, tambin en la Universidad de Wisconsin-Madison.

Una vez fuera de la universidad, Bob se convirti en una de las dos personas de un equipo de programadores de sistemas operativos UNIX que trabajan para una com-paa que desarrollaba una mini-supercomputadora. Desarroll una versin multipro-cesador del UNIX BSD 4.3 como un proyecto paralelo a los esfuerzos de desarrollo uniprocesador que tena en marcha el equipo. Desde entonces, ha trabajado como programador del ncleo de sistemas operativos UNIX para compaas de I+D en el rea de Boston.

La llegada de Linux y el acceso del consumidor a la conectividad Internet 24n dio a Bob las claves para un sueo que albergaba desde 1982: tener su propio servidor y su propia LAN UNIX en su hogar. Lo que empez como un esfuerzo pragmtico por realizar su propio sistema seguro en Internet, rpidamente creci como una pasin por el usuario particular de UNIX. Ofrece gratuitamente al pblico, servicios de dise-o de firewall (cortafuegos o servidor de seguridad) de Linux basados en Web, al igual que un firewall popular y unas FAQ de LAN para ayudar a las personas a conse-guir configurar rpidamente sus sistemas LINUX de forma segura.

Ahora es ingeniero jefe de Nokia, y est diseando y programando productos de firewall para la familia de productos Ipsilon de Nokia.

Acerca de los revisores

Debbie Dailey es actualmente administradora de sistemas UNIX para un lder mundial en productos de conexin. Trabaj con mainframes durante seis aos antes de volver a la universidad para estudiar Ciencias de la computacin, especializndose en seguridad de redes. Debbie empez su carrera en UNIX como estudiante de prc-ticas de administracin de sistemas mientras asista a clase. Recientemente ha recibi do su licenciatura en Ciencias de la computacin por la Universidad de Purdue.

El Dr. Craig Hollabaugh ha sido un devoto de UNIX desde su primera confe renda en 1985. Administr estaciones de trabajo de Sun a la vez que segua un doc-torado en ingeniera elctrica sobre simulacin analgica interactiva en el Instituto de Tecnologa de Georgia. Luego desarroll herramientas de interfaz de C++ para el so-lucionador interactivo de gradientes paralelos distribuido en el laboratorio de din-mica de fluidos de computacin de la Universidad de Texas. En 1995, cuando cre su primera compaa (que naci con un capital nulo), Wireless Scientific, desarroll una aplicacin de telemetra industrial inalmbrica centrada en Linux. Posteriormente, su brillante carrera como consultor de Craig le llev a Cambridge, Massachussets, donde ahora es el vicepresidente de ingeniera en Kiava Systems. Se dedica a supervisar la in tegracin de Kiava y el desarrollo del hardware DSP incrustado. Su inters personal por la investigacin se centra en la simulacin interactiva en matemticas elementa-les y en la enseanza de la ciencia.

Uno de mis dos amigos de toda la vida muri mientras escriba este libro. A Gloria Frawley, quien a lo largo de la vida ha sido amiga, amante, hermano,

hermana, padre, hijo, marido, esposa. Hasta que volvamos a caminar juntos, gracias por el amor ms puro, ms verdadero y ms desinteresado que he

conocido, y por ser la mejor compaera que yo nunca pudiera haber esperado.

Agradecimientos

Nunca he comprendido por qu la gente escribe las secciones de agradecimien-tos. Quin se molesta en leerlas? Bien, ahora comprendo mejor el porqu.

As, quiero agradecer a Bill Sommerfeld por ofrecerme el primer tutorial cuando se dio cuenta de lo negado que era; a Gary Zaidenweber por recalcarme la necesidad de la seguridad y por ayudarme, en un primer momento, a configurar mi sistema; a mis otros amigos de Hewlett-Packard, que me dieron nimos para ir detrs de mi pa-sin, especialmente a Mary MacGregor y a mi administradora Cindy Buhner, quienes son mucho ms agradecidas de lo que pueden imaginarse; a Paul Fox por enviarme una copia de su propio firewall cuando estaba empezando esta andadura; a Craig Ho-llabaugh por su generosidad a la hora de dedicar semanas a la revisin editorial de las FAQ en las que se basa este libro; a Karl Runge por ofrecer semanas de revisin a las reglas de firewall; a numerosos clientes del grupo de noticias NorthEast Mediaone; a mi madre, quien confi en m para que encontrase mi propio camino cuando pasaba apuros con los problemas propios despus de terminar la carrera durante un ao; a Regina Weyer por estar siempre all, a millas de distancia y durante todos los aos; a Jonathan Kaplan por ser una fuente de esperanza y apoyo; a Old Person por ser un amigo constante y una fuente de nimo durante los ltimos aos; a Alan Small por re-hacer amablemente las partes ms difciles del texto de este libro, y, por ltimo, pero no menos importante, a Kitty Jarrett, mi editora, quien de alguna forma sobrevivi a toda mi inexperiencia. Kitty habla de forma suave y sin malicia. Simplemente observa y pregunta, a menudo con humor.

Introduccin

Llnux disfruta de una popularidad creciente entre los particulares aficionados y entre las pequeas empresas que se dirigen desde casa. El acceso directo y continuo a Internet est extendindose en las casas conforme el modem cable y los servicios de conexin ADSL se expanden en el mercado de consumo.

UNIX no es slo una plataforma de servidor popular, especialmente para servido-res web, sino que es tambin excelente como pasarela a una LAN particular. Detrs de esa pasarela, continuamente conectada a Internet, hay otras mquinas UNIX, pla-taformas Windows y NT, Macintosh e impresoras compartidas. Como resultado, los usuarios de sistemas pequeos deben afrontar cuestiones de seguridad en las que nunca antes haban tenido que pensar.

La seguridad de la red es una cuestin especialmente importante para los usuarios de Llnux con conexiones directas a Internet. Al contrario que un sistema sencillo de equipos personales, UNIX es un sistema operativo de pleno derecho y potente. Su propsito fundamental y su filosofa fue promover el poder compartir informacin en un entorno de investigacin 1 desarrollo. Como tal, creci para ser grande y crptico, y no para que lo usaran personas sin experiencia o sin proteccin.

Conectar un sistema UNIX a Internet es como anunciar una casa abierta al pbli-co, dejando la puerta principal abierta de par en par e irse a unas largas vacaciones. Si no se toman precauciones, los intrusos no deseados entrarn en ambos casos y esto ocurrir ms temprano que tarde.

El usuario medio de un sistema particular o de un sistema pequeo no tiene el tiempo, el inters o la paciencia necesaria para aprender todos los aspectos necesa-rios de la seguridad. El objetivo de este libro es ayudar a los usuarios de Llnux y de pequeos negocios a conseguir rpidamente medidas de seguridad de Internet, sin necesidad de convertirse en un experto en seguridad de redes. Las precauciones ne-cesarias no son difciles de implementar, pero encontrar toda la informacin en un si-tio, poniendo especial nfasis en cmo hacerlo, no es una tarea sencilla.

Lo que se explica en este libro

Para los usuarios de pequeos sistemas, las cuestiones de seguridad estn relacio-nadas casi exclusivamente con la seguridad externa, con protegerse a ellos mismos contra accesos de red no deseados desde el exterior. Por ejemplo, algunas familias pueden estar preocupadas en limitar cierta clase de accesos al sistema y a Internet a

XVI Introduccin

sus hijos, pero eso suele ser slo una parte del problema. Para la mayora, el entorno particular se considera como un entorno seguro.

Este libro gua a los usuarios particulares y de pequeos negocios en los pasos b-sicos que deben seguir para disear e implementar un firewall de filtrado de paque-tes. Sin embargo, un firewall es slo un paso ms para crear un sistema seguro. Tam-bin son necesarias las medidas de seguridad de alto nivel.

La seguridad del equipo requiere una aproximacin de varios niveles. Un solo nivel de un esquema de seguridad no es suficiente por s mismo. Cada nivel sucesivo depen-de de las protecciones que ofrecen los niveles inferiores. Los servicios que se habilitan, adems del firewall, forman la base para la seguridad del sistema. Por ello, este libro se preocupa de deshabilitar servicios innecesarios, seleccionar los servicios que se harn pblicos e identificar los servicios locales peligrosos que debe proteger el firewall.

Se examinan los tipos de proteccin de firewall que puede soportar fcil y eco-nmicamente un sistema pequeo. Entre otros temas se trata la idea que subyace al filtrado a nivel de paquete, cmo configurar su propio firewall, cmo configurar al-gunos servicios de forma ms segura en trminos del firewall y protocolos de comu-nicacin, enmascaramiento IP para esconder las identidades de los equipos internos cuando acceden a Internet, y asegurar que el firewall funcione.

Aunque no es el principal tema del libro, la Parte III, "Supervisin y seguridad y a nivel de sistema", explica las formas de ms alto nivel de control de acceso. Entre los temas se incluyen listas de control de acceso compatibles con tcp_wrappers y port-map, la configuracin del servidor, los servidores proxy y las prcticas generales de administracin de sistemas.

Por ltimo, el libro trata la seguridad del sistema y la supervisin de la integridad, detectando sondeos e intentos de acceso no autorizados antes de que tenga lugar una intrusin. Tambin se explican las herramientas para detectar signos de una situacin comprometida y cmo solucionarla si se descubre una situacin comprometida.

El texto y los ejemplos de este libro se basan en la versin Linux 6.0 de Red Hat. Los ejemplos estn escritos con la semntica ipchains. Como la conversin de ipfwadm a ipchains est en proceso actualmente, ya que los sistemas Linux estn usando ambas versiones en la actualidad, los ejemplos con semntica ipfwadm se incluyen en el Apndice B, "Ejemplos de firewalls y secuencias de comandos compatibles".

Lo que no se explica en este libro

Las directivas y los procedimientos de seguridad que una gran empresa necesita enfatizar son casi opuestos a los de un usuario de un sistema pequeo. La seguridad externa de Internet representa slo un pequeo porcentaje de las cuestiones de se-guridad de una empresa grande. Se estima que sobre el 90 % de las violaciones de se-guridad de nivel empresarial se originan desde el interior de las LAN corporativas, no desde Internet.

Este libro no intenta solucionar las cuestiones relativas a la seguridad interna del sistema, de los grandes sistemas, de la seguridad LAN multiusuario, de complejas con-figuraciones de proxy, de mtodos y tecnologas de autenticacin de nivel corporati-vo, de redes privadas virtuales, de cifrado, ni de firewall y arquitecturas de red a nivel comercial.

Intentos de piratera informtica: mbito del problema

Resulta dificil conseguir las estimaciones actuales del nmero de intentos de in-trusin. Quiz esto se deba a que los intentos sin xito en gran parte pasan desaper-

Introduccin XVII

cibidos y muchos sitios se han habituado a ellos y han empezado a considerarlos como habituales en Internet. Las estimaciones en los documentos del CERT oscilan entre un crecimiento constante con el crecimiento de Internet hasta un crecimiento exponencial en 1998.

Cualesquiera que sean los nmeros reales, no hay duda que los intentos globales de piratera en Internet y su nivel de sofisticacin estn creciendo. Los modelos de las exploraciones de puerto han cambiado desde simples sondeos de-unos pocos indica-dores de seguridad hasta una exploracin de todo el dominio del intervalo completo del puerto del servicio. Las ltimas herramientas de piratera se comparten en Inter-net a travs de sitios web, listas de distribucin y grupos de noticias. Varios grupos de hackers aficionados usan IRC (Internet Relay Chat) para coordinar exploraciones y ataques en grupo de forma corporativa, a menudo para reducir el riesgo de deteccin. Algunas de las debilidades recientemente descubiertas se publican rpidamente en In-ternet e inmediatamente las aprovechan los hackers. Los fabricantes y las organiza-ciones de supervisin de seguridad se encuentran en una constante carrera con la co-munidad hacker, en la que ambos intentan mantenerse un paso por delante del otro.

Qu puede conseguir un hacker informtico As que, quines son esos hackers y qu esperan conseguir? No existe una res-

puesta sencilla. Gran parte de la motivacin de un intento de piratera es realmente el resultado

de la curiosidad, un error, software pobremente escrito y sistemas mal configurados. Mucha de la actividad hacker la originan los adolescentes y estudiantes curiosos. Otra se origina desde sistemas comprometidos, especialmente en sitios universitarios. El propietario del sistema no es consciente de que su equipo lo est usando como base de operaciones un individuo no invitado. Tambin est el grupo poco estructurado de hackers que cooperan entre s mencionado anteriormente, personas para las que esta es la mejor forma de pasar un buen rato. El espionaje corporativo y poltico puede ser otra de las motivaciones, incluso para el usuario particular.

Como ejemplo de lo que el hacker espera obtener, algunas personas buscan el reto de resolver el puzzle. Algunos quieren permitirse el lujo de presumir. A otros sim-plemente les gusta entrar y destruir. Tambin se pueden obtener ganancias tangibles. Una nueva base de operaciones desde la que lanzar posteriores ataques, para que este sitio se vea comprometido como el culpable, es un hallazgo muy importante. De igual forma, un sitio comprometido ofrece una base o recursos de sistema para enviar co-rreos electrnicos de forma masiva. Un objetivo ms hostil es encontrar un sitio don-de establecer un almacn WAREZ. Por ltimo, est el obvio objetivo del robo, de ro-bar software u otra propiedad intelectual.

Qu tiene que perder Cuando un sistema est comprometido, al usuario particular medio se le causan

molestias y se suele asustar. La perdida de datos es un problema habitual, porque mu-chos hackers se introducen para borrar los discos duros de las personas. La perdida de datos tambin afecta a cualquier archivo del que no se haya hecho copia de segu-ridad, ya que un sistema comprometido debe volver a cargarse desde cero, se haya re-alizado dao o no.

La perdida del servicio suele ser otro problema comn. Un ISP normalmente des-conectar la cuenta hasta que se corrija el problema. El propietario del sistema debe primero averiguar el defecto de seguridad y aprender cmo hacer el sistema seguro antes de implementar el procedimiento de seguridad crtico. Esto lleva tiempo. Para

XVIII Introduccin

un negocio pequeo, estas dos consecuencias significan la prdida de ingresos, as como inconvenientes.

No slo el ISP ver al propietario como sospechoso, sino que el propietario pue-de sufrir una prdida de reputacin ante cualquiera a quien haya molestado alguna ac-cin lanzada por el hacker desde su sistema. Si el ISP no cree en su inocencia perso-nal, lo eliminar como cliente. Si su sitio ha sido identificado como un sitio WAREZ, o si el hacker atac los sitios equivocados, puede enfrentarse a problemas legales y a la denuncia pblica.

Por ltimo, se puede borrar o difundir la informacin personal y la informacin propietaria.

Firewalls frente a la piratera informtica en un mundo ideal

Desde un punto de vista conceptual, muchos o la mayora de los intentos de pi-ratera los puede detener el ISP o los proveedores de servicio de pasarela en el origen. El uso de un conjunto estndar de procedimientos de filtrado, aplicados en enruta-dores y pasarelas, terminarn con la mayora de este tipo de intentos de violacin de la seguridad. Por desgracia, esto slo es prctico en un mundo ideal, por ahora. No slo ser necesario convencer a todos los proveedores de servicio de cualquier lugar de su funcin y responsabilidad en el esfuerzo, sino que habr que habilitar a los en-rutadores de red para manejar la carga extra de filtrado de paquetes a escala masiva. Todava no nos hemos referido al hardware.

Sin embargo, estas clases de procedimientos de filtrado pueden implementarse f-cilmente en sistemas particulares y de pequeos negocios sin ninguna degradacin palpable del rendimiento. Estos procedimientos no slo ayudarn a mantener un sitio ms seguro, sino que tambin protegern a otras personas de los errores.

Consideraciones previ~

1 Conceptos bsicos subyacentes a los firewalls de filtrado de paquetes.

1 Conceptos bsicos subyacentes

a los firewalls de filtrado de paquetes

Un sitio pequeo puede tener acceso a Internet a travs de cable modem, una lnea ASDL o, a menudo, a travs de una conexin PPP a una cuenta de acceso telefnico. El equipo conectado directamente a Internet es el centro de las cuestiones de seguridad. Si se dispone de un equipo o una red de rea local (LAN, Local Area Network) pequea de equipos conectados, el centro de un sitio pequeo ser la mquina que tiene la conexin directa a Internet. Esta mquina ser la mquina firewall.

El trmino firewall (cortafuegos o servidor de seguridad) tiene varios significados dependiendo de su implementacin y de su propsito. En este momento inicial del libro, utilizaremos el trmino firewall para referirnos a la mquina conectada a Internet. Aqu es donde se implementarn las direc-tivas de seguridad. La tarjeta de interfaz de red externa de la mquina fire-wall es el punto de conexin, o pasarela, a Internet. El objetivo de un fire-wall es proteger lo que hay en el lado del usuario de esta pasarela de lo que hay al otro lado.

Una configuracin simple de firewall suele recibir el nombre de firewall bastin, debido a que es la principal lnea de defensa contra cualquier ataque desde el exterior. Todas las medidas de seguridad se implementan desde este defensor de su entorno. En consecuencia, es el que hace todo lo posible para proteger el sistema. Es el primer y nico bastin de defensa.

Detrs de esta lnea de defensa se encuentra el equipo o el grupo de equi-pos del usuario. El propsito de la mquina firewall puede ser simplemente

4 Captulo 1 Conceptos bsicos subyacentes a los firewalls de filtrado ...

servir como punto de conexin a Internet para otras maquinas de la LAN. Quiz detrs de este firewall, se ejecuten servicios privados locales, como una impresora compartida o un sistema de archivos compartido. Quiz se quiera que todos los equipos tengan acceso a la World Wide Web y que una de las mquinas albergue los registros financieros privados. Tambin se pue-de querer tener acceso a Internet desde esta mquina, pero que nadie ms disponga de este servicio. En algn momento, se querrn ofrecer servicios propios a Internet. Una de las mquinas podra estar albergando un sitio web propio para Internet. La configuracin y objetivos particulares determinarn las directivas de seguridad.

El propsito del firewall es hacer cumplir unas determinadas directivas de seguridad. Estas directivas reflejan las decisiones que se han tomado sobre qu servicios de Internet deben ser accesibles a los equipos, qu servicios se quieren ofrecer al exterior desde los equipos, qu servicios se quieren ofre-cer a usuarios remotos o sitios especficos y qu servicios y programas se quieren ejecutar localmente para uso privado. Todas las directivas de seguri-dad estn relacionadas con el control de acceso y uso autenticado de servi-cios privados o protegidos y de programas y archivos en los equipos.

Los sistemas particulares y de pequeos negocios no se enfrentan direc-tamente con todas las cuestiones de seguridad de un gran sitio corporativo, aunque las ideas bsicas y los pasos sean los mismos: simplemente no existen tantos factores a considerar y se presta especial atencin a la proteccin del sitio de los intentos ilcitos de acceso desde Internet. Un sitio corporativo debe prestar especial atencin a la seguridad interna, cosa que no sucede con un sitio particular. Un firewall para filtrado de paquetes es una aproximacin comn y una pieza de la seguridad de red y del control del acceso desde el exterior.

Antes de entrar en detalles de cmo programar un firewall, este captu-lo explica los conceptos subyacentes y mecanismos bsicos en los que se basa un firewall de filtrado de paquetes. Estos conceptos incluyen un mar-co general o referencia en el que se analiza para qu sirve la comunicacin de redes, cmo se identifican los servicios basados en red, qu es un pa-quete y los tipos de mensajes e informacin que se envan entre los equi-pos de una red.

El modelo de referencia TCP/IP para redes

Con el fin de poder ofrecer un entorno de trabajo para este captulo, y para el resto del libro, vamos a usar algunos trminos antes de definirlos en las siguientes secciones de este captulo. Estas definiciones son ya conocidas en el mundo informtico y no sern ajenas para las personas que trabajan con redes, pero pueden ser nuevas para los menos iniciados tcnicamente. Si todo esto es nuevo para el lector, no se preocupe. Ahora mismo, lo nico que pretendemos es ofrecerle un marco conceptual donde colocar las prximas definiciones, de forma que tengan ms sentido.

Captulo 1 Conceptos bsicos subyacentes a los firewalls de filtrado ... 5

Si tiene conocimientos acadmicos formales en redes, estar familiarizado con el modelo de referencia OSO) de interconexin de sistemas abiertos. El modelo de referencia ISO se desarroll a finales de los 70 y principios de los 80 para ofrecer un marco para los estndares de interconexin de redes. El modelo de referencia ISO es un modelo acadmico, formal y elegante. Los li-bros de texto y los acadmicos usan este modelo como marco conceptual cuando hablan de redes.

Las redes comenzaron a implantarse a finales de los 70 y principios de los 80, de forma que el mundo sigui su curso durante los siete aos que el mo-delo de referencia ISO se estuvo preparando. Como TCP/IP se convirti en el estndar de facto para la comunicacin en Internet entre mquinas UNIX du-rante este tiempo, se desarroll un segundo modelo informal llamado mode-lo de referencia TCP/IP. En vez de ser un ideal acadmico, el modelo de re-ferencia TCP/IP lo elaboraron los fabricantes y los programadores que, por fin, llegaron a un acuerdo sobre las comunicaciones en Internet. Adems, este modelo es ms sencillo que el modelo ISO, por que desarrolla TCP/IP desde el punto de vista del programador, partieno de lo que es el mundo real y prctico. Por tanto, donde ISO traza explcitamente siete capas, el modelo TCP/IP las agrupa en cuatro.

Este libro usa el modelo de referencia TCP/IP. Como la mayora de las per-sonas con cierto bagaje en informtica, tendemos a usar el vocabulario ISO, pero para referirnos al modelo conceptual de TCP/IP.

La comunicacin de red se explica como un modelo de capas, donde la comunicacin se realiza entre capas adyacentes sobre un equipo individual, y entre capas paralelas sobre equipos que se comunican. El programa que se ejecuta (por ejemplo, un navegador Web) se encuentra en la parte superior, en la capa de aplicacin, comunicndose con otro programa sobre otro equi-po (por ejemplo, un servidor web).

Para que la aplicacin cliente del navegador web enve una peticin de una pgina Web a la aplicacin del servidor web, tiene que usar llamadas de biblioteca y de sistema para obtener la informacin del navegador web y encapsularla en un mensaje apropiado para poder transportarlo entre dos programas por la red. Estos mensajes son segmentos TCP o datagramas UDP de la capa de transporte. Para construir estos mensajes, la capa de aplicacin llama a la capa de transporte para que ofrezca este servicio. Los mensajes de la capa de transporte saben cmo entregar mensajes entre un programa de un equipo y un programa situado en el otro extremo de la red. Tanto el modelo ISO como el modelo TCP/IP llaman a esta capa la capa de transporte, aunque el modelo ISO divide esta capa en varias capas funcionales.

Para que los mensajes de la capa de transporte se entreguen entre los dos programas, es necesario enviar los mensajes entre los dos equipos. Para ello, la capa de transporte hace uso de funciones del sistema operativo que toman el mensaje de transporte TCP o UDP y lo encapsulan en un datagrama de Inter-net adecuado para enviarlo al otro equipo. Estos datagramas son paquetes IP. Los paquetes IP de Internet se envan entre los dos equipos a travs de lnter-


net. La capa de Internet sabe cmo comunicarse con el equipo situado en el otro extremo de la red. El modelo de referencia TCP /IP llama a esta capa la capa de Internet. Para esta capa se suele usar el vocabulario del modelo de referen-cia ISO, por lo que se suele llamar la capa de red. Los dos son uno y el mismo.

Debajo de la capa de red est la capa de subred. De nuevo, el paquete se encapsula en un encabezado Ethernet. En la capa de subred, el mensaje se llama ahora trama de Ethernet. Desde el punto de vista de TCP/IP, la capa de subred es un conjunto de todo lo que sucede para conseguir que el paquete se entregue al siguiente equipo. Este conjunto incluye todo el direcciona-miento y los detalles de entrega asociados con el enrutamiento de la trama entre los equipos, de un enrutador al siguiente, hasta que, por ltimo, se al-canza el equipo destino. Esta capa incluye la traduccin de la trama de red de una clase de red a otra a lo largo del camino. La mayoa de las redes actuales son redes Ethernet, pero tambin existen redes ATM, redes FIDI, redes Token Ring, etc., es decir, cualquier tecnologa de red que se est usando para trans-portar las tramas entre dos equipos. Este grupo incluye el hardware, los ca-bles fsicos que conectan dos equipos, las seales y el cambio del voltaje, que representan los bits individuales de una trama y la informacin de control ne-cesaria para crear una trama a partir de un byte individual.

La idea general, como se muestra en la Figura 1.1, es que la capa de apli-cacin representa la comunicacin entre dos programas. La capa de trans-porte representa cmo se realiza la comunicacin entre los dos programas. Los programas se identifican por nmeros llamados puertos de servicio. La capa de red representa cmo se transporta esta comunicacin entre los dos equipos terminales. Los equipos, o sus tarjetas de interfaz de red individua-les, se identifican por nmeros llamados direcciones /P. La capa de subred re-presenta cmo se transporta la comunicacin entre cada equipo individual a lo largo de la trayectoria. En una red Ethernet, estas interfaces de red del equi-po se identifican por nmeros llamados direcciones Ethernet, con las que puede que el usuario est familiarizado, como la direccin MAC de hardwa-re impresa en la tarjeta de red.

La siguiente seccin muestra la informacin que deben intercambiar estas capas y que termina usando un firewall de filtrado de paquetes.

Puertos de servicio: la puerta a los programas en su sistema

Los servicios basados en red son programas que se ejecutan en una m-quina a los que pueden acceder otros equipos de la red. Los puertos de ser-vicio identifican los programas y las sesiones individuales o las conexiones que se realizan. Los puertos de servicio son los nombres numricos para los diferentes servicios de red. Tambin se usan como identificadores numricos para los extremos finales de una conexin particular. Los nmeros de puerto de servicio van desde O hasta el 65535.


.-----C-a_p_a_d_e_a_p_li_c_ac_i__n-----, E Programas de cliente ______ ~

y servidor

Capa de transporte Puertos de servicio

y protocolos TCP y UDP

Capa de red/Internet Paquetes IP, direccin IP

y mensajes ICMP

Capa de subred Tramas Ethernet

y direcciones MAC

Cable de cobre, cable de fibra ptica, microondas

Figura 1.1.

Navegador web Servidor web

Envo de mensajes programa a programa

Envo de mensajes equipo origen a equipo destino

Capa de vnculos de datos OSI Envo de mensajes equipo a equipo (interfaz de red del conmutador)

Capa fsica OSI Envo de bit/seal fisica

Modelo de referencia TCP/IP.

Los programas de servidor (por ejemplo, los demonios) escuchan las co-nexiones entrantes en un puerto de servicio asignado a ellos. Por convencin histrica, los servicios de red principales estn asignados a nmeros de puer-to bien conocidos, en el intervalo inferior, desde 1 a 1023. Estas asignaciones numricas de puerto a servicio las coordina la Autoridad de asignacin de n-meros de Internet (IANA, Internet Assigned Numbers Autboriry) como un conjunto de convenciones o estndares universales de mutuo acuerdo.

Estos puertos de intervalo inferior se llaman puertos privilegiados por-que sus propietarios son programas que ejecutan privilegios del nivel de sis-tema (es decir, superusuario o root). La idea es incrementar la confianza en que el programa del cliente est realmente conectado al servicio anunciado que se desea. Esta es la intencin, pero no una garanta. El usuario nunca pue-de tener la absoluta certeza de que una mquina remota o un servicio remo-to es quien o lo que dice ser.

Un servicio anunciado es simplemente un servicio disponible en Internet desde su puerto asignado. Si una mquina no ofrece un servicio particular y alguien intenta conectarse al puerto asociado con dicho servicio, no ocurri-r nada. Estn llamando a la puerta, pero nadie vive all para abrirle. Por ejem-plo, los servidores web estn asignados al puerto 80. Si una mquina no eje-cuta un servidor web y alguien intenta conectarse al puerto 80, el programa


cliente recibe un mensaje de error procedente de la mquina indicando que ese servicio no est disponible.

Los nmeros de puerto superiores, desde 1024 hasta 65535, se llaman puertos no privilegiados. Sirven para un propsito doble. Casi siempre, es-tos puertos se asignan de forma dinmica al cliente de una conexin. La com-binacin de pares de nmeros de puerto cliente y servidor, junto con sus res-pectivas direcciones IP, identifican unvocamente la conexin.

Adems, los puertos en el intervalo de 1024 hasta 49151 estn registrados por el IANA. Estos puertos pueden usarse como parte del conjunto no privi-legiado general, pero tambin se asocian a servicios particulares como SOCKS o servidores X Window. En un principio, la idea era que esos servicios que se ofrecan en los puertos superiores no se ejecutaran con privilegios de root. Eran para que los usaran los programas no privilegiados, de nivel de usuario. En cada caso concreto, se puede mantener o no la convencin.

Asignacin de nombres de servicio a nmero de puerto

Las versiones de Llnux incluyen una lista de los nmeros de puerto de servicio co-munes. La lista se encuentra en el archivo /etc/services. Cada entrada consta de un nombre simblico para un servicio, el nmero de puerto asignado a l, el protocolo (fCP o UDP) sobre el que se ejecuta el servicio y cualquier alias opcional para el servicio. La siguiente tabla muestra algunas asignaciones habi-tuales de nombre de servicio a nmero de puerto, tomada de la versin 6.0 de Red Hat.

Nombre del puerto Nmero de puerto/Protocolo Alias

ftp 21/tcp telnet 23/tcp smtp 25/tcp mail whois 43/tcp nicname domain 53/tcp nameserver domain 53/udp nameserver finger 79/tcp pop-3 110/tcp nntp 119/tcp readnews www 80/tcp http auth 113/tcp ident ntp 123/udp https 443/tcp

Observe que los nombres simblicos asociados con los nmeros de puer-to varan segn la versin de Linux. Los nombres y los alias difieren. Los n-meros de puerto no difieren.

Tenga tambin en cuenta que los nmeros de puerto estn asociados con un protocolo. La IANA ha intentado asignar el mismo nmero de puerto de servicio tanto al protocolo TCP como al protocolo UDP, sin tener en cuenta si un servicio particular usa ambos protocolos. La mayora de los servicios usan un protocolo u otro. El servicio domain usa ambos protocolos.


Paquetes: mensajes de red IP El trmino paquete hace referencia a un mensaje de red (IP) del protoco-

lo de Internet. El estndar IP define la estructura del mensaje que se enva en-tre dos equipos sobre la red. Es el nombre que se asigna a un mensaje dis-creto y sencillo o la pieza de informacin que se enva sobre una red Ethernet. Estructuralmente, un paquete contiene un encabezado de informa-cin y un cuerpo de mensaje que contiene los datos que se transfieren. El cuerpo del paquete IP, sus datos, forman un solo mensaje de un protocolo de nivel superior o una pieza (un fragmento) de ste.

El mecanismo firewall IP (IPFW) que se incluye en Linux es compatible con tres tipos de mensajes IP: ICMP, UDP y TCP. Un paquete ICMP (Internet Control Message Protocol, Protocolo de mensajes de control de Internet) es un mensaje IP de control y estado del nivel de red. A nivel de red, los mensa-jes ICMP contienen informacin sobre la comunicacin entre los dos equipos finales. Un paquete IP UDP transporta datos de la capa de transporte UDP en-tre dos programas basados en red, sin ninguna garanta de xito en cuanto a la entrega o sobre el orden de la entrega de paquetes. El envo de un paquete UDP a otro programa es como enviar una postal. Un paquete IP TCP (Trans-misin Control Protocol, Protocolo de control de transmisin) tambin trans-porta datos de la capa de transporte TCP entre dos programas de red, pero el encabezado del paquete contiene informacin adicional de estado para man-tener una conexin confiable y activa. El envo de un paquete TCP es muy pa-recido a mantener una conversacin telefnica con otro programa. La mayo-ra de los servicios de red de Internet usan el protocolo de comunicacin TCP en vez del protocolo de comunicacin UDP. En otras palabras, la mayora de los servicios de Internet se basan en la idea de una conexin activa con co-municacin bidireccional entre un programa cliente y un programa servidor.

Todos los encabezados de paquetes IP contienen las direcciones origen y destino IP y el tipo de mensaje de protocolo IP (ICMP, UDP o TCP) que contie-ne el paquete. Adems de esto, el encabezado de un paquete contiene campos algo distintos en funcin del tipo de protocolo. Los paquetes ICMP contienen un campo tipo que identifica el tipo de mensaje de control o estado, junto con un segundo campo cdigo que define el mensaje de forma ms especfica. Los paquetes UDP y TCP contienen nmeros de puerto de servicio origen y desti-no. Los paquetes TCP contienen informacin adicional sobre el estado de la co-nexin e identificadores nicos para cada paquete. El encabezado tambin con-tiene otros campos. Los dems campos no son visibles o tiles generalmente en la capa de filtrado de paquetes IP. (casi todos los libros sobre redes TCP/IP de-fine los restantes campos del encabezado. Una referencia es TCP/JP Clearly Explained de Pete Loshin, publicado por Academic Press).

Tipos de mensajes IP: ICMP Un paquete ICMP es un mensaje de control y estado IP de la capa de red.

Su encabezado contiene las direcciones IP origen y destino, el identificador

..:.:],_:. . ;;

..... _ ti


de protocolo ICMP y un tipo de mensaje ICMP. Un tipo de mensaje ICMP in-dica si el paquete es un comando, una respuesta a un comando, informacin de estado o una condicin de error. Los tipos de mensaje individuales ICMP se explican en el Captulo 3, "Creacin e instalacin de un firewall". Los men-sajes ICMP no contienen puertos origen y destino. No se envan entre pro-gramas, sino entre los equipos origen y destino.

Un ejemplo de mensaje ICMP es un mensaje de estado de error. Si inten-ta conectarse a un servidor web remoto y el servidor web no se est ejecu-tando en el host remoto, el host remoto devolver un mensaje de error ICMP indicando que el servicio no existe. Los campos de inters del encabezado del paquete se muestran en la Figura 1.2.

Navegador web Puerto 14000 Direccin 192.168. I 0.30

Navegador web Puerto 14000 Direccin 192.168. I 0.30

Protocolo: ICMP

Host remoto Puerto 80 Direccin 10.10.22.85

Host remoto Puerto 80 Direccin 10.10.22.85

Tipo de mensaje: Servicio no disponible Direccin de origen: 10.10.22.85 Direccin destino: 192.168.10.30

Figura 1.2. Mensaje de error ICMP entrante.

Tipos de mensajes IP: UDP UDP es un protocolo de entrega de transporte sin estado (es decir, sin co-

nexin) y no confiable. Un programa enva un mensaje UDP, que puede reci-birse o no y responder a l o no. No se devuelve acuse de recibo. No se ofre-ce control de flujo, por lo que un datagrama UDP simplemente se elimina si no se puede procesar durante el camino.


Un encabezado de paquete UDP contiene las direcciones IP origen y des-tino, el tipo de protocolo UDP y los nmeros de puerto de servicio origen y destino.

No es UDP confiable?

UDP se conoce como un servicio de datagrama no confiable. No confiable no im-plica ninguna connotacin negativa para la utilidad de UDP. No confiable, en este caso, significa que no se realiza ningn esfuerzo para asegurar la entrega correcta. Por ello, sin la sobrecarga de TCP orientada a la conexin y confiable, la trasferencia de datos basada en UDP es varias veces ms rpida que la transferencia de datos ba-sada en TCP. Por ello, UDP se presta a tipos de comunicacin sencillas de peticin y respuesta.

Como ejemplo, la mquina puede intentar peridicamente contactar con un servidor remoto de tiempo de la red. Los servidores de tiempo de Inter-net tienen asignado el puerto de servicio UDP 123. El servidor de tiempo de-volver la hora actual. El sistema del usuario puede actualizar el reloj con la informacin ms precisa procedente del servidor de tiempo. Si el intercam-bio no tiene xito porque el servidor de tiempo no est activo en la mquina remota, o porque la mquina remota est apagada en ese momento, se de-vuelve un mensaje de error ICMP, Servicio o host no disponible.

Como se muestra en la Figura 1.3, el programa cliente del sistema inicia la peticin. Se asigna un puerto no privilegiado a la peticin. Se construye una peticin de paquete UDP saliente con el puerto no privilegiado como puerto origen. El puerto destino es el conocido puerto de servicio de tiem-po, 123.

El servidor de tiempo responde con un paquete UDP que contiene la hora actual. Llegar un paquete de respuesta UDP entrante desde la direccin IP del servidor originado en el puerto 123, dirigido a la direccin IP y al puerto no privilegiado destino proporcionado inicialmente.

Tipos de mensajes IP: TCP La gran mayora de servicios de red se ejecutan sobre TCP. Los mensajes

se envan de forma confiable en ambas direcciones como parte de una co-nexin activa entre dos programas; se entregan sin error, sin prdidas o du-plicaciones, y de forma ordenada. Cada segmento TCP se confirma despus de recibirse. Cada segmento TCP se identifica mediante un numero de se-cuencia nico. Se usan los bits indicadores para definir el estado de la co-nexin.

Si un segmento TCP IP encapsulado es ms largo que la unidad de trans-misin mxima (MTU, Maximum Transmission Unit) de la red subyacente, el segmento se divide en fragmentos (como en la mayora de las redes Ethernet, la MTU es de 1500 bytes como mximo por trama Ethernet). Los fragmentos se identifican como pertenecientes a un segmento particular y se envan in-


dividualmente, para que el equipo destino final los reconstruya en el seg-mento TCP original.

Cliente de tiempo local Puerto 14000

Direccin 192.168. I 0.30

Cliente de tiempo local Puerto 14000

Direccin 192.168. I 0.30

Protocolo: UDP Direccin origen: 192.168. I 0.30

Puerto origen: 14000 Direccin destino: 10.10.22.85

Puerto destino: 14000

Servidor de tiempo Puerto 123

Direccin 10.10.22.85

Servidor de tiempo Puerto 123


Protocolo: UDP Direccin origen: 10.10.22.85

Puerto origen: 123 Direccin destino: 192.168. I 0.30

Puerto destino: 14000

Figura 1.3. Peticin y respuesta UDP.

Cuando un programa cliente inicia una conexin a un servidor, se se-lecciona un puerto del grupo no privilegiado del cliente. La combinacin de la direccin IP del cliente y del nmero de puerto definen el socket del cliente. En el lado del servidor, la combinacin de direccin IP de host y el nmero de puerto conocido del servidor forman el socket del servidor. La conexin entre cliente y servidor se define de forma unvoca mediante este par de sockets.

Cada conexin individual entre un cliente dado y un servidor, quiz slo una en un conjunto de conexiones simultaneas a dicho servidor (por ejem-plo, un servidor web), se define unvocamente mediante la direccin origen y el nmero de puerto del cliente, junto con la direccin IP del servidor y el nmero de puerto asignado.

El encabezado de un paquete TCP contiene las direcciones origen y des-tino IP, el tipo de mensaje de protocolo TCP, los puertos de servicio destino y los nmeros de secuencia y de confirmacin, as como los indicadores de control que se usan para crear y mantener un circuito virtual confiable, o co-nexin bidireccional activa.


Una conexin TCP tpica: cmo visitar un sitio web remoto

Un ejemplo habitual de conexin TCP consiste en dirigirse a un sitio web usando el navegador de Netscape (es decir, conectarse a un servidor web). Esta seccin muestra los aspectos de establecimiento de conexin y de co-municacin activa que sern importantes para el filtrado de paquetes IP en los captulos posteriores.

Qu sucede? Como se muestra en la Figura 1.4, se ejecuta un servidor web en una mquina situada en cualquier lugar, esperando una peticin de conexin sobre el puerto de servicio TCP 80. El usuario hace clic en el vn-culo de un URL en Netscape. Parte del URL se analiza sintcticamente como un nombre de host, el nombre de host se traduce en la direccin IP del ser-vidor web; y se asigna un puerto no privilegiado al explorador (por ejemplo, 14000) para la conexin. Se crea un mensaje HTTP para el servidor web. El mensaje se encapsula en un mensaje TCP, dentro de un encabezado de pa-quete IP y se enva al exterior. En este caso, el encabezado contiene los cam-pos que se muestran en la Figura 1.4.

Navegador web Puerto 14000

Direccin 192.168. I 0.30

Protocolo: TCP Direccin origen: 192.168.10.30

Puerto origen: 14000 Direccin destino: 10.10.22.85

Puerto destino: 80 (www)

Servidor web Puerto 80


Indicadores: SYN (peticin de sincronizacin de conexin)

Figura 1.4. Peticin de conexin de un cliente TCP.

En el encabezado se incluye informacin adicional que no es visible a ni-vel de filtrado de paquetes. Sin embargo, describir los nmeros de secuencia asociados con los indicadores SYN y ACK ayuda a clarificar lo que ocurre du-rante el saludo de tres vas. Cuando el programa cliente enva el primer men-saje de peticin de conexin, se incluye un nmero de secuencia de sincro-nizacin con el indicador SYN. El cliente solicita una conexin con el


servidor y la enva junto con un nmero de secuencia inicial que usar como base para numerar el resto de los mensajes que debe enviar.

El servidor recibe el paquete. Se enva al puerto de servicio 80. El ser-vidor escucha el puerto 80, por lo que se le notifica una peticin de cone-xin entrante (el indicador de peticin de sincronizacin SYN) desde la di-reccin IP origen y del par de puertos de socket ( 192.168. I 0.30). El servidor asigna un nuevo socket en su extremo ( 10.10.22.85) y lo asocia con el soc-ket del cliente.

El servidor web responde con una confirmacin (ACK) al mensaje SYN, junto con su propia peticin de sincronizacin (SYN), como se muestra en la Figura 1.5. Ahora la conexin est semiabierta.


Direccin 192.168. I 0.30




Puerto origen: 80 (www) Direccin destino: 192.168.10.30

Puerto destino: 14000 Indicadores: ACK (confirmacin de sincronizacin)

SYN (peticin de sincronizacin de conexin)

Figura 1.5. Confirmacin de peticin de conexin del servidor TCP.

Dos campos no visibles a nivel de filtrado de paquetes se incluyen en el encabezado SYN-ACK. Junto con el indicador ACK, el servidor incluye el n-mero de secuencia del cliente incrementado en uno. El propsito de la con-firmacin es reconocer el mensaje al que el cliente hace referencia por su n-mero de secuencia. El servidor lo confirma incrementando el nmero de secuencia del cliente, lo que indica que recibi el mensaje, y el nmero de secuencia + 1 es el siguiente mensaje que el servidor espera recibir. El clien-te puede enviar una copia del mensaje SYN original, ahora que el servidor ha recibido un acuse de recibo del mismo.

El servidor tambin define el indicador SYN en el primer mensaje. Con el primer mensaje del cliente, se incluye un numero de secuencia de sincroni-zacin con el indicador SYN. El servidor enva su propio nmero de secuen-cia inicial para su mitad de la conexin.

Captulo 1 Conceptos bsicos subyacentes a los firewalls de filtrado... 15

Este primer mensaje es el nico mensaje que el servidor enviar con el in-dicador SYN activado. ste y todos los mensajes siguientes tienen activado el indicador ACK. La presencia del indicador ACK en todos los mensajes de ser-vidor, cuando se compara con la ausencia de un indicador ACK en el primer mensaje de cliente, ser una diferencia importante cuando queramos obtener la informacin disponible para construir un firewall.

La mquina del usuario recibe este mensaje y responde a l con su propia confirmacin, despus de lo cual, se establece la conexin. La Figura 1.6 muestra un esquema de esta situacin. De ahora en adelante, tanto el cliente como el servidor activan el indicador ACK. El indicador SYN no lo volver a activar ningn programa.


Direccin 192.168. I 0.30




Punto origen: 14000 Direccin destino: 10.10.22.85

Puerto destino: 80 (www) Indicadores: ACK (confirmacin)

Figura 1.6. Establecimiento de la conexin TCP.

Con cada confirmacin, los programas cliente y servidor incrementan su nmero de secuencia del proceso asociado en el nmero de paquetes conti-guos secuenciales recibidos desde que se envi el ltimo ACK, indicando la recepcin de los paquetes, as como el siguiente mensaje que el programa es-pera recibir.

A medida que el navegador recibe la pgina Web, la mquina recibe men-sajes de datos desde el servidor web con encabezados de paquete, como se muestra en la Figura l. 7.

Al final, se envan los mensajes adicionales con indicadores para cerrar la conexin, pero estos indicadores no estn disponibles a nivel de filtrado de paquetes. Los indicadores importantes son SYN y ACK. El indicador SYN se activa cuando un cliente y un servidor intercambian los primeros dos men-sajes durante el establecimiento de la conexin. Todos los mensajes siguien-tes entre cliente y servidor tienen el conjunto de indicadores ACK.



Direccin 192.168.10.30




Puerto origen: 80 (www) Direccin destino: 192.168.10.30

Puerto destino: 14000 Indicadores: ACK (confirmacin)

Figura 1. 7. Conexin servidor a cliente TCP en marcha.

Resumen

Los sencillos ejemplos de este captulo muestran la informacin en la que se basan los firewalls de filtrado de paquetes. El Captulo 2, "Conceptos

11 Filtrado de paquetes y medidas

bsicas de seguridad

2 Conceptos del filtrado de paquetes. 3 Creacin e instalacin de un firewall. 4 Redes de permetro, firewalls mltiples y problemas con los

LAN. 5 Depuracin de las reglas del firewall.

2 Conceptos del t11trado

de paquetes

El trmino firewall tiene varios significados, dependiendo del mecanismo que se use para implementarlo, el nivel de la pila del protocolo TCP/IP sobre el que funciona el firewall y las arquitecturas de red y enrutamiento que se usen. Tres de los significados ms comunes se refieren a un firewall de filtra-do de paquetes, a una pasarela de aplicacin, tambin llamada un firewall de host explorado, y a una pasarela de circuito del nivel de aplicacin, tambin llamada firewall proxy.

Un firewall de filtrado de paquetes se suele implementar dentro del siste-ma operativo y funciona en las capas de transporte y red de la red IP. Prote-ge el sistema realizando las decisiones de enrutamiento despus de filtrar los paquetes basndose en la informacin del encabezado del paquete IP.

Una pasarela de aplicacin, o firewall de host explorado, se implementa en los niveles de arquitectura de red y configuracin del sistema. El trfico de red nunca pasa a travs de la mquina de aplicacin de pasarela. Todo el tr-fico, interno y externo, debe realizarse a travs de la mquina de pasarela. Los usuarios locales deben iniciar la sesin en la mquina de pasarela y acceder a Internet desde all. Adems, la mquina de pasarela puede estar protegida me-diante un firewall de filtrado de paquetes tanto en la interfaz externa como en la interna.

Un firewall proxy se suele implementar como aplicacin independiente para cada servicio con el que se desea usar un proxy. Cada aplicacin proxy aparece ante el servidor como el programa cliente, y ante el cliente como el servidor real. Los programas cliente especiales, o programas de cliente con-figurados especialmente, se conectan al servidor proxy en vez de a un servi-

20 Captulo 2 Conceptos del filtrado de paquetes

dor remoto. El proxy establece la conexin al servidor remoto en el lado de la aplicacin cliente, despus de sustituir la direccin origen del cliente por la suya propia. Las aplicaciones proxy pueden asegurar la integridad de los datos, es decir, que se estn intercambiando los datos apropiados para el ser-vicio, que se filtran contra virus y se hacen cumplir las directivas de alto ni-vel de control de acceso detallado.

Este libro explica las ideas en las que se basa un firewall de filtrado de pa-quetes. Las tres perspectivas controlan a qu servicios se puede acceder y por quin. Cada perspectiva tiene sus puntos fuertes y ventajas, que se ba-san en la distinta informacin disponible en las diferentes capas del modelo de referencia TCP/IP Los grandes productos firewall comerciales suelen in-corporar alguna combinacin de filtrado de paquetes, host explorados pro-tegidos y funcionalidad proxy para aplicaciones en un paquete de seguridad multinivel.

El Captulo 1, "'Conceptos bsicos subyacentes a los firewalls de filtrado de paquetes", explic los conceptos y la informacin en la que se basa un fi-rewall. Este captulo explica cmo se usa esta informacin para implementar reglas de firewall. Gran parte de este captulo se centra en el filtrado de pa-quetes entrantes, los tipos de paquetes que se deben filtrar y por qu. Se hace menos nfasis en el filtrado de paquetes salientes ya que un sitio pequeo es un entorno razonablemente seguro sin las cuestiones de seguridad internas adicionales a las que debera hacer frente una organizacin ms grande. De hecho, no todos los firewall comerciales ofrecen la capacidad de filtrar pa-quetes salientes. Esto se debe en parte al apreciable coste de rendimiento que el filtrado de paquetes impone a los grandes enrutadores. El hardware no es lo suficientemente rpido, todava.

Tanto el Captulo 1 como este captulo explican con detalle los puertos de servicio TCP y UDP La ltima seccin de este captulo, "Servicios de red pblicos frente a privados", describe los servicios de red comunes que exis-ten en una mquina UNIX y qu hacen, as como algunas recomendaciones, por si quisiera ejecutar estos servicios sobre una mquina firewall.

Un Firewall de filtrado de paquetes

Un firewall de filtrado de paquetes IPFW consta de una lista de reglas de aceptacin y denegacin. Estas reglas definen explcitamente los paquetes que se permiten pasar y los que no a travs de la interfaz de red. Las reglas del firewall usan los campos del encabezado del paquete, explicadas en el Ca-ptulo 1, para decidir si enrutar un paquete hacia su destino, eliminar el pa-quete o bloquear un paquete y devolver una condicin de error a la mquina emisora. Estas reglas se basan en la tarjeta de interfaz de red especfica y en la direccin IP del host, las direcciones IP origen y destino del nivel de red, los puertos de servicio UDP y TCP de la capa de transporte, los indicadores de conexin TCP, los tipos de mensaje ICMP del nivel de red y en si el pa-quete es entrante o saliente.

Captulo 2 Conceptos del filtrado de paquetes 21

Usando un hbrido del modelo de referencia TCP/IP, un firewall de filtra-do de paquetes funciona en las capas de red y de transporte, como se mues-tra en la Figura 2.1.

Capa de aplicacin Programas cliente

y servidor

Capa de transporte Puertos de servicio de los

protocolos TCP y UDP

Capa de red Paquetes IP, direccin IP

y mensajes ICMP

Capa de vnculo de datos Tramas Ethernet y direccin MAC

Capa fisica Cable de cobre, cable

de fibra ptica y microondas

Cliente telnet Servidor web

Firewall Puertos TCP/UDP origen y destino

Indicadores de estado de la conexin TCP Direccin origen y destino IP Cdigos de control ICMP IP

---------1~~-T_a_ri_eta~d_e_in_t_erfa~z_d_e_r_e_d~~

Figura 2.1. Ubicacin del firewall en el modelo de referencia TCP/IP.

La idea general es que el usuario debe controlar con mucho cuidado lo que sucede entre Internet y la mquina que se ha conectado directamente a Internet. Sobre la interfaz externa a Internet, el usuario filtrar individual-mente lo que procede del exterior y lo que sale de la mquina de forma tan precisa y explcita como sea posible.

Para una configuracin de mquina sencilla, podra servir de ayuda pen-sar en la interfaz de red como en un par E/S. El firewall filtra independiente-mente lo que entra y lo que sale a travs de la interfaz. El filtrado de entrada y el filtrado de salida pueden tener reglas completamente diferentes. Las lis-tas de reglas que definen lo que puede entrar y lo que puede salir se llaman cadenas. El par E/S es la lista de reglas tanto de la cadena de entrada como de la cadena de salida. Las listas se llaman cadenas porque se compara un pa-quete con cada regla de la lista, una a una, hasta que se encuentra una coin-cidencia o la lista se termina, como se describe en la Figura 2.2.

Esto suena bastante fuerte, y lo es, pero no es un mecanismo de seguri-dad infalible. Es slo parte del problema, una capa de todo el esquema de se-guridad. No todos los protocolos de comunicacin de aplicacin se prestan


para el filtrado de paquetes. Este tipo de filtrado pertenece a un nivel dema-siado bajo como para permitir autenticacin y control de acceso preciso. Es-tos servicios de seguridad deben proporcionarse a niveles ms altos. IP no tie-ne la capacidad de verificar que el emisor es quien o lo que dice ser. La nica informacin de identificacin disponible en este nivel es la direccin origen del encabezado de paquete IP La direccin origen se puede modificar fcil-mente. Ni la capa de red ni la de transporte pueden verificar que los datos de la aplicacin son correctos. Sin embargo, el nivel de paquete permite un con-trol ms preciso y sencillo sobre el acceso directo a un puerto, el contenido del paquete y los protocolos de comunicacin correctos que se pueden es-tablecer fcilmente o de forma adecuada, en niveles superiores.

Interfaz de red

Paquete de entrada Coincide con la regla 31

Cadena de entrada

Coincide con la regla 11 Coincide con la regla 21

Coincide con la regla 21 Coincide con la regla 11

Cadena de salida

Coincide con la regla 31 Paquete de salida

Figura 2.2. Cadenas de entrada y salida.

Sin filtrado a nivel de paquete, el filtrado de alto nivel y las medidas de se-guridad proxy son intiles o probablemente ineficaces. Hasta cierto punto,


deben basarse en la exactitud del protocolo de comunicacin subyacente. Cada nivel de la pila del protocolo de seguridad agrega otra pieza que los de-ms niveles no pueden ofrecer fcilmente.

Eleccin de una directiva predeterminada de filtrado de paquetes

Cada cadena del firewall tiene una directiva predeterminada y una colec-cin de acciones a realizar en respuesta a tipos de mensajes especficos. Cada paquete se compara, uno a uno, con cada regla de la lista hasta que se en-cuentra una coincidencia. Si el paquete no coincide con ninguna regla, fra-casa y se aplica la directiva predeterminada al paquete.

Hay dos perspectivas bsicas para un firewall: Denegar todo de forma predeterminada y permitir que pasen paque-tes seleccionados de forma explcita. Aceptar todo de forma predeterminada y denegar que pasen paquetes seleccionados de forma explcita.

La directiva de denegar todo es la propuesta que se recomienda. Esta apro-ximacin facilita la configuracin de un firewall seguro, pero es necesario ha-bilitar explcitamente cada servicio y la transaccin de protocolo relacionada que quiera el usuario (vase la Figura 2.3). Esto significa que se debe com-prender el protocolo de comunicacin para cada servicio que se habilite. La propuesta denegar todo requiere preparar el terreno para habilitar el acceso de Internet. Algunos productos de firewall comerciales slo son compatibles con la directiva denegar todo.

La directiva aceptar todo facilita mucho la configuracin y la puesta en funcionamiento de un firewall, pero obliga a prever todo tipo de acceso imaginable que quiera deshabilitar (vase la Figura 2.4). El peligro es que no prever un tipo de acceso peligroso hasta que sea demasiado tarde, o pos-teriormente habilitar un servicio no seguro sin bloquear primero el acceso externo al mismo. En definitiva, programar un firewall seguro para aceptar todo, implica ms trabajo, mayor dificultad y, por tanto, es ms propenso a errores.

Rechazar frente a denegar un paquete

El mecanismo del firewall IPFW ofrece la opcin de rechazar o denegar los paquetes. Cul es la diferencia? Como se muestra en la Figura 2.5, cuan-do se rechaza un paquete, el paquete se descarta y se devuelve un mensaje de error ICMP al remitente. Cuando se deniega un paquete, simplemente se descarta el paquete sin ningn tipo de notificacin al remitente.


Cadena de firewall

Coincida con la regla 1 1 Aceptar

Coincida con la regla 21 Aceptar

Coincida con la regla 31

Directiva: DENY (denegar)

Figura 2.3. Directiva denegar todo de forma predeterminada.

La denegacin es casi siempre la mejor eleccin. Hay tres razones para esto. Primero, enviar una respuesta de error duplica el trafico de red. La mayora de los paquetes se descartan porque son malvolos, no porque representen un in-tento inocente de acceder a un servicio que no se le ha ocurrido ofrecer. Se-gundo, cualquier paquete al que responda se puede usar en un ataque por de-negacin de servicio. Tercero. cualquier respuesta, incluso un mensaje de error, ofrece informacin potencialmente til a quien podra ser un hacker.

Cmo filtrar los paquetes entrantes El lado de entrada del par E/S de la interfaz externa, la cadena de entrada,

es el ms interesante a la hora de asegurar un sitio. Como se mencion ante-riormente, se puede filtrar basndose en la direccin origen, la direccin des-tino, el puerto origen, el puerto destino y el indicador de estado TCP. Se usa-r toda esta informacin en un momento u otro de las siguientes secciones.


Paquete IP

Cadena de firewall

Coincide con la regla 11 Denegar

Coincide con la regla 21 Denegar

Coincide con la regla 31

Directiva: ACCEPT (Aceptar)

Figura 2.4. Directiva aceptar todo de forma predeterminada.

Devolver error al enviar

Paquete

Descartar

Figura 2.5. Cmo rechazar un paquete frente a denegarlo.


Filtrado de direccin origen remota

A nivel de paquete, el nico medio de identificar el remitente del paque-te IP es la direccin origen del encabezado del paquete. Este hecho abre la puerta al spoofing, o usurpamiento de direccin origen, donde el remitente coloca una direccin incorrecta, en vez de la suya propia, en el campo ori-gen. La direccin puede ser una direccin inexistente o puede ser una direc-cin legtima perteneciente a otra persona. Esto puede permitir varias formas desagradables de romper el sistema y hacerse pasar por el usuario mientras atacan otros sitios, fingiendo ser otra persona cuando estn atacando, o ha-cerle creer que es el origen de los mensajes entrantes.

Usurpamiento de direccin origen y direcciones ilegales Hay seis clases principales de direcciones origen que siempre se deben

denegar en la interfaz externa. Estas direcciones son las de paquetes entran-tes que dicen ser una de las siguientes direcciones:

Su direccin IP: Nunca se vern paquetes entrantes legales que indi-quen proceder de su mquina. Como la direccin origen es la nica informacin disponible, y sta se puede modificar, es la nica forma de usurpamiento que se puede detectar a nivel de filtrado de paque-tes. Los paquetes entrantes que dicen proceder de su mquina perte-necen al usurpamiento de direcciones. No es posible saber con certe-za si otros paquetes entrantes proceden de donde dicen proceder. Direcciones IP privadas de clase A, By C: Un conjunto de direcciones en cada uno de los intervalos de las clases A, B y C son reservadas para su uso en las LAN privadas. No se pueden usar en Internet. Como ta-les, estas direcciones las puede usar cualquier sitio de forma interna sin necesidad de comprar direcciones IP registradas. Su mquina nunca debe ver paquetes entrantes procedentes de estas direcciones origen. En realidad, las direcciones origen privadas se suelen ver con cierta frecuencia en suhredes ISP locales debido a sistemas mal configura-dos, al igual que desde sitios donde se usa el usurpamiento de forma intencionada. Si alguien filtra estas direcciones, se vern.

Las direcciones privadas de clase A se asignan al intervalo de di-recciones de 1 O.O.O.O a 10.255.255.255. Las direcciones privadas de clase B se asignan al intervalo de di-recciones de 172.16.0.0 a 172.31.255.255. Las direcciones privadas de clase e se asignan al intervalo de di-recciones de 192.168.0.0 a 192.168.255.255.

Direcciones IP multidifusin de clase D, Las direcciones IP en el in-tervalo de la clase D se reservan para su uso como direcciones desti-no cuando se participa en una difusin en una red multidifusin, como una difusin de sonido o vdeo. El intervalo comienza en la di-reccin 224.0.0.0 y termina en 239.255.255.255. Su mquina nunca de-bera ver paquetes procedentes de estas direcciones origen.


Direcciones reservadas de la clase E: Las direcciones IP en el interva-lo de la clase E se han reservado para usos futuros y experimentales y no se asignan pblicamente. El intervalo comienza en la direccin 240.0.0.0 y termina en 247.255.255.255. Su mquina nunca deberia ver paquetes de estas direcciones origen y es muy probable que no lo haga. Las redes de defensa e inteligencia son lo bastante buenas como para no perder sus paquetes. Direcciones de interfaz de bucle invertido: La interfaz de bucle in-vertido es una interfaz de red privada que usa el sistema UNIX para servicios locales basados en red. En lugar de enviar el trfico local a travs del controlador de la interfaz de red, el sistema operativo toma un atajo a travs de la interfaz de bucle invertido como una forma de mejorar el rendimiento. Por definicin, el trfico de bucle invertido apunta al sistema que lo gener. No sale fuera de la red. El intervalo de las direcciones de bucle invertido es 127.0.0.0 a 127.255.255.255. Normalmente se ver como 127.0.0.1, localhost o la interfaz de bucle invertido lo. Direcciones de difusin mal formadas, las direcciones de difusin son direcciones especiales que se aplican a todas las mquinas de una red. La direccin O.O.O.O es una direccin origen de difusin especial. La direccin origen de difusin ser O.O.O.O o una direccin IP normal. Los clientes DHCP vern los paquetes de difusin entrantes proce-dentes de la direccin origen O.O.O.O. Ignoro personalmente cualquier otra situacin donde se puede ver la direccin de difusin O.O.O.O. No es una direccin origen punto a punto legtima. Cuando se ve como la direccin origen en un paquete no de difusin regular, la direccin est falsificada.

Cmo bloquear sitios problemticos Otro esquema comn de filtrado de direccin, pero que se usa menos,

consiste en bloquear todos los accesos desde una mquina seleccionada, o de forma ms normal, desde todo un bloque de direcciones IP de red. As es como la comunidad de Internet suele tratar los sitios problemticos y a los ISP que no vigilan a sus usuarios. Si un sitio se gana la reputacin de ser un mal vecino de Internet, otros sitios tienden a bloquearlo sin excepciones.

A nivel individual, es conveniente bloquear todos los accesos desde redes seleccionadas cuando los individuos de la red remota no hacen ms que oca-sionar problemas.

Cmo limitar los paquetes entrantes a aquellos procedentes de los host remotos seleccionados

Puede que se quiera aceptar ciertas clases de paquetes entrantes proce-dentes slo de sitios externos especficos o personas concretas. En estos ca-sos, las reglas del firewall definirn direcciones IP especficas o un intervalo limitado de direcciones origen IP desde las que se aceptarn estos paquetes.


La primera clase de paquetes entrantes procede de servidores remotos que responden a las peticiones del usuario. Aunque algunos servicios, como los servicios Web o FfP, se puede esperar que procedan de cualquier lugar, otros servicios tendrn una procedencia legtima slo si proceden del ISP o de los host seguros elegidos. Algunos ejemplos de servidores que es proba-ble que slo ofrezca el ISP son el servicio de correo POP, la asignacin de di-reccin IP dinmica DHCP y, quiz, las respuestas del servidor de nombres de dominio (DNS, Domain Name Server).

La segunda clase de paquetes entrantes es la que procede de clientes re-motos que acceden a los servicios que se ofrecen desde su sitio. De nuevo, aunque algunas conexiones de servicio entrante, como las conexiones al ser-vidor web, se puede esperar que procedan de cualquier sitio, otros servicios locales slo se ofrecern a unos pocos usuarios o amigos de confianza. Algu-nos ejemplos de servicios locales restringidos pueden ser telnet, ssh y finger.

Filtrado de direccin destino local

El filtrado de paquetes entrantes basndose en la direccin destino no sue-le ser problemtico. La tarjeta de interfaz de red ignora los paquetes habitua-les que no se dirigen a ella. La excepcin son los paquetes de difusin, que se difunden a todos los host de la red.

La direccin 255.255.255.255 es la direccin destino de difusin general. Esta direccin se puede definir de forma ms explcita como la direccin de red seguida por el nmero 255 en las restantes tuplas de direccin. Por ejem-plo, si la direccin de red del ISP es 192.168.0.0 y su direccin IP es 192.168. I 0.30, se podran ver paquetes de difusin dirigidos a 192.168.255.255 o a 255.255.255.255 procedentes del ISP.

La direccin de difusin a destino O.O.O.O se parece a la situacin de los pa-quetes punto a punto que decan proceder de la direccin origen de difusin mencionada anteriormente en la seccin "Usurpamiento de direcciones ori-gen y direcciones ilegales". En este caso, los paquetes de difusin se dirigen a la direccin origen O.O.O.O en vez de a la direccin destino, 255.255.255.255. Por tanto, existe algo extrao sobre la intencin del paquete. Esto es un in-tento de identificar el sistema como una mquina UNIX. Por razones histri-cas, el cdigo de redes procedente del UNIX BSD devuelve un mensaje ICMP de error tipo 3 en respuesta a la utilizacin de la direccin O.O.O.O como la di-reccin destino de difusin. Otros sistemas operativos simplemente descar-tan el paquete. Como tal, este es un buen ejemplo de por qu es diferente de-negar que rechazar un paquete. En este caso, el propio mensaje de error es lo que est buscando el hacker.

Filtrado de puerto origen remoto

El puerto origen en los paquetes entrantes identifica el programa del host remoto que enva el mensaje. En general, todas las peticiones entrantes des-


de clientes remotos a sus servicios siguen el mismo modelo, y todas las res-puestas entrantes de servidores remotos al cliente local siguen un modelo di-ferente.

Las peticiones y las conexiones de entrada desde clientes remotos a los servidores locales tendrn un puerto origen del intervalo no privilegiado. Si se alberga un servidor web, todas las conexiones entrantes al servidor web debern tener un puerto origen entre 1024 y 65535.

Las respuestas entrantes de los servidores remotos con los que se ha co-nectado tendrn el puerto origen asignado al servicio particular. Si se conec-ta a un sitio web remoto, todos los mensajes entrantes procedentes del ser-vidor remoto tendrn el puerto origen establecido a 80, que es el nmero de puerto del servicio http.

Filtrado de puerto destino local

El puerto destino en los paquetes entrantes identifica el programa o el ser-vicio del equipo al que se dirige el paquete. Como ocurre con el puerto ori-gen, en general, todas las peticiones entrantes procedentes de clientes re-motos a sus servicios siguen el mismo modelo, y todas las respuestas entrantes procedentes de servicios remotos a sus clientes locales siguen un modelo diferente.

Las peticiones entrantes y las conexiones entrantes procedentes de clien-tes remotos a los servidores locales establecern el puerto destino al nmero de servicio asignado al servicio particular. Un paquete entrante dirigido a un servidor web local tendr el puerto destino establecido a 80, que es el n-mero del puerto del servicio http.

Las respuestas entrantes de los servidores remotos con los que se ha co-nectado tendrn el puerto destino en el intervalo no privilegiado. Si se co-necta a un sitio web remoto, todos los mensajes entrantes debern tener un puerto destino entre 1024 y 65535.

Filtrado del estado de la conexin TCP entrante

Las reglas de aceptacin del paquete TCP entrante pueden hacer uso de los indicadores de estado de la conexin asociados con las conexiones TCP. Todas las conexiones TCP se adhieren al mismo conjunto de estados de co-nexin. Estos estados difieren entre cliente y servidor debido al saludo de tres vas que se realiza durante el establecimiento de la conexin.

Los paquetes TCP entrantes procedentes de clientes remotos tendrn el in-dicador SYN activado en el primer paquete recibido como parte del saludo de establecimiento de la conexin de tres vas. La primera peticin de conexin tendr el indicador SYN activado, pero no el indicador ACK. Todos los paque-tes entrantes despus de la primera peticin de conexin tendrn slo el indi-cador ACK activado. Las reglas del firewall del servidor local permitirn pa-quetes entrantes, sin tener en cuenta el estado de los indicadores SYN y ACK.


Los paquetes entrantes procedentes de servidores remotos siempre sern respuestas a la peticin de conexin inicial que comienza en el programa cliente local. Cada paquete recibido desde un servidor remoto tendr el in-dicador ACK activado. Las reglas del firewall cliente local solicitarn que to-dos los paquetes entrantes procedentes de servidores remotos tengan el in-dicador ACK activado. Los servidores legtimos no intentarn iniciar conexiones a programas cliente.

Sondeos y exploraciones Un sondeo es un intento de conectar o de obtener una respuesta desde

un puerto de servicio individual. Una exploracin es una serie de sondeos a un conjunto de diferentes puertos de servicio. Las exploraciones suelen estar automatizadas.

En todo momento, los sondeos y las exploraciones son inofensivos. En In-ternet, la nica forma de descubrir si un sitio ofrece un servicio concreto es sondear el puerto. Cmo saber si un sitio tiene un servidor web si no se co-noce su URL? Intente acceder a su sitio web. En otras palabras, debe sonde-ar el puerto http.

Por desgracia, los sondeos y las exploraciones rara vez son inocentes. Es ms probable que sean la fase inicial de recopilacin de informacin, que bus-ca debilidades interesantes antes de lanzar un ataque de un hacker. En 1998, en particular, se produjo un incremento exponencial de las exploraciones todo el mundo. Las herramientas de exploracin automatizadas son de uso ge-neralizado, y los esfuerzos coordinados por grupos de hackers son habituales.

Exploraciones de puerto generales Las exploraciones de puerto generales son sondeos indiscriminados a lo

largo de un bloque de puertos de servicio, probablemente todo el intervalo (vase la Figura 2.6). Estas exploraciones, posiblemente generadas por herra-mientas antiguas de mantenimiento de red, como satan o strobe, se estn convirtiendo en menos frecuentes a medida que aparecen otras herramientas ms sofisticadas y especficas como mscan, sscan y nscan.

Exploraciones de puerto dirigidas Las exploraciones de puerto dirigidas buscan debilidades especficas (v-

ase la Figura 2.7). Las herramientas ms nuevas y sofisticadas intentan identi-ficar el hardware, el sistema operativo y las versiones de software. Estas he-rramientas estn diseadas para anular por completo las debilidades conocidas de objetivos especficos.

Destinos comunes en los puertos de servicio

Los destinos com.unes se suelen sondear y explorar de forma individual. El hacker puede estar buscando una debilidad especfica, como un servidor de correo inseguro o un demonio portmap de RPC abierto.


Puertos de servicio TCPy/o UDP

1

o

1023

Hasta 65,536 sondeos 65535

Figura 2.6. Exploracin de puerto general.

En la seccin "Interpretacin de los registros del sistema" del Captulo 6, "Cmo verificar que el sistema funciona como se espera", se muestra una ex-tensa lista de puertos. Aqu, y para que tenga una idea general, mencionare-mos tan slo unos pocos puertos comunes:

Los paquetes entrantes procedentes del puerto O reservado son siem-pre falsos. Este puerto no se usa de forma legtima. Los sondeos de puertos TCP del O al 5 son una firma del programa sscan.

telnet (23/tcp), smtp (25/tcp), pop-3 (110/tcp), sunrpc (111/udp/tcp), imap (143/tcp), snmp (161/udp), route (520/udp) y mount (635/udp) son los puertos destino favoritos. Representan algunas de las debilida-des ms importantes de un sistema. Como estos servicios son tan co-munes, representan buenos ejemplos de por qu no se quieren ofre-cer al mundo exterior o de la necesidad de controlar con mucho cuidado el acceso exterior a estos servicios. Los sondeos NetBIOS (137, 138/tcp/udp, 139/tcp), Netbus (12345/tcp) y Back Orifice (31337/udp) son muy comunes. No suponen una ame-naza para un sistema UNIX. En este caso, el destino es un sistema Windows.


Puertos de servicio TCPy/o UDP

1 telnet ~ 1~ ~ 1~ ~ 1 sunrpc (udp 111)

Exploracin destino 1~ ~ 1 route (udp 520) 1 mount (udp 635)

1 socks (tcp 1080) 8 sondeos

Figura 2.7. Exploracin de puerto dirigida.

Cmo evitar la paranoia: responder a las exploraciones de puerto

Prcticamente todos los das, los registros del firewall, que se encuentran en /var/log/messages, muestran todas las clases de intentos de conexin fallidos.

Intentan las personas acceder de forma ilegal al sistema con esta regula-ridad? S lo hacen. Est el sistema comprometido? No, no lo est. Los puer-tos estn bloqueados. El firewall est realizando su trabajo. Son intentos de conexin fallidos que el firewall deneg.

En qu momento decide informar personalmente de ello? En que mo-mento es lo suficientemente importante dedicar algo de tiempo para infor-mar de ello? En qu momento decir basta y seguir adelante normalmente, o debera escribir a la direccin [email protected] cada vez que sucede esto?

No hay respuestas "correctas". La forma de responder es una llamada a su juicio personal. Es uno de esos temas que puede provocar discusiones bi-zantinas. Para sondeos y exploraciones claras, no existe una respuesta bien definida. Depender de su propia personalidad, de su nivel de comodidad, de la forma en que defina un sondeo serio y de su conciencia social.


Teniendo esto presente, stas son algunas pautas a seguir. Los intentos ms comunes son una combinacin de sondeos automatiza-

dos, errores, intentos legtimos basados en la historia de Internet, en la igno-rancia, en la curiosidad y el software que se comporta de forma errnea.

Deben ignorarse los intentos de conexin individuales, restringidos a tel-net, ssh, ftp, finger o a cualquier otro puert para un servicio comn que no se ofrezca. Los sondeos y las exploraciones son un hecho del da a da en In-ternet, todos muy frecuentes y que no suelen suponer ningn riesgo. Son una clase de vendedores que van de puerta en puerta, de llamadas telefnicas co-merciales, de nmeros de telfono equivocados y de la propaganda en el co-rreo. No hay suficiente tiempo en un da para responder a cada uno de ellos.

Por otro lado, algunas personas que se dedican a sondear son ms persis-tentes. Puede que sea necesario agregar reglas de firewall para bloquearlos completamente, o quiz incluso bloquear todo el espacio de direcciones de dominio si el dominio tiene una mala reputacin o si usan mltiples direc-ciones origen.

Las exploraciones de un subconjunto de los puertos conocidos como po-sibles agujeros de seguridad son normalmente los precursores de un intento de piratera si se encuentra un puerto abierto. Las exploraciones ms globa-les suelen ser parte de una exploracin ms amplia en busca de aberturas en un dominio o de una subred. Las herramientas de piratera actuales sondean, uno tras otro, un subconjunto de estos puertos.

En algunas ocasiones, aparecern intentos serios de piratera. Este es, sin ninguna duda, el momento de realizar las acciones. Escrbales. Denncielos. Duplique la comprobacin de la seguridad. Observe lo que hacen. Bloque-los. Bloquee su bloque de direcciones IP. Ponga su sistema fuera de lnea, si es necesario.

Puertos histricamente peligrosos

Para obtener ms informacin acerca de puertos histricamente peligrosos, consulte el documento "Packet Filtering far Firewall Systems" (Filtrado de paquetes para sis-temas de firewall), que puede encontrar en www.cert.org.

Algunos administradores de sistemas consideran serias todas las aparicio-nes, porque incluso si una mquina es segura, las mquinas de otras personas pueden no serlo. La siguiente persona puede que ni siquiera tenga la capaci-dad de saber que est siendo sondeado. Crear informes de sondeos es una responsabilidad social que, por el bien de todos, hay que tomar.

Cmo debera responder a las exploraciones de puerto? Si escribe a estas personas, al administrador, al NOC proveedor de servicio de vnculo ascen-dente al coordinador de bloques de direcciones de red, intente ser educado. Concdales el beneficio de la duda. Suelen ser muy frecuentes las reacciones exageradas. Lo que puede parecer un intento de piratera serio para el usuario es a menudo un nio curioso jugando con un nuevo programa. Unas palabras educadas al abuse, root o postmaster normalmente solucionarn el problema. Es necesario ensear a las personas Netiquette (buenos modales en Internet)


en lugar de rescindirles las cuentas. Y, pueden ser inocentes de todo. Con mu-cha frecuencia, el sistema de la persona est comprometido y no tienen ni idea de lo que sucede. Estarn agradecidos por la informac

Linux Firewalls Guía Avanzada

Documents

Transcript of Linux Firewalls Guía Avanzada