Competitive Analysis: Netscape

Indice1. Definición del problema 2. Introduccion 3. Evolución de la solucion 4. Propuesta de la solucion 5. Servicios 6. WWW 7. FTP 8. Configuración de los servidores

1. Definición del problema

Brindar y utilizar servicios desde una red conectada a Internet vía un firewall, disponiendo de una única dirección de IP válida en Internet (por lo que no mediaría routing). Los objetivos de este trabajo son los siguientes:

• Estudiar diferentes configuraciones de redes que puedan presnetarse
• Investigar posibles soluciones & tecnologías disponibles.
• Evaluar las soluciones elegidas desde el punto de vista de la seguridad.
• Plantear una solución.

2. Introduccion

Brindar servicios y utilizar servicios pueden en una primera aproximación considerarse actividades similares. Sin embargo, existe una diferencia fundamental que afecta la viabilidad de las distintas aproximaciones existentes: mientras que como administradores de la red podemos forzar procedimientos de acceso o características en el software cliente que se adecuen a los requerimientos de los mecanismos de acceso en el momento de utilizar servicios, solo podemos asumir procedimientos y clientes normales al brindar servicios. Esto decididamente limita las alternativas para brindar servicios a dos tipos básicos de solución:

• Brindar el servicio en el firewall. Este método es el más sencillo de implementar. Sin embargo, muchos servicios hacen un uso intensivo de los recursos del host que los provee. Teniendo en cuenta que el firewall estará involucrado tanto los mecanismos para brindar como para utilizar servicios, su capacidad puede verse fácilmente superada.
• Utilizar un mecanismo transparente de acceso a un servidor dentro de la red tal que a todos los efectos el firewall se comporte como el servidor real, al menos en lo que respecta al cliente del servicio. Debe notarse que no todos los servicios se adaptan a mecanismos tales (más sobre esto luego).

Para poder brindar servicios es necesario que el firewall sea conocido para todos los hosts de Internet como el proveedor de cada servicio, ya que es el único host en la red conectado a Internet. Esto se logra con una implementación adecuada del servicio de DNS.

Para poder utilizar servicios brindados por hosts en Internet dentro de la red, debemos hacer que el firewall funcione como un relay o proxy para estos servicios)

Proying provee a internet el acceso a un solo host o un numero muy pequeño de ellos simulando el acceso a todos los hosts de una subred. Los hosts que son accesidos externamente actuan com proxies o "representantes" entre el cliente externo y las maquinas a las cuales se desea acceder pero no tienen acceso directo desde internet.

La utilización de proxies es transparente a los usuarios. De hecho, los usuarios nunca se enteran que en realidad no estan interactuando con el host deseado sino conun representante(proxy) que lo hace por ellos.

El concepto de proxe tiene varias ventajas:

• Los servicios permiten a los usuarios acceder a servicios de Internet "directamente".
• Los servicios de Proxy son buenos para el logging

Dado que los servidores de proxy "entienenden el protocolo subyacente, permiten el logging sea realizado de una forma particularmente efectiva: en vez de hacer log sobre todos los datos trasnferidos, un proxy FTP hace logs sobre los comandos realizados por el usuario y las respuestas recibidas, lo cual resulta en un log mucho mas sencillo y util.

Entre las desventajas del Proxy tenemos:

• Los proxies de servicios son funcionan siempre con todos los servicios
• Lo servicios de proxy no imponen ningún tipo de protección de las debilidades inherentes al protocolo.

Lo que debemos estudiar y evaluar son los distintas métodos de los que disponemos para realizar este objetivo. En una primera aproximación, notamos que lo que diferencia más notable se encuentra en el nivel del stack de TCP/IP en el que funciona cada uno, a saber:

1. Métodos que funcionan al nivel de la capa de transporte: son los más generales, y funcionan conceptualmente como pipes o puentes transportando información de la aplicación. Se configura el firewall para que mapee un puerto a otro puerto en algún host de la red. Las ventajas de este método son su sencillez y la facilidad de restringir su uso, y el hecho de que los clientes del servicio no necesitan estar enterados del funcionamiento de este mecanismo (salvo para el hecho de que deben realizar la conexión con el firewall, pero puede hacerse que de un lado del firewall se relacione el nombre del servidor del servicio en cuestión con la dirección del firewall), pero es muy poco flexible ya que este mapping es estático. Además no permite guardar información de auditoría que sea relevante al protocolo de aplicación que se encapsule dentro del de transporte, ni definir reglas de acceso pertinentes a aquel protocolo (por ejemplo, no permitir que el cliente utilice el comando put en un servidor de FTP fuera de la red privada).
2. Métodos que funcionan entre la capa de transporte y la de aplicación: en esta categoría se encuentra el uso de un proxy Socks. El cliente del servicio conoce la existencia del servidor, y se comunica con este utilizando un protocolo que le permite gestionar conexiones con hosts arbitrarios al otro lado del firewall. Este método tiene como ventaja esta flexibilidad para el acceso a los servicios y permite el uso de la mayoría de los servicios que funcionan sobre los protocolos de transporte que el servidor socks soporta (con el consiguiente aumento en la complejidad de la configuración). Sin embargo, al igual que los métodos mencionados en 1. No se trabaja a nivel de aplicación. Además, se necesitan versiones especiales de cada software utilizado en conjunto con este servidor (para el otro lado de la conexión, el servidor socks es, a todos los efectos, el cliente o servidor real).
3. Métodos que funcionan al nivel de aplicación: los proxies en este nivel entienden el protocolo de la aplicación, y permiten configuraciones estrechamente relacionadas con este protocolo, así como la posibilidad de proveer características con valor agregado como el caching en un http proxy. Como desventaja, los clientes deben configurarse para comunicarse con este proxy, y debe utilizarse un proxy para cada protocolo de aplicación que se necesite (y este debe existir, cosa que no siempre es posible con nuevas aplicaciones desarrollándose continuamente).

