Debe introducir al menos 3 caracteres en el buscador.
Inicio / Wikis / Tutoriales / Seguridad en Unix y redes - Componentes de un cortafuegos

Seguridad en Unix y redes - Componentes de un cortafuegos

 ****- (7 opiniones)
GNU Free Documentation License Tutorial de Antonio Villalón Huerta - 28 de Febrero de 2006
Temas Relacionados: Seguridad informática
86. Componentes de un cortafuegos

Filtrado de paquetes


Cualquier router IP utiliza reglas de filtrado para reducir la carga de la red; por ejemplo, se descartan paquetes cuyo TTL ha llegado a cero, paquetes con un control de errores erróneos, o simplemente tramas de broadcast. Además de estas aplicaciones, el filtrado de paquetes se puede utilizar para implementar diferentes políticas de seguridad en una red; el objetivo principal de todas ellas suele ser evitar el acceso no autorizado entre dos redes, pero manteniendo intactos los accesos autorizados. Su funcionamiento es habitualmente muy simple: se analiza la cabecera de cada paquete, y en función de una serie de reglas establecidas de antemano la trama es bloqueada o se le permite seguir su camino; estas reglas suelen contemplar campos como el protocolo utilizado (TCP, UDP, ICMP...), las direcciones fuente y destino, y el puerto destino, lo cual ya nos dice que el firewall ha de ser capaz de trabajar en los niveles de red (para discriminar en función de las direcciones origen y destino) y de transporte (para hacerlo en función de los puertos usados). Además de la información de cabecera de las tramas, algunas implementaciones de filtrado permiten especificar reglas basadas en la interfaz del router por donde se ha de reenviar el paquete, y también en la interfaz por donde ha llegado hasta nosotros ([Cha92]).
>Cómo se especifican tales reglas? Generalmente se expresan como una simple tabla de condiciones y acciones que se consulta en orden hasta encontrar una regla que permita tomar una decisión sobre el bloqueo o el reenvío de la trama; adicionalmente, ciertas implementaciones permiten indicar si el bloqueo de un paquete se notificará a la máquina origen mediante un mensaje ICMP ([Mog89]). Siempre hemos de tener presente el orden de análisis de las tablas para poder implementar la política de seguridad de una forma correcta; cuanto más complejas sean las reglas y su orden de análisis, más difícil será para el administrador comprenderlas. Independientemente del formato, la forma de generar las tablas dependerá obviamente del sistema sobre el que trabajemos, por lo que es indispensable consultar su documentación; algunos ejemplos particulares - pero aplicables a otros sistemas - pueden encontrarse en [CHS91] (routers NetBlazer), [Par98] (routers Cisco), [RA94] (TIS Internet Firewall Toolkit sobre Unix) y también en la obra indispensable al hablar de cortafuegos: [CZ95] (screend, NetBlazer, Livingston y Cisco).
Por ejemplo, imaginemos una hipotética tabla de reglas de filtrado de la siguiente forma:
Origen Destino Tipo Puerto Accion
158.43.0.0 * * * Deny * 195.53.22.0 * * Deny 158.42.0.0 * * * Allow * 193.22.34.0 * * Deny
Si al cortafuegos donde está definida la política anterior llegara un paquete proveniente de una máquina de la red 158.43.0.0 se bloquearía su paso, sin importar el destino de la trama; de la misma forma, todo el tráfico hacia la red 195.53.22.0 también se detendría. Pero, >qué sucedería si llega un paquete de un sistema de la red 158.42.0.0 hacia 193.22.34.0? Una de las reglas nos indica que dejemos pasar todo el tráfico proveniente de 158.42.0.0, pero la siguiente nos dice que si el destino es 193.22.34.0 lo bloqueemos sin importar el origen. En este caso depende de nuestra implementación particular y el orden de análisis que siga: si se comprueban las reglas desde el principio, el paquete atravesaría el cortafuegos, ya que al analizar la tercera entrada se finalizarían las comprobaciones; si operamos al revés, el paquete se bloquearía porque leemos antes la última regla. Como podemos ver, ni siquiera en nuestra tabla - muy simple - las cosas son obvias, por lo que si extendemos el ejemplo a un firewall real podemos hacernos una idea de hasta que punto hemos de ser cuidadosos con el orden de las entradas de nuestra tabla.
>Qué sucedería si, con la tabla del ejemplo anterior, llega un paquete que no cumple ninguna de nuestras reglas? El sentido común nos dice que por seguridad se debería bloquear, pero esto no siempre sucede así; diferentes implementaciones ejecutan diferentes acciones en este caso. Algunas deniegan el paso por defecto, otras aplican el contario de la última regla especificada (es decir, si la última entrada era un Allow se niega el paso de la trama, y si era un Deny se permite), otras dejan pasar este tipo de tramas...De cualquier forma, para evitar problemas cuando uno de estos datagramas llega al cortafuegos, lo mejor es insertar siempre una regla por defecto al final de nuestra lista - recordemos una vez más la cuestión del orden - con la acción que deseemos realizar por defecto; si por ejemplo deseamos bloquear el resto del tráfico que llega al firewall con la tabla anterior, y suponiendo que las entradas se analizan en el orden habitual, podríamos añadir a nuestra tabla la siguiente regla:
Origen Destino Tipo Puerto Accion
* * * * Deny
La especificación incorrecta de estas reglas constituye uno de los problemas de seguridad habituales en los cortafuegos de filtrado de paquetes; no obstante, el mayor problema es que un sistema de filtrado de paquetes es incapaz de analizar (y por tanto verificar) datos situados por encima del nivel de red OSI ([Ste98a]). A esto se le añade el hecho de que si utilizamos un simple router como filtro, las capacidades de registro de información del mismo suelen ser bastante limitadas, por lo que en ocasiones es difícil la detección de un ataque; se puede considerar un mecanismo de prevención más que de detección. Para intentar solucionar estas - y otras vulnerabilidades - es recomendable utilizar aplicaciones software capaces de filtrar las conexiones a servicios; a dichas aplicaciones se les denomina proxies de aplicación, y las vamos a comentar en el punto siguiente.

