Análisis de redes socioinstitucionales y cohesión social ...
ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/5393/1/T2015.pdf2. ANÁLISIS DE...
169
ESCUELA POLITÉCNICA NACIONAL ESCUELA DE INGENIERÍA ANÁLISIS Y OPTIMIZACION DE LA EXTRAÑE? DE LA BOLSA DE VALORES QUITO PROYECTO PREVIO A LA OBTENCIÓN DEL TITULO DE INGENIERO EN ELECTRÓNICA Y TELECOMUNICACIONES JUAN DIEGO PESANTEZ DURAN DIRECTOR: ING. PABLO HIDALGO L. Quito, Marzo 2002
Transcript of ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/5393/1/T2015.pdf2. ANÁLISIS DE...
ESCUELA POLITÉCNICA NACIONAL
ESCUELA DE INGENIERÍA
ANÁLISIS Y OPTIMIZACION DE LA EXTRAÑE?DE LA BOLSA DE VALORES QUITO
PROYECTO PREVIO A LA OBTENCIÓN DEL TITULO DE INGENIERO ENELECTRÓNICA Y TELECOMUNICACIONES
JUAN DIEGO PESANTEZ DURAN
DIRECTOR: ING. PABLO HIDALGO L.
Quito, Marzo 2002
DECLARACIÓN
Yo. Juan Diego Pesantez Duran, declaro que el trabajo aquí descrito es de mi autoría; que
no ha sido previamente presentado para ningún grado o calificación profesional; y, que he
consultado las referencias bibliográficas que se incluyen en este documento.
La Escuela Politécnica Nacional, puede hacer uso de los derechos correspondientes a
este trabajo, según lo establecido por la Ley, Reglamento de Propiedad Intelectual y por la
normatividad institucional vigente.
Juan Diego Pesantez Duran
CERTIFICACIÓN
Certifico que el presente trabajo fue desarrollado por Juan Diego Pesantez Duran, bajo mi
supervisión.
Ing. Pablo Hidalgo L.
DIRECTOR DE PROYECTO
AGRADECIMIENTOS
La cristalización del presente trabajo se debe fundamentalmente a la constante
motivación y apoyo por parte de mis padres y hermanos, por lo cual deseo
expresar mi profunda gratitud.
Mis más sinceros agradecimientos a todos quienes han demostrado interés en
la realización y culminación de este proyecto; a los miembros del tribunal
examinador por sus comentarios y sugerencias, y de manera especial al Ing.
Pablo Hidalgo, por la paciencia y apoyo brindados durante la realización del
presente proyecto.
Al personal del Departamento de Sistemas de la Bolsa de Valores Quito, por su
apertura hacia el proyecto y por generar un ambiente de trabajo óptimo.
PRESENTACIÓN i
RESUMEN 3
CAPÍTULO I
1. DESCRIPCIÓN DE LA RED ?
1.1 EXTRANET 6
1.1.1 RED LOCAL 6
1 .1 .1 .1 Capa//arta Red 6
/. /. /. /. / Capa Host a Red en la Red Loca/ 8
1.1 .1 .2 Capa Inter-Red 8
/. /. /. 2. / Protocolos Je ruteo 8
/. /. /. 2.2 Direccionamienfo IP 10
/. /. /. 2.3 Knnnamiemo Sin (Alases 12
/. /. /. 2.4 Protocolos de enrittamiento \
I. i. 1.2.5 Capa Iníer-Redde la Red Local 14
1.1.1.3 Capa Transporte 16
LL1.3.I TCP 16
1.1 .1 .4 Capa Aplicación 18
/. /. 1.4.1 ("afja Aplicación en la Red Local \
1.1.2 SUBRED DE COMUNICACIONES 18
1.1.2 .1 Capa Host a Red en la subred de comunicaciones 201.1.2. i. i l'.35 20
1.1.2.1.2 PPP 21
1.1.2.2 Capa Inter-Red en la Subred de Comunicaciones 22
I I
1.1.2.3 Capa Transporte en la Subred de Comunicaciones 26
1.1 .2 .4 Capa Aplicación en la Subred de Comunicaciones 26
REFERENCIAS CAPÍTULO I 27
CAPÍTULO II
2. ANÁLISIS DE REDES 28
2.1 INTRODUCCIÓN AL ANÁLISIS 28
2.1.1 DEFINICIÓN DE ANÁLISIS DE REDES 28
2.1.2 El ANALIZADOR DE PROTOCOLOS 28
2.1.2.1 Definición 28
2.1.2.2 Clasificación 29
2.1.2.2.1 Analizadores LAN 29
2.1.2.2,2 Analizadores WAN 31
2.1.2.3 Elementos 32
2.1.2.3.1 Pucnos 33
2.1.2.3.2 Decodificadorcs 3 3
2.1.2.3.3 /-'i//ros f( 'api aray \ 34
2. ¡. 2.3. ~f Gráficos y esiadisíicas 34
2.1.2.3.5 Alarmas 34
2.1.2.3.6 fiíiffer de ('aptnm 3 5
2.1.3 LA SESIÓN DE ANÁLISIS 35
2.1.3.1 Identificación de las áreas de interés 35
2.1.3.2 Ingreso a la red 35
2.1.3.3 Recolección interpretación y documentación de la información 37
2.1.4 DELINEAMIENTO BASE DE LA RED 39
111
2.1.4.1 Definición 39
2.1.4.2 Ventajas 40
2.1.4.3 Procedimiento 41
2. 1. -i. 3.1Estadísticas a nivel Je segmento 42
2.1. 4. 3.2 Esíadisticas a nivel de Estación 52
2.1. -4.3.3 Estadísticas ci nivel de Aplicación 56
2.1.4.4 Documentación 60
2.2 ANÁLISIS DE LA EXTRANET 61
2.2.1 REPORTE DE LA SESIÓN DE ANÁLISIS 61
REFERENCIAS CAPÍTULO II 78
CAPÍTULO III
3. OPTIMIZACIÓN DE LA EXTRANET 79
3.1 TRAMAS CORTAS 79
3.2 RUTAS 80
3.3 TRÁFICO INNECESARIO 81
3.4 SEGURIDADES EN REDES: DEFINICIONESY CONCEPTOS 83
3.4.1 DEFINICIONES 83
3.4.1.1 Seguridad Computacional 83
3.4. L L1 Confidencialidad 83
3.4.1.1.2 Integridad 83
3.4.1.1.3 Disponibilidad 84
IV
3.4.1.2 Amenazas s4
3.4.1.3 Intrusiones 8"*
3.4.1.4 Ataque y Penetración $4
3.4. /.-/. / l'eneiraciones Externas 84
3.-4. 1.4.2 Penetraciones Internas 84
3.4.1.4,3 Abusos de Autoridad 85
REFERENCIAS CAPÍTULO III 86
CAPITULO IV
4. PLAN DE SEGURIDAD PARA LA EXTRANET 87
4.1 GENERALIDADES 87
4.2 VALORACIÓN DE RIESGOS 87
4.2.1 IDENTIFICACIÓN DE BIENES 88
4.2.2 IDENTIFICACIÓN DE AMENAZAS 88
4.2.1.1 Amenazas Contra la Confidencialidad 88
4.2.1.1.1 Ataques por Moniloreo de Red 88
4.2. i. 1.2 Ataques por falsificación lly 89
4.2.1.1.3 Ataques de Contraseña 89
4.2.1.1.4 Divulgación de Información ("rilica 90
4. 2.1.1.5 A laques de intermediarios 90
4.2.1.2 Amenazas Contra la Integridad 90
4.2.1.2.1 A laques por Rastreadores de luquetes 9!
4.2.1.2.2 Ataques de contraseña 9]
4.2.1.2.3 Ataques a nivel de aplicación 92
4.2.1.3 Amenazas Contra la Disponibilidad 92
4.2.1.3.1 Consumo de Recursos limitados 93
V
4.2.1.3.2 Alteración o destrucción de información de configuración 97
4.2.1.3.3 Destrucción Física o Alteración de los (Componentes de Red 97
4.3 DESARROLLO DEL PLAN DE SEGURIDAD 98
4.3,1 ARQUITECTURA 98
4.3.1.1 Objetivos 98
4.3.1.1.1 Planes de Seguridad (Completamente Definidos 98
4.3. i. 1.2 Separación de Servicios 99
4.3.1.1.3 Denegar Todo Permitir Todo 99
4.3.1.1.4 Nuevos Servicios 99
4.3.1.2 Configuración de Red y de Servicios 100
4.3. /. 2.1 Protección de la Infraestructura \0
4.3. /. 2.2 Protección de la Red \0
4.3.1.2.3 Protección de los Servicios 103
4.3.1.2.4 Protegiendo al Sistema de Protección ] 06
4.3.1.3 Muros de Segundad (Firewalls) 106
4.3.1.3.1 Muros de Seguridad por nitrado \7
4.3.1.3.2 Muros de Seguridad mediante Servicios Apoderados (Proxy) \8
4.3. /. 3.3 Muro de Seguridad Basado en /Mementos Actuales de la Extrañe/ 109
4.3. /. 3.4 Muro de Seguridad Basado en el Sistema Operativo Linux \4
4.3.1.4 Sistemas para Detección de Intrusiones (IDSs) I 19
4.3. i. 4.1 Sistema Sencillo para Moni toreo del Desempeño de la red v
Detección de Intrusiones \1
4.3.2 SERVICIOS DE SEGURIDAD Y PROCEDIMIENTOS 123
4.3.2.1 Autentificación 123
4.3.2.!. J (Contraseña de una Ocasión \4
4.3.2.1.2 Kerheros \4
VI
4. 3. 2.1.3 ( "í)ntrtixeiict\ I - 5
4.3.2.2 Confidencialidad Mediante Encripeión 126
4.3.2.3 Integridad Usando Sumas de Comprobación 126
4.3.2.4 Autorización 127
4.3.2.5 Acceso 128
-4.3.2.5. 1 Acceso Físico 128
4. 3. 2. 5. 2 Punios de Libres para Conexión a /a Red 1 28
REFERENCIAS CAPÍTULO IV 129
CAPITULO V
5. CONCLUSIONES Y RECOMENDACIONES 13
ANEXOS
A. FORMATOS PARA LINEAMIENTO BASE
B. MANEJO DE FILTROS V LISTAS DE ACCESO
DENTRO DE RUTEADORES MOTOROLA VANGUARD
C. FUNCIONAMIENTO DE LA HERRAMIENTA
IPCHAINS DE LINUX
D. FUNCIONAMIENTO DEL PROGRAMA SOUID PARA
LINUX
PRESENTACIÓN
El objetivo de todo administrador de una red de datos es el de brindar altos
niveles de disponibilidad y rendimiento, el cual al parecer es un objetivo
sencillo, pero lograrlo no es tarea fácil.
Se dice que el mejor administrador de red es aquel a quien se lo encuentra
sentado en su escritorio leyendo el periódico, ¿la razón?...todo se encuentra
bajo control, el sistema está operando de manera óptima, y no existen
imprevistos, situación que le proporciona el tiempo libre para llevar a cabo
dicha actividad. Por otro lado se tiene a! administrador "bombero", que corre
de un lado a otro "apagando incendios" cada vez que aparecen, esto es,
resolviendo todo tipo de problemas; durante la jornada de trabajo recibe del
usuario las más diversas quejas: la aplicación es lenta, no responde, no se
puede conectar, la estación de trabajo colapsa, etc.
Si bien es cierto las dos son situaciones extremas, pero el hecho es que la
implantación o no de políticas de administración y procedimientos de
mantenimiento puede marcar la diferencia entre tender hacia uno u otro lado
del espectro. Dicho de otra manera, el administrador debe ser más proactivo
y menos reactivo, debe implementar métodos que le proporcionen un buen
entendimiento de los valores típicos con ios que opera su red. Esto implica la
posibilidad de conocer las causas de problemas actuales, prevenir la
ocurrencia de fallas futuras, y disponer de una base o referencia para fines de
control y comparación, esto es extremadamente ventajoso, sobretodo al
momento de medir cuan efectiva resulta cierta acción tomada, que
teóricamente debería mejorar el desempeño de la red.
Recordando el caso del administrador "bombero", toda la información
suministrada por sus usuarios (aplicaciones lentas, dificultad en la conexión,
etc.) se relaciona con la capa de Aplicación, pero no necesariamente se trata
de problemas exclusivamente generados dentro de ella, las fallas detectadas
pueden reflejar anomalías en cualquiera de los diferentes niveles que formen
parte de la arquitectura de red empleada.
De todo lo anterior se desprende la necesidad de herramientas que ayuden a
discriminar problemas a nivel de cada una de las capas, y que permitan
materializar los procedimientos de administración y mantenimiento
previamente mencionados, siendo los analizadores de protocolos poderosas
herramientas que cumplen con estos dos aspectos.
El presente trabajo, tiene como objetivo principal el demostrar que existen
alternativas para la optimización en cuanto al desempeño de una red dada,
sin que impliquen necesariamente cuantiosas inversiones para nuevos
equipos y/o reemplazo de dispositivos existentes. Para conseguir tal objetivo,
se pretende cubrir las bases teóricas referentes tanto al analizador de
protocolos, herramienta principal utilizada en el "Delineamiento Base de Red",
como al método de aproximación (del inglés "Network Baselining") empleado
para la optimización del desempeño de la Red.
Dentro de los objetivos secundarios están el dar a conocer las ventajas que
presenta el desarrollar un delineamiento base para una red, la importancia de
incluir estos conceptos y prácticas dentro de los programas de administración
y mantenimiento de una red tendiendo hacia una gestión cada vez más
proactiva y menos reactiva; adicionalmente, se pretende conocer las
potenciales amenazas a las que está expuesta una red como la estudiada, y
proponer soluciones basadas en las necesidades reales, documentadas
dentro del "Reporte de Análisis".
R E S I M E N
En el Capítulo 1. "Descripción de la Red", se realiza una inspección de la red
que será objeto de estudio, se describe la arquitectura implementada y las
particularidades dentro de cada nivel, poniendo especial atención en las
capas inferiores; la descripción se realiza tanto para la red local como para su
respectiva subred de comunicaciones. Al igual que en el resto de capítulos,
se incluye una lista de las referencias bibliográficas.
Dentro del Capítulo 2, "Análisis de Redes" se cubren los conceptos
relacionados con el análisis de redes en general, y con su herramienta
principal: el analizador de protocolos, adicionalmente se describe el método
para el "Delineamiento Base" de una red genérica. Finalmente se aplican
todos estos conceptos a una red particular: la red objeto de estudio; el
resultado consiste en un "Reporte de Sesión de Análisis", que caracteriza a
dicha red particular.
El Capítulo 3, "Optimización de la Red", se basa en los hallazgos
documentados dentro del Reporte de Sesión para lograr una optimización de
la red; incluye sugerencias a nivel de las capas host a red, e Inter-red
tendientes a mejorar el desempeño, contiene recomendaciones referentes a
los protocolos activos dentro de la red. Adicionalmente se trata el problema
de las seguridades en una primera parte: Mediante un estudio general de
conceptos como intrusión, ataque, penetración, etc.
El Capítulo 4 "Plan de Seguridad para la Extranet", contiene la principal
propuesta de optimización: se enfoca en el tema específico de las
seguridades en redes, y de las violaciones de seguridad observadas dentro
de la red y documentadas en el Reporte de Análisis, así como de los más
frecuentes tipos de ataque e intrusiones que podrían observarse en un futuro.
Se desarrollarán y pondrán entonces, a disposición del administrador de la
red, sugerencias para incrementar el nivel de seguridad presentado por la
red, mediante dos propuestas de implementación de muros de segundad y un
sistema para monitoreo del desempeño de la red y detección de intrusiones,
todo esto bajo los lineamientos definidos dentro del objetivo principal que
implican inversiones bajas (o nulas).
El Capítulo 5 presenta las Conclusiones y Recomendaciones que
desprenden del presente estudio.
se
Dentro de los Anexos se tiene:
A. Formatos para la documentación de sesiones de análisis y delineamiento
base Red
B. Manejo de filtros y listas de acceso dentro de enrutadores Motorola
Vanguard 320
C. Funcionamiento de la Herramienta Ipchains del Sistema Operativo Linux
D. Funcionamiento del Programa SQUID para el Sistema Operativo Linux
CAPITULO I
1. DESCRIPCIÓN DE LA RED
La red de la Bolsa de Valores Quito (BVQ), se basa en una implementación
del modelo de referencia TCP/IP, y se encuentra representada, en forma
global, mediante la figura 1.1
Red Corporativa \ Extranet
Red BVQ
Figura 1.1 Representación global de Ja red BVQ.
Como se observa en la figura 1.1 la red BVQ se divide, para su estudio, en
tres áreas de interés, las cuales se han nombrado según la función que
desempeñan:
Extranet
Red SINEL1
Red Corporativa
Sistema de Negociación Electrónica
1.1 EXTRANET
Es la red objeto de estudio. Consiste en la puerta de enlace con el mundo
exterior, permite el acceso a cierta información desde la Internet. Está
conformada por una red local y una subred de comunicaciones.
1.1.1 RED LOCAL
Es básicamente una red TCP/IP, sobre una LAN (Local Área Network, o red
de área local), del tipo IEEE 802.3 10Base-T, como lo muestra la figura 1.2.
Modelo de ReferenciaTCP/IP
Aplicación
Transporte
Inter-red
Hosl-a-red
Capa 4
Capa 3
Capa 2
Capa 1
ArquitecturaExtrañe!
h i t "t « S ^ otros-31 i- w "
TCP UDP
IP
IEEE 802.3
10Base-T
Figura 1.2 Arquitectura de la Extranet, implementada según el modelo dereferencia TCP/IP.
1.1.1.1 Capa Host a Red
La red local se construye sobre una plataforma IEEE 802.3 10Base-T, como
se mencionó anteriormente.
El estándar 802.3 describe una red de área local que emplea técnicas de
transmisión por difusión y métodos distribuidos de asignación dinámica del
canal.
La transmisión por difusión implica que todas las máquinas pertenecientes a
la red comparten un mismo medio de transmisión (en este caso se trata de
segmentos de cable UTP conectando cada estación a un concentrador de
cableado o HUB. a velocidades de transmisión en banda Base de 10 Mbps, lo
que en forma abreviada explica el término 10Base-T).
Los mensajes enviados por una máquina son recibidos por todas las demás
pero únicamente son procesados por la destinataria de dichos mensajes
mientras que las estaciones restantes los desechan (unicast): dentro de este
esquema de transmisión por difusión puede darse el caso en que se desee
que todas las máquinas de la red sean destinatarias de un mensaje
(broadcast), o cierto número de ellas lo sea (multicast).
De lo anterior se ve la necesidad de un método de gestión del canal que
permita tener solamente una estación transmitiendo a la vez; en el estándar
802.3 la gestión es dinámica pues se realiza según la demanda, y es además
distribuida: cada estación toma la decisión de ocupar el canal para transmitir
o abstenerse cuando alguien lo ha tomado previamente, es decir, no existe
una entidad que otorgue permisos sobre el canal.
El método empleado para este fin se denomina CSMA/CD (Carrier Sense
Múltiple Access with Colusión Detection) o acceso múltiple por escucha de
portadora con detección de colisiones en el que antes de transmitir, las
estaciones perciben o sensan actividad sobre el canal; de estar ocupado
éstas permanecerán escuchando el canal para tratar de tomarlo en cuanto se
libere. Si por alguna razón dos estaciones transmiten al mismo tiempo, ocurre
una colisión y la información se deteriora, al tener capacidad de detección de
colisiones, las estaciones se detienen e intentan retransmitir luego de un
tiempo aleatorio.
Cada estación tiene su propia tarjeta de red, dentro de su electrónica se
encuentra toda la lógica del CSMA/CD; la discriminación de las estaciones
origen y destino de los mensajes se realiza en base a una dirección física, o
"dirección de hardware" que, de fábrica, viene grabada en la ROM de la
tarjeta, y es única en el mundo. La dirección tiene 48 bits expresados en 12
dígitos hexadecimales, los primeros 6 representan un código único para cada
fabricante, otorgado por el IEEE2, y conocido como OUI (Organizational
Unique Identifier) o identificador organizacional único, los 6 restantes son
administrados por cada vendedor y corresponden al número de serie de la
tarjeta.
/. /. 7. /. / Capa Hosi a Red en la Red Local
La tabla 1.1 muestra la dirección física de cada estación dentro del presente
caso de estudio.
HostDirecciónFabricante
HostDirecciónFabricante
Servidor proxy00104b875e403Com
Servidor web 2005004 7940e9
Servidor web00508b d893a8
Estación 10020af 700db5
3Com7
Servidor mailOOOOfS 03b6a3DECEstación 2
0020af 40d59f3Com7
Ruteador08003e 06e3e4Motorola
Tabla 1.1 Direcciones físicas de las tarjetas de red asociadas a cada host.
Para este caso particular el servidor proxy tiene tres tarjetas de red, una de
ellas está relacionada con la Extranet en tanto que el resto se asocia con
cada una de las otras redes (la figura 1.4 aclara la topología física de la red
local).
1.1.1.2 Capa Inter-Red
Provee un servicio no orientado a conexión, especifica protocolos de ruteo y
protocolos de enrutamiento.
/. /. /. 2.1 Protocolos de ruteo
Dentro del modelo de referencia TCP/1P se tiene como protocolo de ruteo IP
(Internet Protocol) el cual define el formato del datagrama y la función de
cada uno de sus campos.
o Elccincol and l-'.hclnmics
El datagrama IP consiste de dos campos generales: cabecera, como la
indicada en ia figura 1.3, y cuerpo o carga útil, que contiene a la unidad de
información de la capa transporte (segmentos TCP o UDP). Dentro de la
cabecera se tienen varios subcampos:
32 bits
I I I I I I I I I I I I I I ! I I I I I I ! I ! I I I I ! 1 I
Versión | IHL | Tipo de ServicioIdentificación
Tiempo de vida | Protocolo
Longitud Total'ÍDF|MH Desplazamiento
Suma de comprobación (cabecera)Dirección de OrigenDirección de Destino
Figura 1. 3. Formato del encabezado del paquete IP.[Tan97]
Versión (4 bits): Indica la versión de protocolo a la que pertenece el
paquete.
IHL (4 bits): Longitud de la cabecera, expresada en palabras de 4
Bytes (Longwords), el valor IHL mínimo es de 5 (20 Bytes)
representando un datagrama sin opciones, el máximo valor de IHL es
de 15 (60 Bytes), dando un campo de opciones de 40 Bytes.
Tipo de Servicio (8 bits): básicamente concebido para que los hosts
puedan solicitar a la subred ciertas características de servicio
deseadas, los tres primeros bits indican la precedencia: O para
prioridad normal y 7 para prioridad alta (datagrama de control) los
siguientes tres bits son indicadores de retardo, rendimiento y
confiabilidad, respectivamente, que permiten al host especificar su
preferencia; los dos bits sobrantes no se utilizan.
lo
• Longitud total (16 bits): expresa el tamaño de todo el datagrama, esto
es. cabecera más datos, con 16 bits se pueden tener datagramas de
64 KBytes, pero en la práctica por lo general son de 1500 Bytes.
• Identificación (16 bits): el host de destino puede reconocer las partes
de un mismo datagrama previamente fragmentado.
• Campo de Banderas (3 bits):
Sin uso (1 bit).
DF: "No fragmentar" (1 bit) ordena a los ruteadores enviarlo sin
fragmentar.
MF: "Más fragmentos" (1 bit) indica si el fragmento es el último
del datagrama.
• Desplazamiento: informa sobre la ubicación del fragmento recibido con
respecto del datagrama original. El valor de este campo es un múltiplo
de 8 Bytes, que es la longitud del fragmento elemental.
• Tiempo de vida (8 bits): es un contador que disminuye en cada salto, el
datagrama se elimina cuando llega su valor a cero.
• Protocolo (8 bits): Indica el protocolo encapsulado en el datagrama
(TCP, UDP, ICMP, etc.).
• Suma de Comprobación (16 bits) detecta errores en la cabecera.
• Dirección de origen (32 bits) y Dirección de destino (32 bits) [Tan97].
/. y. /. 2.2 Direccionamienío í¡}
Un datagrama IP lleva direcciones fuente y destino de 32 bitst cada una
dividida en dos partes: prefijo de red, y número de host dentro de esta red, los
prefijos de red más utilizados y simples pertenecen a las denominadas clases
A, B, C, D, o E. Las tres primeras especifican cantidades de redes diferentes
(cada una con un máximo de hosts diferente). Como se indica en la tabla 1.2,
solamente con identificar la clase a la que pertenece una dirección, se la
puede dividir en sus dos partes constituyentes: identificador o prefijo de red, y
número de host dentro de esta red.
32 bits
CLASE i i i i i i i j i i i i i i i i i i i i i r i i i i i i i i
Prefijo de Red Número de Host
1 0 Prefijo de Red Número de Host
1 1 0 Prefijo de Red Número de Host
1 1 1 0 Dirección de Multitransmisión
1 1 1 1 0 Reservado para uso futuro
RANGO
1.0.0.0127.255.255.255
128.0.0.0191.255.255.255
192.0.0.0223.255.255.255
224.0.0.0239.255.255.255
240.0.0.0247.255.255.255
Tabla 1.2 Clasificación de las direcciones IP [Tan97].
Clase A: Cuando el primer bit es cero, los siguientes siete bits del primer
octeto identifican a una de entre 126 redes (la red 127 está reservada para
pruebas de loopback), con los 24 bits restantes se especifica a uno de entre
16777214 hosts dentro de cada red.
Clase B: Los dos primeros bits son 1 y O, los siguientes 14 discriminan a la
red mientras que los 16 bits restantes conforman el número de host. Este
arreglo permite tener 16382 redes con 65534 hosts cada una.
Clase C; se tienen 2097150 de redes hasta con 254 hosts.
Clase D: direcciones para multitransmisión de datagramas IP.
Clase E: direcciones reservadas para uso experimental [Tan97].
i:
Esta simple noción ha sido extendida por el concepto de subredes: Las
subredes proveen a la Internet de una estructura de enrutamiento jerárquica
multi-nivel; básicamente particionan al número de host en dos campos, un
número de subred y un número de host dentro de dicha subred;
dirección IP = número de red, número de subred, número de host.
Las redes físicas, interconectadas dentro de una misma organización usan el
mismo prefijo de red, pero diferentes identificadores de subred; la subdivisión
normalmente no es visible desde afuera de la red porque el ruteo en el
exterior usa sólo el prefijo de red de la dirección IP destino, dentro de una red
subdividida los ruteadores utilizan el "prefijo extendido" formado por el
número de red y el número de subred dentro de esta red. A diferencia del
esquema original, el número de bits del prefijo (extendido) de red no se indica
por una clase, sino por una "máscara de subred" que consta de 32 bits, los
más significativos son "unos" y su cantidad corresponde al número de bits
para el prefijo extendido, el resto de bits de la máscara son ceros, e indican
cuántos bits conforman el campo "número de host dentro de la subred"
[Bak95].
/. /. ¡.2.3 J'Jimtamiento Sin Clases
Los esquemas de direccionamiento basados en clases no utilizan de forma
eficiente el espacio de dirección de 32 bits al definir redes de tamaño fijo:
254, 65534, o 16777214 hosts (Clases C, B y A respectivamente). A menudo
una cantidad fija no es la adecuada para una organización a la que se asigna
por ejemplo una red clase B, si sólo son utilizadas 30 mil direcciones, las 35
mil restantes se desperdician. Por otro lado, a una organización más pequeña
solicitando direcciones para mil hostst se le asignan, por ejemplo, cuatro
direcciones de red clase C, que introducen cuatro rutas diferentes,
incrementando el tamaño de las tablas en los enrutadores IP globales
[Moto I].
El explosivo crecimiento de la Internet ha obligado a la búsqueda de un mejor
aprovechamiento del espacio de direccionamiento IP; una solución consiste
en ef enrutamiento interdominio sin clases (CIDR o C/ass/ess ínter Domain
Routing), que es un método actualmente desplegado para lograr un uso más
eficiente del espacio de direccionamiento IP porque permite la formación de
redes de tamaño arbitrario. El CIDR asigna tamaños variables de red
mediante bloques contiguos de redes clase C.
Para comprimir información de enrutamiento, es útil dividir a la Internet en
dominios de direccionamiento, dentro de los cuales está disponible
información detallada sobre sus redes constituyentes, fuera de ellos, sólo se
anuncia el prefijo de red en común [Bak95], Se dividió al mundo en cuatro
zonas, asignando a cada una de ellas una parte del espacio de direcciones C
libres [RFC 1519]:
De: 194.0.0.0 a: 195.255.255.255 para Europa.
De: 198.0.0.0 a: 199.255.255.255 para Norteamérica.
De: 200.0.0.0 a: 201.255.255.255 para Centro y Sudamérica.
De: 202.0.0.0 a: 203.255.255.255 para Asia y el Pacífico.
Esta misma idea puede aplicarse a todas las direcciones, no solamente a las
nuevas direcciones clase C; con CIDR, las viejas redes clase A, B, y C, no se
usan más para ruteo [Tan97], se preservan las clase D (multicasting), y E
(experimental).
Una dirección CIDR, se representa por la dirección estándar IP de 32 bits
seguida de un indicador del número de bits que conforman el prefijo de red,
por ejemplo: a una organización que requiera 2000 direcciones se le
asignaría la red 194.24.0.0/21 (2048 direcciones, 8 redes clase C) esto es
equivalente a la dirección 194.24.0.0; 255.255.248.0 dentro del esquema de
subredes [MotoI].
El uso de redes y subredes es ahora histórico, aunque el lenguaje usado para
describirlas permanece activo, pues ambas representaciones son de uso
común [Bak95].
14
A /. 1.2.4 Protocolos de enrntamienio
Son utilizados por los nodos de la subred de comunicaciones (sección 1.1.2)
para crear las "tablas de enrutamiento", en base a las cuales deciden hacia
dónde enviar un paquete, la tabla lista todos los segmentos de red a los que
conoce como llegar, y contiene tanto rutas estáticas como dinámicas [Motol].
Se tiene un esquema dinámico cuando los nodos son capaces de actualizar
sus tablas intercambiando entre ellos información acerca del estado de la
subred, a través de protocolos como, por ejemplo: RIP3, OSPF4, etc.
Por otra parte, dentro de un esquema de enrutamiento estático, las tablas
tienen entradas fijas, ingresadas de antemano por el administrador de la red
(rutas estáticas), los nodos no son adaptables a cambios en la topología de la
subred.
1. i. 1.2.5 Capa Inter-Red de la Red Local
La figura 1.4 representa una zona ampliada de la nube denominada
"Extranet" (a la que se hace referencia dentro de la figura 1.1). Se puede
apreciar que la Red Local está conformada por seis estaciones y el
concentrador o HUB que las conecta físicamente, adicionalmente constan las
direcciones IP asignadas tanto a la Red Local como a cada uno de sus hosts.
El ruteador forma parte de la Red Local y de la Subred de comunicaciones de
la Exíranet.
Routing Information ProtocolOpen Shortest Paíh l-'irs¡
Ser
vido
r W
EB
192.
168.
150.
11S
ervi
dor
MA
IL
192.
168.
150.
10
Ext
rane
t19
2.16
8.15
0.0
255.
255.
255.
0
216.
219.
15.1
30
Ser
vido
r W
EB
219
2.16
8.15
0.2
Est
ació
n 1
192.
160.
150.
4E
stac
ión2
Fig
ura
1.4
Dia
gram
a de
la
Ext
rane
t.
1.1.1.3 Capa Transporte
La entrega confiable de datos dentro del modelo, está provista por protocolos
de capa transporte como el TCP, que implementa retransmisión extremo-
extremo, reordenamiento, control de la conexión. Un servicio de capa
transporte no confiable (sin conexiones) lo provee el protocolo de datagramas
de usuario UDP. [Bak95]
U. 1.3.1 TCr
La función principal del TCP, es proporcionar a la capa aplicación de un
servicio confiable para el transporte de un flujo de fíytes, escondiendo las
imperfecciones de la subred (no confiable), subyacente.
Antes de que la información entre una estación fuente y una estación destino
pueda ser transmitida, TCP necesita establecer una conexión entre ellas. Una
conexión TCP es una corriente de Bytes, sin fronteras entre mensajes,
adicionatmente es "full-dúplex", punto-a-punto, esto es, existen dos puntos
terminales en una conexión (puertos) que pueden transmitir y recibir
simultáneamente.
La unidad de información que maneja el TCP se denomina "segmento" y se
constituye de una cabecera más un campo de datos, el cual no está presente
cuando se trata de segmentos para el establecimiento, control y liberación de
la conexión [Tan97].
El procedimiento para establecer una conexión entre dos estaciones implica
una serie de pasos y se denomina "Acuerdo de tres vías" (Three-way
handshake): el primer paso consiste en la emisión de un segmento TCP "de
sincronismo" para solicitar la conexión, denominado "SYN" (los segmentos
TCP implicados en el proceso se distinguen por los bits de banderas activos
dentro de la cabecera del segmento) por parte de la estación fuente, el
segundo paso es una respuesta de sincronismo por parte de la estación
destino indicando que ésta reconoce el mensaje de sincronismo recibido y
que continúa en el proceso (tiene dos banderas activas: SYN y ACK),
finalmente un tercer mensaje enviado por el origen (ACK) indica al destino
que ambas estaciones están de acuerdo con el establecimiento de la
conexión, el tercer mensaje puede contener adicionalmente datos de usuario
en su campo de carga útil fSKK ]
El acuerdo también inicializa los números de secuencia para la entrega
confiable y retransmisión dentro de la nueva conexión, en la figura 1.5 la
estación A envía un número de secuencia inicial "x" dentro del primer
mensaje: SYNX, B reconoce el primer mensaje con ACKx+i y le envía su
propio número de secuencia "y", finalmente, A reconoce el mensaje de B
enviando el último segmento del acuerdo de tres vías: ACKy+1 [SKK'J.
Estación A Estación B
SYN
SYNy ACKX+1
ACKY+1
Figura 1.5 Acuerdo de tres vías.
Para liberar una conexión, cualquier estación envía un segmento FIN, que
deberá ser reconocido por la otra, de no hacerlo durante un lapso de tiempo
dado por un temporizador, quien transmitió el segmento FIN libera la
conexión.
Como lo indica la figura 1.2, la red local implementa los protocolos TCP y
UDP a nivel de la capa de transporte.
18
1 . 1 . 1 . 4 Capa Aplicación
Se distinguen dos categorías de protocolos de capa aplicación:
Protocolos de usuario: prestan servicio directamente al
usuario (Telnet, FTP, SMTP).
Protocolos de soporte o apoyo: proveen funciones de sistema
comunes, son usados para administración, mapeo de
nombres de host, inicialización o booting; incluyen SNMP,
BOOTP, TFTP, DNS, y una variedad de protocolos de
enrutamiento (BGP) [Bak95].
/. /. 1.4.1 ( \\pa Aplicación en la Red Local
La Extranet proporciona varios servicios o aplicaciones que se encuentran
dentro de los servidores de la red local; las funciones de éstos se detallan a
continuación.
• SERVIDOR PROXY: Es el nexo entre las tres redes, posee una tarjeta
de red -y una dirección de red asociada- por cada una de ellas.
Permite el acceso a Internet para usuarios de las redes interiores.
• SERVIDOR WEB: Almacena las páginas web de la empresa y las
pone a disposición de cada uno de los usuarios de la Internet.
• SERVIDOR MAIL: Provee de mensajería electrónica a cada uno de
los usuarios de las diferentes partes que conforman la red BVQ.
1.1.2 SUBRED DE COMUNICACIONES
La red objeto de estudio forma parte de la Internet valiéndose de los servicios
de una subred de comunicaciones, formada por un ruteador local (Motorola
Vaguard 320) y un remoto (Cisco 3660, perteneciente al ISP) interconectados
a través de un enlace punto-a-punto, de 128 Kbps contratado a una empresa
portadora (o carríer) autorizada.
Hos
t B
VQ
o. tí .c1 I-
ü_ 5 co
TC
P
w z Qot
ros
UD
P
IP
IEE
E 8
02.3
10B
ase-
T
k
Nod
o: I
NT
BV
Q
IP
*
i
IEE
E80
2.3
10B
ase-
T
r
PP
P
V.3
5
f R
ute
ador'
Mol
1 A
M
oról
a
i
IP
i
i
PP
P
V.3
5 <
7/
Rut
eC
isco
\A/A
M
Cis
coH
DLC
V
ador
'36
60 \M¿
35 , IM
BV
QIS
P
Figu
ra 1
.6 E
sque
ma
de in
terc
onex
ión
de la
s red
es B
VQ
- IS
P.
La figura 1.6 muestra de manera esquemática la arquitectura de la subred
que permite la interconexión entre la Extranet y la red del ISP, se pueden
observar los protocolos en cada una de las capas. Nótese la interoperatividad
que se logra entre equipos de distintas marcas que han sido configurados
para utilizar un mismo protocolo previamente convenido.
1.1 .2 .1 Capa Host a Red en la subred de comunicaciones
El ruteador local interactúa con dos redes diferentes, tiene una interfaz
asociada a cada red, y una dirección de red asociada a cada interfaz (Fig.
1.4), debe implementar las funciones requeridas por cada una de las redes.
Para la red de área local (LAN), se adapta a las especificaciones IEEE 802.3
10BaseT, tratadas con anterioridad.
En el caso de la red extendida (WAN) se debe emplear un protocolo que
asegure la interoperabilidad con el ruteador remoto; en particular, los equipos
de interconexión utilizan el estándar de la Internet para líneas punto a punto:
PPP (Point-to-Point Protocof) o protocolo punto-a-punto.
La comunicación a nivel físico entre el ruteador y el equipo de la portadora
(empresa proveedora del enlace) se realiza mediante un interfaz serial
sincrónico V.35.
1.1,2,1,1 V.35
V.35 originalmente fue especificada, por el CCITT, como una interfaz para
transmisiones sobre líneas a 48 Kbps ahora adoptada para todas las
velocidades de línea superior a 20 Kbps.
Utiliza señales balanceadas (del tipo RS 422) para datos y temporización, en
tanto que señales de retorno común (tipo RS 423) se emplean para líneas de
control, incluyendo DTR, DSR, DCD. RTS y CTS, puesto que estas señales
son constantes, o varían con baja frecuencia; mientras que pares
balanceados son usados por las señales de frecuencia mayor.
Las especificaciones eléctricas vienen dadas por las recomendaciones UIT
V.11 y V.28.
Los circuitos se especifican en ta recomendación UIT V.35 y las
características mecánicas se definen en el estándar ISO IS2593. [Volny]
1.1.2.1.2 PPr
Es un protocolo WAN que transporta datos sobre líneas punto-a-punto, más
simple y eficiente que protocolos orientados a conexión como X.25, puesto
que no posee mecanismos para compensación de errores de transmisión.
Al igual que Frame Relay, puede detectar errores pero no soporta métodos
de retransmisión a nivel de la capa de enlace; por estas razones es aplicable
para transportar tráfico no orientado a conexión, como IP, que provee su
propio mecanismo de transporte para la recuperación de paquetes perdidos o
dañados.
Tiene tres componentes:
• Protocolo de Control de Enlace (LCP o Link Control Protocol):
usado para establecer, configurar, y probar un enlace PPP.
• Protocolos de Control de Red (NCPs o Network Control
Protocois} para el establecimiento y configuración de diferentes
protocolos de capa red.
• Autentificación, usada para validar una conexión remota (no se
emplea en este caso particular).
LCP maneja opciones de encapsulación, tamaño de trama y errores de
configuración. LCP configura un enlace intercambiando tramas de
configuración, una vez reconocidas o aceptadas por ambos extremos, la
conexión entra en un estado de "Abierta" y el enlace es establecido [Moto!].
Las opciones son una forma para que eí dispositivo local le indique al remoto
lo que aceptará de este último, y no lo que desea enviarle.
Le corresponde al dispositivo remoto decidir lo más conveniente a enviar,
dentro de los confines del grupo de opciones que el dispositivo local ha
manifestado que puede aceptar. Por consiguiente, es perfectamente
aceptable y normal que un dispositivo remoto reconozca o acepte todas las
opciones indicadas en una petición de conexión LCP, incluso si no soporta
ninguna de dichas opciones.
Las opciones simplemente son un mecanismo para que cada dispositivo le
indique al otro qué es lo que van a aceptar, y no necesariamente lo que
enviarán [Bak95].
Los NCPs manejan protocolos específicos, como IP o IPX5; el nodo local
soporta los NCPs: IPCP, e IPXCP, pero al tratarse de una interconexión con
una red TCP/IP como lo es la Internet, se utiliza el primero [Motol].
1.1.2.2 Capa ínter-Red en la Subred de Comunicaciones
El equipo local de interconexión recibe un datagrama, lee la dirección destino
de 32 bits dentro de la cabecera, si el paquete está destinado a este ruteador,
es procesado internamente por el módulo de software apropiado (por
ejemplo, paquetes de control, de actualización de rutas, paquetes de
diagnóstico, etc.) si el paquete está dirigido a un host dentro del segmento
LAN directamente conectado, el ruteador asocia la dirección destino de 32
bits con la dirección física del host en cuestión (revisando su tabla ARP6),
entrega el paquete al módulo de capa inferior para su inclusión dentro de una
trama 802.3 y posterior envío hacia la dirección física apropiada. Cuando el
paquete está dirigido a un host perteneciente a un segmento remoto, el
dispositivo examina su tabla de enrutamiento para determinar la interfaz que
conduce hacia ese segmento, el datagrama es entonces enviado dentro de
una trama PPP al enrutador predeterminado (Default Gateway).
" Protocolo de Capa Red dentro del modelo NetWare de Novell." Protocolo para resolución de direcciones (. liklress Resolmion l'roíocol).
2.1
Del lado remoto, el equipo recibe, por la interfaz respectiva, las tramas
originadas en la red BVQ, luego de comprobar que no existan bits errados a
nivel de enlace, extrae el datagrama contenido en la trama PPP y examina la
información del encabezado. Si la dirección de destino indica que se trata de
servidores de la red del ISP (por ejemplo, una solicitud DNS7), el datagrama
es encapsulado dentro de la trama específica de su red local, enviándola
hacia el servidor indicado. Por el contrario, cuando el datagrama está dirigido
a un segmento de red remoto, el equipo examina su tabla de enrutamiento
para determinar la interfaz que conduce al segmento adecuado.
Cada entrada de la tabla contiene una dirección de destino y asociada a ésta,
la dirección IP del siguiente salto en el trayecto, si la dirección en una entrada
de la tabla coincide con la del encabezado, el datagrama se encapsula según
el protocolo de capa enlace utilizado por la interfaz asociada a la entrada (por
ejemplo, la versión HDLC de Cisco) y se transmite a través de ésta al
siguiente ruteador del trayecto (Next Hop Router).
Si un datagrama no coincide con ninguna de las entradas de la tabla, es
enviado hacia un enrutador predeterminado (Default Gateway). [Tan97]
En la figura 1.7 se puede apreciar un diagrama detallado de la subred. se
incluyen los principales parámetros configurados a nivel de la capa Inter-red:
• Direcciones IP asociadas a cada interfaz de red (LAN y WAN).
• Esquema de enrutamiento basado en rutas estáticas.
En general, cuando los ruteadores dentro de una red tienen paquetes
destinados para una red desconocida los entregan a su respectivo "ruteador
predeterminado" (o Default Gateway), quien conoce como enrutar el tráfico
que los otros ruteadores no supieron encaminar, este parámetro se puede
configurar directamente al especificar la dirección IP del nodo que constituye
Sisicnin de Nombres de Dominio {limitan \tntn1
el "siguiente salto" (next hop). en el trayecto hacia el ruteador predeterminado
o de forma indirecta, ingresando manualmente una ruta estática dentro de la
tabla de enrutamiento.
Dicha ruta tendrá la dirección 0.0.0.0 como red de destino, la dirección IP del
siguiente salto, y el valor de la métrica asociada a la ruta. Los algoritmos de
enrutamiento determinan el camino óptimo hacia el destino considerando un
número de variables llamadas métricas, como por ejemplo: longitud,
contabilidad, retardo, ancho de banda, carga, costos de comunicación, etc.
Diferentes algoritmos usan diferentes métricas [Motol].
Específicamente, el ruteador local posee sólo la ruta estática que apunta
hacia el enrutador remoto, quien resolverá la manera de alcanzar las redes
de destino: entregando datagramas directamente o a su vez mediante la
acción de su ruteador predeterminado.
• Traducción de direcciones
El ruteador local, adicionalmente, realiza funciones de NAT (Network Address
Translation), o traducción de direcciones de red; esta característica permite
que dispositivos pertenecientes a una red privada que utiliza un esquema de
direccionamiento interno o privado, puedan accesar a, y ser accesados por
otros hosts que utilizan el esquema de direccionamiento IP global, mapeando
la dirección "interna" (privada) de un dispositivo a una "externa" (global).
NAT se encuentra definido por el RFC 1631, mientras que el IETF. como lo
especifica el RFC 1918, ha reservado tres bloques de direcciones para redes
privadas [Motol].
Clase A
Clase B
Clase C
10. 0.0.0a 10.255.255.255
172. 16.0.0a 172. 31.255.255
192.168.0.0 a 192.168.255.255
Tabla 1.3 Bloques reservados por el IETF para uso privado: RFC 1918.
Def
ault
Gat
eway
.21
6,21
9.15
.129
Rut
a es
tátic
a eq
uiva
lent
e:R
ed:
0.
¡ 0.
0.
\
Mas
k:
0.
I 0.
0.
O
Nex
tHop
: 21
6.21
9.15
.129
192.
168.
150.
125
5.25
5.25
5.0
216.
219.
15.1
3025
5.25
5.25
5.24
021
6.21
9.15
.129
255.
255.
255.
240
Rut
eado
rC
isco
366
0S
ervi
dor
WE
B
Inte
rna
i19
2.16
8.15
0.10
h
192.
168.
150.
11
*19
2.16
8.15
0.12
*
Ext
ema
216.
219.
15.1
3121
6.21
9.15
.132
216.
219.
15.1
33
192.
168.
150.
21^2
16.2
19.1
5.14
2
Ser
vido
r D
NS
Fig
ura
1.7
Det
alle
de
la s
ubre
d de
com
unic
acio
nes,
pri
ncip
ales
par
ámet
ros
conf
igur
ados
en
los
equi
pos d
e ru
teo
Las direcciones IP públicas, necesarias para la interconexión con la Internet,
son asignadas por el ISP. La figura 1.7 detalla el direccionamiento IP dentro
de la subred de comunicaciones, ta correspondencia entre direcciones
públicas y privadas, y el esquema de enrutamiento.
1.1.2.3 Capa Transporte en la Subred de Comunicaciones
Según el RFC 1812, no se requiere que un ruteador implemente cualquiera
de los protocolos de transporte, excepto aquellos requeridos por protocolos
de capa aplicación que soporta el ruteador (por ejemplo, Telnet, SNMP, etc.)
[Bak95].
En el presente caso de estudio, los ruteadores IP implementan tanto TCP
como UDP.
1.1.2.4 Capa Aplicación en la Subred de Comunicaciones
Según lo expuesto en 1.1.1.4, dentro de los equipos de interconexión se
encuentran habilitados el protocolo de usuario TELNET, y el protocolo de
soporte o apoyo SNMP.
27
REFERENCIAS CAPÍTULO I
(Bak951 BAKER, F; "Requirements for IP Versión 4 Routers " RFC-¡812, ¿995.
[Motol] MOTOROLA DOCÜMENTATION; "IP and LAN Feature Protocols
Manual"
[SKK+1 SCHUBA, C; KRSUL, I; KUHN, M; SPAFFORD, E: SÜNDARAM, A;
ZAMBÓN I, D; "Analisys of a Denial of Service Attack on TCP"
COSAT Laboraíory, Department of Computer Sciences, Purdue
University. ( hííp://ciíe.seer. ni. nec, com)
[Tan97] TANENBAUM, S, Andrew; "Redes de Computadoras" 3" Ed.
Prenüce-HalL 1997.
[ Volny 1 hltp://\vww. volny. cz/fufik/techhelp/konekt/v35. htm
CAPITULO II
2. ANÁLISIS DE REDES
2.1 INTRODUCCIÓN AL ANÁLISIS
2.1.1 DEFINICIÓN DE ANÁLISIS DE REDES
El análisis de redes, también conocido como análisis de protocolos, es el
proceso de "escuchar", mediante la captura de datos, las comunicaciones
dentro de la red para poder determinar su "condición de salud" [ChaOO].
En base a la información obtenida se logra conocer el estado "actual" de
operación de una red, lo cual es fundamental para lograr una gestión efectiva
dentro de los siguientes ámbitos:
• Resolución de problemas
• Optimización
• Planificación y crecimiento
De esta manera, el primer paso hacia un desenvolvimiento más eficiente
dentro de estos campos, consiste en elaborar un registro que documente la
situación de la red.
2.1.2 El ANALIZADOR DE PROTOCOLOS
2.1.2.1 Definición
Un analizador de protocolos, o también llamado analizador de red,
básicamente es un dispositivo capaz de capturar todos los paquetes que
cursan la red, interpretarlos o decodificarlos, y mostrarlos en orden de
aparición; para ello, podría requerir una tarjeta y controlador de red que
soporten operación en modo "promiscuo1" [Cha99].
Capacidad para caplurar iram;is erróneas o no dircccionadas hacia la tarjeta local.
Adicionalmente puede monitorear la red y proveer detalles sobre diferentes
estadísticas, eventos y condiciones de error, entregando una visión general
sobre el desempeño de la red y su nivel de utilización, así como detalles
específicos sobre usuarios y aplicaciones individuales.
Ventajas sobre otras tecnologías incluyen el análisis en tiempo real, y análisis
del desempeño encaminado hacia la planificación para el crecimiento,
afinamiento u optimización de la red [Mey99].
2.1.2.2 Clasificación
Los analizadores de protocolos se pueden clasificar en dos grandes grupos:
Analizadores para redes LAN y analizadores para redes WAN, dentro de
estos grupos existen subdivisiones según diversos aspectos, tales como la
tecnología (analizadores basados en software o en hardware), o el tipo de
arquitectura.
2.1.2.2,1 Analizadores LAN
Dentro de esta categoría se pueden encontrar analizadores tanto por
Software como por Hardware. Los analizadores constituidos por software son
diseñados para instalarse en un computador personal con tarjeta de interfaz a
la red local, y correr bajo un sistema operativo estándar. Su utilización ha sido
factible gracias a los avances en cuanto a la capacidad de los PCs y las
tarjetas de red actuales.
Para redes de tipo ETHERNET, IEEE 802.3 10Base2, IEEE 802.3 10Base5,
IEEE 802.3 10BaseT, el PC necesita una tarjeta de red que soporte un modo
promiscuo de operación, lo que garantiza que todas las tramas dentro del
segmento de red sean entregadas al PC para su procesamiento y análisis,
sin esta capacidad la tarjeta actuaría como un filtro dejando pasar sólo las
tramas cuya dirección de destino coincide con la dirección local, siendo de
muy poca utilidad la información así obtenida.
En este tipo de analizadores, el PC es quien desempeña todas las funciones
de análisis, por consiguiente, características propias del computador como
capacidad de procesamiento, memoria, adaptador de red, etc. influyen de
manera significativa en cuanto al rendimiento del analizador.
La figura 2.1 muestra un diagrama de bloques funcional del analizador por
software.
MEMORIA
Tarjeta10BaseT
TX RX
PROCESADOR
SOFTWARE DEANÁLISIS
Estación 2
HUB
Figura 2.1 Esquema funcional del analizador LAN por software [Mey99].
Por otro lado se encuentran los analizadores constituidos principalmente por
hardware, que utilizan circuitos electrónicos y software especialmente
diseñados para asegurar muy alto desempeño al momento de capturar y
monitorear el tráfico de la red, a diferencia de los anteriores, pueden llegar a
ser extremadamente costosos, dedicando procesadores especiales para la
captura y análisis del tráfico. El desempeño en este caso no depende del PC
utilizado para la interpretación de los datos adquiridos por el analizador.
Desde el punto de vista de la arquitectura, existen principalmente dos tipos
de analizadores basados en hardware, el primero consiste en una sola
unidad que contiene todos los dispositivos de entrada-salida, es decir, tarjeta
de red, teclado, pantalla, etc. Adaptar la unidad a nuevas tecnologías de red,
o incluso actualizarla podría presentar ciertas dificultades. El segundo
consiste en un dispositivo o unidad externa que se conecta a un PC, la
información capturada por la unidad se guarda en el disco duro del PC y
puede ser posteriormente revisada sin necesidad de preparar y configurar
todo el conjunto.
Analizadores por hardware se emplean principalmente dentro de redes que
normalmente presentan muy altos niveles de utilización en donde se requiere
un extremado grado de desempeño en cuanto a captura de información.
:. 1.2.2.2 Analizadores WAN
Sólo existen aquellos basados en hardware, debido a la naturaleza
btdireccional de los enlaces WAN.
En la figura 2.2 se muestra el método típico de conexión y un esquema
funcional de operación del analizador.
Como se puede ver, tanto el equipo terminal de datos (DTE) como el de
comunicación (DCE) tienen un transmisor y un receptor. Para poder
monitorear el tráfico en ambas direcciones, el analizador debe ser capaz de
supervisar las dos líneas: de transmisión y recepción, lo cual requiere de dos
receptores dentro del equipo
32
El método más común para conectar un analizador WAN consiste en el uso
de un cable "Y", denominado así por la forma que presenta al proveer de una
derivación para el analizador.
PC: Configuracióny Visualización
SOFTWARE DEANÁLISIS
CPU MEMORIA
RX1
RX2
ii Analizador
1 n n r 11 — '
Laptop
DTE
si-Estación
HUB
Estación
Figura 2.2 Esquema de conexión y diagrama funcional del analizador WAN[Mey99].
2.1.2.3 Elementos
A pesar de las diversas clasificaciones que se les pueda dar a estas
herramientas de análisis, existen elementos inherentes, comunes a la gran
mayoría de analizadores.
La figura 2.3 muestra un esquema conceptual de un analizador de protocolos,
y sus principales componentes como: puertos, decodificadores, filtros de
captura y visualización, mediciones y gráficas estadísticas, buffers o espacios
de memoria para el almacenamiento de la información capturada y/o
desplegada.
FILTRO DE CAPTURA
BUFFERDE CAPTURA
FILTRO DE DISPLAY
FILTRO DE DISPLAYDest3Con7700DBSOrg OOS08BD393A9
Ethertype «0800 (IP)
UDP puerta Uro - 137(HetfcJlUb-ns)puerto Dest . U7 i NetBIOS -ns 1
VIHS. ID - 33Q72Flags = 85
DECODIFICADOR
ESTADÍSTICAS
BUFFER DE DISPLAY
BUFFER DE DISPLAY
Figura 2.3 Principales componentes de un analizador de protocolos.
2.1,2,3.1 Puertos
Interfaz físico entre el analizador y la red, por ejemplo V.35 o RS-232 para
redes WAN, RJ45 para redes del tipo 802.3, etc.
2.1.2.3.2 Decodificadores
Tienen que ver con la forma en que el contenido de las tramas es desplegado
en la pantalla, en la figura 2.3 las tramas capturadas en el cable han sido
descifradas, e interpretados los contenidos de todos los campos dentro de las
diversas unidades de información involucradas, particularmente, la trama
decodificada pertenece a una transacción WINS (servicio de nombres
NetBIOS).
2.1.2.3.3 /''i/tros (Captura y Visualización)
Los filtros de captura, también denominados pre-filtros, son definidos por el
usuario y especifican el tráfico a ser copiado desde la red hacia el buffer de
captura; pueden designarse de tal forma que de todo el tráfico visto dentro de
la red, únicamente se registren las conversaciones entre dos estaciones
dadas, o solamente el tráfico perteneciente a tal o cual protocolo. Los pre-
filtros ahorran espacio en el buffer de captura, pero en el caso de
analizadores por software, implican ciclos de interrupción del procesador y
posiblemente pérdida de tramas de interés dentro de redes con altos niveles
de utilización.
Filtros de Visualización, o despliegue, se aplican sobre la información
capturada, creando subconjuntos del buffer de captura (los denominados
"buffer de oVsp/ay" dentro de la figura 2.3), son de gran utilidad cuando se
requiere enfocar características o situaciones específicas, reduciendo el
número de tramas que serán objeto de observación; por ejemplo, se pueden
usar para desplegar únicamente el tráfico ICMP, o el tráfico relacionado con
difusiones y multidifusiones.
2.1.2.3.4 Gráficos y estadísticas
Entregan una perspectiva gráfica sobre el estado de salud y el flujo de tráfico
dentro de la red (su utilidad, en este caso, se puede resumir citando la frase
"una imagen vale más que mil paquetes" [Cha99])
2.1.2.3.5 A ¡armas
Configurables por el usuario para alertar el momento en que se encuentren
errores o situaciones de anormal comportamiento, por ejemplo, alarmas
programadas para que dentro de una sesión de análisis o monitoreo
notifiquen la presencia de altos niveles de utilización, paquetes por segundo,
difusiones por segundo, o errores a nivel de enlace.
2,1.2.3.6 Buffer de (Captura
Conforma la localidad de almacenamiento de la información capturada; la
aplicación de filtros de despliegue sobre un buffer de captura no lo modifica,
en lugar de ello, con las tramas que cumplen los requerimientos o
condiciones del filtro se crea un subconjunto denominado buffer de
despliegue.
2.1.3 LA SESIÓN DE ANÁLISIS
La presente sección describe la revisión de los pasos a seguir dentro de una
sesión general de análisis de red.
2.1.3.1 Identificación de las áreas de interés
Todas las redes tienen partes críticas o de mayor interés, el primer paso
dentro de una sesión de análisis consiste en definir claramente el tipo de
información que sería de mayor utilidad y enfocarse sobre las zonas
relacionadas, por ejemplo, el tráfico de un segmento específico, el tráfico en
el "Backbone" o dentro de un enlace WAN.
Dentro del presente caso de estudio, se ha dividido a la red en tres áreas
principales, denominadas según su funcionalidad como Extranet, Red Sinel, y
Red Corporativa.
2.1.3.2 Ingreso a la red
Una vez seleccionada la zona a estudiar, el equipo se conecta dependiendo
del tipo de red, es decir, si el segmento consiste en una red local con
concentrador de cableado, el analizador se colocará como cualquier otra
estación, en uno de los puertos libres, tal como lo muestra la figura 2.1. En
tanto que si se trata de un enlace WAN, el equipo de medición apropiado se
conectará, como en la figura 2.2, en paralelo mediante el uso de un cable "Y".
.Vi
No obstante podrían encontrarse redes dentro de las cuales operan
dispositivos que segmentan el tráfico, como el enrutador (router), puente
(bridge) o el conmutador (switch). En el caso en que se precisa analizar el
tráfico cursado, entre dos segmentos, a través de puentes (tráfico
"puenteado"), una solución se muestra en la figura 2.4, y consiste en colocar
un analizador en cada segmento (con analizadores por software se puede
fácilmente correr el programa en una estación propia de cada segmento),
esto presenta una oportunidad para comprobar no sólo el tráfico cursado,
sino también el tráfico propio de cada segmento, es decir, conversaciones a
nivel MAC pertenecientes a dos estaciones del segmento A, deberían ser
detectadas únicamente por el analizador del segmento A. La misma solución
podría aplicarse para el caso en que la figura 2.4 constara de dos
enrutadores en lugar de puentes, y no se disponga de un analizador WAN; si
bien es cierto, no se tendrá información estadística del enlace (utilización,
errores, etc.), pero sí del tráfico cursado, en este caso a nivel de la capa Red
y también del tráfico propio de cada segmento. Ahora las conversaciones a
nivel IP por ejemplo, entre dos estaciones del segmento A e incluso las
difusiones dentro de éste, normalmente deberían ser detectadas tan solo por
el analizador del segmento A.
Estación
Estación
Estación
Analizador A Analizador B
Kigura 2.4 Monitoreo del tráfico "puenteado" entre los segmentos A y B
.17
Los dispositivos de conmutación o switches, operan un tanto diferente, estos
aprenden las direcciones MAC de los dispositivos asociados a cada uno de
sus puertos, según lo cual toman decisiones de encaminamiento desde un
puerto origen hacia el puerto destino indicado; es decir, colocar el analizador
en un puerto libre no serviría de mucho, a no ser de que se trate de un puerto
específicamente destinado para control y monitoreo, o sea configurable por el
usuario para SPAN2, pero estas dos características se ligan fuertemente al
fabricante.
Dentro de la figura 2.5 se ilustran dos posibilidades para la ubicación del
analizador dentro de redes locales conmutadas.
La figura 2.5(a) indica que el tráfico dentro del switch fluye directamente
desde el puerto de origen hacia el destino. El conmutador de la figura 2.5 (b),
denominado "switchl" presenta un puerto denominado SPAN, por ser
configurable para recibir una copia del tráfico originado en todos o algunos de
los otros puertos, el analizador de la figura se conecta al puerto SPAN. Para
el caso en que no se pueda configurar el puerto, sea por limitaciones de
accesibilidad o por que el modelo no soporta esta facilidad, como lo indica la
figura 2.5(c), se tiene una opción que consiste en introducir un concentrador o
hub entre una estación de interés y el respectivo puerto del switch, con lo
cual, se logra capturar todo el tráfico desde y hacia dicha estación. La
conexión entre hub y switch utiliza un cable de red normal siempre y cuando
esté involucrado el puerto de expansión del concentrador, o un cable de red
cruzado si se trata de un puerto ordinario,
2.1.3.3 Recolección interpretación y documentación de la información
Una vez que se ha definido el lugar y se ha colocado correctamente, el
analizador está listo para empezar a obtener información de la red, sea
mediante la captura de tramas, el registro de parámetros de operación
(niveles de utilización, errores, entre otras que se explicarán posteriormente),
o ambas actividades.
,s1ii//í7íf<//>(í/v.l.\íí//.w\o;uialisiseii pucrio conmutado
38
Estación
Estación
SWITCH 1
Servidor
(a)
SWITCH 1
Analizador
(b)
Servidor
SWITCH 2
Servidor
EstaciónAnalizador
(c)
Figura 2.5 (a) Red conmutada, (b) Uso del puerto de monitoreo (c) inserción de unconcentrador. La línea de puntos indica el flujo de datos dentro delconmutador [Cha99],
La siguiente sección describe al "delineamiento base d« la red" como método
para la medición y registro de la información, se incluye una interpretación de
posibles resultados y la documentación de la información obtenida mediante
sesiones de análisis sobre la Extranet.
2.1.4 DELINEAMIENTO BASE DE LA RED
Hasta aquí se ha definido al proceso de análisis y a la herramienta principal,
su funcionamiento, sus componentes e incluso la forma de conexión
dependiendo de la topología, dejándola lista para la extracción de información
de la red; en la presente sección, se define específicamente sobre qué tipo
de información enfocarse, cuáles son los parámetros relevantes y cuál es su
significado.
El objetivo de este proyecto consiste en lograr una optimización del
desempeño, mediante una aproximación por "delineamiento base de la red",
método que especifica los parámetros que de mejor manera caracterizan a la
operación de una red dada.
De lo anterior se podría decir que, con el objeto de lograr una actuación
eficiente dentro de importantes campos de la administración de redes como
lo son: Resolución de problemas de red, Optimización y Planificación y
crecimiento, se deberá establecer el delineamiento base de la red,
valiéndonos para ello de un ciclo programado de sesiones de análisis.
2.1.4 .1 Definición
El Delineamiento Base de una Red, consiste en la medición y registro de un
estado de operación de la red, sobre un período de tiempo [Mck%a|.
El objetivo consiste en llegar a conocer y comprender los valores típicos, o
"normales", para ciertos parámetros específicos con los que opera la red
|\V&G98J, aquellos valores serán tomados como "normales" cuando sean los
indicadores de un desempeño que tanto usuarios como servicios de red han
considerado aceptable |MckQ6a|.
40
2.1.4.2 Ventajas
Desarrollar un lincamiento base y mantenerlo resulta en un activo valioso
dentro de la administración de redes.
La principal contribución consiste en la definición de un nivel de operación
"normal" de la red, un ciclo programado de sesiones de análisis permitirá
comparar cada estado "actual" (recordando lo expuesto en 2 .1 .1 el resultado
de una sesión de análisis es el estado actual, mientras que el lineamiento
base define un estado normal) con el estado "normal" de operación,
ayudando al administrador a identificar y resolver los problemas de la red de
manera más eficiente, adicionalmente el administrador podrá estar en
capacidad de analizar las tendencias para predecir la operación de la red y
tomar las medidas necesarias anticipadamente.
Otras ventajas importantes implican la capacidad para medir la efectividad de
los cambios o actualizaciones realizadas dentro de la red, y una facultad para
confirmar la compatibilidad entre una ampliación y los servicios de red
existentes. La capacidad de una red para soportar nuevas aplicaciones y
usuarios ya no será cuestión de especulación o conjetura.
Un lineamiento integral permitiría al administrador mantener la red de manera
proactiva. Un cronograma apropiadamente implementado proveerá de una
valiosa comprensión de tendencias o cambios dentro de la operación
cotidiana de la red. Esta comprensión podría permitir al administrador
predecir la operación de la red bajo una carga dada, o anticipar los problemas
creados por la adición de nuevos servicios [Mck96a].
Estos aspectos tienen implicaciones económicas, pero la principal quizás
tiene que ver con el hecho de que muchos de los administradores apuestan
al incremento de la capacidad de transmisión, como la solución a sus
problemas de red.
Una decisión tomada en función del número de requerimientos recibidos,
relacionados con la existencia de algún tipo de problema, podría no ser la
41
adecuada, la consecuencia directa de un incrementando en la capacidad -de
la red local o de un enlace- simplemente podría ser que, de existir,
información inútil dentro de la red viaje con mayor facilidad.
Adicionalmente, luego de haber incrementado la velocidad de transmisión,
¿Cómo saber si efectivamente ha mejorado el desempeño de la red?
[Mck96a].
Como se verá más adelante, ampliar la capacidad de un enlace como medida
frente a una "sensación" de congestión no siempre es la solución adecuada,
la decisión de ampliación deberá tomarse luego del análisis y evaluación, no
sólo de las estadísticas, sino también del tráfico que atraviesa el enlace, caso
contrario podría incurrirse en un gasto innecesario e injustificado.
2.1.4.3 Procedimiento
Lo ideal es realizar el delineamiento base con cada uno de los segmentos
que conformen una red, y durante un período significativo de tiempo, un día
laborable completo o sería mucho mejor durante una semana. Luego de
examinar los datos obtenidos se recomienda elaborar un cronograma de
evaluación, enfocando áreas especiales (por ejemplo, aquellas con niveles
excesivos de utilización o frecuentes condiciones de error). Se determinará
entonces qué es lo normal, lo aceptable y lo inaceptable para la red.
En la práctica, considerando el tiempo y los recursos, puede no ser posible el
medir cada segmento, en este caso se seleccionarían las partes críticas o
problemáticas para realizar el proceso.
Recordando la definición dada en 2.1.4.1, el proceso de lineamiento base
demanda la realización de mediciones, éstas se elaborarán alrededor de
criterios relevantes para cada red.
Algunos parámetros comunes a las redes, que caracterizan o definen su
estado de operación, y se consideran como criterio relevante para un
lineamiento base, se describirán a continuación.
Se recomienda la elaboración de un formato estandarizado que facilite el
registro de la información obtenida, una tabla o carta especifica para cada
segmento; un ejemplo se propone en el anexo A.
J?. 1.4.3.1 EsfadisHcas a nivel Je segmento
Pueden dar una perspectiva amplia de lo que ocurre en un segmento
particular [W&G97], Un lineamiento general se enfocará en el backbone de la
red y en el análisis de segmentos específicos de la red, prestando especial
atención a los siguientes parámetros:
a. UTILIZACIÓN DE LA RED [Mck96a]: En redes del tipo Ethernet, la
limitación presentada por el ancho de banda es de 10 Mbps. Debido a la
naturaleza de acceso-múltiple, podría solamente esperarse que un backbone
o un segmento dado opere eficientemente a niveles de utilización del 40% o
menos, por supuesto que la definición de "eficientemente" variará de una red
a otra red.
Una vez que la red excede un nivel de utilización del 40%, los nodos
empiezan a experimentar retardos en la transferencia de información
causados por congestión en la red. En la mayoría de los casos, esta
congestión se manifiesta por sí misma, en forma de colisiones. Según la
utilización aumenta, lo hace también la probabilidad de que ocurra una
colisión ocasionada por múltiples usuarios intentando acceder
simultáneamente al medio de comunicación. La mayor parte de redes tipo
Ethernet operan en el rango del 10 al 25% de utilización promedio. De
encontrarse a una red operando dentro de niveles de utilización promedio de
40 o 50% se debe empezar a evaluar la forma en la cual se podría particionar
a la red (mediante puentes, ruteadores o conmutadores) con el objeto de
bajar el nivel de utilización en el segmento.
Esto no quiere decir que las redes de este tipo no operan eficientemente
sobre el 40%, no debe sorprender el hecho de que una red alcance picos de
utilización mayores al 40%, por esta razón es que se toman en cuenta tres
componentes de la utilización:
• Utilización Pico: Períodos de máxima utilización ocurrirán durante el
día, al examinar tos períodos pico se determinan a los usuarios,
protocolos, y dispositivos que crean los picos. Períodos de alta
utilización a menudo ocurren, como puede esperarse, al inicio y fin del
día de labores, y entre los recesos o breaks. Estos períodos deben ser
monitoredos para determinar la eficiencia de la red3.
El monitoreo de estos períodos proporciona un servicio dual, indica
cuan pesada se está volviendo la red y actúa como un signo de alerta
cuando la red empieza a saturarse.
• Utilización Promedio: Es cálculo normalizado de la utilización durante
el tiempo de monitoreo (promedia los niveles actual y pico). Lo que se
busca es una medida de utilización dentro de los indicadores de
desempeño aceptable para la topología de red en uso. En este caso
se sugiere que cualquier valor dentro del rango del 10 al 25% es
aceptable, y que cualquiera que exceda el 40% requiere de
investigación, esto es, si a cierto nivel (mayor que el 40%), se
determina que no existe pérdida de paquetes, puede tomarse como no
excesivo. Por el contrario, si se observan altas tasas de colisiones, y
paquetes que se pierden a dichas tasas, entonces se tiene un nivel
excesivo de utilización y se debe empezar a pensar en la
segmentación de la red.
> Utilización Actual: Es la utilización promediada sobre un intervalo de
tiempo fijo, típicamente el tiempo de muestreo (tasa a la cual el
analizador registra actividad en la red) varía entre 100ms y 10s. Esta
medida es útil para ayudar a determinar cuan intensiva una operación
de red puede ser [Mck96a].
' Eficiencia de la red.- Para establecer cuan eficiente es una red. cada uno de sus componentes debe sernnali/ado tomando como referencia un lincamiento base establecido: cslo debería rcalixarse como panedel mantenimiento regular de la red [Mck96a|.
44
Un incremento gradual en los niveles de utilización típicamente es causado
por el aumento de estaciones de trabajo, mientras que un incremento
repentino generalmente se debe a la adición de aplicaciones o a la
realización de cambios dentro de la red. Se pueden analizar los niveles de
utilización para proyectar el crecimiento de la red, con un grado razonable de
certeza.
Luego de evaluar la utilización de la red, una decisión tendrá que ser tomada
referente a lo que es aceptable o inaceptable. Estas tres estadísticas de
utilización contribuyen al desarrollo de una mayor y mejor comprensión de la
operación de la red.
b. TRAMAS POR SEGUNDO: Muchos analizadores miden este parámetro en
denominaciones Pico, Promedio y Actual. Conocer este parámetro es crítico,
sobretodo para los dispositivos que necesitan tomar decisiones referentes a
los contenidos de las tramas o paquetes, por ejemplo, al ser enviadas hacia
un ruteador, necesitan ser procesadas y su contenido analizado a nivel de la
capa red antes de su encaminamiento. Si el ruteador no soporta la tasa de
tramas de la red, los paquetes empiezan a perderse. Este indicador es
fundamental para dimensionar los equipos de interconexión que van a formar
parte de la red.
La cantidad de tramas por segundo no indica un porcentaje de utilización de
la red, debido a que no se conoce el tamaño de cada trama. El valor de la
tasa de tramas se debe interpretar conjuntamente con estos dos parámetros.
c. TAMAÑO DE TRAMA: La trama de información es un componente común
en todas las redes de datos que puede proporcionar un aumento inmediato
en la eficiencia de la red. Lo primero es conocer los límites superior e inferior
del paquete de datos, los cuales están predefinidos por la topología de la red
imptementada. Estas fronteras han sido seleccionadas para proveer un nivel
estándar de simplicidad y eficiencia a lo largo de la red.
45
Para topologías del tipo Ethernet, la trama mínima es de 64 Bytes, y la
máxima es de 1518 Bytes (sin contar con los siete Bytes de "preámbulo", ni
con el Byte "inicio de trama").
Con los parámetros de utilización, tasa y tamaño de tramas, se puede
evaluar, dependiendo del enfoque, la eficiencia de la red a diferentes niveles:
usuario, aplicación, protocolo, enrutamiento, etc. La eficiencia de una
aplicación, o usuario, puede directamente ser evaluada por el tamaño de los
paquetes y por ende de las tramas, utilizados para una comunicación.
La comunicación de datos entre dos nodos es más eficiente cuando mayor es
el tamaño de carga útil de la trama. Al detectar la presencia de tramas
pequeñas se debe observar el tipo de tráfico, no sería sorpresa si pertenecen
a secuencias de comandos, pero si se trata de transferencia de información,
entonces se tiene una aplicación de red poco eficiente.
Las aplicaciones deberán generar tamaños de paquetes consecuentes con
los límites impuestos por la topología subyacente. A pesar de que los
paquetes grandes tienen una mejor relación entre información de control y
datos, pueden llegar a degradar la eficiencia cuando son demasiado grandes,
la meta es incrementar el tamaño del paquete justo por debajo del punto
donde se necesita su fragmentación [Bre97].
Otro factor sutil, y quizás desconocido, puede afectar el tamaño de trama,
software del tipo "Conectar y Usar" (Plug-and-Play) a menudo limita las
comunicaciones de datos al preestablecer un máximo tamaño de trama a ser
usado. Aunque esta facilidad permite al administrador implementar
rápidamente cambios en la red, el precio que se paga usualmente consiste
en un decrecimiento de su eficiencia. Técnicas de comunicación "Plug-and-
Play" son diseñadas para operar bajo las condiciones del peor caso, no para
proveer eficiencia de red. La implementación de una solución de este tipo
usualmente garantiza que el software seleccionará un tamaño de trama
intermedio como el tamaño por omisión (default).
Para ilustrar, se toma el ejemplo de una aplicación operando en una red de
tipo Ethernet. Se asume que la aplicación está predefinida para seleccionar
un tamaño máximo de paquete de 512 Bytes. Dentro de este tipo de red, el
máximo tamaño de paquete a ser encapsulado dentro de una trama es de
1500 Bytes, lo que significa que simplemente fijando el tamaño por omisión
del paquete a un valor mayor, se podría mejorar inmediatamente la eficiencia
de la aplicación [Mck96a].
En el fondo, se debería determinar el tamaño máximo del paquete para todos
los nodos de la red. Aumentar razonablemente el tamaño de paquete que
una aplicación utiliza es una forma fácil de aprovechar más a la red
virtualmente sin costo alguno [Mck96a].
d. ESTADÍSTICAS DE ERROR: Cierto número de errores pueden ser
tomados como indicadores del "estado de salud" de la red.
Es notable el hecho de que del 50 al 60% de todos los problemas de red se
originan en las capas física y enlace [Mck96a], como lo muestra la tabla 2.1.
1
Capas (modelo OSI)Aplicación
PresentaciónSesión
TransporteRed
Enlace de DatosFísica
Resolución deproblemas por Capa
3%5%7%10%15%25%35%
Percepción por partedel usuario
100%
Tabla 2.1 Porcentaje de problemas de red a resolver según su nivel de origen, latercera columna indica que la mayoría de usuarios identifican a latotalidad de los problemas a nivel de la capa Aplicación [W&G98],
Por esta razón se pone particular atención en las siguientes estadísticas de
errores dentro de redes de tipo Ethernet:
47
Colisiones de Red: Las colisiones de por sí. son más bien eventos
Ethernet que errores. Recordando lo expuesto en 1 . 1 . 1 . 1 . el acceso a
una red de este tipo está regulado por un algoritmo de contienda
llamado CSMA/CD, una estación escucha dentro de la red para
determinar si es que existe tráfico. Cuando la red no se encuentra
ocupada, la estación empieza a transmitir a la vez que escucha para
cerciorarse de que la información no se altere con tráfico de alguna
otra estación, si todo marcha bien, la transmisión es completa, si
ocurre una colisión, la estación espera durante un corto período
aleatorio y retransmite [W&G98].
Normalmente las colisiones ocurren cuando las estaciones toman el
canal al mismo tiempo, y dan como resultado un fragmento (dentro del
contexto de errores en Ethernets, un fragmento se refiere a una trama
de tamaño menor que 64 Bytes, con un CRC errado). No obstante se
deben diferenciar entre tres tipos existentes de colisiones:
-Locales: Ocurren, desde el punto de vista de la estación, en el
lado local de un dispositivo de repetición (como un concentrador
o hub). Las colisiones locales son identificadas por un pico en el
nivel de la señal junto con un fragmento.
-Remotas: Aquellas que ocurren en el otro lado de un
dispositivo repetidor (éste no reproduce el pico en la señal, pero
sí reproduce el fragmento).
-Tardías: Si la colisión no ocurre cuando las estaciones
involucradas toman simultáneamente el canal, sino cuando una
de ellas ha transmitido una parte de la trama. Se pueden
diferenciar de las anteriores por el hecho de que los campos de
dirección a menudo son legibles. Las colisiones tardías pueden
ser un indicador de una tarjeta de red defectuosa [Cha99], estas
colisiones no deberían ocurrir, de existir, la red probablemente
4S
estaría excediendo especificaciones sobre longitud de cable, o
número de repetidoras.
Dentro de una red tipo Ethernet, la tasa de colisiones puede ser
utilizada como un indicativo de la utilización de red. Las colisiones no
afectan al desempeño de la red tan negativamente como se podría
pensar. Si una colisión ocurre en los primeros 64 Bytes de una trama
Ethernet, ésta es retransmitida por el chipset en la tarjeta de red,
ningún mecanismo de capa superior a la de enlace se ve involucrado.
El tiempo requerido para una retransmisión a este nivel es
despreciable [Mck96a]. Tasas modestas de colisiones son normales,
redes funcionales pueden tener tasas de colisión en el corto plazo (por
ejemplo durante intervalos de un segundo), del 20 o 25%; Si las tasas
de colisión sobrepasan el 30% se deberían estudiar cuidadosamente
[W&G98].
Un alto número de colisiones con un elevado nivel de utilización
típicamente indican una red congestionada, si la utilización es baja
mientras que la cuenta de colisiones aumenta, lo más seguro es que
exista una tarjeta o dispositivo defectuoso dentro de la red [Cha99].
FCS (Frame Check Sequence): Antes de transmitir una trama, la
tarjeta de red realiza un algoritmo de comprobación por redundancia
cíclica sobre el contenido de dicha trama, el resultado de la ecuación
es colocado en el campo final de la trama (denominado FCS).
Una vez recibida la trama, la tarjeta de red del receptor realiza el
cálculo sobre el contenido, y compara su resultado con el valor del
campo final de la trama entrante, si las cantidades coinciden, la trama
se considera válida, caso contrario se la interpretará como alterada
[Cha99]. Los errores FCS, que pueden ser producto de tarjetas
defectuosas o el resultado de colisiones tardías, indican que los datos
han sido alterados tanto por la estación transmisora o mientras se
transportaron a través de la red. Este tipo de error tiene el mismo
efecto que las colisiones tardías, las tramas perdidas deben ser
retransmitidas por los protocolos de capa superior, usualmente de
capa transporte, resultando en un efecto negativo sobre el desempeño
de la red.
Inicialmente será importante evaluar la red y determinar si ésta es una
de las preocupaciones con las que se tendrá que lidiar [Mck96aj.
• Tramas Cortas: Denominadas también como "Runts", una trama corta
es aquella cuya longitud es menor que 64 Bytes, pero que tiene un
CRC válido, usualmente es el resultado de una tarjeta de red
defectuosa o de su controlador (dríver) [Cha99]. Si se incrementan con
regularidad, sin la actividad de colisiones correspondiente, entonces
debe implementarse análisis a nivel de estación para identificar cuál
está generando estas tramas [Mck96a].
• Fragmentos: Un fragmento hace referencia a una trama de tamaño
menor que 64 Bytes, con un CRC errado. Son el resultado de las
colisiones de red.
• Tramas Largas: Tienen una longitud mayor a los 1518 Bytes y un CRC
válido, al igual que las cortas, típicamente son causadas por
controladores LAN defectuosos o fuera de especificación. Cuando
estas tramas tienen un CRC no válido se denominan "Jabbers"
(balbuceos), son típicamente cadenas de datos sin sentido [Cha99].
Son el Indicador de que una tarjeta no dejará de transmitir, deben ser
eliminados pues impiden el acceso de otros nodos a la red [W&G98].
Hasta ahora se han analizado los problemas originados a nivel de capa física
y enlace correspondientes a redes de área local compatibles con los
estándares IEEE 802.3/Ethernet, (según la tabla 2.1 el 60% de los problemas
se sitúa dentro de estos niveles.) no obstante, un importante 15% se
50
localizaría a nivel de la capa red, por cuanto sería útil además analizar lo que
aquí pueda ocurrir.
Protocolos que se valen de una capa de red subyacente precisan de cierto
grado de administración, requieren que el administrador de la red asigne
direcciones e implemente filtros de red y restricciones de comunicación.
Independientemente del protocolo de red se debe poner atención especial a:
• Direcciones Duplicadas: Implica que dos estaciones físicas han sido
asignadas a la misma estación lógica, Los resultados pueden ser
muchos y variados, pero con seguridad todos negativos.
• Estación/Red//-/osí Inalcanzable: Indica que un nodo, pieza de
equipamiento de comunicación o enlace de datos no está operando,
• Tiempo de Vida Excedido: Cuando un protocolo de red ha sido incapaz
de entregar un paquete debido a un diseño de red inapropiado.
configuración incorrecta de software, o falla de la red.
• Errores CFC/FCS, la mayoría de protocolos realizan una secuencia de
CRC o FCS en cada capa.
e. DIFUSIONES (Broadcasts): El tráfico de difusión dentro de la mayoría de
las redes representa un mal necesario, generalmente es utilizado para
anunciar o buscar servicios y para resolver direcciones de capa enlace desde
direcciones de red [W&G98J. Las difusiones, a nivel de la capa enlace en
redes tipo Ethernet, se encapsulan dentro de tramas cuyo destino consiste en
la dirección FF FF FF : FF FF FF (Hex), éstas deben ser procesadas por
todos los dispositivos dentro del segmento, independientemente del protocolo
de capa red que implementen [ChaOOJ. Si el paquete encapsulado resulta no
ser de interés para una(s) estación(es) se descarta, entonces se ha
desperdiciado tiempo de procesamiento y se han utilizado recursos
innecesariamente (W&G98], lo cual puede degradar el desempeño de la
aplicación. La importancia de monitorear el tráfico de difusión radica en el
limite que tienen los dispositivos en cuanto al número de tramas que pueden
ser procesadas durante períodos cortos de tiempo [W&G98]. Equipos de
interconexión como los ruteadores trabajando cerca de la tasa de tramas
límite, podrían descartar paquetes importantes mientras procesan el tráfico
de difusión, en que la mayoría de las ocasiones no estarían interesados,
originando retransmisiones y mayor congestión.
Ejemplos de protocolos que usan difusión son: ARP, DHCP4
(descubrimiento), RIP IP, RIP IPX, SAP5, entreoíros.
f. MULTIDIFUSIONES (Multicasts) Consiste en un tipo especial de tráfico que
está designado para un grupo específico de estaciones dentro de la red.
Generalmente se utiliza para anunciar servicios o nombres de estaciones en
uso, ejemplos de protocolos que utilizan multidifusión son OSPF y NetBIOS.
Tasas altas de tramas enviadas a una misma dirección de multidifusión, (por
ejemplo la dirección 030000:000001 de NetBIOS) afectan a todas las
estaciones implicadas en el grupo, pudiendo causar congestión,
retransmisiones, etc. -Se ha dado el caso de redes TCP/IP con estaciones
basadas en sistema operativo Windows 95/98 que adicionalmente
implementan los protocolos de sesión NetBIOS (encapsulado sobre
TCP/UDP), y NetBEUI (NetBIOS sobre LLC), a pesar de que las necesidades
de comunicación se solventan enteramente por la pila de protocolos TCP/IP;
las estaciones a más de procesar las difusiones propias de esta pila, tienen
que hacerlo con las de NetBIOS, y con las multidifusiones NetBEUI; el hecho
de que todas las estaciones deban procesar adicionalmente información
perteneciente a protocolos innecesarios puede ocasionar pérdida de
paquetes, retransmisiones, congestión, etc. -
Protocolo de Confiííuración Dinámica de //av/.v. (Dynamic Host Configitraiion Proiocoh.Protocolo de Anunciación de Sen icios en redes Novell NetWare (Sen-icc. Idverii\infi l'rotatal).
_?. I- 4.3. _? A'.v/í/í//.v//mv a nivel Je
A nivel de conversaciones, las estadísticas por estación pueden dar una
rápida visión de quienes son los mayores usuarios de la red, ayudan a
identificar cuáles son las conversaciones más fuertes, quienes hablan más.
quienes son los que más escuchan, y determinar el tipo de tráfico que
generan.
Cuando se detectan estaciones "presionan" a la red se analizarían en detalle
todas sus conversaciones para determinar el tipo de tráfico que cada una
produce [W&G97].
a. MAYORES USUARIOS: En la mayoría de las redes, un pequeño
porcentaje de dispositivos son responsables del 80% del total de utilización.
En general, la cantidad de estaciones clasificadas por un analizador de
protocolos como "mayor usuario" varía entre 5 y 20, el número de estaciones
en esta categoría depende del tipo de trabajo realizado por los usuarios de la
red. Para identificarlos se recomienda monitorear durante períodos pico, al
menos por un lapso de una hora. Al empezar a evaluar a los mayores
usuarios probablemente se encuentre que algunos dispositivos de
conectividad, como ruteadores, puentes o conmutadores, residen en esta
categoría.
b. USUARIOS ERRADOS: Es necesario categorizar a las estaciones
involucradas en la creación o identificación de errores de red. Debido a la
estructura estratificada de las comunicaciones, los errores de red se registran
entre varias capas o niveles de comunicación [Mck96a]. El apartado anterior
estableció que entre el 65 y 75% de los errores se originan en las capas
física, enlace y red. Con esto en mente, el registro de errores por nodo se
enfocará a nivel de las capas MAC, y Red.
c. MAYORES CONVERSACIONES: La forma más práctica de examinar las
conversaciones entre dispositivos consiste en el análisis de la información en
una presentación gráfica, denominada por los analizadores de protocolos
como "matriz de comunicaciones".
53
Estación N
(a)
Estación K
Dispositivo Crítico:Consiste en el único puntode congestión y/o falta.
Patrones dispersos:No se aprecian rutas oservicios centralizados
ConversaciónSuplementaria
Estación N
Estación N
Figura 2.6 Patrones de tráfico dentro de una red, ilustrados en forma de matriz
[ChaOO]
Mediante una simple inspección se puede determinar cuales son los
dispositivos críticos dentro de la red (aquellos a los que otras estaciones
apuntan), la figura 2.6 aclara un poco más la situación [ChaOO].
El gráfico anterior muestra las principales formas de conversación entre un
par de estaciones dado, la figura 2.6(a) corresponde al tipo de comunicación
más común en una red, desde un cliente hacía un servidor o hacia un
dispositivo de interconexión, a menudo se encuentran conversaciones
adicionales o suplementarias -como lo indica la figura 2.6(b)- claramente
visibles en la matriz, éstas requieren de un análisis particular, (personas no
autorizadas podrían haber levantado servicios en sus sistemas) [ChaOO].
Finalmente, se pueden encontrar patrones simplemente dispersos, figura
2.6(c), lo cual puede ser el resultado de procesos servidor cargados en varias
estaciones cliente.
Puede decirse que el mayor problema con el que tiene que lidiar el Servidor 1
de la figura 2.6(a), es la carga. Una práctica común al incrementar la
eficiencia de servidores consiste en segmentar e incrementar el ancho de
banda disponible para estos dispositivos. Durante el delineamiento base, se
examina que todas las estaciones clasificadas como "mayores usuarios" no
están intentando usar los mismos servidores e impresoras que el usuario
común de red.
La segmentación de usuarios pesados en grupos apoyados por un backbone
de alta velocidad es la manera más fácil de incrementar la eficiencia de red.
La mayoría de estaciones de trabajo y computadores personales son
capaces de soportar interíaces Fast Ethernet o FDDI. En lugar de escalar
toda la red, se puede segmentar a los mayores usuarios, actualizar sus
accesos a la red (a Fast Ethernet, FDDI, o ATM) y dedicar servidores y/o
periféricos para su utilización. El beneficio es doble:
• El usuario promedio obtiene un acceso más rápido.
• Se evita (temporalmente) el costo de actualizar toda la red.
Una estrategia alterna consiste en incrementar el número de puertos de
acceso en el servidor. La mayoría de servidores proveen múltiples puertos
para NIC adicionales. El incremento de puertos de acceso en el servidor
debería ayudar a aliviar "cuellos de botella".
d. PROTOCOLOS EN OPERACIÓN: Las redes tienden a ser heterogéneas
cuando se trata de protocolos en operación. Muchas redes, especialmente
LAN, se han desarrollado desde sus raíces, las que a veces se remontan
hasta los años 70. La tendencia a construir sobre la tecnología existente, a
menudo resulta en redes que tienen en coexistencia protocolos antiguos y
recientes. No es inusual encontrar redes que tienen todo desde DECnet y
TCP/IP hasta los últimos protocolos de la ISO operando en un mismo
segmento. Frecuentemente se ven redes que tienen cuatro o cinco (si no son
más) pilas de protocolos operando en un momento dado. Al delinear la red,
se sugiere que una lista completa de los protocolos y sus host sea
establecida. Cuando se delinea una red, podrían encontrarse protocolos que
nadie sabía que estaban operando dentro de la misma, es importante rastrear
y establecer el lugar en que cada protocolo se origina.
No existen reglas rígidas en cuanto al número máximo de protocolos que
podrían operar en una red, sin embargo, debemos destacar el hecho de que
cada protocolo añade cierta cantidad de información adicional que será
procesada entre sus entidades (denominada como conversación de segundo
plano), por ejemplo, para identificar servicios, negociar procedimientos de
comunicación entre estaciones, y localizar otras estaciones. A mayor número
de protocolos activos, más alto es el nivel de conversaciones de segundo
plano, y ciertamente mayor es la utilización promedio de la red, más
importante aún, de no ser filtrada adecuadamente esta información, podría
ser transportada a través de los enlaces WAN de la red, incrementando el
costo de mantenimiento del desempeño de red.
La meta del lincamiento base es en este caso, establecer el número de
protocolos que están operando en la red y el lugar de procedencia.
Llevando el concepto a nivel de las estaciones, especial atención se debe
prestar en los protocolos implementados por aquellas clasificadas dentro de
la categoría de "Mayores Usuarios", así como en el registro de las diferentes
direcciones atribuidas por cada protocolo [Mck96a].
2. /. -4. 3.3 fcsltidísticas a nivel de Aplicación
En los dos últimos apartados se han cubierto las estadísticas consideradas
como relevantes para un delineamiento base de red. Tanto a nivel de
estación como a nivel de segmento se ha prestado principal atención a
cuanto se relaciona con las capas Física, Enlace y Red, puesto que,
recordando la información de la tabla 2.1, aproximadamente el 75% de los
problemas de red tendrían solución dentro de estos tres niveles, no obstante,
un importante 25% se relacionaría con las capas superiores, y si se trata del
modelo TCP/IP, como en nuestro caso de estudio, sólo la capa Transporte
respondería por más del 10%; esto quiere decir que se puede lograr una
optimización adicional de la red al enfocar algunos eventos a nivel de las
capas de transporte y aplicación. Puntualmente, el análisis de los patrones de
tráfico a nivel de transporte entre dos estaciones, y la evaluación del
desempeño de la aplicación, representarían una potencial contribución en
cuanto a la optimización de la red.
a. PATRONES DE TRÁFICO: Para realizar el estudio de los patrones de
tráfico se utilizan los decodificadores de tramas, que forman parte de la
mayoría de las herramientas de análisis (descritos con cierto grado de detalle
en 2.1.2.3.2 y dentro de la figura 2.3), básicamente lo que interesa ahora es
identificar ciertos patrones de tráfico que podrían presentarse dentro de una
red, en algún momento dado:
• Solicitud-Respuesta, Solicitud-Respuesta: Este es un patrón normal
cuando se trata de secuencias de comandos, ejemplos de este tipo de
patrones son los procesos iniciales de conexión para transferencia de
archivos. Cuando este patrón está involucrado en la transferencia de
datos de usuario se tiene una comunicación de red ineficiente. Pueden
encontrarse dentro de lecturas de archivos mediante procesos que
soportan ventanas de valor unitario (SPX6 versión 1 por ejemplo),
aplicaciones que limiten la cantidad de información a intercambiar, etc.
• Solicitud, Solicitud, Solicitud: Probablemente algún dispositivo está
realizando una búsqueda continua de servicio sin obtener respuesta;
De no existir un mecanismo temporizado que finalice las solicitudes, el
proceso continúa, ejemplos de este comportamiento son;
- Interrogaciones RIP IPX no contestadas
- Difusiones ARP sin contestar
- Difusiones para descubrimientos DHCP sin respuesta
• Solicitud-Respuesta-Respuesta-Respuesta: Correspondiente a una
transferencia de información utilizando ventanas, es un buen patrón
que se observa en aplicaciones para transferencia de archivos
basadas en TCP (como FTP).
• Respuesta-Respuesta-Respuesta: Este patrón generalmente se
emplea para distribución de información, típicamente pertenecen a
protocolos informacionales como RIP (IP e IPX).
b. DESEMPEÑO: Como lo describe la tabla 2.1, especialmente la tercera
columna, se puede decir que desde el punto de vista del usuario la medida
definitiva del desempeño de la red (y del administrador) consiste en la
cantidad de tiempo empleado en abrir un documento o desplegar una página,
de aquí la importancia de mantener dentro del usuario una percepción
positiva sobre el desempeño de la red, para lograrlo, el delineamiento base
debe extenderse hasta el nivel de aplicación. Se trata de emplear el mismo
principio pero ahora para medir las características de desempeño de una
aplicación específica, generalmente alguna hecha a la medida de las
JtK/tií'i Kxchange, es un protocolo de capa transporte en redes Novell NciVVarc.
necesidades particulares de una organización, razón por la que se depende
de ella enteramente.
Como se estableció en apartados anteriores, la meta de toda medición para
lineamiento base es establecer un punto de referencia sólido para
comparaciones futuras, al tiempo que se provee de una forma para la
cuantificación del impacto de ciertas medidas de optimización.
Una medición de desempeño de aplicación debería cuantificar el tiempo total
requerido para llevar a cabo una transacción específica dentro de una
aplicación dada, esencialmente, el registro del tiempo empleado para la
transacción provee de una referencia contra la cual efectuar comparaciones
futuras, ésta y otras mediciones de desempeño pueden realizarse fácilmente
con un analizador de protocolos, a través de la captura de las tramas
transferidas entre el cliente y el servidor, y del uso de un apropiado filtrado,
basado en direcciones, para impedir la inclusión de tráfico de red innecesario.
Usando la característica de tiempo relativo de los analizadores, y tomando
como referencia el inicio de la transacción, se puede medir la duración de la
transacción entera. Esta es toda la información requerida para repetir la
medición en el futuro y realizar comparaciones de desempeño,
adicionalmente, el total acumulado de Bytes dividido por la duración revela el
rendimiento (Syfes/segundo) global para esta transacción. Con esto se logra
representar a la comunicación bidireccional total, incluyendo las solicitudes
del cliente, y no sólo a la transferencia de datos de aplicación.
Se debe tomar en cuenta la variación de los niveles de utilización actual
dentro de la red, por lo que la medición de la transacción sería realizada más
de una vez por sesión, para asegurar que el resultado se ha obtenido
partiendo de una condición normal de operación de la red.
Muchos factores pueden afectar al desempeño de una aplicación, y no todos
ellos están relacionados con la red; por ejemplo, la capacidad de
procesamiento, tanto de clientes como de servidores, la cantidad de RAM, el
Sistema Operativo, y el mismo software de aplicación son factores
contribuyentes propios de la estación, no de la red. Tanto el tipo de tarjeta
interfaz de red, si se basa en ISA o PCI, como los parámetros de la pila de
protocolos dentro de la máquina son ejemplos de factores relacionados con la
red pero que residen físicamente dentro de servidores y clientes. Contiendas
por el acceso a la red, retardo de propagación, latencia de dispositivos de
interconexión (enrutador, puente, o conmutador), son factores influyentes en
el desempeño de la aplicación netamente fundamentados en la red [Cha97].
Una vez delineado el desempeño de la aplicación, el siguiente paso es definir
un procedimiento para la aproximación a la resolución de problemas
detectados a este nivel, referentes a la identificación de cualquier retardo
excesivo; dicho proceso consistiría en cuantificar el efecto contribuyente de
cada componente de red involucrado en el intercambio de datos entre el
cliente y el servidor en cuestión, esto incluye al cliente, al servidor, y a
cualquier dispositivo de interconexión entre ellos.
Las mediciones se toman grabando la transacción con un analizador de
protocolos, primero desde el segmento al que el cliente se conecta. Si largos
retardos entre paquetes están presentes (más de unos cuantos milisegundos
para conexiones LAN del mismo segmento), se debe definir si es el cliente
quien los induce (cuando el retardo es entre la respuesta del servidor y la
siguiente solicitud del cliente). De no ser así, entonces los retardos serían
causados por el servidor, la contienda por el canal de transmisión, o por los
dispositivos de interconexión intermedios.
Ahora el objetivo ha dejado de ser la medición del desempeño de la
aplicación, sino que se ha convertido en el intentar segmentar el retardo total
(problema detectado) en sus componentes contribuyentes, aislando
efectivamente las causas. Se asume adicionalmente, que para haber llegado
ha este punto se debió haber pasado por el análisis de las diversas
estadísticas mencionadas en apartados anteriores, es decir, en esta sección
se piensa sólo en términos de retardo de paquetes o de latencia, puesto que
los otros tópicos que pueden afectar significativamente la duración de una
transacción de red. tales como retransmisiones, congestión, errores, etc han
sido analizados previamente.
La primera posibilidad al analizar los retardos, consiste en que el cliente sea
quién los induce, resolver este problema resulta un poco más complicado de
lo que parece, en realidad, la mayoría de transacciones de las aplicaciones
de red incluyen múltiples operaciones, que presentan diferencias en el
retardo, casi con toda seguridad atribuibles al tiempo de procesamiento de la
estación cliente, esto no significa que ocurra algo malo con ella, en todo caso
significa que una ampliación o mejora en cuanto al desempeño del cliente
probablemente haga más para acelerar esta transacción que cualquier cosa
que pueda hacerse sobre la red o el servidor. Si el cliente ya es
razonablemente potente, y cuenta con la versión más reciente de software de
aplicación, entonces en este caso podría no haber mucho lugar para una
optimización.
Para el caso en que la observación de los retardos hubiera determinado que
la mayoría de ellos no se fundamenta en el cliente, sino en "la otra parte"
(que incluye tanto al servidor como a la trayectoria seguida por los datos),
con el objeto de solucionar el problema, se debe aislar al mayor factor
contribuyente, sea éste el efecto total de uno o más dispositivos de
encaminamiento de paquetes en el trayecto de los datos, o el propio servidor.
2.1.4.4 Documentación
Una vez desarrollado el lineamiento base de la red, es muy recomendable
que un formato estándar sea desarrollado para permitir fácil registro de la
información obtenida: una tabla específica para cada red [Mck96a].
El establecer una base de datos central, en donde se guarden todos los
reportes de lineamiento base de la red, servirá como una valiosa referencia
para la misma. A mayor información desarrollada y mantenida, sobre cada
usuario, segmento, dispositivo de conexión, o servidor, más fácil se vuelve la
tarea de mantenimiento de una red [Mck96a].
Adicionalmente se tiene una muy buena oportunidad para levantar o
actualizar, y llevar de forma paralela el inventario: establecer, por ejemplo,
una lista completa de componentes de hardware, acceder e imprimir, de ser
posible, los archivos de configuración y anexarlos a una forma que incluya
números de serie, de parte, versión de software, etc.
En resumen, al mantener una correcta documentación se está construyendo
una historia de la red, un "manual del usuario" para una red en particular. En
el anexo A se encuentran formatos propuestos para la documentación de un
delineamiento base.
En cuanto a la documentación de una sesión de análisis, se recomienda
presentarla en forma de reportes, que describan todos los hallazgos dentro
de la sesión, en una forma entendible, incluso por personal poco
especializado, (por ejemplo un resumen ejecutivo como introducción al
reporte técnico, que puede ser tan profundo y detallado como sea requerido)
que contenga interpretaciones gráficas. Las siguientes secciones se han
desarrollado desde el punto de vista de reportes de análisis.
2.2 ANÁLISIS DE LA EXTRANET
2.2.1 REPORTE DE LA SESIÓN DE ANÁLISIS PARA LA BVQ
GENERALIDADES
El siguiente reporte de análisis de red, se basa en las sesiones realizadas en
el sitio de operación de la denominada "Extranet", propiedad de, y
administrada por, la Bolsa de Valores Quito (BVQ). La investigación "en sitio"
se realizó tanto a nivel WAN como LAN. En el primer caso se empleó el
analizador de protocolos Parascope 2000 fabricado por la casa Frederick
Engineering, Inc. En el segundo, para captura de datos se utilizó el programa
PacketBoy 1.4.4, un analizador de protocolos de la NDG Software. La
interpretación de resultados y el análisis posterior se llevó a cabo mediante el
producto SnifferPro V.4.5 perteneciente a la casa NAI.
62
La visita a la red de la BVQ, y la obtención de ta información para este
reporte ha sido posible gracias a la colaboración de los Ingenieros: Segundo
Saransig, Marco de Faz, y demás personal del Departamento de Sistemas de
la Bolsa de Valores Quito.
CONTENIDO
El presente reporte contiene hallazgos y consideraciones (resumidos en un
sumario ejecutivo y luego detallados en un reporte técnico) en cuanto al
estado de operación de la Extranet, tanto a nivel de la red local como de la
extendida.
SUMARIO EJECUTIVO
• ANTECEDENTES
Ante la preocupante degradación del desempeño de la Extranet,
especialmente en el acceso a la Internet, personal técnico de la BVQ solicita
apoyo para encontrar una solución. Se planifican entonces visitas y sesiones
de análisis sobre dicha red, monitoreando iniciatmente el enlace con el ISP y
luego la red local.
• HALLAZGOS
Existe congestión del enlace WAN que interconecta a la Extranet con el ISP,
un análisis más profundo revela que dicha saturación es el resultado de una
intrusión externa que se aprovecha de la vulnerabilidad presentada por la red
local, específicamente del servidor de correo electrónico; el objetivo de esta
intrusión no es otro que el de perjudicar a la Extranet, y a través de ella a
otras redes en la Internet, así como a quienes proveen la cadena de enlaces
que las interconectan.
Como resultado de las sesiones de análisis dentro de la LAN se ha
encontrado la existencia de tramas menores al límite inferior impuesto por la
topología de red utilizada, todas generadas por el servidor denominado "Web-
Server 2". adicionalmente. existe un alto porcentaje de información (43%)
perteneciente a protocolos probablemente innecesarios: como MS DCE/RPC,
DLSw (de la arquitectura IBM SNA), NetBEUI, NetBIOS, RIP.
Los niveles de difusión y multidifusión son bajos pero se deben tener en
cuenta. Los dispositivos más críticos en la red son los servidores de Correo
Electrónico, Proxy, y el enrutador.
Tráfico ICMP revela la presencia de saltos adicionales a nivel de ruteo y la
necesidad de añadir rutas estáticas.
RED DE ÁREA EXTENDIDA (WAN)
• UTILIZACIÓN DEL ENLACE WAN
La figura 2.7 muestra el nivel de utilización del enlace para cada dirección,
desde el punto de vista de la BVQ, la línea azul se refiere a la transmisión
(saliente) y la verde representa la recepción (entrante).
Percent Utilization
100 -
75 -
50 -
25 -
m^mm ^^HDTE DCE
-
-
-
-
00:OC
-_L~ A A -
:12 00:00:24 00:00:36 00:00:48 00:01:00 00:01:12 00:01:24 00:01:36 00:01:48 00:02:00
Source DTE DCEAverage 0.36 99.82Mínimum 0.00 (00:00:01) 0.00 (00:00:01)Máximum 5.63 (00:00:46) 99.90 (00:01:29)
Figura 2.7 Porcentaje de utilización del enlace WAN.
64
Claramente se observa que existe saturación en el circuito de transmisión del
enlace, específicamente se tiene una ocupación promedio del 99.82%.
El camino más fácil en este punto sería contratar un enlace de mayor
capacidad y dar por terminado el trabajo, a pesar de ser una idea muy
tentadora se debe profundizar un poco más, nótese que el patrón de tráfico
típico para redes que tienen acceso a la Internet es todo lo contrario, es decir,
el tráfico entrante debería ser mucho mayor que el saliente, esta
particularidad alienta a indagar un poco más.
• PROTOCOLOS EN OPERACIÓN
i. Tráfico ICMP
Las figuras 2.8 y 2.9 demuestran que un aumento en la capacidad de
transmisión como solución al problema de tráfico en la red implica la incursión
en gastos excesivos que podrían resultar innecesarios:
::.">• "3Nunber trr Luth
123456789
18111213141516171»192021222324252627282930313233343536
158615861586150615861586158615861586158615061506150615061506150615061506150615061506150615061506150615061506
141*
1506150615061506150615061506
PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:PPP:
flddr/CtrlUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUncoRpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconprpssUnconpressUnconpressUnconpressUnconpressUnconpressUnconpressUnconpress
Protocol ÜnprIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPIPLCPLCPIPIPIPIPIPIPIP
NoNoNoNoNoNoNONoNoNoNoNoNoNoNoNoNoNoNoNoNoNoNoNoNoNoNoNoNoNONoNoNoNoNoNo
ÍP:IP:IP;IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:IP:
IP:IP:IP:IP:IP:IP:IP:
ProtocolICMPICMPICMPICMPICMPICMPICHPICHPICHPICHPICHPICHPICHPICHPICHPICHPICHPICHPICHPICHPICMPICHPICMPICHPICMPICMPICHP
ICMPICMPICMPICMPICMPICHPICMP
Üource216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219216.219
216.219216.219216.219216.219216.219216.219216.219
flddr.15,131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131.15.131
.15.131
.15.131
.15.131
.15.131
.15.131
.15.131
.15.131
ücst flddr24.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.15724.157
24.15724.15724.15724.15724.15724.15724.157
.101.106
.101.106
.101.106
.101.106
.101.106
.101.106
.101.106
.101.186
.181.106
.181.106
.181.106
.181.106
.101.106
.181.106
.181.106
.181.106
.181.106
.181.106
.101.106
.101.106
.181.186
.101.186
.181.106
.181.106
.101.106
.101.106
.101.106
.181.106
.181.106
.101.106
.181.186
.181.106
.101.106
.101.106
Figura 2.8 Decodificación resumida de las tramas capturadas.
65
Se puede apreciar que la mayor parte del tráfico observado se conforma por
tramas de 1506 Bytes que contienen información perteneciente al protocolo
de mensajes de control ICMP, lo cual resulta completamente extraño e
inusual, adicionalmente el color azul y la dirección de red indican que se trata
de paquetes generados por el servidor de correo electrónico de la Extranet.
Para aclarar un poco la situación se examinan las características de una de
las tramas, valiéndose de la decodificación detallada del analizador:
Frame 10 (1506 bytes) was captured with no errors.PPP:
Addr/Qr! = UncompressProtocúl = IFCompressioh - No
IP:Versión = 4, IP Headet Length (bytes} * 20Precedence = RoutineType of Service = Normal ServicePacket Total LengthIdentification = 18078DF Flag = May Fragment, MF FlagfMore FtagmentsFragment Offset = O X*-—
e = 31CEfotocoi =
Header Lhecksum = C91DS ource Address = 216.219.15.131, Destination Address = 24.157.101,105
g| ^m/^
Type = EchoocíS"=
Checksum = 50695Id = 256Seqtt=34637
nformation:02Oh: a b83Oh: q84 0h:85 0h:86 0h:07Oh: 108Oh: e09Oh: u u w
5 D 0 h : i j k l m n o p q r s t u u w a
Figura 2.9 Decodificación detallada de la trama número 10.
66
Como lo muestra la figura 2.9, se trata de continuos mensajes "solicitud de
eco" ICMP, cada mensaje es tan largo, que se divide en más de diez
fragmentos un tanto menores a 1500 Bytes, sin observarse respuesta alguna.
El efecto es similar al que tendría la ejecución del comando:
PING 24.157.101.106-T-L [longitud]
donde el parámetro -T indica la ejecución indefinida del comando y -L
precede a la longitud (en este caso mucho mayor que 1500 Bytes) deseada
para los paquetes de solicitud de eco que se dirigirán al host 24.157.101.106.
El resultado: imposibilidad para establecer una nueva conexión o mantener
una existente entre estaciones de la red local y hosts en la Internet, debido a
un altísimo grado de ocupación del enlace, e imposibilidad para recibir
cualquier información originada en la Internet debido a la naturaleza
unidireccional de la red local, y a su alto índice de ocupación.
ii. Tráfico RIP
En la figura 2.10, se observa la existencia de información perteneciente al
protocolo de enrutamiento RIP, originada por el ruteador local.
JlJiB ¡ít
Err l.utti IP: Pi-utocol So u reí1 flduV(11 IP;52 IP:72 IP:
134 IP:50 IP:52 IP:52 IP:62 IP:181846 IP:400 IP:52 IP:8Ú5 IP:52 IP:
ÜÍPTCPUDPUDPICPTCPTCPICMP
TCPTCPTCPTCPTCP
63.121.156,34216.219.15.13263.71.198.5216.219.15.132216.219.14. 1262QQ.5B.18.210216.219.15.132
Uest flddr
216.219.15,13263.71.198.5216.219.15.132216.219.14.126216.219.15.132216.219.15.13263.71.198.5
UDI': Sourcí' l'ort Dest P«rt H IP : Conni.niiJ:.'; Besponse
UDP: 3327UDP: 53 <Donain
53 (Ñaue S3327
216.219.15.132 216.219.14.126216.219.15.132 216.219.14.126216.219.14.126 216.219.15.132216.219.14.126 216.219.15.13263.171.156.3* 216.219.15.132
Figura 2.10 Tráfico RIP.
67
La trama sombreada pertenece al protocolo RIP, a pesar de ser relativamente
pequeña, se debe tener presente que este protocolo envía información cada
30 segundos, ocupando los siempre limitados recursos WAN.
RED DE ÁREA LOCAL (LAN)
La sesión de análisis se realiza ahora sobre la red local, el objetivo consiste
en identificar las causas que originan el comportamiento anormal descrito en
la sección referente al tráfico ICMP y eliminar sus nocivos efectos.
• ESTADÍSTICAS
i. Utilización
Los niveles de utilización más críticos se indican en la figura 2.11, como se
puede apreciar, la red atraviesa por un período de mayor actividad
observándose picos muy frecuentes que sobrepasan el 75% de utilización, el
promedio con toda seguridad igualaría al 40 o 45%.
Figura 2.11 Altos niveles de utilización revelan un período pico de operación de lared.
ii. Tamaño de Tramas
La figura 2.12 indica la cantidad de tramas -expresada como un porcentaje
del total (270891) observado- dentro de cada rango de longitudes. Los
tamaños se miden en Bytes y excluyen los campos preámbulo e inicio de
trama (8 Bytes).
Distribución de Tramas según el tamaño
• Menor a 64
D 64-127
• 128-255
B 256-511
• 512-1023
• 1024-1518
• Mayor a 1518
Menora64 64-127 128-255 256-511 512-1023 1024-1518 Mayora
1518
Figura 2.12 Porcentaje de tramas perteneciente a cada categoría.
El mayor porcentaje (38.813%) pertenece a tramas de longitudes
comprendidas entre los 64 y 127 Bytes. Un 25.227% corresponde a tramas
de 1024 a 1518 Bytes, es decir, el mayor número de tramas se encontraría
bordeando los límites -inferior y superior- permitidos por la topología de red
subyacente (Ethernet o 10BaseT), no obstante se observa la existencia de
"Tramas Cortas" que tienen un CRC válido pero su longitud es menor al límite
inferior permitido, un análisis más puntual revela que son originadas por una
sola estación (denominada Web-Server2).
• NIVELES BROADCAST/MULTICAST
Los niveles de difusión y multidifusión observados no representan mayor
amenaza contra el desempeño de la red (conforman el 0.22% y 0.03% de las
tramas observadas), sin embargo deben ser monitoreados y mantenidos.
• MAYORES USUARIOS
En la figura 2.13, se puede apreciar que las estaciones que con mayor
frecuencia tomaron el canal son el servidor de correo electrónico (DEC,
33.5%), el servidor Proxy (3com, 32.88%), y el enrutador (Motorola 23.5%),
identificados por la dirección MAC correspondiente.
Tramas Salientes100000-900008000070000-600005000040000-3000020000-10000
O• DEC03B6A3
D MotrlaQ6E3E4
• 3com 875E40
00508BD893A8
3Com7 700DB5
0050047940E9
• Broadcast
D 3Com740D59F
• NetBIOS
Figura 2.13 Mayores Usuarios según el número de tramas emitidas.
• MAYORES CONVERSACIONES
El análisis de las conversaciones entre las estaciones de red entrega los
resultados indicados por la figura 2.14, en ella se puede notar que la mayor
parte de las tramas capturadas pertenecen a comunicaciones entre los
servidores Proxy y de Correo Electrónico, esto es, un 40.66% de las tramas
observadas son originadas por uno de ellos y destinadas para el otro.
Con la información dada por las figuras 2.13 y 2.14 se deduce que las
estaciones más activas dentro de la red son los servidores de Correo y Proxy,
adicionalmente, la mayoría de las comunicaciones de red se dan entre ellos.
70
Teniendo esto en mente, se procede al análisis de los protocolos
involucrados en dichas comunicaciones.
Tramas Intercambiadas
20000-
• 3com 875E40-DEC 03B6A3
D Motrla06E3E4-DEC 03B6A3
• Motrla06E3E4-3com 875E40
ü 00508BD893A8-MotrlaQ6E3E4
• 0050047940E9-00508BD893A8
• MotrlaQ6E3£4-0050047940E9
D 00508BD893A8-3com 875E40
• 00508BD893A8-3Com7 700DB5
3Com7 700DB5-3Com7 40D59F
3Com7 700DBS-DeC 0386A3
Motrla06E3E4-Motrla06E3E4
MotrlaQ6E3E4-Broadcast
3Com7 7QODB5-NetBIOS
Figura 2.14 Mayores conversaciones según el número de tramas intercambiadas
• PROTOCOLOS OPERATIVOS
Como es de esperarse, para una red que es parte de la Internet, los
protocolos de transferencia de correo y de hipertexto, (SMTP, http ) ocupan
los primeros lugares: de un total de 270891 tramas capturadas, el 23.2%
corresponde a información de correo electrónico (SMTP), y el 22.92% a
transferencia de hipertexto (http), pero lo más notable es la presencia de un
alto porcentaje (43%), perteneciente a otro tipo de protocolos, que deben y
serán analizados con mayor detalle.
71
Protocolos
120000
100000
• DNS DHTTP IICMP INetBIOS_ BNetBIOS_ •NetBIOS_ DOthers BRIP O SMTPDGM U NS U SSN T
Figura 2.15 Distribución de los principales protocolos operando dentro de la red
i. NetBIOS y RIP
A pesar de su bajo porcentaje no se debe pasar por alto la existencia de
protocolos como el de sesión NetBIOS, que podrían resultar innecesarios en
la LAN, y en especial de aquellos que utilizan con cierta frecuencia el
esquema de difusión (Broadcast), puesto que demandan atención de todas
las estaciones a pesar de que la mayoría no está interesada en dicha
información. Tal es el caso de los protocolos RIP (empleado por el enrutador
para anunciar las redes a las que pertenece), Servicio de Nombres NetBIOS
(encapsulado sobre UDP).
ii. Otros Protocolos: RPC de Microsoft, DLSw de IBM
Un alto porcentaje de tráfico ha sido clasificado por el analizador dentro de la
categoría de "otros protocolos", la mayor parte pertenece al protocolo
MS/DCE RPC (Figura 2.16), utilizado por la aplicación MS-Exchange para
intercambiar información entre las estaciones denominadas Mail-Server y
Proxy-Server (192.168.150.10 y 192.168.150.12 respectivamente).
Adicionalmente, un volumen significativo del tráfico intercambiado entre estos
72
servidores consiste en información DLSw (Data Link Switching), protocolo
perteneciente a capa de enlace de datos de la arquitectura IBM SNA.
te-l
12345678¡910II12
[192 168.[192 USi[192 168¡[192.166'[192 168i[192 163[192 168[192 168[192.168¡[192 168i[192 168
150 10]150 12]150 10]150.12]ISO 12]150.10]150 10]150 12]150.10]150 12]150 10J
[192.168[192.168.'[192.168.¡[192.160.![192.160.'[192,168.[192 168.[192 168[192.168.
I [192.168I[192.168
150 12]150 10]150 12]150 10]150 10]150 12]150 12]150 10]150.12]150 10]150 12J
- HO Obje:t '"JIC specihed ir. objec' haadie1 : KO 'navte cali setantics reques'ec] - N07 Iiideiípoteiit req>¡est
O * toes ÍIOT suppcrt concuirent jiultiplmng1 - Pespond nth Fack PDUj = NCT C»:i:el Pendía; a' se:¡ri?r1 ; Last Fra=F.est
iKS/DCE RPC' Packed Data Repí^sentstion = ú x Ü G C Q ü H ܧHS/IX:E RPC. FragMtit Isr^ih « 112S]E/DCtRPC A- i th ra t i ^T icmlc tg th - 16SüS'DCE RFC i>l! r = 1:^7QüS'DCtRp: ¿ll-xation Ein t = üx 'J ' J i jOT^S^HS/DCERPC Pr«e¡itition Coiitex', Ident i f i s r = G x O O ü f lA MS/'CCE i?PC
0000000: 00 00 f8 03 b& a3 00 10 4b 37 Se 40 08 00 í .0 l£ K| * Z0000010- )J ^3 f : -;! . J . . . . t l i ICA-* I Yts I ;,0000020 ' i -, i J , U i ' u i i | i „ t
0000030: IP 4 n i i í ji 1 1 i 11 n i i u Ji, 'p i [ E pO O O O O i O : lt iri bd .1, n .n ' ü i D i O í U n i 1. u ttJUt V
0000060: b 6 a 3 M l £ QO 00 S 00 GO OJ14 Qü 30 BOn0000070: ái'iS a| pí •t'ai s5 ai aj 45 ,W tS iift '0000080 » a? li 80 bi If 81 09 00 Oí OS tt fff flü tS^OÍ W i *0000090 OS 00 Ofl 45 15 00 01 00 00 00 00 DO QO 00 C£T 00 . E
m <m tmjín pfl no
Fig. 2.16 Tráfico DCE RCP entre los servidores de correo y proxy, se observanpatrones del tipo solicitud-respuesta solicitud-respuesta.
Como se observa en la figura 2.16, el servidor Proxy realiza solicitudes RPC
y el servidor de correo le devuelve una respuesta por cada solicitud, un
patrón más óptimo devolvería varias tramas de tipo respuesta para cada
solicitud.
Las figuras 2.17 y 2.18 muestran otro tipo de tráfico cursado entre los dos
servidores, en este caso se trata del protocolo de conmutación a nivel de
enlace de datos, DLSw (Data Link Switching), las tramas intercambiadas son
del tamaño máximo permitido por la red local y contienen uno de veinte
fragmentos que componen cada mensaje original de 30572 Bytes.
í"
s
il¡
:22318 m| m122319122321Í22322i 22324122325J22327i 223281 22330Í 22331¡22333122335122336122337122339:22340122342122343•22345122346
:[192.168[192.168[192.168[192.168[192.168'[192. 168[192.168:[192.168;[192.1681(192.168:[192.168¡[192.168l[192.168.[192.168![192.168[192.168[192.168
11192.168i[192.16B
J22348 ¡[192.168!.-„ --X. , . .ts.
Hjjjjgjjll150.10]150.10]150.10]150.10]150.10]150.10]150.10]150.10]150.10]150.10]150,10]150.10]150,10]150,10]150.10]150,10]150.10]ISO. 10]150.10]150.10]f.iC. t ÍL". •
BjDLS: Vector Offset Lengthi fih TYTC.
1 § DLS: 0 0x0036: §DLS: 1 0x0036'••8 DIS: 2 0x0036
ÜDLS: 18 0x0036:'§DLS: 19 0x0036'-8 DIS: 20 0x0036Í*inrc. .
146014601460
146014601372
DstAteIIÍHHÍI
[192.168[192.168[192.168[192.168[192.168[192.163[192.168[192.168[192.168[192.168[192.168[192,168[192,168[192,168[192.168[192.168[192.168[192.168[192.168[192.168
-*/
Frame
223182231922321
223452234622348
BHHH150.12]150.12]150.12]150.12]150.12]150.12]150.12]ISO. 12]150.12]150,12]150.12]150.12]150.12]150.12]150.12]150.12]150.12]150.12]150.12]150.12]
¡Surm:PJH¡DIS:¡DIS:¡DIS:¡DLS::DLS:;DLS:;DLS:'DLS:ÍDIS:¡DLS:ÍDIS:¡DLS:¡DLS:¡DLS::DLS:IDLS:¡DLS:¡DLS:¡DLS:'DLS
•BUHÉContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation ofContinuation oíContinuation ofContinuation ofContinuation oíContinuation oí
'„ "„," -* -",
frame 22318frame 22318frame 22 3 13frane 22318frane 22318frane 22318frane 22318traite 22318trame 22318írame 22318frame 22318frame 22318frame 22318frame 22318frame 22318frame 2231Sframe 22318frame 22318frame 22318frame 22318
1\|
1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1460 Bytes1372 Bytes
»>"*»'
of dataof dataof dataof dataof dataof dataof dataof dataof dataof dataof dataof dataof dataof dataoí dataof dataof dataof dataof dataof data
ranü1514151415141514151415141514151415141514 .1514151415141514151415141514151415141426
"•••••§ DLS: 30572 bytes of re-assembled data.
Fig. 2.17 Ventana del decodificador de tramas, tráfico DLSw entre los servidoresproxy y de correo.
Las figuras 2.17 y 2.18 revelan la existencia de protocolos de red propietarios
de IBM (probable implementación NetBIOS) instalados en el servidor de
correo electrónico.
Adicionalmente se ha logrado detectar la presencia de tráfico MS/RPC entre
los servidores denominados como Web-Server y Web-Server2
(192.168.150.11 y 192.168.150.2 respectivamente), pero la diferencia radica
en que dicho tráfico no es encapsulado directamente sobre segmentos TCP,
sino más bien sobre unidades de sesión NetBIOS. No hay evidencia de
tráfico DLSw entre ellos.
74
I[192.166.150.10] [[19Z.168.1S0.12] ¡DIS: Continuation oí frase 22318; 1460 Bytes Of data T514'[192.168.150.10] ;[192.163 ISO 12] DLS Continuation o£ fraile 22316; 1460 Bytes qf data 1514
20 0x0036 1372 22348
J|DLS: 30572 bytes oE re-asseíibled data.J|DLS:-J|DIS' Data Link Switching ProtocolJJ DIS1§DIS: Versión - 31 (RFC 1795)ÜDIS' Header length = 172 bytes
f DLS: Message length - 57509DIS Renote data linh correlator = DOBF2EA3
HUÍS. Renote DIC port ID = 2DÁCEQA5§jDIS. Message type = 8D (Unknown)H DLS: Flow control = 87•®DIS. 1 = FCI (Indiestra)HOIS' 0. . . . = FCA (lío ack)HDIS; 111 = FCO (?- ffi'ndow operator)HDIS; Protocol ID = 165|S|DIS: Header nuiber = 165
t DIS. Circuit prioríty - 6 (?)DIS; Message type = 2 4
ÜDIS: Target = Station 616U7A5á567JfcDIS: Ongin = Station B5A52E21B191•5 DIS: Origin SAP • A7§DIS: Target SAP = ASÜDIS' Frane direction = 165 (?)ÜDIS; DIC header length = 40359J|DIS; Origin DIC port ID = A5A5F5F4^DIS: Origin data link correlator = 2EAS2DAC§DIS; Origin transport ID = EOA5F64D3 DLS, Target DIC port ID = DBA7A5AS.HDLS- Target data link correlator = 2065DOÁF-MDLS: Target transport ID * FE246181
Fig. 2.18 Ventana del decedificador de tramas, tráfico DLSw entre los servidoresproxy y de correo, (continuación).
Hasta aquí, se ha logrado identificar que las estaciones más activas son los
servidores Proxy y de Correo Electrónico, que la mayor parte de las
comunicaciones observadas se realiza entre dichas estaciones más activas
(mas no entre una estación y un ruteador, como es de esperarse en el caso
de una red que es parte de la Internet), y que existe un porcentaje
significativo de información perteneciente a "otros protocolos" (43%), en
consecuencia, podríamos concluir que aquel 43% se relaciona mayormente
con estas dos estaciones, es decir, los servidores de correo y proxy
probablemente están cursando una cantidad considerable de tráfico
innecesario debido al empleo de otro tipo de protocolos posiblemente
prescindibles.
75
iii. Tráfico ICMP
La presencia de tramas pertenecientes al protocolo ICMP puede evidenciar
algún tipo de problema o complicación. Los mensajes de control observados
pertenecen a los siguientes tipos:
Paquetes ICMP de destino inalcanzable: Se refieren a redes, hosts o
puertos de destino pertenecientes a estaciones de la Internet.
Paquetes ICMP de redirección: Revelan la existencia de
inconvenientes a nivel de enrutamiento.
Paquetes ICMP de solicitud de ECO: La figura 2.19 muestra un
excesivo número de paquetes ICMP generado por el servidor de correo y
dirigido hacia un host de la Internet, provocando una súbita elevación de
los niveles de utilización de la red local, y del enlace WAN (figura 2.7).
192.UB 150.10] ' 1 9 3 . 4 1 . 1 4 7 210 :1
8 ICMP: 65008 b?tes Qf
Figura 2.19 Tráfico ICMP observado dentro de la red local.
76
Como se aprecia en la figura 2.20, el paquete capturado número 36954 tiene
como origen la dirección IP 24.184.129.30, y encapsula un segmento TCP
destinado al puerto 80 (http) del servidor de correo, dicho segmento contiene
la instrucción http "GET", que ejecuta a su vez el comando:
PING.exe-T -L65000 -W500 193.41.147.210
Ubicándose previamente en el directorio \Winnt\System32\e trata de una intrusión externa cuyo objetivo no es otro que el de perjudicar
a la disponibilidad tanto de la red donde se originan los paquetes, de la red
que los recibe, y a la cadena de enlaces que las interconectan.
HTTP: Cfor t -2944 GET (QQ>scnpts/.,teG^af
36952369S336954136955369S&3695736958369E93696036961
PROXYIHAIL-SERVERÍHAIL-SERVER;PROXY¡PRQXYÍHAIL-SERVERPROXY
i HAIL-5EKVEK!PROXY![24,1S4.129.30]ÍKAIL-SERVERÍKAIL-SERVERiPROXYHÁIL-SERVER
TCPMS-Exchange: Infornation Store CAU (Do RPCMS-Exchange: Infornation Store RESP (Do RPC (Worker £MS-Exchange: Information Store CAU (Do RPC ((forker £
.150• 60!60
(Vorker £¡132214198
ÍOOOOQOO:30000010:30000020:30000530:00000040.00000050:00000060:00000070.00000080'00000090.OCOOOOaO.OOOOOObO:OOOOOOcO:OOOOOOdO:OOOOOOeO:DOOOOOÍO:
3e 06 e3 e4
3? bw 03 01 6? cf 5C54 20 00 ?3 63 11 ¿925 61 6& 2& ~¿<s 2i 7?6S &d 3í 32 2f 70 652b 2d 6c 2b 36 35 302b 31 39 33 2a 34 3143 54 S4 50 2Í 31 2e32 31 30 2e 32 31 3S
73 6S 72 2d 41 676c 61 2: 34 2e 30
Figura 2.20 Evento causante de la saturación del enlace WAN.
DIR
EC
CIO
NE
S Y
PR
OT
OC
OL
OS
AS
OC
IAD
OS
A C
AD
A E
ST
AC
IÓN
Nod
o/E
stac
ión
# 1 2 3 4 5 6 7
Nom
bre
Mai
l-Ser
ver
Web
-Ser
ver
Pro
xy-S
erve
rW
eb-S
erbe
r2JC
PIN
OE
SP
INO
ZF
INT
BV
Q
Dire
cció
n
Fís
ica
OO
OO
F803
B6A
300
508B
D89
3A8
0010
4B87
5E40
0050
0479
40E
900
20A
F70
0DB
500
20A
F40
D59
F08
003E
06E
3E4
Red
192.
168.
150.
1019
2.16
8.15
0.11
192.
168.
150.
1219
2.16
8.15
0. 2
192.
168.
150.
4
192.
168.
150.
1
Pro
toco
los
más
act
ivos
SM
TP
/H
TTP
/ / /
Net
BIO
Sy^
n §
/n
H §
/
H §
/
§/0
H §
Net
BE
UI
^L /^
/ / /
DLS
w
J
Otr
osD
CE
RP
C
DC
E R
PC
ICM
P,
RIP
nS
ess/
on (T
CP
)H
A
/am
e S
e/v/
ce (
UD
P)
§
Dat
agra
m (U
DP
)
78
REFERENCIAS CAPÍTULO II
[ChaOO] CHAPPELL, Laura; "Advanced Nerwork Análysis Techniqnes"
Podbooks, 2000.
|Cha99] (^HAPPEL, Laura; "Introduction lo Network Análysis" Podbooks
1999.
|Cha97] CHAPMAN, Alan; "Measuring Network Application Performance"
Wandel ct Golíerman 1997.
[Mck96a] McKELLAR, Brian; " Nerwork Baselining" Wandel & Golterman
1996.
|Mck96b| McKELLAR, Brian; "Analyzing the Analyzer: The Essential Featnres
for Protocol Anaiysis " Wandel & Golíerman 1996.
[Mey99J MEYER, Gary; "Whal is a Protoco/Analyzer? " Wandel & Golíerman
1999.
[W&G98J WANDEL £ GOLTERMAN; "Latí Troubleshootingandbaselining
guide" 1998.
[W&G97J WANDEL £ GOL TERMAN; "Choosing a baselining tool" 1997.
|WB95| WELLS, L; BARTKI, A; "Data Link Swilching: Swilch lo Swi/ch
Protocol" RL'C 1795 (Abril 1995).
CAPITULO III
3. OPTIMIZACIÓN DE LA EXTRANET
Las siguientes recomendaciones se proponen con base en el reporte de la
sesión de análisis practicada sobre la Extranet. A continuación se presentan,
según su ubicación dentro de la arquitectura implementada, las medidas y
acciones más relevantes que resultarán en un mejor desempeño de la red.
3.1 TRAMAS CORTAS
El reporte revela la existencia de tramas cuya longitud es menor al límite
inferior impuesto por la topología de red utilizada y tienen un CRC válido.
Todas las tramas cortas observadas dentro de la red local fueron generadas
por una sola estación (Web-server2), la causa de este comportamiento
inusual podría ser un defecto tanto de la tarjeta de red como de sus
consoladores (drivers).
Se recomienda comprobar la correcta instalación del hardware de red y la
utilización de los controladores (o drivers) específicos para la tarjeta de red
empleada en particular.
El reemplazo de la tarjeta de red se justifica siempre y cuando se tenga igual
comportamiento luego de haber revisado la instalación.
Dentro de la red local, a nivel de la capa Host a Red se debería evaluar la
posibilidad de sustituir el cableado UTP categoría 3 por el de categoría 5, con
miras a una migración futura hacia tecnologías de alta velocidad.
Mantener el orden y la correcta identificación del cableado facilita la gestión
de las redes y resulta beneficioso pues el crecimiento de éstas es ordenado y
controlado.
Sil
3.2 RUTAS
Existen paquetes ICMP de redirección, enviados por el enrutador hacia el
servidor de correo para indicarle que puede llegar a las redes internas (SINEL
y Corporativa) directamente a través del servidor proxy en lugar de requerir la
intervención del ruteador, o dicho de otra manera, el ruteador le informa al
servidor que dentro de la misma red local existe una pasarela (gateway) que
provee una mejor ruta hacia la red deseada, particularmente esto implica un
salto menos en la trayectoria.
La existencia de este salto adicional implica el consumo de recursos del
enrutador, lo cual puede influir negativamente durante períodos de alta
utilización de la red (pérdida de paquetes, retransmisiones, etc).
Adicionalmente se ha observado que en el caso del envío de datos hacia la
red corporativa (192.168.65.0), los paquetes son encaminados por el
enrutador a través del enlace WAN, consumiendo de forma innecesaria los
siempre escasos recursos de la subred de comunicaciones (se han recibido
respuestas ICMP enviadas desde UUNET1).
Se recomienda evaluar la inclusión de dos entradas dentro de la tabla de
ruteo local del servidor de correo electrónico, mediante la ejecución de las
siguientes instrucciones desde la línea de comandos:
ROUTE acfcí 132.1.0.0 mask 255.255.0.0 192.168.150.12
ROUTE add 192.168.65.0 mask 255.255.255.0 192.168.150.12
Esto implica un salto menos en el trayecto hacia redes internas y la liberación
de recursos de la subred de comunicaciones.
Dentro de la Extranet se tiene un esquema de enrutamiento estático, la
presencia de información correspondiente a protocolos de enrutamiento
(como RIP) implica el consumo de recursos dentro de la red.
Punió de prcscncin (PoP) p;u;i el ISP local
81
3.3 TRAFICO INNECESARIO
Los niveles extremos de utilización observados dentro de la Extranet, tanto a
nivel local como dentro del enlace WAN, no justifican de ninguna manera la
ampliación de este último ni tampoco la migración inmediata hacia
tecnologías LAN de alta velocidad. Los problemas de comunicación que
presenta la Extranet en parte se deben a la presencia de protocolos activos
que consumen recursos y podrían resultar innecesarios.
El reporte de la sesión de análisis evidencia la existencia de información
perteneciente al protocolo de enrutamiento RIP, la cual resulta ser
innecesaria debido a que, como se mencionó en la sección anterior, nos
encontramos ante una subred de comunicaciones formada sólo por un enlace
punto-a-punto, en la que se ha implementado un sistema de enrutamiento
estático. Deshabilitar RIP en el ruteador resultaría beneficioso para el
desempeño del enlace, sobretodo durante períodos pico de utilización.
Se recomienda evaluar la necesidad del protocolo Microsoft DCE RPC, en
caso de no poder prescindir de éste se debe analizar la posibilidad de
mejorar los patrones de tráfico utilizados (figura 2.16).
La existencia de tráfico correspondiente al protocolo DLSw de IBM resulta
extraña e innecesaria puesto que la arquitectura implementada corresponde
al modelo de referencia TCP/IP, mas no a SNA de IBM. Como se define en el
RFC 1795, DLSw (Data Link Switching) consiste en un mecanismo de
encaminamiento para los protocolos IBM SNA e IBM NetBIOS, provee
conmutación a nivel de la capa de enlace SNA y encapsulación en TCP/IP
para transporte sobre la Internet. Se recomienda revisar cuidadosamente la
configuración de red dentro del servidor de correo ( de fabricación IBM ) y
prestar especial atención en los parámetros referentes a NetBIOS y NetBEUI.
Prescindir del uso de los protocolos DCE RPC de Microsoft y DLSw de IBM
implicaría una reducción de la carga a nivel LAN en un 40%
aproximadamente, de igual manera, eliminar NetBIOS, NetBEUI, y RIP
resultaría en un decrecimiento significativo en los niveles de difusión y
multidifusión.
Et reporte de análisis refleja que la saturación existente dentro del enlace
WAN se origina por la presencia de tráfico ICMP, particularmente se trata de
mensajes de solicitud de eco.
Como primera acción se implementa un filtro dentro del ruteador local para
impedir la salida de paquetes solicitud de eco ICMP originados en ei servidor
de correo. Una vez liberado el enlace queda reestablecido el servicio de
Internet, mientras se programan sesiones de análisis en la red local con el
objeto de encontrar el origen de este tipo de tráfico, eliminarlo y/o prevenirlo
(figura 2.20).
Las sesiones de análisis practicadas a nivel local indican que la congestión
existente en el enlace hacia el ISP no refleja la necesidad de ampliación sino
el resultado de una intrusión externa, esto señala inequívocamente la
vulnerabilidad de la Extranet, solucionar el problema de aquel tipo particular
de intrusiones liberará recursos a nivel LAN y WAN, medidas preventivas
podrían consistir en la implementación de un filtro dentro del ruteador para
que no se permitan conexiones TCP destinadas al puerto 80 dentro del
servidor de correo o bloquear el servicio http dentro de este servidor y demás
estaciones que no almacenen páginas WEB.
Estas medidas evitarán temporalmente las intrusiones hasta la
¡mplementación de un plan integral de seguridad para la Extranet, que incluya
mecanismos para reducir la probabilidad de que ocurran varios posibles tipos
de intrusión o ataque.
La optimización a nivel de seguridades representa la mayor labor a realizarse
dentro de la Extranet y se analizará en las secciones posteriores.
3.4 SEGURIDADES EN REDES: DEFINICIONES Y CONCEPTOS
La seguridad dentro de una red es un tema muy amplio, mientras más
usuarios ingresan a la Internet, y más compañías expanden sus redes, el reto
de brindar seguridad a redes internas se vuelve cada vez más difícil fCiscl],
La seguridad de las redes se ha vuelto una preocupación primordial para
compañías alrededor del mundo, más aún, la extensa disponibilidad de
información y herramientas necesarias para penetrar las seguridades de
redes corporativas ha incrementado esta preocupación.
Es por esto que el tema será tratado en dos partes: fa presente sección
describe de manera general el problema de la seguridad en redes de datos e
indica brevemente los principales conceptos y definiciones concernientes a
intrusiones y ataques, mientras que el capítulo 4 se enfoca en las
recomendaciones y propuestas de seguridad para la Extranet.
3.4.1 DEFINICIONES
3.4.1.1 Seguridad Computacional
Una definición de seguridad computacional se basa en el nivel alcanzado de
confidencialidad, integridad y disponibilidad en un sistema de cómputo2
[San95]. Es decir, un sistema seguro protege sus datos y recursos del acceso
no autorizado, manipulación y denegación de uso.
3.4. / . / ./(\Mifidendalidcid
Confidencialidad implica el acceso a información sólo por quienes han sido
autorizados para ello.
3.4.1.1.2 Integridad
Integridad requiere que la información no pueda ser alterada por accidentes o
por intentos maliciosos.
Russcll. D; Giingeini. T; "Computer Sccurity Bnsics"
S4
3.4.1.1.3 Disponibilidad
Disponibilidad quiere decir que el sistema permanece operando sin
degradación del acceso ni de los recursos que provee a usuarios autorizados
cuando éstos lo necesiten.
3.4.1.2 Amenazas
Los primeros estudios definen una amenaza como la posibilidad potencial de
una intrusión, esto es, de un intento deliberado, no autorizado, para acceder
a cierta información, manipular cierta información, o volver a un sistema
inoperable o poco confiable3 [San95],
3.4.1.3 Intrusiones
Estudios posteriores tratan a las intrusiones como un conjunto de acciones
que intentan comprometer la confidencialidad, integridad, o disponibilidad de
un recurso, esta definición es dada por Heady, R; Luger, G; Maceaba, A;
Servilla, M; "The Arquitecture of a Network Leve/ intrusión Detection System"
[San95].
3.4.1.4 Ataque y Penetración3
Se describe un "ataque" como una formulación específica o ejecución de un
plan para llevar a cabo una intrusión, y cuando un ataque es exitoso se
denomina "penetración", distinguiéndose tres tipos:
3.4. ¡. 4.1 Penetraciones Internas
Aquellas llevadas a cabo por usuarios no autorizados de un sistema.
3.4.1.4.2 Pene I me iones ¡memas
Efectuadas por usuarios autorizados del sistema, pero que no tienen
autorización para los datos o recursos comprometidos
1 Andcrson. J: "Computer Seauil\l Moniloring ¡ind Survcillance"
3.-1.1.4.3 Ahitsostk' Anforiíftit/
Definidos como una mata utilización de información autorizada y otros
recursos por parte de usuarios autorizados para fines diferentes.
4. PLAN DE SEGURIDAD PARA LA EXTRANET
4.1 GENERALIDADES
Un método básico propuesto por PITES, M; KRATZ, P; BREBNER, A;
"Control and Secutityof Computer Information Systems" 1989, comprende los
siguientes pasos [Fra97]:
- Identificación de los activos a proteger.
- Determinación de las amenazas y de su probabilidad.
- Implementación de medidas de protección costo-efectivas.
- Revisión continua del proceso, acondicionamiento a cada nueva
debilidad hallada.
4.2 VALORACIÓN DE RIESGOS
La valoración de riesgos tiene que ver con los dos primeros pasos
mencionados anteriormente: la determinación de qué se necesita proteger,
contra qué y cómo protegerlo. Consiste en examinar todos los riesgos y
clasificarlos por orden de severidad.
Existen dos elementos básicos dentro de la valoración de riesgos que se
cubrirán brevemente:
- Identificación de bienes.
- Identificación de amenazas.
Para cada uno de los bienes, las metas fundamentales de seguridad son
confidencialidad, integridad y disponibilidad. Cada amenaza se examina
tomando en cuenta la forma en que pueda afectar a estas áreas.
88
4.2.1 IDENTIFICACIÓN DE BIENES
Mediante un listado de los principales elementos que podrían ser afectados
como resultado de un problema de seguridad:
- Hardware.
- Software.
- Datos
- Documentación.
4.2.2 IDENTIFICACIÓN DE AMENAZAS
Luego de identificados los bienes que requieren protección, es necesario
identificar las amenazas para estos bienes, y examinarlas para determinar los
daños potenciales.
4.2.1.1 Amenazas Contra la Confidencialidad
La información confidencial de un sistema se puede encontrar en dos formas:
residente en una unidad de almacenamiento, como un disco duro, o
transitando a través de! cableado de red en forma de paquetes de datos,
estos dos estados presentan múltiples oportunidades para ataques
originados tanto por usuarios internos como por aquellos en la Internet.
Entre los métodos más comunes de ataque que comprometen la
confidencialidad de la información dentro de la red se encuentran [Cisc2J:
- Ataques por Monitoreo de Red
- Falsificación IP
- Ataques de Contraseña
Distribución de Información Critica
- Ataques por intermediarios
-/.2.1.1.1 Attitjncs por Monitoreo tic Red
Varias aplicaciones de red distribuyen sus paquetes en forma textual, es
decir, la información enviada a través de la red no ha sido codificada o
encriptada y puede, por esta razón, ser procesada y comprendida por
cualqu
de la I
como
ograma capaz de recoger los paquetes de la red; actualmente los
o requieren de un amplio conocimiento para desarrollar estos
ebido a que se encuentran disponibles en gran cantidad dentro
, tanto en versiones de distribución libre (freeware y Shareware)
ersiones demostrativas (demos), éstos son los denominados
de paquetes" (packet sniffers).
Como
interfaj
clave
usuarH
ixplica en la sección 2.1.2.1, este tipo de software utiliza una
red en modo promiscuo y puede proporcionar a su usuario de
comprensible y a menudo sensible, un nombre de cuenta y su
;eso. Un problema serio resulta ser el hecho de que a menudo los
futilizan sus nombres de cuenta y claves de acceso para vanas
5. En este caso el objetivo del ataque es el de ganar acceso a
crítica.
4.2.1.
Un at
red p
rango!
'es por i'alsificación ¡P
falsificación IP ocurre cuando una máquina atacante fuera de la
ser un computador fiable, usando una dirección tP dentro del
jrecciones de la red interna o una IP externa autorizada por la red,
la cual se provee de acceso a ciertos recursos de la red
4.2.1. yBWM/í///c'v Je (\nttru.wña
Pued^Batiplementarse utilizando varios métodos diferentes, incluyendo
• fuerza bruta, por programas denominados "Troyanos",
falsificaran de e-maii o mediante rastreadores de paquetes. A pesar de que
estos •VJos pueden procurar nombres de cuenta y claves, los Ataques de
se refieren normalmente a intentos repetidos para identificar una
cuentJHW clave, aquellos intentos repetidos se denominan ataques por
fuerza bruta.
Estos ataques a menudo se efectúan utilizando un programa que corre a
través de la red e intenta acceder a un recurso compartido, como un servidor.
Cuando un atacante gana acceso a un recurso, tiene los mismos derechos
que el usuario cuya cuenta ha sido comprometida, y si la cuenta tiene
9(1
suficientes privilegios, el atacante puede crear una puerta para futuros
accesos sin preocuparse por el estado de la cuenta comprometida o por
cambios futuros de la contraseña.
4. 2. /. /. 4 Divulgación de Información (V/'//ft/
Controlar la distribución de este tipo de información es el corazón de un plan
de seguridad de red. La mayoría de ingresos no autorizados a redes
corporativas son causadas por ex-empleados o trabajadores descontentos
que podrían distribuir información a los competidores.
4.2.1.1.5 A laques de Intermediarios
Requieren que el atacante tenga acceso a los paquetes que cruzan las redes:
como ejemplo, un empleado del ISP que pueda ganar acceso a todos los
paquetes transferidos entre la red del cliente y cualquier otra red dentro de la
Internet.
Los posibles usos de tales ataques son, robo de información, piratería de una
sesión saliente para ganar acceso a los recursos de la red interna, análisis de
tráfico para derivar información sobre la red y sus usuarios, denegación de
servicio, corrupción de información transmitida e introducción de información
4.2.1.2 Amenazas Contra la Integridad
La prioridad más alta radica en la protección de la información, y
salvaguardar la integridad de la red es crítico en cuanto a la protección de la
información que ella contiene. Una brecha en la integridad de la red puede
ser extremadamente costosa en tiempo y esfuerzo, y puede abrir múltiples
vías para ataques prolongados.
Entre los más comunes métodos de ataque utilizados para comprometer la
integridad de las redes se encuentran:
- Rastreadores de paquetes
- Ataques de contraseña
- Ataques a nivel de capa Aplicación
Al considerar la protección de una red, se debe preocupar en mantener la
integridad tanto del hardware como del software de red, de cualquier otro
recurso, e incluso de la propia reputación del administrador. La integridad
involucra identidades verificables de usuarios y computadoras, operación
apropiada de los servicios provistos por la red, y un desempeño óptimo de la
red. Todas estas preocupaciones son importantes en el mantenimiento de un
ambiente de red productivo.
4.2.1.2. / Ataques por Rastreadores de Paquetes
Como se describió en la sección -(.2.1.1.1, el uso de este tipo de programas
puede revelar información confidencial, como nombres de cuentas y sus
claves de acceso. En el peor caso, un atacante podría ganar acceso a una
cuenta a nivel de sistema, mediante la cual podría crear una cuenta oculta
que le proporcionará acceso ilimitado a la red y sus recursos. Con tales
privilegios el atacante estaría en capacidad de modificar archivos críticos del
sistema, como la clave de acceso a la cuenta de "administrador", la lista de
servicios y permisos en servidores de archivos, la información de acceso para
otros computadores que posean información confidencial, etc.
Los rastreadores pueden otorgar información referente a la topología de la
red que muchos atacantes podrían encontrar útil, como el número de
máquinas en la red, qué computadores proveen tales servicios, qué
máquinas tienen acceso a qué otras. Adicionalmente, un rastreador puede
ser modificado para interferir o cambiar la información contenida en un
paquete.
4.2. /. 2.2 Ataques de contraseña
Al igual que con los rastreadores de paquetes, se pueden obtener cuentas de
acceso privilegiadas y sus contraseñas para realizar cambios o
modificaciones sobre archivos críticos, por ejemplo, un atacante podría
modificar las tablas de enrutamiento de la red, asegurándose de que todos
los paquetes sean transmitidos al atacante antes de ser transmitidos a su
destino final, en tal caso el atacante puede monitorear todo el tráfico de la red
convirtiéndose efectivamente en un "intermediario".
4.2.1.2.3 Ataques a nivel Je aplicación
Pueden implementarse utilizando varios métodos, uno de los más comunes
consiste en la explotación de vacíos o debilidades bien conocidas del
software que normalmente se encuentra dentro de los servidores, (Sendmail,
FTP, etc), explotando estas debilidades el atacante puede ganar acceso a un
computador con los permisos de la cuenta que corrió la aplicación, que
usualmente es privilegiada, a nivel de sistema [Ciscl].
4.2.1.3 Amenazas Contra la Disponibilidad
Existe otro tipo de ataques que a diferencia de los anteriores, no buscan
ganar acceso a la red y a su información, más bien procuran hacer que un
servicio o recurso no esté disponible para su normal uso, éstos son
denominados como ataques de "Denegación de Servicio" o DoS (del inglés:
Denial of Service).
El principal objetivo de los ataques DoS consiste en impedir que sus victimas
accedan a un recurso en particular. Se caracterizan por un intento explícito
de los atacantes para impedir que usuarios legítimos de un servicio tengan
acceso al mismo. Como ejemplos se encuentran [CER]:
- Intentos para "inundar" una red e impedir el flujo de tráfico legítimo.
- Intentos para interrumpir o cortar conexiones entre dos máquinas
con lo que se impide el acceso a un servicio.
- Intentos para impedir el acceso de un individuo particular a cierto
servicio.
- Intentos para interrumpir el servicio a un sistema o persona
específicos.
La mayoría de éstos se ejecutan en contra de la conectividad dentro de una
red, la idea es atentar contra la disponibilidad al impedir las comunicaciones
entre estaciones de una red, o entre redes. Muchos ataques de este tipo
pueden ser ejecutados utilizando recursos modestos, como un computador
personal poco actualizado y un modem lento, que podrían deshabilitar
máquinas más sofisticadas o incluso redes enteras.
Existen diferentes métodos de ataque que pueden derivar en una condición
de denegación de servicio, y se han clasificado según el procedimiento
utilizado para lograr dicha condición en:
Consumo de recursos escasos, limitados o no renovables.
Alteración o destrucción de información de configuración.
Destrucción física o alteración de componentes de red.
-1.2.1.3.1 Consumo de Recursos Limitados
Las computadoras y sus redes necesitan de ciertos elementos para operar,
tales como: Capacidad de comunicación disponible, memoria y espacio en
disco, tiempo de CPU, estructuras de datos, acceso a otras computadoras y
otras redes, etc. Atentar contra estos elementos afectaría la disponibilidad de
un servicio, de un host o de toda la red.
Entre las formas más comunes de ataque utilizadas para comprometer la
disponibilidad dentro de una red valiéndose del consumo de recursos
escasos o limitados están:
a ATAQUES POR INUNDACIÓN SYN Y POR DIRECCIONES FALSAS
Un ataque por "Inundación SYN" ( o SYN fíood attack), es aquel donde el
intruso inicia el proceso para establecer una conexión TCP con la estación
víctima, pero no lo completa, dejando la conexión en un estado denominado
como "conexión medio abierta", mientras tanto, la máquina víctima ha
reservado, de entre un número limitado, una estructura de datos requerida
para completar la conexión inminente, como resultado, conexiones legítimas
son denegadas mientras la víctima está esperando completar las falsas
conexiones "medio abiertas". En este caso, el éxito del ataque no depende de
la habilidad de un atacante para consumir toda la capacidad de la red, el
intruso está consumiendo estructuras de datos envueltas en el
establecimiento de una conexión, lo cual implica que el intruso pueda ejecutar
este ataque sobre una máquina dentro de una red rápida, utilizando una
conexión por marcación telefónica (dial-up).
Cualquier sistema conectado a la Internet, que provea servicios de red
basados en TCP (Web, FTP, Mail), está potencialmente sujeto a este ataque.
En la sección 1.1.1.3.1, se explica el acuerdo de tres vías, método utilizado
para lograr una conexión TCP entre dos estaciones, como se observa en la
figura 1.5 el potencial de sufrir un abuso aumenta cuando el sistema servidor
(B) ha enviado hacia el cliente (A), un reconocimiento (SYNy, ACKx+i) a la
petición de conexión (SYNX), pero aún no ha recibido de éste, el último
mensaje del acuerdo de tres vías (ACKy+i), es decir, la conexión permanece
en un estado de "medio abierta". El servidor ha incorporado dentro de su
memoria de sistema una estructura de datos reportando cada conexión
pendiente, esta estructura es de tamaño finito y puede desbordar al crearse
intencionalmente muchas conexiones parcialmente abiertas, resultando en
una incapacidad por parte del servidor para aceptar nuevas conexiones.
La creación de conexiones medio-abiertas se cumple fácilmente con la
falsificación de direcciones IP. El sistema atacante envía mensajes SYN al
servidor del sistema víctima, éstos aparentan ser legítimos, pero el hecho es
que relacionan a un cliente dentro de un sistema incapaz de responder a los
mensajes SYN-ACK, lo cual implica que el último mensaje del acuerdo de
tres vías jamás será enviado al servidor víctima. La estructura de datos para
conexiones medio-abiertas en el servidor eventualmente se llenará y el
sistema será incapaz de aceptar cualquier nueva conexión entrante hasta
que la tabla se vacíe. Normalmente existen temporizadores asociados a una
conexión medio abierta, una vez expirados, las conexiones se liberan y el
sistema se recupera, en todo caso, el atacante simplemente puede enviar
paquetes falsos solicitando continuamente nuevas conexiones TCP, más
rápido de lo que expiran los temporizadores en el sistema víctima.
La víctima de este ataque tendrá dificultad para aceptar nuevas conexiones,
el ataque no ha afectado conexiones entrantes previas ni tampoco la
capacidad para originar conexiones salientes. En todo caso el sistema podría
agotar su memoria, fallar, o volverse inoperable. La localización del sistema
atacante se dificulta debido a que las direcciones de origen dentro de los
paquetes de solicitud de conexión (SYN) son a menudo poco fiables
b. ATAQUES CONTRA PUERTOS UDP
Los intrusos pueden valerse de los propios recursos o servicios de las
víctimas para usarlos en su contra, un ejemplo de ello consiste en el ataque
DoS por Puerto UDP, que consiste en la creación de una tormenta de
datagramas UDP, tanto dentro de un sistema como entre dos sistemas. Un
ataque dentro de un host causa un pobre desempeño del mismo, un ataque
involucrando a dos hosts puede causar congestión extrema en la red que los
comunica a más de afectar de manera adversa al desempeño de los hosts.
Cuando se establece una conexión entre dos servicios UDP, cada uno de los
cuales entrega una respuesta o resultado, los dos servicios pueden producir
un número muy alto de paquetes que podría conducir a una denegación de
servicio en la(s) máquina(s) donde los servicios son ofrecidos. Cualquier
persona con conectividad a la red puede lanzar el ataque, no se necesitan
cuentas de acceso. Como ejemplo, al conectar el servicio de "echo" en un
host, con el servicio "chargen", en el mismo o en otro host, las máquinas
involucradas serían puestas fuera de servicio de manera efectiva debido al
número excesivamente alto de paquetes producidos, adicionalmente, si una o
más parejas de hosts se conectan de dicha manera, la red interventora puede
también congestionarse y denegar el servicio a todas las estaciones cuyo
tráfico atraviesa dicha red.
c. INUNDACIONES ICMP
Mediante la generación de gran cantidad de paquetes enviados hacia la red,
un intruso puede ser capaz de consumir toda la capacidad de comunicación
disponible, en principio pueden ser cualquier tipo de paquetes, pero
típicamente se trata de paquetes de eco ICMP, más aún, el intruso no
necesita operar desde una sola máquina, podría coordinar o asociar varias
máquinas en diferentes redes para conseguir el mismo efecto [CER].
Dentro del caso estudiado y documentado en capítulos anteriores, se logró
identificar el patrón utilizado para efectuar un ataque DoS, resultante en el
consumo total de la capacidad de comunicación disponible. En resumen, el
sistema atacante realiza una conexión TCP con el puerto 80 (http) de un
servidor de correo electrónico, mediante comandos http se ubica en el
directorio apropiado, ejecuta el comando Ping de manera continua y
empleando paquetes de máxima longitud consigue dificultar las
comunicaciones dentro de la red local e impide cualquier comunicación con
redes externas pues el único enlace se encuentra totalmente saturado.
Adicionalmente, el host cuya dirección IP coincida con la dirección de destino
especificada al ejecutar el comando Ping, se convierte en una segunda
victima, para ella, el atacante aparecerá como el servidor de correo, y si el
administrador de el segundo sistema afectado se inclina por filtrar todo el
tráfico proveniente del aparente originador del ataque, resultaría en una
denegación de servicio para un legítimo sistema final no hostil.
Una variante de la inundación ICMP consiste en destinar los paquetes de eco
para la dirección de broadcast de una subred (por ejemplo 10.255.255.255),
una inundación de estos paquetes consumiría todos los recursos disponibles
dentro de un sistema final [Gre].
Otra forma de ataque se basa en el hecho de que algunos sistemas
reaccionarían de forma impredecible al recibir paquetes IP
sobredimensionados (sección /././.2. /), y se han utilizado paquetes emitidos
por el comando ping para provocar reacciones como falla, congelamiento o
reinicio del sistema, resultando en denegación del servicio fCRR].
d. ATAQUES CONTRA OTROS RECURSOS
A más de la capacidad de comunicación, intrusos podrían consumir otros
recursos necesarios para la operación de los sistemas, como ciertas
estructuras de datos, que se agotan gracias a la creación de programas
simples que de manera repetitiva crean copias de si mismos, intrusos podrían
intentar consumir espacio de disco en otras formas, como la generación de
un número excesivo de mensajes de correo electrónico, generación
intencional de errores que se registren en memoria, colocación de archivos
en áreas ftp anónimas. En general, cualquier cosa que permita el
almacenamiento de datos en disco puede ser utilizada para ejecutar un
ataque DoS si no existen limitaciones en cuanto a la cantidad de datos
permitida para almacenamiento. Un ejemplo de lo anterior consiste en el
"Bombardeo de e-mail y correo no deseado" (e-mail spamming)". El
bombardeo de e-mail se caracteriza por el envío repetitivo de un mensaje de
correo electrónico hacia una dirección en particular; el envío de correo no
deseado es una variante del bombardeo, "spamming" se refiere al envío de
correo hacia cientos o miles de usuarios (o listas que se extienden a ese gran
número de usuarios). Tanto el bombardeo como el spamming se pueden
combinar con falsificación de correo (e-mail spoofing), que altera la identidad
de la cuenta que envía el mensaje, dificultando la identificación del origen de
los mensajes.
Cuando grandes cantidades de mensajes son dirigidos hacia o a través de un
solo sitio, éste podría sufrir una denegación de servicio por pérdida de
conectividad de red, fallas del sistema o del servicio, debidos a:
- Conexiones de red sobrecargadas.
- Uso de todos los recursos disponibles del sistema.
- Llenado del disco como resultado de múltiples artículos recibidos.
•4.2. i. 3.2 Alteración o destrucción de información Je configuración
Un computador configurado de manera inapropiada podría funcionar mal o
simplemente no operar. Un intruso podría llegar a alterar o destruir
información de configuración impidiendo el uso del computador o de la red,
cambios en la información de enrutamiento dentro de los ruteadores podría
anular la red, igualmente modificaciones en los registros de los servidores
podrían desactivar ciertas funciones.
4.2.1.3.3 Destrucción I<isica o Alteración Je los Componentes Je ReJ
La preocupación principal con este tipo de ataque es la seguridad física.
Debe haber una prevención contra acceso no autorizado a computadores,
ruteadores, centros de cableado, segmentos de backbone, unidades de
energía y ventilación, y cualquier otro componente crítico de la red.
La seguridad física es el componente primordial para protección contra
muchos tipos de ataque a más del DoS [CER].
4.3 DESARROLLO DEL PLAN DE SEGURIDAD
Una vez cubiertos los dos primeros pasos se procede a la elaboración del
plan de seguridad como preparación para la implementación de las medidas
de protección [Fra97].
4.3.1 ARQUITECTURA
Define una estructura básica y segura, sobre la cual se agregarán
herramientas adicionales que aumentarán el nivel de seguridad de la red
según sus necesidades, estas herramientas se analizarán brevemente en las
secciones 4.3 1.3 y 4.3.2.
4.3.1.1 Objetivos
V. 3.1.1.1 Planes de Seguridad (\)ntplelamenle Definidos
Un plan de seguridad comprensivo debe ser definido y desarrollado como un
marco de amplios procedimientos dentro del cual encajarán las políticas
específicas de seguridad, estas políticas individuales deben ser consistentes
con la arquitectura global de segundad.
Dentro del plan de seguridad se definen:
- Servicios de red a ser ofrecidos: Proxy http, E-mail, WWW.
- Áreas de la organización que proveerán los servicios: Extranet.
- Acceso autorizado a los servicios: Usuarios internos deben acceder
mediante la red local. Los usuarios WWW pueden ser externos, en
este caso accederán únicamente a este servicio mediante la red
extendida. Se permite tráfico SMPT entrante y saliente sólo para el
servidor de correo.
- Administración de los servicios: A cuenta del administrador de la
red.
4.3.}. 1.2 Separación de Servicios
De ser posible, los servicios proporcionados a usuarios deben correr por
separado, en máquinas diferentes cuya única labor sea la de proporcionar un
servicio específico.
Servicios esenciales para la seguridad de la red, o para su adecuada
operación se colocarían en una máquina dedicada con acceso limitado, en
lugar de hacerlo en aquella que provea un servicio (o servicios)
tradicionalmente poco seguro o que requiera gran accesibilidad por parte de
tos usuarios.
4.3. LI.3 Denegar Todo Permitir Todo
Existen dos corrientes diametralmente opuestas que se pueden adoptar al
definir un plan de seguridad:
- Denegar todo aquello que no ha sido explícitamente permitido.
- Permitir todo aquello que explícitamente no ha sido denegado.
El primer modelo consiste en desactivar todos los servicios para luego
activarlos de manera selectiva, uno a uno, según sean necesarios, lo cual
puede hacerse a nivel de red o aplicación; este modelo generalmente es más
seguro y requiere de mayor trabajo. El segundo modelo es más fácil de
implementar, pero menos seguro; todos los servicios y protocolos son
permitidos, serán restringidos o desactivados a la medida en que las fallas en
la seguridad se vuelvan apreciables.
El segundo método puede ser aplicado para el tráfico entre las estaciones de
trabajo para uso general en redes que están detrás de la Extranet, mientras
que la adopción del primero para el tráfico desde y hacia la Internet, e incluso
dentro de la misma Extranet, proporcionará un mejor nivel de seguridad.
4.3.1.1.4 Nuevos Servicios
Cada vez aparecen nuevos servicios, que deberán ser evaluados con una
actitud escéptica para determinar si en realidad son necesarios. La
10(1
complejidad en seguridad puede crecer de manera exponencial según el
número de servicios ofrecidos.
4.3.1.2 Configuración de Red y de Servicios
-/. 3. /. 2.1 Protección de Iti Infraestructura
La infraestructura comprende tanto los hosts de la red como la red misma, es
decir, equipos de comunicación, de interconexión, líneas de transmisión;
adicionalmente incluye la administración de red {SNMP), servicios {WWW,
DNS) y seguridad (autenticación, restricciones de acceso).
4. 3.1.2.2 Protección Je la Red
Las redes son vulnerables a una variedad de problemas, el más frecuente
consiste en un ataque DoS.
En cuanto a los ataques por inundación SYN y por direcciones falsas, a pesar
de que no existe una solución aceptada de manera general, una
configuración apropiada dentro del enrutador puede reducir la probabilidad de
que sea un elemento de la propia red quien origine uno de estos ataques.
Se puede reducir el número de paquetes falsificados que entran y salen de la
red, el mejor método consiste en instalar un ruteador capaz de restringir el
ingreso por la iníerfaz externa de paquetes que tengan direcciones de origen
de la red interna, adicionalmente, que pueda filtrar los paquetes salientes
cuya dirección origen pertenezca a una red diferente a la interna.
La aplicación de este tipo de filtros no sólo reduce la probabilidad de recibir
un paquete con dirección IP falsa, sino que también previene que un ataque
basado en falsificación de direcciones IP sea lanzado desde la Extranet. A
pesar de esto, la combinación de estos filtros no evitará todos los ataques por
inundación SYN, pues los atacantes externos podrían falsificar direcciones de
otras redes externas y los internos aún podrán lanzar ataques falsificando
direcciones internas, por esta razón se alienta a todos los ISPs para que sean
ellos quienes implementen este tipo de filtrado, es decir, pongan en práctica
101
las recomendaciones incluidas en el RFC 2827 fFSOO]. En resumen, se
recomienda filtrar:
• A la entrada de la interfaz externa, esto es viniendo desde la
Internet hacia la red, paquetes con las siguientes direcciones de
origen:
- Redes de Difusión: 0.0.0.0 y 255.255.255.255
- Redes Locales: direcciones de las redes internas.
- Direcciones reservadas para Redes Privadas (tabla 1.3)
10. 0.0.0 - 10.255.255.255 10 / 8
172. 16.0.0 -172. 31.255.255 172.16 / 12
192.168.0.0-192.168.255.255 192.168 /16
• A la entrada de la interfaz interna, paquetes con direcciones de
origen pertenecientes a:
-Redes Externas
-Redes Privadas, que no sean utilizadas por la red
interna.
Para reducir el riesgo de sufrir ataques contra puertos UDP, la
recomendación apunta hacia la anulación de los servicios echo y chargen
(sección 4.2.1.3.1 literal b. ATAQUES CONTRA PUERTOS UDP) en los hosts,
así como a su filtrado dentro del ruteador o firewall (puertos TCP/UDP 7 y
TCP/UDP 19 respectivamente).
Consecuentemente con el modelo adoptado en 4.3.1.1.3 ("Denegar Todo"), se
recomienda desactivar todos los servicios UDP no utilizados en un host y
bloquear, dentro del muro de seguridad, todos los puertos UDP menores al
900, con la excepción de aquellos servicios específicamente requeridos
(como el puerto UDP 53 para DNS). Si se debe proveer de servicios UDP
externos, se recomienda monitorear la red para conocer los sistemas que
están usando dichos servicios, y para detectar señales de abuso de los
mismos.
102
El Equipo de Respuesta ante Emergencias Computacionales, CERT
(Computer Emergency Response Team), recomienda adicionalmente filtrar
los servicios listados en la tabla 4.1
ServicioDNS (Transferencias Zonales)TFTPD (TFTP Daemon)Link (comúnmente usado por intrusos)SUN RPCNFSComandos "r" Unix (rsh, rlogin, etc.)LPD (Une Printer Daemon)UUCPD (unix-to-unix copy program daemon)Open WindowsX Windows
Puerto536987111
2049512-514
5155402000
6000-6000+x
TipoTCPUDPTCP
TCP y UDPUDPTCPTCPTCP
TCP y UDPTCP y UDP
Tabla 4.1 Recomendación CERT sobre puertos y servicios TCP/UDP Los puertosXwindows varían hasta 6000 + x, donde x representa el número más altode terminales "X" en el mismo hosí.
Cisco® recomienda filtrar el servicio FINGER (puerto TCP 79) para impedir
que externos puedan conocer sobre directorios de usuarios internos y los
nombres de los hosts a los que pueden acceder.
Al tratarse de ataques por inundación ICMP, CERT recomienda el filtrado de
los paquetes ICMP de redirección y destino inalcanzable. Por lo observado
en las sesiones de análisis de la red, se sugiere filtrar solamente paquetes
ICMP echo externos (o por lo menos permitir únicamente aquellos originados
en la red del ISP o en alguno de sus host, para efectos de monitoreo), así
como aquellos paquetes dirigidos al puerto TCP/UDP 80 (http) de los
servidores de correo electrónico.
Ataques DoS pueden resultar en pérdidas significativas de tiempo y dinero
para muchas organizaciones, CERT alienta a considerar las siguientes
opciones con respecto a las necesidades:
Implementar filtros en los ruteadores, como se especificó
anteriormente, y como se describe en el RFC 2827, lo cual reducirá el
riesgo de sufrir ciertos ataques DoS, adicionalmente ayudará a
prevenir que usuarios de la red lancen de manera efectiva ciertos
ataques DoS.
- De estar disponibles para cierto sistema, instalar parches para
protección contra inundaciones TCP SYN, esto disminuirá
sustancialmente la exposición a estos ataques pero no eliminará
totalmente el riesgo.
Desactivar cualquier servicio de red innecesario o no utilizado, esto
limitará la capacidad de un intruso para ejecutar un ataque tomando
ventaja de dichos servicios.
- Monitorear el desempeño del sistema y establecer delineamientos
base para actividad normal, utilizar los delineamientos para evaluar
niveles anormales de operación.
- Examinar en forma rutinaria la seguridad física.
- Manejar herramientas que permitan detectar cambios en la
información de configuración u otros archivos (Tripwire o similares).
- Invertir en máquinas backup y mantenerlas actualizadas, para que
sean puestas en servicio de forma rápida en el evento de que su
similar haya sido desactivada.
- Invertir en configuraciones de red redundantes y tolerantes a fallas.
- Establecer y mantener políticas para cronogramas regulares de
respaldo de información (backup), particularmente para información de
configuración importante.
- Establecer y mantener políticas apropiadas sobre las claves de
acceso, especialmente al tratarse de cuentas privilegiadas como Root
en UNIX, o Administrator en Windows NT.
-4.3.1.2.3 Protección de los Servicios
Existen algunos tipos de servicio, cada uno con sus propios requerimientos
de seguridad que variarán de acuerdo al uso designado del servicio, por
ejemplo, servicios que deberían estar disponibles dentro de la organización
podrían requerir mecanismos de protección que difieran de aquellos provistos
para uso externo (como WWW). Podría bastar con proteger los servicios
internos contra el uso externo, no obstante, el servidor que provee
104
información a cualquier persona en la Internet requiere protección inherente,
es decir, el servicio, protocolo, o servidor, deben proveer cualquier seguridad
requerida para evitar acceso no autorizado y modificación de la base de
datos que contiene la información.
Servicios Internos -aquellos intencionados para los usuarios pertenecientes a
la organización- y Servicios Externos -a disposición de usuarios fuera de la
organización- tendrán, en general, diferentes requerimientos de protección
como se ha descrito anteriormente, por lo que resulta apropiado confinar los
servicios internos a un grupo de estaciones y los externos a otro grupo, esto
es, servicios internos y externos no serán colocados dentro del mismo host.
De hecho en muchos casos cada grupo de estaciones forma una red
diferente, la primera de ellas accesible únicamente dentro de la organización,
y la segunda accesible desde afuera, ambas conectadas mediante un muro
de seguridad.
Existe un tipo de servicio externo en particular que requiere especial
consideración, aquel que proporciona acceso anónimo o de invitado (acceso
no autentificado), es extremadamente importante asegurar que los servidores
FTP anónimo y los accesos con identificación de usuario invitado (guest),
sean cuidadosamente aislados de cualquier host o sistema de archivos a los
que no deberían acceder usuarios externos. Especial cuidado se tendrá si el
acceso anónimo tiene permiso de escritura, pues la organización será
responsable por el contenido de la información públicamente disponible.
Entre los servicios más populares se considerarán a continuación: WWW,
Proxy/Autenticación y Correo Electrónico, pues son los observados dentro de
la red objeto de estudio.
a. Servidores Proxy/Autenticación
Un servidor Proxy provee ciertas mejoras en cuanto a seguridad, permite
concentrar los servicios a través de un host específico para permitir
monitoreo, encubrimiento de la estructura interna, etc. Esta concentración de
IOS
servicios crea un blanco atractivo para potenciales intrusos. El tipo de
protección requerida por un servidor Proxy depende del protocolo delegado
en uso y de los servicios apoderados. Un buen punto de partida es la
aplicación de la regla general: limitar el acceso sólo a las estaciones que
necesiten los servicios, y limitar su acceso sólo para esos servicios
b. Correo Electrónico
Los sistemas de correo electrónico (e-ma/7) han sido por mucho tiempo una
fuente de intrusiones debido a que los protocolos de e-ma/7 están entre los
servicios más antiguos y más desplegados. Por su propia naturaleza, un
servidor de correo requiere acceso al mundo exterior, y la mayoría acepta
datos provenientes de cualquier fuente.
El servidor de correo generalmente consiste en dos partes, un agente de
recepción/envío, y un agente de procesamiento. Como el correo se entrega a
todos los usuarios y usualmente es privado, el agente de procesamiento
requiere típicamente privilegios a nivel de sistema para entregar el mensaje.
La mayoría de las implementaciones realizan ambas porciones del servicio, lo
cual implica que el agente de recepción también tenga privilegios a nivel de
sistema, esto abre algunos vacíos de seguridad. No obstante, existen ciertas
implementaciones que permiten una separación de los dos agentes, se
consideran más seguras pero aún así requieren de una instalación
meticulosa para evitar la creación de un problema de seguridad
c. WWW
La mayoría de servidores WWW aceptan cierto tipo de ordenes y comandos
por parte de las personas que acceden a sus servicios, el caso más común
consiste en tomar una solicitud de un usuario remoto y pasar la información a
un programa que corre en el servidor para procesar la solicitud, muchos de
estos programas no se han escrito tomando en cuenta la seguridad y pueden
crear vacíos. Si un servidor Web está disponible en la Internet, es muy
importante que la información confidencial no sea colocada en el mismo host
que el servidor, de hecho, se recomienda que el servidor ocupe una estación
100
dedicada y calificada como "insegura" o "poco confiable" por parte de las
estaciones internas.
Muchos sitios podrían desear colocar el servicio FTP con su servicio WWW,
esto debería ocurrir sólo con servidores FTP anónimo que únicamente
provean información.
4.3.1.2.4 Protegiendo al Sistema de Protección
Es asombroso cuan a menudo un sitio pasa por alto la debilidad más obvia
en su seguridad dejando al propio servidor de seguridad abierto al ataque.
El servidor de seguridad no debería ser accesible desde afuera, debería
ofrecer acceso mínimo a usuarios internos, excepto para la función de
autentificación, y no debería ser colocado con algún otro servicio. Más aún,
todo acceso al nodo, incluyendo el acceso al propio servicio, debería ser
registrado.
4.3.1.3 Muros de Seguridad (Fir&valls)
Una de las medidas de seguridad desplegadas y publicitadas con más
amplitud en la Internet es el muro de seguridad, a diferencia de lo que
comúnmente se piensa, no consisten en la solución a todos los problemas de
seguridad de las redes, son solamente una herramienta más, disponible
dentro de la búsqueda de un sistema seguro. Proveen cierto nivel de
protección, en general, a nivel de la capa red. El grado de seguridad provisto
por un firewall puede variar tanto como el nivel de seguridad en una máquina
particular.
Un muro de seguridad es cualquier mecanismo usado para controlar y
observar el acceso hacia y desde una red con el propósito de protegerla.
Actúa como una pasarela (Gateway) a través de la cual pasa todo el tráfico
desde y hacia la red protegida. Ayuda a poner limitaciones entre la cantidad y
tipo de comunicación que toma lugar entre la red protegida y otra red (como
por ejemplo, la Internet).
Generalmente es una herramienta usada para construir una pared entre dos
redes, por ejemplo la red interna de una compañía, y la Internet. La única
característica sobre esta pared es que necesariamente debe proporcionar
formas para que cierto tipo de tráfico con características particulares pueda
pasar a través de sus puertas, cuidadosamente monitoreadas. La parte crítica
consiste en el establecimiento de los criterios (reglas) por los cuales se
permite o deniega el acceso de los paquetes.
Conceptualmente existen dos tipos:
- Muros de seguridad por filtrado de paquetes.
- Muros de seguridad en base a servidores apoderados.
4. 3.1.3. / Muros de Seguridad por Filtrado
Trabajan a nivel de la capa red, las reglas se basan en el contenido de los
encabezados de cada paquete IP recibido: protocolo, direcciones origen y
destino; incluso se pueden extender hasta la cabecera del segmento de
transporte contenido dentro del paquete: puerto de origen, puerto de destino,
etc [Pea].
Las decisiones, que se limitan a "aceptar" o "denegar" el paquete, serán
consecuentes con las reglas o políticas de seguridad y con el plan general de
seguridad adoptado por la organización (Denegar Todo Permitir Todo}.
Los filtros generalmente se implementan a nivel del enrutador, debido a que
muchos tienen cierta capacidad (dependiendo del fabricante) para
desempeñar estos servicios de seguridad, aunque también pueden
desarrollarse dentro de un host.
Entre las ventajas ofrecidas por este tipo de muros de seguridad están la
transparencia para el usuario y el tiempo, generalmente corto, que tomará el
proceso (en todo caso dependerá de la complejidad del esquema de filtrado).
Una desventaja radica en el hecho de que no proporcionan mecanismos de
autentificación, la única identificación que presenta el usuario consiste en la
los
dirección asignada a su estación de trabajo, por cuanto son en cierto grado
vulnerables a la falsificación IP. No obstante, algunos ruteadores proveen,
adicionalmente a la capacidad de filtrado, facilidades para control de acceso,
lo cual implica mayor nivel de seguridad y una disminución de los tipos de
paquetes falsificados que podrían atravesarlos [SAMSJ.
-/. 3.1.3.2 Muros cíe Seguridad mediante Servicios Apoderados (Proxy}
Los servidores proxy son mayormente utilizados para monitorear y controlar
el tráfico saliente. En lugar de conectarse directamente a un servidor externo,
el cliente se conecta al servidor proxy, quien a su vez inicia una conexión con
el servidor solicitado.
Dependiendo del tipo de proxy utilizado es posible configurar a los clientes
internos para que realicen automáticamente la redirección, sin conocimiento
por parte del usuario, otro tipo podría requerir que el usuario se conecte
directamente con el proxy y luego iniciar la segunda conexión mediante un
formato específico.
En cuanto al tráfico entrante, cuando un usuario externo desea contactar una
estación de una red que ímplementa este esquema, establece una conexión
con el proxy, que analiza algunos campos dentro de la solicitud, si cumplen
con un grupo de reglas predefinidas, establece una conexión entre el servidor
proxy y la estación originalmente solicitada por el usuario externo e
internamente crea un puente entre las conexiones. Los paquetes IP externos
no son encaminados hacia el interior, en lugar de ello, la pasarela actúa como
un intérprete entre las estaciones.
La ausencia de encaminamiento de los paquetes externos hacia la red
interna constituye una ventaja en cuanto a seguridad.
Existen adicionalmente, significantes beneficios de seguridad que resultan del
uso de servidores proxy. Es posible añadir listas para control de acceso
(Access Control List o ACL), exigir que usuarios o sistemas provean cierto
nivel de autenticación antes de que el acceso sea concedido. Servidores
proxy más inteligentes, denomindos pasarelas a nivel de aplicación (ALGs),
pueden entender protocolos específicos y pueden ser configurados para
bloquear subconjuntos del protocolo, por ejemplo, un ALG para FTP puede
diferenciar entre los comandos "puf y "gef, una organización podría desear
permitir a sus usuarios obtener (get) archivos de la Internet, pero impedir
depositar (put) archivos internos en un servidor remoto. En contraste, un
ruteador de filtrado podría bloquear todo acceso FTP o ninguno, pero no un
subconjunto.
Los servidores proxy además pueden ser configurados para encripción de
flujos de datos, en base a una variedad de parámetros. Una organización
podría usar esta característica para permitir conexiones encriptadas entre dos
locaciones cuyos únicos puntos de acceso están en la Internet.
La mayoría de servidores apoderados proveen registro de eventos, esta
facilidad puede utilizarse para una administración de segundad más
apropiada. Es importante monitorear con regularidad los eventos registrados
para identificar cualquier signo de intrusión o intentos para ingresar por la
fuerza. Muchos intrusos intentarán cubrir sus huellas editando los eventos
registrados, por lo que es importante protegerlos; existe una variedad de
formas para hacerlo: unidades de almacenamiento tipo "escribir una vez, leer
varias veces" o WORM (Write Once Read Many), registros en papel, registro
de eventos centralizado mediante la utilidad SysLog.
4.3.1.3.3 Muro Je Seguridad Basado en Elementos Actuales de la líwaneí
En la práctica, los muros de seguridad son una combinación de los dos
conceptos descritos con anterioridad, esta disposición permite al ruteador
externo bloquear casi cualquier intento para utilizar la capa IP subyacente
con el objeto de romper la seguridad (IP spoofing, enrutamiento desde el
origen, fragmentos de paquete), mientras que el servidor proxy maneja los
potenciales vacíos de seguridad en los protocolos de capas superiores.
La primera propuesta, representada por la figura 4.1, consiste en optimizar el
nivel de seguridad presentado por la Extranet utilizando sus propios recursos.
AU
TE
NT
IFIC
AC
ION
Ser
vido
r P
RO
XY ^
CO
NT
RO
L D
E A
CC
ES
O(A
CL)
216.
219.
15.1
2925
5.25
5.25
5.24
0R
utea
d or
Cis
co
Ser
vido
r M
AIL
216.
219.
15.1
3025
5.25
5.25
5.24
0
FIG
UR
A 4
.1 I
ncre
men
to d
e se
guri
dad
basa
do e
n fi
ltra
do I
P.
II
Como lo muestra la figura 4.1, la solución implica dividir a la Extranet en dos partes,
una pública denominada "Zona Desmilitarizada" (o DMZ), y una privada
("INTERIOR"). La DMZ comprende únicamente a los servidores WEB y Matí, que
son los hosts que prestan servicios externos (a disposición de usuarios fuera de la
organización).
La figura 4.1 también denota la inclusión de una lista de acceso dentro del enrutador
para incrementar el grado de seguridad a nivel de red dentro de la DMZ.
Una mejora adicional en cuanto al nivel de seguridad se lograría mediante una
reconfiguración del servidor proxy, encaminada hacia el control de acceso a la
Internet por parte de usuarios internos y la implementación de funciones de
autentificación.
La lista de acceso se configura de tal forma que cumpla con el mayor número de
recomendaciones citadas dentro de la sección "-Í.3./.2.2 rmtcccióit Je ¡u 7W y su
contenido se muestra en la tabla 4.2, el manejo de la tabla de filtrado y la lista de
acceso dentro de ruteadores Motorola Vanguard se explica en el anexo B.
La posición que ocupa cada una de las entradas dentro de la lista de acceso es
fundamental. Para su organización se distinguen entradas especificas y entradas
generales.
Una entrada es más específica cuando mayor es el número de campos cuyo
contenido representa un valor puntual, (por ejemplo la entrada 4 de la tabla 4.2
especifica una dirección de origen y una de destino, un protocolo y un número de
puerto).
Una entrada resulta ser más general cuando mayor es el número de campos cuyo
contenido representa un rango de valores (como ejemplos, las entradas 18 y 25
dentro de la tabla 4.2).
112
Entrada
#
12345
678910
t i1213141516171819202122232425262728293031323334353637
Tipo
ncludcncludcncludc
1 ncludcMC lude
1 ncludcInclude
ExcludeExcludcE.xcludcExcludcExcludcEscindeExcludcExcludcExcludcExcludcExcludcExcludcE.xcludcExcludcExcludcIncludeIncludeIncludeIncludeIncludeIncludeIncludeInclude
Origen
Dirección
216.219.15.129216.219.15.130192.168.150.163.71.198.5
198.6.1.1
192.168.150.0192.168.150.0
0.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.010.0.0.0
172.16.0.0
216.219 15.1280.0.0.0
255.255.255.25.192.168.150.12
0.0.0.0192.168.150.11
0.0.0.0192.168.150.10
0.0.0.00.0.0.00.0.0.0
Máscara
55.255.255.25555.255.255.25555.255.255.25555.255.255.25555.255.255.25555.255.255.24055.255.255.240
0.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.0
255.0.0.0255.255.240.0
255.255.255.128255.255.255.25.255.255.255.25.255.255.255.255
0.0.0.0255.255.255.25
0.0.0.0255.255.255.25
0.0.0.00.0.0.00.0.0.0
Destino
Dirección
216.219.15.130216.219.15.129216.219.15.129216.219.15.128216.219.15.128
63.71 198.5198.6.1.1
216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128
0.0.0.00.0.0.0
216.219.15.1280.0.0.00.0.0.00.0.0.0
216.219.15.1330.0.0.0
216.219.15.1320.0.0.0
216.129.15.13216.219.15.128216.219.15.128
Máscara
55.255.255.25555.255.255.25555.255.255.255
255.255.255.240255.255.255.240255255.255.255255.255.255.255
255.255.255.240255.255.255.240255.255.255.240255 255 255 24(1255.255.255.240255.255.255.240255.255.255.240255.255.255.241255. 255. 255. 24(255.255.255.241
0.0.0.00.0.0.0
255255.255.1280.0.0.00.0.0.00.0.0.0
255.255.255.250.0.0.0
255.255.255.250.0.0.0
255.255.255.25255.255.255.24f255. 255.255. 24<
Protocolo
Inicio
111
171717
17
17617666666
6
00
0
0
066
6666176
Pin
111
171717
17
171717176666
66
255255255255255666r.6617
6
Puerto
Inicio
0
0
0
53
535353
0200020496000
53
7987
1 1 1
512540
0
0
0
0
080808080
2525900
1024
Pin
>5535
>5535
>5535
535353
53
899200020496010
53
7987
111515540
6553565535f>5535CÓ53565535
8080
8080
2525
6553565535
Tabla 4.2 Implementación de una lista de acceso dentro del enrutador Motorola
Ocupando los primeros lugares de la lista de acceso se encuentran las entradas
inclusivas más específicas, mientras que las más generales se ubican al final. En
medio de éstas, se ordenan las entradas de tipo exclusivo desde las más generales
hasta las más específicas Esta disposición evita que ciertos paquetes que se
desean filtrar logren atravesar el sistema (al haber encontrado primero una entrada
general de tipo inclusiva que abarca las características del paquete), o por el
contrario, que cierto tráfico deseado sea eliminado. Como ejemplo, la entrada 15 en
la tabla 4.1 pretende eliminar todos los puertos UDP menores al 900, de
conformidad con la recomendación CERT, pero de ubicarse en cualquiera de las
tres primeras posiciones, el resultado implicaría la pérdida de todo el tráfico DNS,
imposibilitando el acceso hacia la Internet. Se tiene otro ejemplo al considerar un
cambio en el orden de las entradas 32 (permite el tráfico http entre el servidor WEB
y el mundo externo) y 25 (que elimina ciertas direcciones falsificadas), posibilitando
ciertos ataques por falsificación IP dirigidos al servidor WEB.
Las entradas 8 a 14 se dejan en blanco, o se configuran repitiendo la entrada 7,
para el caso futuro en que se desee agregar algún servicio especifico (por ejemplo
FTP).
Esta aproximación provee a la Extranet de un nivel de seguridad aceptable, no
obstante sacrifica funcionalidad al restringir por completo el uso de ciertos servicios,
por ejemplo, se desearía permitir la descarga de archivos (FTP get), e impedir el
envío de información interna hacia el exterior (FTP put), pero el ruteador bloquearía
todo el tráfico FTP, entonces una decisión deberá ser tomada en cuanto a las reales
necesidades del servicio. Algo similar sucede con los paquetes ICMP de eco
(solicitud y respuesta), el ruteador no puede diferenciarlos de otros paquetes ICMP,
y un intento por bloquearlos impediría las comunicaciones ICMP con otros nodos de
la Internet. Adicionalmente el mantenimiento de los filtros y listas de acceso no es
muy intuitivo, requiere de cierto nivel de conocimiento y preparación.
El muro de seguridad disminuye la probabilidad de recibir ataques por inundación
TCP SYN y por falsificación de direcciones, mas no la elimina.
Permisos a nivel de aplicación se pueden introducir en el servidor proxy, así como
facilidades para cache (almacenamiento local de las páginas solicitadas con mayor
frecuencia por parte de los usuarios) lo cual implica una optimización en el uso del
enlace WAN y un menor tiempo de respuesta para el usuario.
u
-/. 3.1.3.4 Muro de Segundad Basado en el Sistema Operativo Linux
Esta solución implica un mayor nivel de seguridad y versatilidad, la herramienta de
filtrado ipchains es más flexible que el esquema empleado por el ruteador, se puede
permitir la ejecución de los programas Ping y Tracert sin comprometer la seguridad
de la red. El servidor proxy presenta adicionalmente facilidades para guardar
localmente las páginas solicitadas por los usuarios (cache), lo cual implica un mejor
uso del enlace WAN reflejándose en un menor tiempo de respuesta hacia el usuario.
La figura 4.2 representa la solución propuesta. Como se puede observar, el servidor
LINUX separa a la red en tres zonas mediante el uso de tres interfaces de red.
La primera es una zona externa, está formada por el ruteador y representa a toda la
Internet, esto es, el conjunto de todos los que no son considerados como "/?osí de
confianza".
La segunda es la zona desmilitarizada o DMZ, está conformada por los servidores
que prestan servicio a hosts en la Internet y requieren de cierto nivel de protección
(servidor de Correo Electrónico y servidor Web).
Finalmente, la tercera zona es la interior y comprende a los hosts categorizados
como "de confianza", es decir a los hosts de la organización.
El servidor LINUX realiza el filtrado de paquetes entre cada una de las zonas
basándose en las reglas definidas por la herramienta ipchains, propia de este
sistema operativo. La tabla 4.3 muestra las reglas para el filtrado dentro del servidor.
Adicionalmente al filtrado, el servidor podría realizar las funciones de proxy y cache,
mediante la ejecución del software adecuado (por ejemplo el programa SQUID).
Dentro del anexo C se explica el funcionamiento de la herramienta de filtrado
Ipchains de Linux, mientras que el apéndice D describe brevemente al programa
SQUID.
Filt
rado
de
Paq
uete
sa
nive
l de
Apl
icac
ión
(IP
CH
AIN
S)
Filt
rado
de P
aque
tes
a ni
vel d
e R
ed (
AC
L)
Rut
eado
rM
otor
ola
Rut
eado
rC
isco
Pro
xy +C
ache
(SQ
U1D
)
Ser
vido
r LI
NU
Xn
216.
219.
15.1
3025
5.25
5.25
5.24
021
6.21
9.15
.129
255.
255.
255.
240
Ser
vido
r M
AIL
Ser
vido
r W
EB
DM
Z
Fig
ura
4.2
Mur
o de
seg
urid
ad p
or f
iltr
ado
a ni
vel
de r
ed y
con
trol
de
acce
so a
niv
el d
e ap
lica
ción
.
No.
1 2 3 4 5 S 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Com
ando
Ipch
ains
Ipcn
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
tpch
ains
Ipch
ams
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
tpch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ams
tpch
ains
Opc -A -A -A -N -N -N -N -N -N -N -A -A -A -A -A -A -A -A -A -A -A -A -A -A -A
Cad
ena
Inpu
tO
utpu
tF
orw
ard
inte
rna_
a_ex
tern
aln
tem
a_a_
dmz
dmz_
a_in
tern
adm
z_a_
exte
ma
Ext
ema_
a_dm
zex
tern
a_a_
¡nte
rna
lcm
p_ok
Out
put
Out
put
Out
put
Out
put
Out
put
Out
put
lcm
p_ok
lcm
p_ok
lcm
p_ok
lcm
p_ok
lnte
rna_
a_dm
zln
tern
a_a_
dmz
lnte
rna_
a_dm
zln
tern
a_a_
dmz
Inte
rna
a dm
z
Condic
ión
-i ! l
o-i
! lo
-i et
hO-s
192
.168
.1.0
/24
-i e
th2
-s 1
98.1
68.1
.0/2
4-i
eth
! -s
216
.219
.15.
128/
28-i
eth
2-s
216.2
19.1
5.1
28/2
8-i
ethO
-i eth
l-p
icm
p ic
mp-
type
des
tinat
ion-
unre
acha
ble
-p ic
mp
icm
p-ty
pe s
ourc
e-qu
ench
-p ic
mp
__
icm
p-ty
pe t
ime
exce
eded
-p ic
mp
icm
p-ty
pe p
aram
eter
-pro
blem
-ptc
p-d
216
.219
.15.
131
sm
tp-p
tcp
-d 2
16.2
19.1
5.13
1 po
p3-p
tcp
-d 2
16. 2
19.1
5. 1
32 w
ww
-p ic
mp
Acc
ión
-j D
EN
Y-j
DE
NY
-j D
EN
Y
-j in
tern
a_a_
dmz
-j in
tern
a_a_
exte
rna
-] d
mz_
a_in
tern
a-j
dmz_
a_ex
tern
a-j
exte
rna_
a_dm
z-j
exte
rna_
a_in
tern
a-j
AC
CE
PT
-j A
CC
EP
T-j
AC
CE
PT
-j A
CC
EP
T
-j A
CC
EP
T-j
AC
CE
PT
-j A
CC
EP
T-j
icm
p_ok
-j D
EN
Y -I
Desc
ripci
ón
Per
miti
r tr
áfic
o lo
cal y
dene
gar
el r
esto
, m
ient
ras
se c
onfig
uran
las
regl
asF
iltra
do d
e p
aque
tes
que
atra
vies
an e
l Ser
vido
r Li
nux:
a) C
reac
ión
de n
ueva
s ca
dena
s
b) C
onfig
urac
ión
de a
ccio
nes:
dete
rmin
ació
n de
la d
irecc
ión
del
tráf
ico
dete
rmin
ació
n de
l tip
o de
tráf
ico
ICM
PA
cept
able
c) C
onfig
urac
ión
de la
s ca
dena
s de
usu
ario
perm
itir
smtp
hac
ia d
mz
perm
itir
pop3
perm
itir
ww
wan
aliz
ar t
ráfic
o ic
mp
dene
gar
y re
gist
rar
el r
esto
Tab
la 4
.3
Con
figu
raci
ón d
e la
s re
glas
den
tro
del
serv
idor
Lin
ux.
26 27 28 29 30 31 32 33 34 35 36 37 38 39
Ipch
ams
Ipch
ams
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
Ipch
ains
-A -A -A -A -A -A -A -A -A -A -A -A -A -A
inte
rna
a ex
tern
ain
tern
a_a_
exte
rna
inte
rna
a ex
tem
adm
z_a_
inte
ma
dmz
a in
tern
adm
z_a_
exte
rna
dmz_
a_ex
tern
adm
z_a_
exte
rna
dmz
a ex
tern
aE
xtem
a a
dmz
Ext
erna
_a_d
mz
Ext
erna
_a_d
mz
Ext
ema
a dm
z
exte
rna
a in
tern
a
-ptc
p-d
0.0
.0.0
/O w
ww
-pu
dp
-d 6
3.71
. 198
.5 5
3-p
ud
p-d
128
.6.1
.1 5
3-p
tcp
-s 2
16.2
19.1
5.13
1 sm
tp-p
tcp
-s 2
16.2
19.1
5.13
2 w
ww
-ptc
p-s
216
.219
.15.
131
smtp
-p tc
p -s
216
.219
.15.
132
ww
w-p
ud
p-d
63.
71. 1
98.5
53
-pu
dp
-d 1
28.6
.1.1
53
-p tc
p -s
0.0
.0.0
/O 1
024:
-d
216.
219.
15.1
31 s
mtp
-p tc
p -s
0.0
.0.0
/O 1
024:
-d 2
16.2
19.1
5.13
2 w
ww
-pu
dp
-s 6
3.71
. 198
.5 5
3-p
ud
p-s
198
.6.1
.1 5
3
-ptc
p-s
0.0
.0.0
/O w
ww
-d
192.
168.
150.
1210
24:
-j A
CC
EP
T-j
AC
CE
PT
-j A
CC
EP
T-j
AC
CE
PT
-j A
CC
EP
T-j
AC
CE
PT
-j A
CC
EP
T-j
AC
CE
PT
-j A
CC
EP
T-j
AC
CE
PT
-j A
CC
EP
T-j
AC
CE
PT
-j A
CC
EP
T
-j A
CC
EP
T
perm
itir
enví
o w
ww
perm
itir
enví
o dn
s
acep
tar
smtp
des
de d
mz
acep
tar
ww
w d
esde
dm
zen
viar
sm
tpen
viar
ww
wen
viar
dns
reci
bir
smtp
reci
bir w
ww
reci
bir
dns
reci
bir
ww
w
Tab
la 4
.3
Con
figu
raci
ón d
e la
s re
glas
den
tro
del s
ervi
dor
Lin
ux (
cont
inua
ción
).
1S
La tabla 4.4 representa las entradas en la lista de acceso que se configura
dentro del ruteador para incrementar la seguridad a nivel de red, cumpliendo
con las recomendaciones de la sección 4.3.1.2.2.
Entrada#1234567
8
9
10
I I1213U15ir1718
192(222232-
Tipo
•xcludc:. xcludcExcludeixcludcExcludeExcludeí xcludcExcludclí xcludci xcludcExcludcExcludcExcludcINC ludeExcludcIncludcIncludcIncludeIncludcIncludcIncludeIncludcIncludcIncludc
OrigenDirección
0.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.010.0.0.0
172.16.0.0
216.219.15.1280.0.0.0
255.255.255.255192.168.150.12
0.0.0.0192.168.150.11
0.0.0.0192.168.150.10
0.0.0.00.0.0.00.0.0.00.0.0.0
Máscara0.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.00.0.0.0
255.0.0.0255.255.240.0
255.255.255.128255.255.255.255255.255.255.255255.255.255.255
0.0.0.0255.255.255.255
0.0.0.0255.255.255.255
0.0.0.00.0.0.00.0.0.00.0.0.0
DestinoDirección
216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128216.219.15.128
0.0.0.00.0.0.0
216.219.15.1280.0.0.00.0.0.00.0.0.0
216219.15.1130.0.0.0
216.219.15.1320.0.0.0
216.129.15.131216219.15.128216.219.15.128
0.0.0.0
M¡í se a ni255.255.255.240255.255.255.240255.255.255.240255.255.255.240255.255.255.240255.255.255.240255.255.255.240255.255.255.240255.255.255.240255.255.255.240
0.0.0.00.0.0.0
255.255.255.1280.0.0.00.0.0.00.0.0.0
255.255 255 2550.0.0.0
255.255.255.2550.0.0.0
255.255.255.255255.255 255 24(255. 255. 255. 24(
0.0.0.0
ProtocoloInicio
1761766
6
66
66
0
0
0
0
0666
6
6
617
60
Fin
17
17171766
6
66
6
25525525525525566666617
6255
Puertonicio
0
200020496000
5379
87
1 1 1512
5400
0
0
0
08080
8080
2525
y o»)1024
0
Fin
899
200020496010
5379
87
1 1 1515
540655356553565535f>55 i-S
0553580
80
80
80
25
25r>5535
65535
65535
Tabla 4,4 Configuración de la Lista de Acceso dentro del enrutador
Esta implementación es consecuente con lo convenido en -t.3J.L3 , esto es,
aquello que no está especificado por las cadenas dentro del servidor Linux es
descartado.
La presente propuesta presenta varias ventajas sobre la anterior. El sistema
operativo Linux incluye en su kernel medidas de prevención de falsificación IP
y mayor inmunidad a los ataques por inundación TCP SYN, es de libre
distribución y existen parches y mejoras ampliamente disponibles, presenta
mayor facilidad para administración de reglas.
119
Una ventaja de combinar los dos métodos básicos para implementar muros
de seguridad consiste en que ambos se complementan, donde uno es débil
otro es fuerte, además, si por alguna razón uno de ellos debe ser desactivado
o sufre algún tipo de mal funcionamiento, el otro aún puede proveer
seguridad a la red, esto implica protección redundante.
4.3.1.4 Sistemas para Detección de Intrusiones (IDSs)
Los muros de seguridad, como se mencionó anteriormente, proveen cierto
nivel de protección, no obstante atacantes especializados podrían sobrepasar
los obstáculos impuestos por estas herramientas. Amenazas complejas y
elaboradas requieren medidas de segundad avanzadas, se necesita
entonces una tecnología complementaria de seguridad denominada como
detección de intrusiones.
La detección de intrusiones consiste en la habilidad para analizar datos en
tiempo real con el objeto de detectar, registrar, y suspender ataques o
utilización no autorizada de recursos según ocurran. En la práctica, la
detección de intrusiones es más compleja que una definición, y varios
sistemas de detección trabajan en formas diferentes [Cisc3j.
La detección de una intrusión puede dividirse en dos categorías [Sanc)5| :
- Detección de intrusiones por anomalía.
- Detección de intrusiones por mal uso.
La primera se refiere a intrusiones que pueden ser detectadas en base al uso
de recursos y comportamiento anómalos, por ejemplo, actividad nocturna en
la cuenta de un usuario que sólo utiliza su PC en horas de oficina, este tipo
de detección requiere de la elaboración de perfiles de utilización. La segunda
categoría intenta cuantificar un comportamiento usual o aceptable y señala
cualquier otro comportamiento irregular como potencialmente intrusivo.
La premisa central de la detección por anomalía sostiene que la actividad
intrusiva es un subconjunto de la actividad anómala. Cuando un atacante
120
irrumpe en una cuenta sin tener noción del patrón de utilización de recursos
del usuario al que está suplantando, existe una buena posibilidad de que su
comportamiento represente una anomalía.
Señalar toda actividad anómala incluye cualquier actividad intrusiva, pero no
toda actividad anómala es intrusiva, existen cuatro posibilidades en este tipo
de Sistemas para Detección de Intrusiones (IDSs):
- Falso negativos o Errores de tipo 1: Cuando la actividad es intrusiva
pero no resulta anómala. El sistema de detección de intrusiones
reporta falsamente la ausencia de intrusión.
- Falso positivos o Errores de tipo II: Si la actividad no es intrusiva
pero es anómala. Debido a esto, el sistema reporta falsamente la
existencia de una intrusión.
- Verdadero negativos: La actividad no es intrusiva y tampoco
anómala. El sistema no reporta la actividad como intrusiva por no
ser anormal.
- Verdadero positivos: Cuando la actividad es intrusiva y anormal. El
sistema reporta una actividad intrusiva porque también es anómala.
Cuando no se desea la presencia de falso negativos, los umbrales que
definen una anomalía son configurados en niveles bajos, esto resulta en
muchos falso positivos y detracta la eficacia de mecanismos automatizados
para detección de intrusiones, crea mayor carga de trabajo para el personal
de seguridad quien deberá investigar cada incidente y descartar la mayoría.
Por otro lado, la detección de intrusiones por mal manejo se basa en la
existencia de ataques que pueden ser codificados de manera precisa en una
forma que capture arreglos y variaciones de actividades que explotan la
misma vulnerabilidad.
En la práctica no es posible codificar todas las formas teóricamente posibles
de intrusión, la principal limitación de este método se encuentra en que
121
únicamente busca aquellas debilidades conocidas y no podría ser de mucha
utilidad al detectar intrusiones futuras desconocidas [San95].
4.3.1.4.1 Sistema Sencillo para Moni toreo Je/ Desempeño de la red y Delección de
Intrusiones
Las necesidades de la Extranet aún no justifican la inversión en equipo IDS
especializado, sin embargo, se beneficiaría con la implementación de un
sistema sencillo basado en el analizador de protocolos, específicamente en
las características de alarmas y filtros; el producto resultante es una mezcla
de los métodos para detección de intrusiones antes mencionados: mediante
el sistema de alarmas del analizador se detectarán actividades anormales de
la red, y a través de filtros predefinidos se buscarán patrones de intrusión
conocidos.
Un servidor de monitoreo se instalará dentro de la DMZ, como se muestra en
la figura 4.3, éste correrá el software de análisis de protocolos disponible en
la Extranet (NetBoy, de la NDG Software). El procedimiento podrá
implementarse de manera similar, a pesar de utilizar software de otros
fabricantes (por ejemplo el programa Sniffer de la NAI) debido a la similitud
de la mayoría de analizadores.
• Alarmas
Para la detección de comportamiento anormal de red se fijarán umbrales para
los valores típicos de los parámetros principales como Utilización, Paquetes
por Segundo, Tamaño de Tramas, Difusiones y Multidifusiones, etc. Los
valores típicos son aquellos revelados por el Delineamiento Base de la Red.
Los umbrales deberán ser calibrados para minimizar el número de falso
positivos y falso negativos.
En la mayoría de analizadores se pueden usar las alarmas como
disparadores para iniciar la captura de paquetes, adicionalmente existen
facilidades para notificar la ocurrencia de una alarma: mediante la ejecución
122
de un archivo de sonido, el envío de un mensaje por correo electrónico,
beeper, etc. [ChaOO]
• Filtros
Se puede alertar la presencia de ciertos patrones conocidos de ataques
efectuados sobre la red mediante el uso de filtros de captura definidos
apropiadamente por el usuario. Los filtros se configuran de tal forma que
capturen únicamente aquellas tramas que cumplan con las características
descritas dentro de la sección 4.3.1.2.2.
Cualquier incremento dentro del buffer de captura deberá ser
cuidadosamente revisado.
DMZ
Servidor WEB Servidor MAIL
Monitoreo
Multicasts
Tramas por Segundo Tamaños de Paquete
Alarmas
FILTRO DE CAPTURA
BUFFERDE CAPTURA
Figura 4.3 Sistema de monitoreo dentro de la DMZ.
El sistema de monitoreo propuesto resulta muy útil a la hora de diagnosticar
los problemas que una red eventualmente pueda tener, éste alertará cuando
el comportamiento sea anormal ayudando a evidenciar las posibles causas y
a resolver los problemas.
4.3.2 SERVICIOS DE SEGURIDAD Y PROCEDIMIENTOS
A continuación se tratan medidas complementarias para tomar en cuenta al
asegurar una red. Cada sección toca un servicio de seguridad o una habilidad
que podría ser requerida para proteger la información y los sistemas de una
organización. Como servicio de segundad se entiende a un programa o
aplicación que busca resolver los problemas de confidencialidad o integridad
[Fra97].
4.3.2.1 Autentificación
Por mucho tiempo, el método prescrito para autentificar a los usuarios ha sido
el uso de contraseñas estándar reusables. Originalmente se trataba de
terminales de usuario accediendo a un computador central, por lo que el
riesgo de descubrimiento de una contraseña en "texto simple" era mínimo,
pero hoy existen redes entre clientes y servidores, sistemas que son
conectados por redes locales, y éstas adicionalmente se conectan entre sí y
con la Internet, los usuarios acceden a varios servicios y sus contraseñas de
acceso son transmitidas en texto simple (sin encriptar), a la espera de ser
capturadas por cualquiera que se encuentre en medio y disponga de un
programa rastreador de paquetes.
Con el advenimiento de nuevas tecnologías, como contraseñas de una
ocasión, PGP1, y dispositivos de autenticación basados en fichas, la gente
está usando caracteres tipo contraseña como fichas secretas y p/ns, que de
no ser protegidos y seleccionados apropiadamente, la autentificación podría
ser abatida fácilmente.
Privacidad bastante buena o rrciívíjooii /Viwirv
124
4.3.2.1.1 (Contraseña de una Ocasión
Como se mencionó anteriormente, dado el actual ambiente altamente
interconectado, se recomienda migrar del método estándar de contraseñas
reusables.
Varias técnicas de autenticación resuelven el problema de la captura de
contraseñas y nombres de cuenta mediante rastreadores de paquetes
(aquellas enviadas en "texto simple"), ataques por fuerza bruta, uso de
troyanos, etc. Entre ellas, las técnicas de "desafío-réplica" (challenge-
response), que proveen contraseñas a ser utilizadas sólo por una vez.
Existe un número de productos disponibles que las organizaciones deberían
considerar usar.
4.3.2.1.2 Kerberos
"Kerberos" es un sistema distribuido para seguridad en redes que provee
autentificación a través de redes inseguras, si lo demanda la aplicación,
puede ser provista adicionalmente de integridad y encripción. Fue
desarrollado en el MIT2 a mediados de los 80 y existen dos importantes
ediciones: las versiones 4 y 5, que para propósitos prácticos son
incompatibles.
Kerberos depende de una base de datos para claves utilizando un centro de
distribución de claves (KDC) conocido como el Servidor Kerberos. A un
usuario o servicio (conocidos como "directores") se le concede una "boleta" o
"ticket* electrónico, después de haberse comunicado apropiadamente con el
KDC, que será utilizada para autentificación entre directores, todas las
boletas incluyen una marca de tiempo que limita su periodo de validez, por lo
que clientes y servidor Kerberos deben tener una fuente de tiempo segura, y
ser capaces de mantener el tiempo con precisión.
Massachusctts Insliiutc of Technology
El lado práctico de Kerberos es su integración con la capa de aplicación.
Típicas aplicaciones, como FTP, Telnet, Pop, han sido integradas con el
sistema Kerberos.
-f. 3.2.1.3 (Contraseñas Seguras
Hasta que no exista una necesidad extrema de eliminar el uso estándar de
contraseñas reusables, algunas organizaciones podrían seguir utilizándolas,
los siguientes consejos son útiles para la selección y mantenimiento de
contraseñas tradicionales:
- Contraseñas Robustas: La única manera de protegerse contra ataques por
fuerza bruta consiste en la selección de contraseñas robustas, difíciles de
adivinar (esto es, combinaciones de números, letras, signos de puntuación),
deberían ser tan largas como el sistema pueda soportar y usuarios puedan
tolerar
- Cambio de contraseñas predefinidas: Muchos sistemas operativos y
aplicaciones se instalan con cuentas y contraseñas predefinidas, deben
cambiarse inmediatamente por algo que no pueda ser adivinado ni
descifrado.
- Restricción del acceso al archivo de contraseñas: En particular, una
organización desea proteger la porción de contraseñas encriptada del
archivo, y que los intrusos no la tengan disponible para descifrarla. Una
técnica efectiva es usar contraseñas sombra, donde el campo de contraseñas
dentro del archivo estándar contiene una contraseña falsa, el archivo que
contiene las legítimas está en algún otro sitio del sistema.
- Envejecimiento de contraseñas: Cuándo y cómo caducar contraseñas aún
es tema de controversia dentro de la comunidad de seguridades;
generalmente es aceptado que una contraseña no sea mantenida una vez
que la cuenta no está más en uso. No obstante es recomendado cambiar
todas las contraseñas del sistema por lo menos cada vez que una cuenta
privilegiada ha sido comprometida o existan cambios de personal crítico
'2o
(especialmente un administrador), cuando una sola cuenta de usuario ha sido
comprometida podría no ser necesario cambiar todas las demás contraseñas.
- Bloqueo de cuentas: Ciertas organizaciones encuentran útil desactivar
cuentas luego de un número predeterminado de intentos fallidos de
autentificación, si se opta por este mecanismo, se recomienda no anunciarlo,
luego de bloquear la cuenta el mensaje presentado debería seguir siendo el
de un intento fallido, incluso si se ingresa la contraseña correcta. Usuarios
legítimos solicitarán al administrador la reactivación de sus cuentas.
Cuando el mecanismo es anunciado, puede usarse intencionalmente para
provocar denegación de servicio a usuarios legítimos, incluido el
administrador.
4.3.2.2 Confidencialidad Mediante Encripción
Existe información que una organización deseará proteger contra su
divulgación a entidades no autorizadas. Sistemas operativos muchas veces
incorporan mecanismos de protección de archivos que permiten al
administrador controlar el acceso a un fichero dado. Una manera más fuerte
de proveer confidencialidad es mediante encripción.
La encripción se logra al mezclar y desordenar la información de manera que
resulta muy difícil y demorado obtener el "texto simple" para cualquiera que
no sea un recipiente autorizado o un propietario de la información.
Recipientes autorizados y el propietario de la información poseerán las claves
correspondientes para el descifrado, que les permitirán de una manera fácil
reordenar la información en una forma legible (texto simple).
4.3.2.3 Integridad Usando Sumas de Comprobación
Como administrador, se busca asegurar que la información (como archivos
del sistema operativo, datos de la compañía, etc.) no sea alterada en forma
no autorizada, lo que significa proveer cierta confianza en cuanto a la
integridad de la información dentro de tos sistemas. Una manera es hacerlo
127
mediante la producción de sumas de comprobación (Checksum) de los
archivos íntegros, guardarlas fuera de la red (offline) y periódicamente
compararlas con nuevas sumas de comprobación realizadas sobre los
mismos archivos.
Para asegurar la integridad se recomienda el uso de programas para
comprobación que además sean criptográficamente robustos, como el MD53
Existen otras aplicaciones en la que se debe asegurar la integridad, como en
el caso del correo electrónico, existen varios productos que proveen esta
facilidad.
4.3.2.4 Autorización
La autorización se refiere al proceso de otorgar privilegios a procesos y,
finalmente, usuarios. Difiere de la autentificación (proceso utilizado para
identificar a un usuario), en que determina los derechos, privilegios,
propiedades y acciones permisibles para un usuario previamente identificado.
Un método popularizado por Unix asigna tres clases de usuarios a cada
objeto: Propietario, Grupo, Todos. Para cada tipo de usuario existen tres
permisos: lectura, escritura y ejecución, así un objeto podría tener los tres
permisos para su creador (Propietario), permisos de lectura y escritura para
un grupo de usuarios que comparten los derechos de acceso hacia el objeto,
y únicamente permiso de lectura para cualquiera que tenga acceso al sistema
(Todos).
Otro método consiste en adherir a un objeto una lista que contiene
explícitamente la identidad de todos los usuarios (o grupos) permitidos, ésta
es una denominada Lista para Control de Acceso (ACL). La ventaja es que se
mantienen con facilidad y se puede verificar de manera visual quién tiene
acceso a qué. La desventaja son los recursos extra que se requieren para
almacenar las listas.
' Compendio do incnstijc #5 (Mcssugc Di csl) de Ron Rivcsl (TnnV>7|
I2S
4.3.2.5 Acceso
-4.3.2.5.1 Acceso Físico
Restricción del acceso físico a gabinetes de cableado, concentradores, y
elementos importantes de red como ruteadores y servidores.
-/. 3.2.5.2 Punios Je Libres para (Conexión a la Red
Puntos destinados para facilitar la conexión de computadores portátiles a la
red; El tener puntos de conexión libres y habilitados debe ser considerado
tomando en cuenta que permitirán a cualquiera conectar un host no
autorizado a la red, incrementando el riesgo de ataques mediante falsificación
IP, rastreadores de paquetes, etc.
REFERENCIAS CAPITULO IV
[BOR| KORAN. Sean; "IT Securiiy í 'ookbook".
[CER| CERT Coordinaron Center; " Advisories" nw.cert.org advisories
|ChaOO| (^HAPPELL, Laura; "Advanced Nenvork Análysis Tec/uii(fues "
Podbooks 2000.
|Ciscl | CISCO DOCUMENTA TION; "¡ncreasing Securiiy on W NelM'orks ".
[Cisc2| CAVÍ'O DOCUMENTARON; "Infernet\\-orkin^ Technologies
Overvie\v: Security Technologies"
|Cisc3| CISCO DOCUMENTA TION: Inmisión Detection rianning Cntide.
| FPOO| I'ERGUSON, P; "Network Ingress Whering: Dcfauting Denial of
Service Altacks wich employ ¡P Source Address Spo<tfni£" R/-(" J.S'J?:
Mayo 2000
|Fra97| I-'RASER, fí; "Secure Siie Handbook" RI-'C 2196, Septiembre /9V7
|Grc| CiRENNAN, Mark; "l'irewallandProxy Server Howto "
hifp: ww.Iinuxdoc.org HOWTO l''ire\vail-HOWTO.hlml
|IMoíol| MOTOROLA DOCUMENTARON; "IP and Latí Eeatitre Proiocols
Manual"
| Pea|
|Rus|
PEARSON, Osear; "SQUID: A User'sCnñde"
hífp: s(¡uid-docs.sourceforge.net lalesí hlml bookl.hlm
RUSSELL, Rusty; "LinuxIPCHAINS-HOWTO"
htíp: ww.Iinuxdoc.org HOWTO IPCHAINS-HOWTO.hnul
|SAMS1 SAA-/S, "Máximum Internet Secitrity: A Hackers (¡u/Je "
http: w\\ it.com
[San95| SANDEfcí*. Kumar; "Classij¿catión andDetection of Computer
Intrusions" Pitrdue University
CAPITULO V
5. CONCLUSIONES Y RECOMENDACIONES
Para optimizar una red dada, necesariamente se debe iniciar por una
inspección de la misma, conocer su topología, los servicios que presta y sus
particularidades, se debe lograr un grado de familiarización con la red objeto
de estudio.
La primera opción que a la mayoría de administradores de red les vendría a
la mente ante una situación como la acaecida dentro de la Extranet
consistiría en lograr un comportamiento aceptable aumentando la capacidad
de comunicaciones dentro de la red extendida (doblar el acceso a la Internet),
y/o dentro de la red local (actualizar la capa Host a red mediante el uso de
tecnologías como 100BaseTX). Tomar esta decisión sin haber analizado
antes no sólo las estadísticas de utilización (que asimismo indican una
saturación del enlace WAN e igualmente sugieren la ampliación de la
capacidad de comunicación) sino también el tráfico dentro de la red. los
protocolos e incluso el contenido de los paquetes, hubiera representado la
pérdida de significativas inversiones económicas y el desperdicio de
cuantiosos recursos, pues como se ha demostrado, lo único que se habría
conseguido es que una cantidad mayor de información "basura" circule dentro
de la red.
Una segunda opción implica la investigación del origen del problema, detectar
las causas de un comportamiento anómalo es fundamental para encontrar la
solución más adecuada.
El objetivo entonces consistirá en caracterizar el estado de operación de la
red, y la mejor forma de hacerlo es emplear las técnicas para análisis y
delineamiento base de redes descritas dentro del presente estudio. Mediante
el uso de equipos especializados, denominados "analizadores de protocolos"
(hardware o software), y la implementación de un ciclo programado de
132
sesiones de análisis se logra definir el "estado actual" de operación de la red,
el cual es evaluado para definir si resulta aceptable tanto para los usuarios de
la red como para sus aplicaciones, de ser así, se lo registra como un "estado
normal" de operación de la red. Cuando el estado actual no es satisfactorio,
se toman los correctivos necesarios hasta lograr un desempeño aceptable, el
cual será registrado y tomado como "normal" para la red.
Desempeñoóptimo
Registro de un nuevo estadonormal de operación
Realización decorrectivos necesarios
Comparación del estado actual con elestado normal de operación de la red
Sesión de Análisis
Nuevas implementaaones ocambios realizados sobre la red
Figura 5.1 Optimización por delineamiento base de redes.
De esta manera, cualquier acción tomada con el objeto de mejorar el
desempeño de la red podrá ser corroborada de forma efectiva al comparar el
nuevo "estado actual" con el estado normal de operación, si el nuevo estado
resulta satisfacer de mejor manera las necesidades de los usuarios entonces
será registrado como "normal", llevando al desempeño de la red hacia un
estado óptimo, a través de una espiral ascendente.
Como se observa en la figura 5.1, la optimización de las redes se vuelve un
proceso iterativo al usar el método de aproximación por delineamiento base:
la red se ve inmersa en un proceso evolutivo en el que cada estado supera al
anterior.
El resultado directo de la aplicación de este procedimiento dentro del caso de
estudio es un importantísimo ahorro de recursos. La solución a los problemas
de la red no está en el aumento en la capacidad de comunicación (de la red
local y/o de la extendida), sino en la eliminación de protocolos activos que
resultan ser innecesarios y en la implementación de filtros y listas de acceso
para incrementar el nivel de segundad de la Extranet
La investigación y aplicación de técnicas para análisis de redes implica un
aporte directo en cuanto a la optimización con un ahorro de tiempo y
recursos, convirtiéndose adicionalmente en una importante herramienta
dentro de lo referente a la resolución de problemas y la planificación para el
crecimiento de la red.
Se deben incluir dentro del mantenimiento diario de la red, técnicas para el
análisis y delineamiento como las descritas por el presente estudio, un ciclo
programado de sesiones de análisis y su correcta interpretación llevará a la
red hacia un estado óptimo a través de una espiral ascendente
Se recomienda aprovechar al máximo el delineamiento base de la red
manteniendo el proceso de manera cíclica a través del tiempo y no
implementarlo por una sola vez, poder disponer de la mayor cantidad de
134
información actualizada resulta un activo muy valioso dentro de la
administración y mantenimiento de la red.
Se recomienda extender el concepto de delineamiento base hasta el nivel de
aplicación, especialmente de aquellas desarrolladas específicamente para la
organización, así como el de implementar y mantener el delineamiento base
sobre las demás partes que conforman la red BVQ. Adicionalmente se
sugiere adoptar los formatos para la documentación de las sesiones de
análisis y delineamiento de aplicaciones propuestos en el anexo A. o en base
a éstos, desarrollar formatos propios que se ajusten a las necesidades
específicas de la administración de la red.
Las mediciones realizadas sobre la Extranet no sugieren ni justifican, por el
momento, una actualización de la capa host a red mediante el uso de
tecnologías de mayor capacidad (como FDD1, FastEthernet, etc.)
Cualquier inversión realizada en equipos de red debe ser apropiadamente
justificada, y estar de acuerdo con las necesidades de la red. Dentro del caso
de estudio, técnicas de análisis de protocolos han evidenciado la necesidad
de protección de la Extranet, y para asegurarla se deben tomar medidas
consecuentes con el nivel de seguridad requerido. Adquirir un equipo
especializado y sumamente costoso puede resultar exagerado teniendo en
cuenta la información expuesta dentro de la Extranet, en lugar de ésta,
soluciones menos costosas como las expuestas podrán cubrir de manera
satisfactoria sus necesidades de seguridad.
La inseguridad inherente a la Internet debe ponernos en un estado de alerta.
Ningún equipo o dispositivo elimina por completo las amenazas que presenta
la red global, los muros de seguridad y los sistemas para detección de
intrusiones, servicios y políticas de seguridad son solamente herramientas a
disposición del administrador para aumentar los niveles de seguridad dentro
de sus redes, estas herramientas se complementan entre sí y deben
implementarse de manera que apunten hacia un objetivo común definido
dentro del plan de seguridad de la red.
Luego de implementar cualquier medida de protección, se debe tener cuidado
de caer dentro de un falso sentimiento de seguridad, lo cual es aún más
peligroso que estar totalmente desprotegido pero conciente de aquello. Un
programa de evaluación deberá implementarse para mantener actualizado al
sistema de protección y garantizar su relativa inmunidad contra nuevas
formas de ataque.
Es recomendable conocer la posición del ISP en cuanto al tema de
seguridades y proponer las implementaciones descritas en el RFC 2827, los
resultados serán positivos tanto para el cliente como para el proveedor.
Dentro del presente caso de estudio al ISP le hubiera significado un
importante ahorro de 128 Kbps en ancho de banda satelital.
Finalmente se recomienda realizar el cambio periódico de las claves de
acceso de los dispositivos críticos dentro de la red, o por lo menos del
enrutador, así como la obtención de archivos de respaldo de su
configuración.
ANEXOS
A. FORMATOS PARA LINCAMIENTO BASE
B. MANEJO DE FILTROS Y LISTAS DE ACCESO
DENTRO DE RUTEADORES MOTOROLA VANGUARD
C. FUNCIONAMIENTO DE LA HERRAMIENTA
IPCHAINS DE LINUX
D. FUNCIONAMIENTO DEL PROGRAMA SQUID PARA
LINUX
Seg
men
to #
:
Des
crip
ción
:
Ubi
caci
ón:
1085
/Eth
erne
t10
B2
10B
T
Fec
haD
íaH
ora
INIC
IO:
FIN
:
Util
izac
ión
(%)
Tam
año
de T
ram
aT
ram
as p
or S
egun
do
Pic
oP
rom
edio
Est
adís
ticas
de
Red
Tra
mas
Byt
esP
roto
colo
s
Tot
al
Col
isio
nes
CR
Cs
Run
tsF
ragm
ento
sJa
bber
s
Tot
alP
or S
egun
do
Nod
o/E
stac
ión
Dire
cció
nP
roto
colo
s m
ás a
ctiv
os
# N
ombr
eF
ísic
aR
ed
Info
rmac
ión
a n
ivel
de
Est
ació
n
Act
ualiz
ado:
Seg
men
to #
:
Des
crip
ción
:
Ubi
caci
ón:
Fec
haD
ía
INIC
IO:
Hor
a
10B
5/E
ther
net
10B
210
BT
FIN
:
Rut
eado
r #
Nom
bre
Fab
rican
teV
ersi
ón d
e S
oftw
are
Ulti
ma
Con
figur
ació
n Filt
ros
#D
escr
ipci
ón
AC
L#
Des
crip
ción
Rut
as#
Red
Des
tino
Más
cara
NA
T#
Dir.
Priv
ada
Dir.
Glo
bal
Nex
t H
op
Not
as:
Hu
b#
Fab
rican
te:
Ver
sión
Sof
twar
e:
Hu
b#
Fab
rican
te:
Ver
sión
Sof
twar
e:
Puente
*F
abric
ante
:V
ersi
ón S
oftw
are:
Puente
*F
abric
ante
:V
ersi
ón S
oftw
are:
Obs
.
Act
ualiz
ado:
Hoja de Datos para Delineamiento Base de Aplicaciones
INICIO:
FIN:
Fecha
1 1 .L
Día Hora
Hoja #: 01 De: Datos de la Aplicación:
Paquete inicial No. Descripción de la Transacción Paquete Final No.
Proceso:
Conteo de Paquetes:
Duración del Proceso:
Observaciones:
Proceso:
Conteo de Paquetes:
Duración del Proceso:
Observaciones:
Proceso:
Conteo de Paquetes:
Duración del Proceso:
Observaciones:
Hoja #: De: Datos de la Aplicación:
Paquete inicial No. Descripción de la Transacción Paquete Final No.
Proceso:
Conteo de Paquetes:
Duración del Proceso:
Observaciones:
Proceso:
Conteo de Paquetes:
Duración del Proceso:
Observaciones:
Proceso:
Conteo de Paquetes:
Duración del Proceso:
Observaciones:
Proceso:
Conteo de Paquetes:
Duración del Proceso:
Observaciones:
III
B. MANEJO DE FILTROS Y LISTAS DE ACCESO DENTRO DE
RUTEADORES MOTOROLA VANGUARD (Motol|
Dentro de estos ruteadores, los filtros trabajan a nivel de la capa Inter-red
basándose en su dirección IP de destino, se utilizan para asegurar que
paquetes con formatos incorrectos, o con direcciones de destino inapropiadas
no sean encaminados dentro de la red. Evitan el encaminamiento hacia
direcciones especificas, y evita la difusión de cualquier información de
enrutamiento concerniente a tales direcciones.
El ruteador permite al usuario ingresar entradas dentro de una tabla de
filtrado, para descartar automáticamente paquetes dirigidos hacia direcciones
específicas.
Número de entrada12
255
Dirección IP (destino)x.x.x.xy-y-y-y
z.z.z.z
Máscara IPm.m.m.mm.m.m.m
m.m.m.m
Tabla B.l Filtrado dentro de ruteadores Motorola 1'angnard.
Adicionalmente, se puede hacer uso de las facilidades de control de acceso.
El control de acceso permite, mediante la elaboración de una lista (ACL o
/Access Control List), regular la forma en que los paquetes son encaminados
al examinar:
Las direcciones de origen y destino dentro den encabezado IP
- El tipo de protocolo dentro de la cabecera IP.
- El número de puerto dentro de los encabezados TCP o UDP.
El control de acceso dentro de Motorola trabaja de la siguiente manera.
Primero, el ruteador compara un paquete (recibido u originado) con la ACL
antes de compararlo con la tabla de enrutamiento:
- Si una dirección coincide con una entrada "inclusiva", el paquete es
encaminado.
- Si una dirección coincide con una entrada "exclusiva", el paquete
es descartado.
Si una dirección no coincide con ninguna entrada, el paquete es
descartado.
La lista de acceso se compone de varias entradas (hasta 255), cada una
puede ser de tipo "Inclusivo" o "Exclusivo", configurables por el usuario; La
siguiente tabla ilustra la forma de una lista de acceso:
Entrada12
255
TipoOrigen
Dirección MscDestino
Dirección MscProtocoloInicio Fin
PuertoInicio Fin
Tabla B.2 Forma de la Lista de Acceso dentro de los ruteadores Motorola 1'angmird.
Cada paquete IP recibido se compara con todas las entradas que conforman
la lista, en orden de número de entrada. Un paquete "coincide" con una
entrada cuando satisface las especificaciones de todos sus campos
(Dirección de Origen, Dirección de Destino, Protocolos, Puertos TCP/UDP)
• Tipo
Se refiere a la característica de la entrada, esto es, los paquetes que
coincidan con la entrada serán encaminados si ésta es de tipo Inclusivo, o
descartados si es de tipo Exclusivo; si un paquete no coincide con la
primera entrada se compara con las siguientes, de no coincidir con
ninguna, es descartado.
• Dirección de Origen, Máscara de Origen
Una dirección IP de origen coincide con el campo respectivo de la lista de
acceso, cuando el resultado de la operación lógica AND realizada entre la
dirección de origen dentro del paquete recibido y el contenido del campo
"Máscara de Origen" es igual al valor especificado dentro del campo
"Dirección de Origen" en la lista de acceso.
Un valor de 0.0.0.0 para los campos "Dirección de Origen" y "Máscara de
Origen" coincide con cualquier dirección de origen en un paquete IP; en
cambio, valores de 10.0.0.0 y 255.0.0.0, respectivamente, harán que
cualquier paquete IP con el valor 10 en el primer byte de la dirección de
origen satisfaga las especificaciones de Origen. Finalmente, un paquete IP
con dirección 192.168.1.16 satisface las especificaciones de Origen siempre
que los valores en los campos de dirección y máscara sean 192.168.1.16 y
255.255.255.255, respectivamente.
Debe estar claro entonces, que los campos de máscara dentro de la lista de
acceso no se refieren a la máscara de una dirección ip perteneciente a una
subred.
• Dirección de Destino, Máscara de Destino
Una dirección IP de destino coincide con el campo respectivo dentro de la
lista de acceso, cuando el resultado de la operación lógica AND realizada
entre la dirección de destino en el paquete recibido y el valor contenido en el
campo "Máscara de Destino" iguala al contenido especificado dentro del
campo "Dirección de Destino" en la lista de acceso.
Todo paquete IP coincide con el campo dirección de destino siempre que los
valores en los campos de Dirección y Máscara sean 0.0.0.0:
respectivamente. Todos los paquetes cuya dirección de destino inicie con los
bytes 10.100, cumplirá con los requisitos de Destino cuando los valores de
los campos de Dirección y Máscara sean 10.100.0.0 y 255.255.0.0
respectivamente.
Finalmente, un paquete IP con dirección 198.6.1.1 satisface las
especificaciones de Destino siempre que los valores en los campos de
Dirección y Máscara sean 198.6.1.1 y 255.255.255.255. respectivamente.
• Protocolo
Corresponde al Byte de protocolo, dentro del encabezado IP (sección
I. L 1.2.1). Los paquetes IP cuyos valores dentro del Byte de protocolo se
encuentren dentro del rango definido por los campos Inicio y Fin, inclusive,
coincidirán con las especificaciones de protocolo.
Todos los paquetes coinciden si los valores de inicio y fin son iguales a O y
255, respectivamente. Números de protocolo IP comunes son: 1 (ICMP), 6
(TCP), 17 (UDP), etc. (mayor información se encuentra en [REYNOLDS, J;
POSTEL, J; "Assigned Numbers" RFC 1700, Octubre 1994]).
• Puerto
Se refiere al número de puerto dentro del encabezado TCP o UDP. Un
segmento TCP o UDP satisface los requerimientos de puerto cuando el valor
dentro del encabezado está en el rango determinado por los contenidos de
los campos Inicio y fin (O a 65535).
Entre los puertos más comunes están: 21 (FTP), 23 (Telnet), 25 (SMTP), (
más información puede encontrarse en [POSTEL, J; "Transmission Control
Protocof RFC 793 Septiembre 1981] y [POSTEL, J; "User Datagram
Protocof RFC 768 Agosto 1980] ).
C FUNCIONAMIENTO DE LA HERRAMIENTA IPCHAINS DE
LINUX |Rus|
Recordando lo expuesto en (4.3.1.3 Muros de Seguridad), existen dos formas
básicas de muros de seguridad:
- Aquellos que implementan filtrado de paquetes.
Los que se basan en servidores Proxy.
La primera aproximación resulta un tanto obvia, la información viaja a través
de una red en forma de paquetes, al analizar su contenido se podrán
clasificar en "buenos" o "malos". Un filtro para paquetes consiste en una
unidad de software que decide el destino de cada paquete recibido luego de
haber observado el contenido de los encabezados IP y TCP/UDP. Las
decisiones se limitan a "aceptar" o "denegar" el paquete.
Los filtros pueden ser implementados dentro de enrutadores que dispongan
esta facilidad, o dentro de estaciones, en este caso, se podría utilizar el
sistema operativo LINUX, que es de distribución libre, e incluye opciones de
seguridad y de filtrado IP dentro de su /cerne/ (o módulo central). La
herramienta utilizada para especificar los paquetes a ser filtrados por el
kernel se denomina IPCHAINS.
IPCHAINS
La herramienta ipchains inserta y elimina reglas dentro de la sección de
filtrado de paquetes del sistema operativo.
ESQUEMA DE FILTRADO
El sistema operativo inicia con tres listados de reglas, conocidas como
"cadenas de seguridad" (Firewafl Chains) o simplemente "cadenas". Las tres
cadenas son: "Inpuf, "Forward", y "Outpuf
VIH
Cuando un paquete ingresa al sistema por una de sus interfaces, e! kernel
usa la cadena input para decidir su destino, si ha sido aceptado, el sistema
toma una decisión de enrutamiento, es decir, analiza si el paquete debe ser
enviado por otra interfaz (destinado para una red diferente) o no. Si debe
enviarse a otra red, consulta la cadena forward, finalmente, antes de que un
paquete abandone el sistema (sea por la misma interfaz o por una diferente),
la cadena outputes utilizada.
Una cadena entonces, consiste en un listado para la revisión del
cumplimiento de reglas, cada una tiene la forma:
SI: encabezado del paquete = condición.
Entonces: Aceptar (Denegar).
En el caso en que la regla no coincida con el paquete, la siguiente regla de la
cadena es consultada. Finalmente, si no coincide con ninguna de las reglas
de la cadena, el sistema consulta con la política de la cadena para decidir la
suerte del paquete. En consecuencia con el plan de seguridad, esta política
debería decirle al sistema que el paquete debe ser denegado (Denegar Todo
/ Permitir Todo ).
La figura C.1 representa el proceso de filtrado que se explica paso por paso:
FCS: Para cada trama recibida, el sistema calcula la suma de
comprobación y su resultado es comparado con el valor del campo FCS
dentro de la trama, si son iguales, se considera que la trama ha sido recibida
sin errores, caso contrario es descartada.
CONCORDANCIA: De hecho, existe una revisión de concordancia
antes de cada una de las cadenas, en la figura se ha representado la de la
cadena input por ser la más importante.
IX
fflOp o
IU"NI
FCS CONCORDANCIA U-U
Í[DE
CADENAINPUT
DENEGADO PROCESOLOCAL
DECISIÓN DERUTEO
FCS
s'TftoG
CADENAFORWARD
NI
u
Figura C.l Proceso de filtrado de paquetes mediante IPCHAINS.
Esta revisión es necesaria, pues algunos paquetes mal formados podrían
confundir al código de comprobación de reglas, los cuales se descartan en
este nivel (un mensaje se imprime en el sistema de registro de eventos
syslog).
CADENA INPUT: Consiste en la primera cadena contra la cual un
paquete entrante será comparado, si la decisión es aceptarlo, el paquete
continúa con el proceso.
DECISIÓN DE RUTEO: El campo de destino es examinado por el
código de ruteo para decidir si el paquete debe ir hacia un proceso local o
debe ser encaminado hacia una máquina remota.
PROCESO LOCAL: Un proceso local en la máquina puede recibir
paquetes luego de la decisión de ruteo. Un proceso puede también enviar
paquetes, en este caso irán a través del paso anterior (decisión de ruteo)
hacia la cadena output.
Cuando los paquetes de un proceso local son destinados para un proceso
local (figura C.1, línea azul), se dirigen hacia la cadena output con un
indicador de interfaz local (loopback) y luego atraviesan la cadena input.
CADENA FORWARD: Comparada con cualquier paquete que intente
atravesar esta máquina para llegar a cualquier otra.
CADENA OUTPUT: Todos los paquetes son sujetos a comparación,
con las reglas incluidas en esta cadena, justo antes de ser enviados.
Uso de Ipchains
Las operaciones principales tienen que ver con el manejo de cadenas
enteras, existen varias opciones, como la creación de nuevas cadenas,
eliminación de una cadena vacía, cambio de política, listado, o anulación de
todas las reglas de una cadena, etc.
Otras operaciones permiten manipular las reglas dentro de una cadena
específica, por ejemplo, el comando:
# ipchains -A input [condición] [acción]
Añade (-A del inglés Append) la regla [condición] [acción] a la cadena input,
existen otras opciones a más de añadir una regla, como: Insertar (-I),
Reemplazar (-R), o Eliminar (-D) una regla.
Operación de una Regla
Como se explica en el ejemplo anterior, cada regla especifica:
- Un conjunto de condiciones con las que un paquete debe cumplir.
Una acción a tomar en caso de que un paquete cumpla con la
condición.
XI
Condiciones: entre las opciones que se pueden utilizar para especificar las
condiciones con las que debe cumplir un paquete están:
• Especificación de las direcciones ip de origen y destino:
Las direcciones IP de origen (-s) y destino (-d) pueden especificarse de
diferentes maneras:
- Según el nombre completo, como "localhosf o "www.ietf.org"
- Mediante la dirección IP, como 198.6.1.1
- Un grupo de direcciones, mediante de la forma: 10.100.0.0/24 o
también: 10.100.0.0/255.255.0.0
• Especificación de inversión:
Varias banderas, incluyendo -s y -d pueden tener sus argumentos
precedidos por "!" (pronunciado "no.."), para que coincidan las direcciones
que no son iguales a las proporcionadas, por ejemplo: -s ! 192.168.1.10
especifica cualquier paquete proveniente de aquella dirección.
• Especificación del Protocolo:
Mediante la bandera -p [Protocolo], donde [Protocolo] puede ser el número
(RFC 1700) o el nombre respectivo, por ejemplo: -s localhost -p 6 , o su
equivalente, -s localhost -p tcp; se puede anteponer al nombre del protocolo
el prefijo ! para especificar inversión.
• Especificación de puertos TCP y UDP
Para el caso especial en que se desea especificar un protocolo, encapsuíado
dentro de tcp o udp, se puede añadir un argumento extra indicando el puerto,
o incluso un rango de puertos mediante la forma [puerto inicial]: [puerto final];
cuando uno de éstos se omite, su valor por defecto es asumido (O para
[puerto inicial], o 65535 para [puerto final] ).Se puede anteponer el prefijo !
para especificar inversión.
Ejemplos:
-p TCP -s 0.0.0.0/0 :1023 Especifica conexiones entrantes desde
puertos menores al 1024.
-p TCP-d 0.0.0.0/0 80 Designa conexiones al puerto TCP 80
(WWW) de cualquier máquina
-p TCP - d 192.168.1.1 ! 80 Especifica cualquier conexión con cualquier
puerto de 192.168.1.1 excepto el puerto 80.
Argumentos válidos son también: www, smtp, ftp (en lugar de 80, 25, 21, etc).
• Especificación del Tipo y Código ICMP
ICMP ofrece también un argumento opcional, el tipo y el código se
especifican por los parámetros -s y -d respectivamente.
• Especificación del interfaz
El interfaz es el dispositivo físico por el cual un paquete ha entrado o está por
salir; la opción -i especifica el nombre de un interfaz.
El nombre del interfaz puede estar precedido por un ! para especificar
inversión.
• Especificando únicamente paquetes TCP SYN
Es útil permitir conexiones TCP en una sola dirección, por ejemplo permitir
conexiones hacia un servidor WWW externo, pero impedir conexiones desde
ese servidor, bloqueando únicamente los paquetes usados para solicitar una
conexión (paquetes SYN). Ejemplo:
-p TCP-s 10.100.1.1 -y Especifica intentos de conexión provenientes de
10.100.1.1
Mil
• Manejo de Fragmentos
El problema de los fragmentos consiste en que sólo e! primer paquete del
mensaje fragmentado contiene el indicador apropiado dentro de la cabecera
IP, por lo tanto las reglas coinciden sólo con el primer paquete, no con el
resto.
Si la máquina es la única conexión con la red externa, se puede obligar al
sistema operativo a reensambiar todos los fragmentos que lo atraviesan al
compilar el /cerne/con la opción UIP: always defragment' fijada en "Y".
Como ejemplo, la siguiente regla descarta cualquier fragmento dirigido a
192.168.1.1
# ipchains -A output -f -d 192.168.1.1 -j DENY
• Especificación de la Acción
Efectos laterales del filtrado:
Cuando un paquete se empareja con una regla, ocurre lo siguiente:
- Incrementa el contador de bytes para esa regla, según el tamaño
del paquete (incluida la cabecera).
- Incrementa el contador de paquetes para esa regla.
- Si la regla lo requiere, e! paquete se registra
- Si la regla lo indica, el campo "Tipo de Servicio" es cambiado
- El paquete es marcado, siempre que la regla lo requiera
La acción especificada dentro de la regla se examina para decidir
el futuro del paquete.
La acción le dice al sistema operativo qué hacer con el paquete una vez que
ha empatado una regla. Ipchains usa el parámetro -j (jump to) para
especificar la acción.
XIV
El caso más simple es cuando no hay especificación de la acción, este tipo
de regla es útil para contabilizar cierto tipo de paquetes.
Existen varios tipos principales de acción:
ACCEPT: permite el paso del paquete.
DEA/Y: descarta el paquete y actúa como si no lo hubiese recibido.
REJECT. rechaza el paquete y (de no haber sido ICMP) genera una
respuesta ICMP para decirle al origen que el destino es inalcanzable.
MASQ: indica al sistema que el paquete debe ser enmascarado (re-escrito
mientras pasa por el muro de seguridad para aparentar provenir de éste),
esta acción es válida para paquetes atravesando la cadena forward.
REDIRECT: envía el paquete a un puerto local.
RETURN: el paquete se envía al final de la lista de comparación.
Cualquier otra acción indica una cadena definida por el usuario, el paquete
empezará a pasar por las reglas de dicha cadena, cuando ésta no ha
decidido el destino del paquete, continúa con la siguiente regla en la cadena
principal.
• Registro de paquetes
Con la bandera -I se puede registrar información relevante a ciertos eventos
no rutinarios o excepcionales.
Política de una Cadena
La política de una cadena dicta las acciones a tomar cuando un paquete ha
pasado por todas las reglas contenidas en dicha cadena y no se ha dado
equivalencia alguna, la política de cada cadena debe ser consecuente con
XV
(4.3. U. 3), y puede ser una de las siguientes acciones: ACCEPT, DEA/Y,
REJECT, MASK (válida sólo con la cadena forward).
Ejemplo:
# ipchains - P input DENY
Guardar y Restaurar una Cadena
La configuración de las reglas se realiza desde la línea de comandos, tratar
de recordar e ingresar nuevamente todo el arreglo utilizado en caso de
reiniciar el sistema resulta demorado y riesgoso.
El comando ipchains-save lee la configuración actual de una cadena
específica, o de todas las cadenas, y la guarda en un archivo junto con las
políticas de las cadenas INPUT, FORWARD, y OUTPUT.
Ejemplo:
# ipchains-save > filtros_firewall
Saving *input'.
Saving *output'.
Saving 'forward1.
Saving *definida_por_usuario_ 1 '.
Saving *definida_por_usuario_2'.
Las cadenas guardadas se pueden recuperar gracias al comando
ipchains-restore:
# ipchains-restore < filtros_firewall
Restoring ' 'input1.
Restoring 'output'.
Restoring 'forward'.
Restoring 'definida_por_usuaho_ 1 ',
Restoring 'definida_por_usuario_2'.
#
XVI
Una vez definido el grupo de reglas que operarán dentro del sistema se debe
crear el archivo que permita su posterior restauración, adicionalmente se
debe incluir una instrucción que ejecute el comando ipchains-restore cada
vez que el sistema sea reiniciado.
XVII
D. FUNCIONAMIENTO DEL PROGRAMA SQUID PARA LINUX
| Pea |
Squid es un servidor proxy/cache para clientes web. Actúa como un agente al
aceptar solicitudes de sus clientes (navegadores como Internet Explorer o
Netscape) y enviarlas hacia el servidor respectivo dentro de la Internet.
Squid guarda una copia local de la información retornada, cuando los mismos
requerimientos son posteriormente realizados, es la copia local la que se
entrega al cliente, ahorrando recursos de comunicación y agilitando el acceso
a la Internet.
Adicionalmente, Squid permite definir jerarquías de proxies en arreglos
complejos, soporta varios protocolos y permite configurar tiempos de refresco
de la información en disco para evitar la entrega de datos caducados.
Protocolos
Squid soporta dos tipos de protocolos:
a. Protocolos para comunicación Cache-Cliente
Squid acepta solicitudes entrantes pertenecientes a los siguientes protocolos:
• HTTP (HiperText Transfer Protocol) especificación en la que se basa
la www
• FTP (File Transfer Protocof)
• Gopher
• WAIS (Wide Área Information Service)
• SSL (Secare Socket Layer) utilizado para transacciones en línea
seguras
b. Protocolos para comunicación entre caches:
• HTTP, al obtener copias de objetos guardados en otros caches
XV11I
• ICP (ínter Cache Protocol) usado para averiguar si un objeto
específico se encuentra almacenado en otro cache
• Cache Digests. utilizado para traer un listado de los objetos
almacenados en otro cache
• SNMP (Single Network Management Protocol}
Requerimientos de Hardware
Los principales recursos para Squid se relacionan con la memoria, al manejar
altos volúmenes de caches es importante tener discos rápidos, y significativa
cantidad de memoria RAM. El procesador no necesita ser ultra-rápido.
A pesar de no existir reglas específicas en cuanto al dimensionamiento, una
buena recomendación es empezar con:
- Procesador pentium III de 700Mhz
- 256 o 512 MB en RAM
- Disco duro de 40GB
Que son especificaciones comunes dentro de los computadores actualmente
comercializados.
Configuración Básica del Servidor
Los archivos de configuración de Squid se guardan dentro del subdirectorio
nsr local squid ele
El archivo más importante para la configuración se denomina sqnidconf: El
proceso de configuración consiste en la edición de este archivo para incluir
varias etiquetas de opción. A pesar de que existe más de un centenar de
opciones se analizarán las mínimas necesarias para correr Squid.
Cuando no se especifica cierta opción el programa asume que se desea usar
el valor por omisión para dicha opción.
XIX
El siguiente es un ejemplo de configuración del archivo squid.conf; La
explicación de cada una de las opciones involucradas se encuentra en forma
de comentario (precedida por el signo #):
Archivo squid.conf:
# Configuración Básica para Squid
#
http_port 8080
#
#Esta opción especifica el puerto por el cual Squid recibirá las
#solicitudes http, su valor por omisión es el 3129. Muchos ISP utilizan el
#puerto 8080, que es más fácil de recordar.
#
cachemir usr/local/squid/cache/100 16 256
#
# cache_dir le indica al programa los directorios que puede utilizar para
#almacenamiento de información. Los parámetros incluidos son los
#valores por omisión: directorio (cache), cantidad -en MBytes- de
#almacenamiento dentro de éste (100 Mbytes), y número de
#subdirectorios (primero y segundo nivel) a ser creados dentro del
#directorio.
#
cache_mgr [email protected]
#
# Cuando el programa falla, un mensaje de correo electrónico es
#enviado a la dirección especificada. Esta dirección también es anexada
#al final de las páginas de error retornadas al usuario, por ejemplo
#cuando el host remoto no está disponible.
#
ftp_user [email protected]
#
#Squid también actúa como proxy para FTP, cuando se trata de un
^servidor FTP público, Squid se registra como usuario "anonimous" e
#ingresa como clave de acceso la dirección de correo especificada.
#
aci todaip src 0.0.0.0/0.0.0.0
#
#define una lista de acceso que incluye todas las direcciones IP
#
http_(iccess allow todaip
#
#permite a todos los clientes usar el cache
#
Configuración del Cliente
El navegador más común consiste en el Internet Explorer de la firma
Microsoft. Como lo muestra la figura D.1 los pasos a seguir para configurar al
cliente son:
1.- Seleccionar dentro del menú Tools, la opción Interntet Options.
2.- Elegir dentro de la etiqueta referente a conecciones (Connections)
las opciones de configuración LAN (LAN Settings...)
3.- Marcar el recuadro Use a proxy se/ver y especificar la dirección ip
del servidor proxy (ej 10.0.0.10) y el puero utilizado (en este caso
8080).
4.- Ir a las opciones avanzadas.
5.- Marcar sobre Use the same proxy
'¿J hllp://Hww2.idesoft-CQm/squid/basic_conf.txt - Microsoft InterneX X I
Inteinet LJptiorr:
Figura D.l Configuración de Internet Explorer como cliente
XX11
REFERENCIAS ANEXOS
|Motol| MOTOROLA DOCIIMENTATION; "IP and Lan l-eawre Protocola
Manual"
|Pea| PEARSON, Osear; "SOd/D: A llser's• Gtiide"
hlfp: scinid-iiocs.soiirceforge.net /atest html hookl.htm
|Rus] RUSSELL Ritsty; "Linnx IP CHAINS-HOWTO"
htíp: www.linnxt/oc.org HOWTO ¡WHAINS-HOWTO.html
[Wes| WESSELS, Duane; "Squid Programmers Guide"
http://www.squid-cache.org/Doc/Prog-Guide/prog-guide.html