3. Evolución de la solucion

1. Una primer alternativa de solución bastante sencilla es que el server (firewall) sea el que provea todos los servicios de la red.

   

   De esta forma, cualquier acceso a cualquiera de los servicios desde fuera de la red (Internet), es respondido por el servidor, el cual tiene asignado la única dirección IP disponible. Los hosts dentro de la red, también acceden internamente al servidor para utilizar los diferentes servicios disponibles. Lamentablemente esta solución tiene un grave problema: la sobrecarga del servidor.

   Para solucionar este inconveniente, se podría utilizar un proxy socks y repartir los diferentes servicios entre los servidores de la red:

   De esta manera, la carga de la red está repartida entre los diferentes servidores disponibles. Hay que recordar, que los clientes desde fuera de la red (Internet) van a requerir el acceso a los servicios al servidor de proxy (que es el unico que tiene una direccion de IP), y éste va a rutear los paquetes al servidor correspondiente (como se explica en el punto 2 anterior).

2. Se dispone de una sola red en la cual cada host tiene acceso a todas las demas maquinas dentro de la red.
3. b. Mientras se necesite armar una sola red debajo del proxy socks, la solucion anterior es bastante buena, pero acarrea algunos inconvenientes si se dispone de varias organizaciones que deben poseer cada una su propia subred privada.

Al poseer varias subredes surgen diferentes problemas a solucionar: como hacer que cada sub-red sea privada con respecto a la otras, y en que lugar se bede poner cada uno de los servicios que la red posee.

Utilizando la solución del proxy socks, los clientes desde Internet que intentan acceder a los servicios que provee la red generalmente lo hacen por un puerto especifico (para cada uno de los servicios disponibles).

Al realizar el routing de un puerto del proxy a un puerto específica en alguno de los servidores dentro de la red, no es posible que diferentes maquinas provean el mismo servicio, y que éste sea accedido desde fuera, lo que acarrea un problema: solo se puede tener un solo servidor por servicio que pueda ser accedido desde Internet (por supuesto, utilizando simepre el esquema de proxy para socks).

La solución es poner los servidores "generales" en algún lugar en el que cada una de las subredes puedan acceder a ellos:

Además, utilizando este esquema, no existen restricciones en el manejo de información que pueden utilizar cada una de la subredes internamente: por ejemplo, cada subred podría tener sus propios servidores de Terlnet, FTP, WWW, etc, aunques estos no van a poder ser accedidos desde fuera de la red ni por ninguna de las otras sub-redes.

c. se puede ampliar el esquema anterior utilizando un proxy a nivel de aplicación, en lugar de un proxy socks, acarreando las ventajas y desventajas explicadas en el punto 3. De esta forma, por ejemplo, se podría poseer un mail server central a la red, y cada subred su propio servidor de POP. Entonces, se podría hacer un relay para el mail que distribuya los mensajes al servidor de POP en la subred a la que corresponda.

Hay que tener en cuenta que esto también acarrea algunos problemas: por ejemplo, en el servidor de mail sentral, se deben tener definidos todos los usuarios de la red, y éstos deben poseer nombres diferentes, sin importar que pertenezcan a diferentes subredes. Además, los usuarios también deben estar definidos en el servidor particular de la subred a la que pertenezca, por lo que esto implica una doble administración. La ventaja de esta estructura es que si se posee mucho manejo de mail interno, se evita utilizar recursos generarles de la red.

4. Propuesta de la solucion

La propuesta que presentamos en este trabajo tiene en cuenta los aspectos generales de funcionamiento de una red que esta conectada a Internet, tales como son los relacionados con la configuración del DNS, los servicios que deben proveerse en una intranet y el tema de seguridad que es de importancia ya que los datos corporativos se hallan expuestos al ataque externo a través de Internet.

A continuación vamos a describir cada uno de los componentes de la solución, los aspectos a tener en cuenta y la solución adoptada.

1. El Domain Name System (DNS)

2. DNS es una base de datos distribuida que traduce los nombres de los hosts a direcciones IP y viceversa. Es también un mecanismo estándar en Internet para el almacenamiento de muchos otros tipos de información sobre los hosts, opr ejemplo si un host no puede recibir mail directamente, y se hacer cargo otro host, es ta informaci´no es comunicada con un registro MX en el DNS

   Existen varias características de los DNS que los determina como un factor decisivo en la estrategia de solución a -implementar: Packet Filtering, Proxying , los datos que contiene y los problemas de seguridad.

   Packet Filtering: Existen dos tipos de actividades que realiza un DNS: lookups y zonas de transferencia. Los Lookups ovurren cuando un cliente del DNS (o un servidor DNS actuando de parte de un cliente) le consulta información: por ejemplo, la dirección IP de un nombre de host dado o el mail exchanger para un host dado. Las zonas de transferencia ocurren cuando un servidor de DNS(el servidor secundario) requiere del servidor primario toda la información que posea acerca de una parte dada del árbol de nombres del DNS (la zona). Este tipo de transferencia ocurren solamente entre servidores que se supone, proveen la misma información. Un servidor no va a tratar de hacer una zona de transferencia con un servidor al azar bajo circunstancias normales.

   1. Características de Proxying de un DNS.

El DNS esta estructurado de tal manera que los servidores actúan siempre como proxies para los clientes. También es posible usar un "feature" llamado fowarding de manera tal que el DNS server es efectivamente un proxy para otro server.

Anteriormente nos habíamos referido al DNS como una base de datos estructurada en forma de árbol, con servidores para varios sub’arboles desperramados a lo largo de Internet, Existen varios tipos definidos de tipos de registros definidos paraen el árbol, entre los cuales podemos destacar:

