Configuración de una Intranet
Trabajo práctico - Tecnología de Redes
Indice
8. Configuración
de los servidores
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.
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 proxy 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:
3. Evolución de la solucion
A.
Se dispone de una sola red en la cual
cada host tiene acceso a todas las demas maquinas dentro de la red.
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).
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)
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.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:
|
Tipo de registro |
Uso: |
|
A |
Traduce un
nombre de host (hostname)
en un a dirección IP. |
|
PTR |
Traduce una
dirección IP en un nombre de host (hostname). |
|
CNAME |
Traduce el
alias de un host a su hostname
(nombre “canónico”). |
|
NS |
Delega una
zona del arbol del DNS a algún otro server. |
|
SOA |
Denota “Start Of Authority”
para una zona de un árbol de DNS. |
|
TXT |
Registros
no-estructurados de texto. |
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:
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:
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:
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:
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@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@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@company.com, se podrían utilizar otras como usuario@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@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
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.
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.
4.
Sin embargo existen ciertas desventajas:
5.
Loas herramientas actuales de filtrado no son perfectas.
6.
Alguns protocols so especialmente conflictivos para el
“filtrado”.
7.
Algunas politicas no pueden ser facilmemnte llevas a cbo por
algunos routers
8. Configuración de los servidores
Configuración de los servidores.
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
|
... company.com. IN NS NS1.company.com. company.com. IN NS NS2.othercompany.com. NS1.company.com. IN A 200.10.10.5 ... |
NS2.othercompany.com
named.boot file
|
directory
/var/named cache . named.root secondary company.com 200.10.10.5 company.com primary 0.0.127.in-addr.arpa local.rev ;otras zonas que pueda manejar este nameserver primary .... secondary .... ..... |
NS1.company.com
named.boot file
|
directory
/var/named cache . named.root primary company.com company.com.zone primary 0.0.127.in-addr.arpa local.rev ;reverso manejado por nuestro provider |
company.com.zone file
|
company.com. IN SOA NS1.company.com.
hostmaster.company.com. (....) ; registros NS company.com. IN NS NS1.company.com. company.com. IN NS NS2.othercompany.com. NS1.company.com. IN A 200.10.10.5 ; registro MX para el dominio company.com. IN MX 5 NS1.company.com. company.com. IN MX 10 mailhub.somewhere.com. ; registros de los servicios, y sus respectivos registros MX www.company.com. IN CNAME NS1.company.com. www.company.com. IN MX 5 NS1.company.com. www.company.com. IN MX 10 mailhub.somewhere.com. ftp.company.com. IN CNAME NS1.company.com. ftp.company.com. IN MX 5 NS1.company.com. ftp.company.com. IN MX 10 mailhub.somewhere.com. mail.company.com. IN CNAME NS1.company.com. mail.company.com. IN MX 5 NS1.company.com. mail.company.com. IN MX 10 mailhub.somewhere.com. |
El firewall estará configurado para resolver
nombres de hosts consultando a un nameserver
interno. La configuración del resolver será entonces:
resolv.conf file
|
domain company.com nameserver 192.168.0.5 |
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
|
directory
/var/named primary company.com company.com.zone primary 0.168.192.in-addr.arpa 192.168.0.rev primary 0.169.192.in-addr.arpa 192.169.0.rev primary 0.170.192.in-addr.arpa 192.170.0.rev primary 0.0.127.in-addr.arpa local.rev forwarders 192.168.0.1 ;tiene como forwarder
al nameserver en el firewall options forward-only |
resolv.conf file
|
domain company.com nameserver 192.168.0.5 |
company.com.zone file
|
company.com. IN SOA INS1.company.com.
hostmaster.company.com. (...) company.com. IN NS INS1.company.com. INS1.company.com IN A 192.168.0.5 company.com. IN MX mailhub.company.com. ;zonas delegadas sales.company.com. IN NS INS1.sales.company.com. INS1.sales.company.com. IN A 192.169.0.5 ;información sobre los hosts del dominio ;servers webserver.company.com. IN A 192.168.0.10 mailhub.company.com. IN A 192.168.0.11 ftpserver.company.com. IN A 192.168.0.12 .... firewall.company.com. IN A 192.168.0.1 ;workstations ws1.company.com. IN A 192.168.0.101 ws2.company.com. IN A 192.168.0.102 .... ws300.company.com. IN A 192.170.0.100 .... ;otras
configuraciones..... .... |
192.168.0.rev file
|
0.168.192.in-addr.arpa. IN SOA INS1.company.com.
hostmaster.company.com (...) 0.168.192.in-addr.arpa. IN NS INS1.company.com. 1.0.168.192.in-addr.arpa. IN PTR firewall.company.com. 5.0.168.192.in-addr.arpa. IN PTR INS1.company.com. 10.0.168.192.in-addr.arpa. IN PTR webserver.company.com. 11.0.168.192.in-addr.arpa. IN PTR mailhub.company.com. ... 101.0.168.192.in-addr.arpa. IN PTR ws1.company.com. |
INS1.sales.company.com
named.boot file
|
directory
/var/named primary sales.company.com sales.company.com.zone primary 0.0.127.in-addr.arpa local.rev forwarders 192.168.0.5 ;tiene como forwarder al nameserver
principal options forward-only |
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
|
# http_port 80 # redirect_program /usr/local/squid/bin/myredirector.pl #si hay mas de un web server #httpd_accel virtual 80 #si hay un unico web server httpd_accel webserver.company.com 80 httpd_accel_with_proxy off httpd_accel_uses_host_header on |
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
|
# http_port 3128 # control de acceso (solo dejo que me pidan desde
dentro) # solo para acl inner_hosts src 192.168.0.0/255.255.254.0 acl all src 0.0.0.0/0.0.0.0 http_access allow inner_hosts http_access deny all |
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
|
#port http_port 3128 #jerarquia cache_host firewall.company.com parent 3128 3130 cache_host proxy2.company.com sibling 3128 3130 proxy-only ... cache_host proxyN.company.com sibling 3128 3130 proxy-only # inside_firewall company.com # |
El acceso al servicio de www se
configurará en los ACL de los proxies.
Socks
server
ACL
Socks
server
Packet Filtering
Trabajo enviado por:
Leibovich, Matias
matiasl@lacarabela.com
Simonazzi, Fernando
Lyardet, Fernando D.