Proxy de aplicación


Además del filtrado de paquetes, es habitual que los cortafuegos utilicen aplicaciones software para reenviar o bloquear conexiones a servicios como finger, telnet o FTP; a tales aplicaciones se les denomina servicios proxy, mientras que a la máquina donde se ejecutan se le llama pasarela de aplicación.
Los servicios proxy poseen una serie de ventajas de cara a incrementar nuestra seguridad ([WC94]); en primer lugar, permiten únicamente la utilización de servicios para los que existe un proxy, por lo que si en nuestra organización la pasarela de aplicación contiene únicamente proxies para telnet, HTTP y FTP, el resto de servicios no estarán disponibles para nadie. Una segunda ventaja es que en la pasarela es posible filtrar protocolos basándose en algo más que la cabecera de las tramas, lo que hace posible por ejemplo tener habilitado un servicio como FTP pero con órdenes restringidas (podríamos bloquear todos los comandos put para que nadie pueda subir ficheros a un servidor). Además, los application gateways permiten un grado de ocultación de la estructura de la red protegida (por ejemplo, la pasarela es el único sistema cuyo nombre está disponible hacia el exterior), facilita la autenticación y la auditoría del tráfico sospechoso antes de que alcance el host destino y, quizás más importante, simplifica enormemente las reglas de filtrado implementadas en el router (que como hemos dicho antes pueden convertirse en la fuente de muchos problemas de seguridad): sólo hemos de permitir el tráfico hacia la pasarela, bloqueando el resto.
>Qué servicios ofrecer en nuestro gateway, y cómo hacerlo? La configuración de la mayoría de servicios `habituales' está muy bien explicada (como el resto del libro) en el capítulo 8 de [CZ95]. Además, en numerosos artículos se comentan problemas específicos de algunos servicios; uno muy recomendable, centrado en el sistema de ventanas X Window, pero donde también se habla de otros protocolos, puede ser [TW93].
El principal inconveniente que encontramos a la hora de instalar una pasarela de aplicación es que cada servicio que deseemos ofrecer necesita su propio proxy; además se trata de un elemento que frecuentemente es más caro que un simple filtro de paquetes, y su rendimiento es mucho menor (por ejemplo, puede llegar a limitar el ancho de banda efectivo de la red, si el análisis de cada trama es costoso). En el caso de protocolos cliente-servidor (como telnet) se añade la desventaja de que necesitamos dos pasos para conectar hacia la zona segura o hacia el resto de la red; incluso algunas implementaciones necesitan clientes modificados para funcionar correctamente.
Una variante de las pasarelas de aplicación la constituyen las pasarelas de nivel de circuito (Circuit-level Gateways, [CB94]), sistemas capaces de redirigir conexiones (reenviando tramas) pero que no pueden procesar o filtrar paquetes en base al protocolo utilizado; se limitan simplemente a autenticar al usuario (a su conexión) antes de establecer el circuito virtual entre sistemas. La principal ventaja de este tipo de pasarelas es que proveen de servicios a un amplio rango de protocolos; no obstante, necesitan software especial que tenga las llamadas al sistema clásicas sustituidas por funciones de librería seguras, como SOCKS ([KK92]).

Monitorización de la actividad


Monitorizar la actividad de nuestro cortafuegos es algo indispensable para la seguridad de todo el perímetro protegido; la monitorización nos facilitará información sobre los intentos de ataque que estemos sufriendo (origen, franjas horarias, tipos de acceso...), así como la existencia de tramas que aunque no supongan un ataque a priori sí que son al menos sospechosas (podemos leer [Bel93b] para hacernos una idea de que tipo de tramas `extrañas' se pueden llegar a detectar).
>Qué información debemos registrar? Además de los registros estándar (los que incluyen estadísticas de tipos de paquetes recibidos, frecuencias, o direcciones fuente y destino) [BCOW94] recomienda auditar información de la conexión (origen y destino, nombre de usuario - recordemos el servicio ident - hora y duración), intentos de uso de protocolos denegados, intentos de falsificación de dirección por parte de máquinas internas al perímetro de seguridad (paquetes que llegan desde la red externa con la dirección de un equipo interno) y tramas recibidas desde routers desconocidos. Evidentemente, todos esos registros han de ser leidos con frecuencia, y el administrador de la red ha de tomar medidas si se detectan actividades sospechosas; si la cantidad de logs generada es considerable nos puede interesar el uso de herramientas que filtren dicha información.
Un excelente mecanismo para incrementar mucho nuestra seguridad puede ser la sustitución de servicios reales en el cortafuegos por programas trampa ([Bel92]). La idea es sencilla: se trata de pequeñas aplicaciones que simulan un determinado servicio, de forma que un posible atacante piense que dicho servicio está habilitado y prosiga su `ataque', pero que realmente nos están enviando toda la información posible sobre el pirata. Este tipo de programas, una especie de troyano, suele tener una finalidad múltiple: aparte de detectar y notificar ataques, el atacante permanece entretenido intentando un ataque que cree factible, lo que por un lado nos beneficia directamente - esa persona no intenta otro ataque quizás más peligroso - y por otro nos permite entretener al pirata ante una posible traza de su conexión. Evidentemente, nos estamos arriesgando a que nuestro atacante descubra el mecanismo y lance ataques más peligrosos, pero como el nivel de conocimientos de los atacantes de redes habituales en general no es muy elevado (más bien todo lo contrario), este mecanismo nos permite descubrir posibles exploits utilizados por los piratas, observar a qué tipo de atacantes nos enfrentamos, e incluso divertirnos con ellos. En la Universidad Politécnica de Valencia existen algunos sistemas con este tipo de trampas, y realmente es curioso observar cómo algunos intrusos siguen intentando aprovechar bugs que fueron descubiertos - y solucionados - hace más de cuatro años (ejemplos típicos aquí son PHF y algunos problemas de sendmail). En [Che92], un artículo clásico a la hora de hablar de seguridad (también se comenta el caso en el capítulo 10 de [CB94]), se muestra cómo Bill Cheswick, un experto en seguridad de los laboratorios AT&T estadounidenses, es capaz de analizar detenidamente gracias a estos programas las actividades de un pirata que golpea el gateway de la compañía.
Tabla de contenidos
  1. 1 - Introducción y conceptos previos
  2. 2 - Sobre la seguridad
  3. 3 - Sobre las redes
  4. 4 - Seguridad física de los sistemas
  5. 5 - Protección del hardware
  6. 6 - Protección de los datos
  7. 7 - Radiaciones electromagnéticas
  8. 8 - Administradores, usuarios y personal
  9. 9 - Ataques potenciales
  10. 10 - Qué hacer ante estos problemas
  11. 11 - El atacante interno
  12. 12 - El sistema de ficheros
  13. 13 - Sistemas de ficheros
  14. 14 - Permisos de un archivo
  15. 15 - Los bits SUID, SGID y sticky
  16. 16 - Atributos de un archivo
  17. 17 - Listas de control de acceso: ACLs
  18. 18 - Recuperación de datos
  19. 19 - Almacenamiento seguro
  20. 20 - Programas seguros, inseguros y nocivos
  21. 21 - La base fiable de cómputo
  22. 22 - Errores en los programas
  23. 23 - Fauna y otras amenazas
  24. 24 - Programación segura
  25. 25 - Auditoría del sistema
  26. 26 - El sistema de log en Unix
  27. 27 - El demonio syslogd
  28. 28 - Algunos archivos de log
  29. 29 - Logs remotos
  30. 30 - Registros físicos
  31. 31 - Copias de seguridad
  32. 32 - Dispositivos de almacenamiento
  33. 33 - Algunas órdenes para realizar copias de seguridad
  34. 34 - Políticas de copias de seguridad
  35. 35 - Autenticación de usuarios
  36. 36 - Sistemas basados en algo conocido: contraseñas
  37. 37 - Sistemas basados en algo poseído: tarjetas inteligentes
  38. 38 - Sistemas de autenticación biométrica
  39. 39 - Autenticación de usuarios en Unix: autenticación clasi
  40. 40 - Autenticación de usuarios en Unix: mejora de la seguridad (II)
  41. 41 - PAM
  42. 42 - Solaris
  43. 43 - Seguridad física en SPARC
  44. 44 - Servicios de red
  45. 45 - Usuarios y accesos al sistema
  46. 46 - El sistema de parcheado
  47. 47 - Extensiones de la seguridad
  48. 48 - El subsistema de red
  49. 49 - Parametros del núcleo
  50. 50 - Linux
  51. 51 - Seguridad física en x86
  52. 52 - Usuarios y accesos al sistema
  53. 53 - El sistema de parcheado
  54. 54 - El subsistema de red
  55. 55 - El núcleo de Linux
  56. 56 - AIX
  57. 57 - Seguridad física en RS/6000
  58. 58 - Servicios de red
  59. 59 - Usuarios y accesos al sistema (I)
  60. 60 - Usuarios y accesos al sistema (II)
  61. 61 - El sistema de log
  62. 62 - El sistema de parcheado
  63. 63 - Extensiones de la seguridad: filtros IP
  64. 64 - El subsistema de red
  65. 65 - HP-UX
  66. 66 - Seguridad física en PA-RISC
  67. 67 - Usuarios y accesos al sistema
  68. 68 - El sistema de parcheado
  69. 69 - Extensiones de la seguridad
  70. 70 - El subsistema de red
  71. 71 - El núcleo de HP-UX
  72. 72 - Seguridad de la subred: el sistema de red
  73. 73 - Algunos ficheros importantes
  74. 74 - Algunas órdenes importantes
  1. 75 - Servicios
  2. 76 - Algunos servicios y protocolos
  3. 77 - Servicios basicos de red
  4. 78 - El servicio FTP
  5. 79 - El servicio TELNET
  6. 80 - El servicio SMTP
  7. 81 - Servidores WWW
  8. 82 - Los servicios r-
  9. 83 - XWindow
  10. 84 - Cortafuegos: Conceptos teóricos
  11. 85 - Características de diseño
  12. 86 - Componentes de un cortafuegos
  13. 87 - Arquitecturas de cortafuegos
  14. 88 - Firewall-1
  15. 89 - ipfwadm/ipchains/iptables
  16. 90 - IPFilter
  17. 91 - PIX Firewall (I)
  18. 92 - PIX Firewall (II)
  19. 93 - Escaneos de puertos
  20. 94 - Spoofing
  21. 95 - Negaciones de servicio
  22. 96 - Interceptación
  23. 97 - Ataques a aplicaciones
  24. 98 - Sistemas de detección de intrusos
  25. 99 - Clasificación de los IDSes
  26. 100 - Requisitos de un IDS
  27. 101 - IDSes basados en maquina
  28. 102 - IDSes basados en red
  29. 103 - Detección de anomalías
  30. 104 - Detección de usos indebidos
  31. 105 - Implementación real de un IDS (I)
  32. 106 - Implementación real de un IDS (II)
  33. 107 - Algunas reflexiones
  34. 108 - Kerberos
  35. 109 - Arquitectura de Kerberos
  36. 110 - Autenticación
  37. 111 - Problemas de Kerberos
  38. 112 - Criptología
  39. 113 - Criptosistemas
  40. 114 - Clasificación de los criptosistemas
  41. 115 - Criptografía clasica
  42. 116 - Un criptosistema de clave secreta: DES
  43. 117 - Criptosistemas de clave pública
  44. 118 - Funciones resumen
  45. 119 - Esteganografía
  46. 120 - Algunas herramientas de seguridad
  47. 121 - Titan (I)
  48. 122 - Titan (II)
  49. 123 - TCP Wrappers
  50. 124 - SSH
  51. 125 - Tripwire
  52. 126 - Nessus
  53. 127 - Crack
  54. 128 - Gestión de la seguridad
  55. 129 - Políticas de seguridad
  56. 130 - Analisis de riesgos
  57. 131 - Estrategias de respuesta
  58. 132 - Outsourcing
  59. 133 - El "Área de Seguridad"
  60. 134 - Apéndice 1: Seguridad basica para administradores (I)
  61. 135 - Apéndice 1: Seguridad basica para administradores (II)
  62. 136 - Apéndice 2: Normativa (I)
  63. 137 - Apéndice 2: Normativa (II)
  64. 138 - Apéndice 2: Normativa (III)
  65. 139 - Apéndice 2: Normativa (IV)
  66. 140 - Recursos de interés en INet
  67. 141 - Glosario de términos anglosajones
  68. 142 - Conclusiones
  69. 143 - Bibliografía (I)
  70. 144 - Bibliografía (II)
  71. 145 - Bibliografía (III)
  72. 146 - Bibliografía (IV)
  73. 147 - Bibliografía (V)
  74. 148 - libro
Autor y licencia de 'Seguridad en Unix y redes - Componentes de un cortafuegos'
Antonio Villalón Huerta Extraído de: http://es.tldp.org/Manuales-LuCAS/doc-unixsec/unixsec-html/ GNU Free Documentation License
Licencia GNU Free Documentation License: http://www.gnu.org/copyleft/
Este contenido ha sido recopilado por el equipo de Wikilearning. Todo el contenido recopilado se ha obtenido respetando y comunicando en nuestro site la licencia de cada fuente.
Wikilearning tiene permiso expreso por escrito de los autores para publicar los contenidos que ha extraído de otras webs, incluyendo su uso comercial.

Wikis relacionados con 'Seguridad en Unix y redes - Componentes de un cortafuegos'

El objetivo de este documento es enseñar las bases de la instalación de un cortafuegos... Más »
En los últimos años, el desarrollo basado en componentes se ha convertido en la técnica... Más »
Un repaso a los componentes gráficos, aquellos en los que nos tenemos que encargar de... Más »
Es muy fácil crear archivos en el sistema operativo UNIX. Por lo tanto, los usuarios... Más »
Es uno de los mejores cortafuegos disponibles, incluyendo soluciones comerciales, y desde luego, la mejor... Más »
Gente Wiki
Jofre Cantuña
Soy medico pediatra y me interesa los temas de antropologia.
José Luis Orihuela
Profesor universitario, conferenciante y bloguer. Autor de la revolución de los blogs, la esfera de los libros, madrid, 2006 y...
Gestión de contenidos
Edgar Altamirano
Profesor-investigador en la universidad autonoma de guerrero. Mexico. Areas de interes: mundos virtuales en-linea. Moodle. Tic. Clases a distancia. Lengua...
Poesía
José Angel García Landa
Profesor de filología inglesa en la universidad de zaragoza (españa). Mi web: http://www.garcialanda.net mi bibliografía de filología inglesa: http://www.unizar.es/departamentos/filologia_inglesa/garciala/bibliography.html..
Filología, Filosofía,...
Jose Ignacio Ruiz De La Hermosa Bou
Soy médico ginecólogo y me interesa mucho la formación pues el saber da la libertad y la independencia personal. Me...
Enfermería ginecológica
Carlos Reinaldo Miranda
Director del departamento de violencia de la asociación de psicólogos de buenos aires. Supervisor en el area de violencia...
Depresión, Agresividad,...
Suscribirse
¿Estás seguro de que deseas eliminar este capítulo?