De hecho existen 2 árboles de datos del DNS: uno para obtener información vía hostname (como es la dirección de IP, el registro CNAME, el registro HINFO o el registro TXT que corresponde a un hostname dado), y uno para obtener información a través de dirección IP dada (el hostname).

Problemas de seguridad del DNS.

Respuestas falsas a consultas de DNS (Bogus answers): El primer problema de seguridad con el DNS es que muchos servidores y clientes pueden ser afectados por el ataque de un hacker haciéndoles creer información falsa. Esto se debe a que muchos clientes y servidores no verifican que todas las respuestas que obtienen están relacionadas con una pregunta que realmente haya realizado, o bien si las respuestas que obtienen están siendo recibidas del servidor al cual fueron formuladas. Los servidores en particular, pueden "cachear" estas respuestas falsas si que sean verificadas y responder a su vez consultas con esta información falsa que se encuentra cacheada.

Esta falta de chequeo de los servidores puede permitir a los atacantes dar información falsa a los clientes y servidores. Por ejemplo, un hacker podría usar esta capacidad para cargar la cache del server con información que dice que su dirección de IP mapea a un hostname de un host "confiable" para acceso sin password via rlogin.

Revelar demasiada información: otro de los problemas al soportar un DNS con un firewall es que este puede revelar mas información de la conveniente, como por ejemplo hostnames que se suponen "discretos" o "secretos" en cuanto a su existencia para personas no autorizadas.

Configuración del DNS para ocultar información interna.

La capacidad de forwarding de un DNS server nos permite armar un esquema en el cual es posible brindar a los hosts internos una visión irrestricta de los datos internos y externos del DNS, y al mismo tiempo restringir una muy limitada visión de la información interna desde el exterior. Entre varios factores, existen 2 por los cuales este tipo de configuración es necesaria:

1. Evitar el acceso externo a información acerca de los hosts internos
2. Porque se desea proveer de cierta información a los hosts externos y otra información diferente a los hosts internos (por ejemplo, se desea que los host internos envíen mail directamente a hosts internos y los mails que se reciben de hosts externos sean tratados de manera diferente -manejados por otro servidor, por ejemplo-).

La primera etapa para llevar a cabo la ocultación de información del interna del DNS configurar n DNS server que se encargue de resolver el acceso externo y establecer alli que información se desea, pueda ser accedida externamente. Dicho servidor es establecido como authoritative para nuestro dominio. Luego debemos establecerlo como el servidor para nuestro dominio que es nombrado en los registros del Name server mantenidos por el dominio padre.

La información que contendrá este servidor acerca de nuestro dominio será aquella que se desee revelar al exterior. Esta información incluye información de IP básica sobre los siguientes hosts:

• Las máquinas que se encuentran en el perímetro de la red (las que constituyen el firewall).
• Cualquier maquina que deba ser contactada directamente por alguien desde fuera de nuestro dominio. S necesitará ademas publicar los registros MX para cualquier host o nombres del dominio que sean utilizados como parte de direcciones de email en mensajes de email y Usenet Eventualmente puede publicarse información falsa para cualquirra de las maquinas que deban ser contactadas externamente en forma directa.
• Sin embargo, si se utiliza exclusivamente proxying para conectar hosts internos con el resto del mundo, simplemente necesita incluir en la información del DNS sobre el /los hosts que estan corriendo un proxy server, El resto del mundo podráa conocer solamente las direcciones las direcciones de los servidores proxy y nada mas.

Configuración de un DNS para uso interno.

Las computadoras internas necesitan utilizar información verdadera acerca del dominio en el cual funcionan, y no la información falsa que pueda darsea conocer a través de un DNS que atiende las necesidades de interacción el resto del mundo. Esto e realiza a través de un servidor de DNS estándar funcionando en algún host interno. Las maquinas internas pueden necesitar averiguar sobre una dirección externa obien traducir el hostname de un servidor remoto de FTP a una dirección de IP.

La primera posibilidad de lograr esto es permitiendo el acceso a información de DNS externa configurando el DNS interno para que consulte a un servidor de DNS remoto para resolver las consultas de las maquinas internas sobre direcciones externas- Tasl configuración no obstante, requiere abrir cualquier filtrado de paquetes para permitir que el DNS interno pueda establecer contacto e intercambiar información (-se trata de un intercambio basado en UDP-)con un DNS externo.

Otra forma es mediante la utilzación de una característica estándar de los DNS: la directiva forwarders en el archivo de configuración del server de DNS /etc/named.boot . Esta directiva siginifica que si elserver no conoce la información requerida (sea de su información de la zona o de su cache de consultas), debe redirigir (forwardear)la consulta a un servidor específico y permitir a este otro server que determine la respuesta por si mismo. En el archivo de configuración /etc/named.boot se establece la línea de forwarders para apuntar el servidor que maneja los requerimientos externos de información acerca del dominio (discutido en el punto anterior).Este archivo contieneuna línea llamada "slave" (eclavo) para forzar la consulta a un determinado servidor de DNS aún si se dispone de una conexión de red lenta.

Las consultas de los clientes al DNS interno.

El próximo paso es la configuración del los clientes internos del DNS para que dirijan todas sus consulta a este servidor interno. En UNIX, esto se realiza a través del archivo /etc/resolv.conf. Existen dos posibilidades:

• Cuando el server interno recibe una consulta sobre un host interno o externo que está en su cache, donde responde directa e inmediatamente.
• La segunda posibilidad es que la consulta sobre información acerca de un host externo no se encuentre en la cache, enviándosela (mediante forwarding) a un server DNS que pueda resolver dicha consulta. Este segundo servidor consultado resuelve la consulta y la devuelve al primer servisor de DNS, el cual a su vez la retorna al cliente que realizo la consulta, de manera transparente.

DNS en el contexto del problema a resolver.

