Competitive Analysis: Netscape

Indice
1.
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.