El servicio de DNS se utilizará en de distintas formas con distintos objetivos, y su configuración deberá ser bastante cuidadosa. En particular, pretenderemos conseguir lo siguiente:

• Ofrecer a los hosts en Internet una forma de identificar al firewall como proveedor de nuestros servicios y mail exchanger de nuestro dominio, y a la vez no brindar demasiada información sobre los hosts en la red.
• Ofrecer a los hosts en la red la posibilidad de consultar el servicio de DNS de Internet, en el caso que sea necesario (e.g. al utilizar un proxy socks versión 4).
• Proveer una administración razonable para los nombres de la red, considerando una posible crecimiento de la misma.
• Ofrecer al firewall la capacidad de resolver nombres en Internet y en la red. Esta necesidad es inmediata, dadas las características de un firewall.

Es evidente que necesitaremos como mínimo un servidor de DNS conectado a Internet, tal que pueda ser consultado por los hosts en Internet sobre información sobre nuestro dominio. Naturalmente, la información que este nameserver distribuya deberá ser la que queramos que sea conocida fuera de la red. En particular, casi con certeza toda la información se referirá al firewall, ya que debe ser conocido en Internet como el proveedor de nuestros servicios. Un candidato seguro para hospedar a este servidor es el mismo firewall, ya que está bajo nuestro control administrativo. Adicionalmente es requerido que haya al menos otro nameserver para nuestro dominio, preferiblemente en una red distinta a la de nuestro firewall por cuestiones de conectividad. La configuración lógica será que el nameserver en el firewall sea primario y los otros secundarios, estos últimos transfiriendo la zona del primero.

Para la resolución de los nombres de los hosts en la red, necesitaremos un nameserver accesible desde la misma. Podría considerarse utilizar el nameserver en el firewall con este fin, pero esta configuración presenta dos problemas:

• La información sobre la red sería accesible por los hosts en Internet que hagan un query al nameserver en el firewall. Esto fue considerado no deseable.
• Mayor exigencia para el firewall.

De modo que es natural pensar en un nameserver funcionando en un host dentro de la red, que tenga información completa sobre los hosts de la red. Eventualmente, de acuerdo al tamaño de la red y sus necesidades de administración, será necesario o al menos deseable tener más de un nameserver en la red. Estos nameservers internos obviamente no tendrán conectividad directa con los nameservers en Internet, por lo que deberá existir algún proxy de DNS en el firewall como si estos nameservers fueran clientes de un servicio cualquiera (efectivamente lo son!).

Solamente queda pendiente un detalle: dar al firewall la capacidad de resolver nombres de dominios internos y externos. Esto en principio implica que el firewall deba decidir, basándose en un nombre de dominio, si consultará a nameservers internos o externos. Una forma de llevar a cabo esta decisión es utilizar un archivo de hints modificado para el namserver en el firewall, que explícitamente indique los servidores para el dominio interno, y hacer que el firewall consulte a su propio nameserver. Esta aproximación tiene, sin embargo, tres fallas graves:

1. no es deseable modificar el archivo de hints, ya que la información no estándar puede propagarse al resto de los hosts;
3. no es posible ocultar la información interna;
4. no es posible que el dominio interno sea igual al dominio en Internet.

Otra solución, particularmente simple y elegante, es la siguiente: se configura al firewall para que utilice como nameserver a un nameserver interno (esto es, el firewall consultará a un nameserver distinto del que se ejecuta en él mismo). De este modo, cuando el firewall quiera resolver un nombre, le pedirá ese servicio a un nameserver interno. Si el nameserver tuviera la información sobre el nombre (es decir, si fuera un nombre interno sobre el cual el nameserver tuviera autoridad, o si el nameserver tuviera la información cacheada), la retornaría. Si no, como se explicó anteriormente, este nameserver consultaría al nameserver en el firewall, que a su vez consultaría a los nameservers en Internet. Gráficamente:

5. Servicios

Correo electrónico

El servicio de correo electrónico es actualmente, en conjunto con el de acceso a Web sites, el servicio fundamental en Internet. Los objetivos en cuanto al uso de este servicio incluyen la posibilidad de enviar y recibir mail entre la red e Internet y también disponer de alguna forma de correo corporativo.

Hay varias alternativas en cuanto a los sistemas de mail corporativo, que van desde soluciones propietarias (CC Mail, Microsoft Mail, Microsoft Exchange) a sistemas con tecnología de Internet. Aunque existen gateways entre los sistemas propietarios y el correo de Internet es razonable utilizar, con el ánimo de simplificar la administración y de no mediar otras restricciones, la misma tecnología tanto para el correo corporativo como para el de Internet.

SMTP – POP3.

El Simple Mail Transfer Protocol usado para intercambiar mail entre mail servers. Básicamente, un servidor SMTP acepta mail y decide basándose en la dirección de retorno si debe entregarlo localmente o si debe forwardearlo a otro host. SMTP es un sistema ‘store-and-forward’, particularmente adaptado al funcionamiento en un firewall (todo servidor SMTP funciona como proxy). El Post Office Protocol se utiliza entre clientes y servidores (a diferencia del SMTP, usado entre servidores) para obtener el contenido del mailbox de un usuario.

Consideraciones generales. Distintas aproximaciones.

Para nuestro caso particular podemos en principio pensar en tener un servidor SMTP en el firewall que maneje el mail interno. Esto es bastante lógico, ya que el firewall tiene conectividad con la red y con Internet. Sin embargo, esto implica una sobrecarga al firewall y la necesidad (en la mayoría de los servidores SMTP) de crear una cuenta para cada usuario en el firewall. Claramente, esto no es deseable por problemas de seguridad y eficiencia.

Dejamos de lado entonces la idea de que el SMTP server en el firewall maneje el mail corporativo, y asignamos esa tarea a un mail hub en la red. Este mail hub tendrá un SMTP server que reconocerá como locales los dominios corporativos, y también un POP3 server para el acceso de parte de los clientes a sus respectivos mailboxes. El SMTP server en el firewall se limitará a funcionar como relay, en este caso reconociendo los dominios corporativos para remitirlos al mail hub.

Con esta configuración se disminuye la carga en el firewall, ya que su SMTP server se encarga solamente de remitir el mail que corresponda al mail hub, donde estarían efectivamente los mailboxes de los usuarios. Para utilizar el servicio de mail, los clientes deberán comunicarse con el mail hub utilizando SMTP para enviar correo y POP3 para obtenerlo.

Evidentemente, el mail hub se encargará del mail interno usando este mecanismo, ya que en principio sólo tendría que entregarlo localmente.

Con respecto a la configuración DNS, el firewall será conocido en Internet como el mail exchanger para el domino corporativo; esto es, existirán en el DNS server del firewall (y en los servers secundarios) registros MX que referencien al firewall.

Es conveniente por otro lado disponer o al menos tener autorización para utilizar otro SMTP server en Internet como mail exchanger para nuestro dominio, para el caso en que el server en el firewall se encuentre incapacitado para responder a pedidos externos (por ejemplo en el caso de una interrupción en el enlace a Internet). Esto se reflejará en registros adicionales en el DNS. No serían necesarios cambios en la configuración de este nuevo SMTP server, porque sólo el server en el firewall está al tanto de las características especificas del manejo del mail hacia el dominio corporativo.

Gráficamente:

Una primera modificación será separar el mail hub en dos partes: una que aloje los mailboxes y otra que se comunique con el SMTP server en el firewall.

Cuando recibe un mail, el SMTP server en el mail hub determina si la dirección es local, en cuyo caso remite el mensaje al POP3 server, o si es externa, para enviarla al SMTP server en el firewall.

Podría pensarse que distintas áreas decidieran alojar sus propios mail servers, en cuyo caso el mail hub deberá, basándose en la información disponible sobre el destinatario de un mensaje, decidir a que server corresponde dicho mensaje. Esto puede resultar más o menos complicado, de acuerdo a la naturaleza de la información disponible. Si todos los mensajes que recibe el mail hub son de la forma usuario[arroba]company.com no hay otra alternativa más que buscar en alguna tabla en base al nombre de la cuenta a que server corresponde el mensaje. Una implementación muy burda de esto es tener una cuenta por cada posible destinatario, y modificar los archivos de forwarding para cada cuenta (.forward). De más está decir que esto es una pesadilla de administración.

Una forma más elegante es utilizar un archivo de aliases, con entradas de la forma:

usuario: nuevousuario[arroba]realserver.company.com

Ambas alternativas son soportadas por los servidores SMTP razonables.

Si se dispone de mas información la tarea se simplifica notablemente. En lugar de utilizar direcciones de la forma usuario[arroba]company.com, se podrían utilizar otras como usuario[arroba]sales.company.com. El SMTP server en el mail hub podría determinar fácilmente que server interno está encargado del mail dirigido al dominio sales.company.com (claro, si un único server se encarga de todo el correo electrónico de dicho dominio). Este caso es muy similar al de redirector de www para brindar servicios.

Gráficamente:

Un importante aspecto a tener en cuenta es qué clase de direcciones serán visibles en Internet. Claramente, serán indeseables las direcciones que hagan referencia a hosts internos como user[arroba]some.inner.host.company.com, tanto por el hecho de que divulgan información interna como que aumenta la cantidad de dominios que debemos manejar en Internet, además de no ser estéticas (al menos según los criterios actuales). La forma en que se generen estas direcciones puede estar configurada en los programas clientes de mail que utilizan los usuarios, pero no esta de más configurar el SMTP server en el mail hub para que fuerce esta política, reescribiendo las direcciones que no cumplan con los parámetros que definamos.

Implementación

Para implementar nuestros servidores SMTP utilizaremos el software Sendmail sobre Unix. Aunque no lo utilizaremos en toda su capacidad, aprovecharemos varias de sus características, como la posibilidad de reescribir las direcciones en los mensajes salientes, así como el uso de tablas de traducción de direcciones. Aún mas, dado que no está contemplada la conexión a sistemas de mail que no utilicen el protocolo SMTP, nuestra configuración será bastante sencilla. A continuación caracterizaremos a cada SMTP server involucrado.

– Server en el firewall: este servidor estará en contacto con Internet, con lo que es razonable tener en cuenta aspectos de seguridad. Dado

6. WWW

Puede considerarse que el servicio de WWW es el responsable del crecimiento explosivo de Internet en los últimos años, particularmente a partir de la distribución de browsers gráficos como el NCSA Mosaic y el Netscape Navigator. Es entonces imprescindible poder contar con la capacidad de brindar este servicio como punto de presencia en Internet, y de utilizarlo como herramienta de trabajo (y esparcimiento).

El protocolo HTTP (HyperText Transfer Protocol) utilizado para brindar este servicio es muy sencillo conceptualmente, ya que se establece una conexión por cada requerimiento al servidor. Estas conexiones no tienen estado y son básicamente un pedido seguido de una respuesta. Por estas características este protocolo está particularmente adaptado al uso de proxies. Además la mayoría de los clientes soportan el protocolo SOCKS, así como el uso de proxies de HTTP como discutiremos en esta parte, brindando una amplia gama de alternativas al momento de implementar una solución. Es por lo tanto muy sencillo brindar una solución para el uso del servicio de web.

Aunque disponemos ya de un servidor SOCKS en el firewall, que podría perfectamente servir al propósito de utilizar el servicio de web, nos inclinamos por el uso de una solución basada en proxies HTTP. Los beneficios de utilizar estos proxies radican en la posibilidad de realizar caching de las páginas accedidas, con el consiguiente aumento de performance en el acceso, y de realizar restricciones basadas en el protocolo HTTP, más que en los hosts involucrados en la comunicación como sería en el caso de SOCKS (el puerto de comunicación es el mismo en general).

El producto utilizado como proxy de HTTP es el Squid, por dos razones: es de uso gratuito y es uno de los más conocidos.

Como siempre, deberá existir en el firewall algún proxy que nos provea de conectividad con Internet. En el caso del servicio de web, el uso del caching es muy beneficioso sobre todo en nuestra situación, donde disponemos de una única conexión con Internet. Sin embargo, esto consume una gran cantidad de recursos en el host que aloja al proxy, ya sea recursos de almacenamiento como computacionales. Por este motivo, el proxy en el firewall no hará caching. Las funciones de caching serán realizadas por otros proxies funcionando en hosts internos, que serán en definitiva consultados por los clientes internos y que consultarán a su vez al proxy en el firewall. La cantidad de caching proxies internos estará determinada por la magnitud de la red interna, asi como sus necesidades de administración. El Squid puede ser configurado para funcionar en ambos roles.

Una característica muy beneficiosa de los proxies avanzados como el Squid es la posibilidad de establecer jerarquías de proxies, con el objetivo es especificar las relaciones entre los distintos servidores. Básicamente existen dos tipos de relaciones entre proxies: parent (padre) y sibling (hermano).

Para resolver el pedido de un objeto, un verificará en su cache proxy si dispone del mismo. Si es así, lo retornará. En otro caso, consultará a los proxies que tenga configurados como siblings utilizando un protocolo especifico denominado ICP (Internet Caching Protocol); en caso que ningún sibling pueda satisfacer su pedido, el proxy lo pedirá a alguno de sus parents (en caso que los haya, si no es así buscará directamente el objeto en su fuente original).

La solución propuesta es, entonces:

Disponer de un proxy en el firewall, configurado para aceptar únicamente requerimientos de parte los caching proxies que lo tendrán como parent. Este proxy no hará caching.

Disponer de al menos un caching proxy en un host interno. Los proxies internos estarán configurados como siblings entre ellos, y tendrán como parent al proxy en el firewall.

Los clientes internos estarán configurados para utilizar como proxy a alguno de los proxies internos. En general, los clientes modernos pueden configurarse para no utilizar proxy para obtener información desde determinados dominios (en este caso deberían estar configuarados para no utilizar proxy en el dominio local). Adicionalmente, configuraciones más avanzadas como la configuración automática de proxies presente en los productos de netscape, permiten determinar que proxy debe consultarse en base a la ubicación del objeto que quiere conseguirse.

Gráficamente:

Control de acceso…………………………

Naturalmente, al momento de publicar nuestros documentos nos encontramos con las mismas restricciones que para el resto de los servicios: no podemos asumir nada sobre los clientes. Por esto, tenemos tres alternativas:

Tener un web server en el firewall. Descartada por la carga que se impondría al firewall.

Proveer un mapping a nivel TCP desde el puerto estándar 80 en el firewall a algún servidor interno. Aunque esta solución aligera la carga en el firewall, estamos permitiendo el acceso a un host interno de parte de cualquier host en Internet. Esto no es deseable. Además, este mapping será estático y por lo tanto no podrán utilizarse más de un único web server interno.

Utilizar un servidor en el firewall que, de acuerdo al pedido que le realice un cliente (externo probablemente) determine que web server interno tiene la información solicitada y pedírsela, para luego devolverla al cliente original. Es necesario en este caso que este mecanismo funcione de manera transparente para el cliente original.

Esta última solución fue considerara la más adecuada por la flexibilidad que ofrece. Para implementarla se utilizará también squid, aunque en modo http accelerator. A diferencia del funcionamiento normal como caching proxy donde el cliente conoce al proxy como tal, en modo http accelerator squid funciona como un web server normal. Claro que como no dispone de la información debe ir buscarla a un web server real.

La forma en que decide a que server debe consultar puede ser más o menos complicada, dependiendo de la situación. El administrador cuenta con la posibilidad de configurar al squid para que consulte a un programa llamado redirector que haga la traducción entre el URL solicitado originalmente por el cliente y el URL real. Sin embargo, en nuestro caso no es necesaria la traduccion, ya que la dirección IP del host en el URL original será resuelta en el firewall por un name server diferente al que utilizó el cliente (que obtuvo la dirección del firewall!), con lo que basta tener en la red interna un host con el mismo nombre con el que es conocido el servidor en Internet.

La secuencia de acciones que ocurren desde el momento que un cliente quiere obtener un documento a partir de un URL, suponiendo que el URL es ‘http://www.company.com’, serán:

1. El cliente consultará a su nameserver por la dirección de www.company.com.
2. El nameserver consultado por el cliente obtendrá eventualmente la dirección de Internet del firewall (consultar la sección sobre DNS).
3. El cliente pedirá al http accelerator en el firewall (creyendo que es un web server normal) el documento identificado por el URL.
4. El http accelerator consultará a su nameserver por la dirección www.company.com.
5. El nameserver consultado por el http accelerator (un nameserver interno) retornará la dirección de IP en la red interna para el host www.company.com.
6. El http accelerator pedirá al web server real el documento.
7. El http accelerator retornará al cliente original el documento pedido, como si fuera propio.

Al momento de implementar la solución surgió un problema con los web servers virtuales. Para solucionarlo, fue necesario restringir los servers virtuales a servers virtuales basados en dirección IP (en contra de los servers virtuales basados en nombre de host). Aunque este tipo de servers virtuales tiene como desventaja de necesitar una dirección IP por cada dominio, no hay limitaciones en la cantidad de direcciones IP disponibles ya que hay suficientes en los espacios de direcciones privadas.

Tampoco es necesario utilizar un host para cada dominio (o al menos una interface de red para cada dominio), ya que existe la posibilidad de utilizar aliases al momento de asignar direcciones de IP a una interface para un host en nuestra plataforma de implementación.

Quedarán entonces configurados los distintos componentes de la siguiente manera:

Donde los web servers internos o bien mas de una interface a la red, o utilizan IP ALIASING para asignar más de una dirección IP a su interface.

De esta forma no hay inconvenientes al momento de determinar cual es el virtual server que debe atender el requerimiento original.

7. FTP

Para realizar una sesión de FTP, se utilizan diferentes conexiones: una se usa para transportar comandos entre el cliente y el servidor, y la otra para transportar los datos. El canal de comandos utilizado por el servidor se encuentra en el puerto 21, y el de datos en el 20. El cliente, utiliza puertos por encima del 1023 tanto para el canal de datos como para el de comandos. También se pueden utilizar conexiones en modo "pasivo" en donde el cliente no identifica el canal de datos, y es el servidor el que utiliza un canal superior al 1023, que es utilizado exclusivamente por el cliente.

En una configuración de red como la anterior, no existen muchas alternativas para proveer el servicio de FTP.

La alternativa más sencilla es poseer un servidor de FTP en la entrada de la red, en donde éste puede ser accedido por los clientes de la red, como desde fuera. Esto posee varias desventajas anteriormente mencionadas: la sobrecarga del servidor principal (que contiene a todos los servicios), y algunos inconvenientes de seguridad, ya que puede ser accedido desde el exterior.

Utilizando un proxy socks en el proxy server, se puede configurar al servidor de FTP en algún lugar interno de la red, en el cual pueda ser accedido por los clientes internos, y por los externos a través del proxy.

Sin embargo, si se posee una gran red con muchas subredes, a veces es conveniente el de disponer de servidores de FTP locales. Como se mencionó anteriormente, los clientes acceder al canal de comandos del servidor de FTP a través del puerto 21. Utilizando un proxy socks se puede mapear ese puerto a un solo servidor de la red, por lo que no sería posible acceder desde fuera de la red a más de un servidor de FTP.

La mejor alternativa es la de disponer un servidor de FTP global de la red, el cual puede ser accedido tanto desde fuera como desde las subredes, y servidores locales internos.

La seguridad es inmediata: los servidores locales son totalmente seguros, ya que no existe el acceso a los mismos por agentes externos, y la seguridad del servidor general está dada por el proxy.

Telnet

Continuando con la configuración de red anteriormente mencionada, se está ante un problema similar al anterior. Los usuarios que acceden a la red desde el exterior, sólo pueden conectarse con un servidor de telnet

Sin embargo, posee una diferencia radical: aquellos usuarios conectados a una terminal general, disponen de la posibilidad de realizar conexiones con las terminales locales de las subredes. Un usuario puede conectarse desde el exterior a una terminal local a través de otra (global), que actúa de fireball.

Por lo general, es conveniente disponer de servidores de FTP en las maquinas en las que se posee terminales. De esta manera, un usuario conectado a cualquier terminal de la red desde el exterior, podría tener la posibilidad de obtener archivos de cualquier servidor de FTP de la red; estos archivos serían almacenados temporalmente en la terminal, para luego ser obtenidos por el usuario nuevamente vía FTP.

Aunque este proceso sería un poco más trabajoso para el usuario, solucionaría el problema que no podía resolverse en el caso anterior.

Existen muchos otros servicios que pueden ser deseables proveer por la red. Siempre y cuando estos servicios utilicen diferentes puertos de comunicación, se puede configurar al servidor de socks para mapear el servicio a un maquina (servidor) específica.

Por supuesto, y como en todos los casos anteriores, no es posible el de disponer de diferentes servidores que proporcionen el mismo servicio, al no ser que se disponga de un producto específico que esté diseñado para ello, como en el caso de los servidores de Web.

DCHP

Cada computadora en una red TCP/IP debe tener tener asignado un nombre y dirección de IP únicos. Esta dirección de IP identifica a la computadora y la subred a la cual pertenece. Cuando una computadora es movida a una subnetwork diferente, la dirección de IP debe ser cambiada para reflejar la nueva Network ID.

DHCP es un protocolo diseñado para reducir la complejidad en la configuración de computadoras para TCP/IP. El RFC 1541 identifica los dos elementos mas importantes del DHCP:

• un protocolo de comunicación de parámetros de configuración de TCP/IP entre un servidor de DHCP y sus clientes.
• un método para la alocación dinámica de direcciones de IP para los clientes de DHCP.

Wins

Microsoft Windows Internet Name service (WINS) es una implementación del servicio de mapeo de nombre NetBIOS a una dirección de IP.WINS permite que los clientes basados en Windows puada facilmente localizar facilmente recursos compartidos en una red con TCP/IP. Los servidores de WINS mantienen bases de mappings de nombres de recuursos estáticos y dinámicos a direcciones de IP. Dado que WINS soporta entradas de nombre y direcciones de IP dinámicas, puede ser utilizado con DCHP para proveer administración y configuración sencillas en redes TCP/IP basadas en Windows. De hecho esta posibilidad es mas bien un requerimiento, para permitir que los clientes pueden ser actualizados dinámicamente en los mappings de nombre-a-IP.

Packet Filtering

Packet filtering es un mecanismo de seguridad de redes que funcionan controlando que datos pueden fluir desde y hasta una red.

Un router debe decidir una decisión de ruteo sobre cada paquete que recibe sobre como enviarlo a su destino final. En general, los paquetes no llevan consigo información para ayudar al router en esta decisión, aparte de la dirección de IP destino (- salvo algunos paquetes poco comunes denominados "source routed packets"-). En la determinación de como enviar el paquete, el router habitualmente se preocupa solamente de resolver el problema de cómo realizar el envío. Un router que además hace packet filtering se preocupa por decidir si debería rutear ese paquete o no.

La utlización de packet Filtering o "filtrado de paquetes" permite el control (habilitación o deshabilitación) de las transfarebecias de datos basado en :

• La dirección en la cual los datos se (supuestamente) envían.
• La dirección en la cual los datos son dirigidos.
• La sesión y los protocolos de aplicación utilizados para la transferencia de datos.

La mayoría de los sistemas de filtrado de paquetes no hacen nada respecto de los datos en si, porque no realizan ningun tip de decisiones basados en el contenido. Un filtradode paquetes permite establecer reglas del siguiente tipo:

• No permitir que nadie utilice el TELNET (unprotocolo de aplicación) para loguearse desde el exterior de la red
• Permitir que cualquiera envia mails utilizando el sendmail (otro protocolode aplicación.
• Que una computadora pueda enviarnos NEWS via NNTP (otro protocolo de aplicación) pero solamente esa computadora.

Sin embargo, existe nciertas cosas que no se pueden realizar con esta técnica:

• Que un usuarios pueda realizar un TELNET desde elexterior pero n otros usuarios.

Esto se debe a que el concepto de usuario no es algo que el sistema de filtrtado sea capaz de reconocer. Otro ejemplo de esto podria ser:

• Poder transferir algunos archivos y otros no.

Una de las principales ventajs qiue provee esta técnica es simplicidad: perimite establecer en un solo lugar políticas de seguridad para toda una red. Por otra parte, ciertas protecciones sólo pueden ser provistas a través de esta técnica y solamente si estas se implementan en determinados puntos de accesos de la red. A continuación enumeramos las principales ventajas de Packet Filtering:

1. Un solo Router ed Screenning puede ayudar a proteger toda una red.
2. Packet Filterig no requiere del conocimiento del usuario o cooperación
3. Está disponible en una gran variedad de routers.

Sin embargo existen ciertas desventajas:

1. Loas herramientas actuales de filtrado no son perfectas.
2. Alguns protocols so especialmente conflictivos para el "filtrado".
3. Algunas politicas no pueden ser facilmemnte llevas a cbo por algunos routers

8. Configuración de los servidores

Configuración de los servidores.

DNS

El DNS server en el firewall (NS1.company.com) será authoritative del dominio company.com.

Tendrá registros para los dominios que quieran hacerse públicos, y será el nameserver primario de la zona company.com.

Habrá al menos otro nameserver (NS2.othercompany.com), secundario, con conectividad directa a Internet que transferirá la zona company.com desde DNS1.

Asumiendo que tenemos una sola dirección de IP para nuestro firewall, tendremos que dejar que el proveedor de nuestro enlace maneje el DNS reverso para nuestra única dirección (i.e. no tendremos control sobre esto).

Las configuraciones de los distintos nameservers involucrados serán entonces:

Root name servers:

.com zone file

NS2.othercompany.com

named.boot file

NS1.company.com

named.boot file

company.com.zone file

El firewall estará configurado para resolver nombres de hosts consultando a un nameserver interno. La configuración del resolver será entonces:

resolv.conf file

En la red interna habrá al menos un nameserver (INS1.company.com con dirección IP 192.168.0.5), sin conectividad a Internet. Este nameserver será authoritative de la zona company.com (como el nameserver en NS1.company.com) pero obviamente no le será delegada la zona en los root servers. Este nameserver será consultado por todos los hosts en la red interna, incluyendo el firewall.

Eventualmente, de acuerdo al tamaño de la red interna y las características de la administración, será necesario o conveniente delegar zonas a otros nameservers internos.

Como los nameservers internos no podrán consultar a los root nameservers, y tendrán por lo tanto que estar configurados como forward-only (antes slave) y tener como forwarders a algún nameserver con conectividad.

Suponiendo que es necesario delegar la zona sales.company.com al nameserver INS1.sales.company.com, las configuraciones serán las siguientes.

INS1.company.com

named.boot file

resolv.conf file

company.com.zone file

192.168.0.rev file

INS1.sales.company.com

named.boot file

Mail

Habrá mail servers en el firewall (firewall.company.com) y en un servidor interno (mailhub.company.com). Las configuraciones particulares para estos servidores seran:

Firewall: el mailserver en el firewall aceptará mail para y desde el dominio company.com y funcionará como relay únicamente. La configuración incluirá reglas para evitar el uso indebido del servidor como relay para mail no deseado (spam mail).

Mailhub: el mailserver en el mailhub aceptará como local el mail para company.com, y funcionará como relay para los mails generados dentro de la red privada. Los clientes de mail internos no deberán intentar enviar el mail directamente (ya que no tienen conectividad).

(# poner configuracion del sendmail – en los aspectos significativos: smart host, local domains).

World Wide Web

En el firewall funcionaran un redirector para brindar servicio al exterior y un proxy para poder acceder a los servers externos. Adicionalmente, funcionará en la red interna al menos un caching proxy.

Redirector: el redirector será un squid funcionando como http accelerator, configurado para transformar los URL que reciba a direcciones en los servidores internos. Las directivas de configuración necesarias serán:

squid.accelerator.conf file

este squid no hará proxying.

Proxy: el proxy será otro proceso squid, que hará proxying pero no caching para aligerar. Sólo atenderá pedidos desde los caching proxies internos.

squid.ncproxy.conf file

Caching proxy internos: los caching proxies internos formaran (en caso que haya mas de uno) una jerarquía. Una elección razonable sera hacer que los proxies internos sean siblings entre ellos, y tengan como paren al proxy en el firewall. De este modo, la configuración será:

squid.cproxy.conf file

El acceso al servicio de www se configurará en los ACL de los proxies.

Socks server

ACL

Socks server

Packet Filtering

Autor:

Leibovich, Matias

Simonazzi, Fernando Lyardet, Fernando D.