INTRODUCCION

Con el paso del tiempo los avances tecnolgicos van en pro de la facilitacin del
vivir diario de los humanos. Cada vez ms las tareas ejecutadas por las personas son
sustituidas por sistemas o redes automatizadas que las realizan de la manera ms eficiente y
rpida posible. En el mbito empresarial generalmente se recurre al la instalacin de redes o
sistemas automatizados para as lograr que sus proyectos alcancen los objetivos planeados
de una forma profesional y exitosa. Estas redes deben cumplir con una serie de
caractersticas fsicas y lgicas adaptadas a los requerimientos de un usuario en especifico.
Actualmente las redes implementadas estn sufriendo una serie de cambios, orientados a al
masificacin de su uso y a la mejora de su disponibilidad. Es por esta razn que muchas de
las redes que se usan comnmente son replanteadas buscando cumplir los objetivos
mencionados con anterioridad. Por una parte la configuracin fsica de las redes limita en
cierto grado el uso comn de las mismas, por lo que dispositivos inalmbricos, son
colocados en funcionamiento mucho ms a menudo. Estos dispositivos inalmbricos abren
un abanico de opciones para las disposiciones fsicas de las redes.
En las empresas cada vez es ms comn ver el uso de redes inalmbricas ya que
facilitan el acceso, en gran medida, a los recursos de los cuales esta dispone. Uno de los
recursos ms importantes, implementados y sobresalientes de las redes inalmbricas, es el
de los puntos de acceso inalmbricos a la red de internet. Muchos de estos son brindados a
los usuarios de forma abierta o por pago dependiendo de la demanda que caiga sobre este.
Tomando estas premisas en cuenta, el proyecto que se plantea a continuacin ofrece una
solucin rpida para la implementacin de un punto de acceso inalmbrico a la red de
Internet implementando herramientas de uso libre. Fundamentalmente se trabaj en el
diseo y montaje de los componentes bsicos que requiere tal sistema. En seguida se
presentar un esquema de ejecucin para el desarrollo de este proyecto que divide el mismo
en varios captulos:

Capitulo I: aqu se plantea claramente los objetivos, causas y fines del proyecto a
1

desarrollar.

Capitulo II: contiene un marco terico de las bases y trminos usados en la

consecucin del proyecto.

Capitulo III: describe la cronologa de los hechos y menciona la integracin con la

empresa .

Capitulo IV: contiene los componentes esenciales para el montaje del punto de
acceso inalmbrico.

Capitulo V: aqu se encuentran los parmetros bsicos de seguridad.

Capitulo VI: en este se contempla la distribucin de la red y su dominio.

Capitulo VII: contiene parmetros de configuracin a nivel de la capa de aplicacin.

Capitulo VIII: contiene la configuracin del hardware.

Capitulo IX: integra los componentes del punto de acceso

CAPITULO I:
Planificacin y Objetivos
1.1 Planteamiento del Problema
1.2 Objetivo General
1.3 Objetivo Especifico
1.4 Justificacin
1.5 Alcance del Proyecto
1.6 Limitaciones

CAPITULO I
Planificacin y Objetivos
1.1 Planteamiento del problema
La empresa Corvus Latinoamrica es una entidad orientada al desarrollo y soporte
de productos informticos utilizando software de cdigo abierto y libre, razn por la cual
decidi abrir un proyecto para el desarrollo de un nuevo producto que consiste en un
servicio de acceso a Internet de forma inalmbrica, que provea seguridad, estabilidad y
rapidez para el manejo de los datos, tomando en cuenta que para acceder al servicio se
podra pagar una cuota establecida.
1.2 Objetivo general
Creacin un servicio para proveer acceso inalmbrico a internet, que permita la
conexin de forma segura, transparente y rpida de clientes que se encuentren dentro del
rea de transmisin, utilizando la tarjeta D-LINK DWL-500 configurada bajo la plataforma
GNU/LINUX.
1.3 Objetivo especfico

Diseo de un Firewall usando un complemento nativo del sistema operativo Linux

Montaje de un servidor DHCP utilizando una aplicacin de Linux

Montaje de un servidor DNS a base del servicio BIND9

Montaje y diseo de un servidor Proxy usando como herramienta SQUID3

Montaje de un servidor Web a base del servicio Apache2

Configuracin del hardware usado para la trasmisin de los datos

Unin de todos los servidores para el armado del punto de acceso inalmbrico

1.4 Justificacin
Cada vez las redes de acceso inalmbrico son ms usadas en cualquier sitio donde
exista gran concurrencia de gente que necesite por cualquier causa una conexin a internet.
La ventaja del uso de este tipo de redes es que se puede acceder a ellas sin la necesidad de
conexin cableada, debido a que los puntos de conexin no tienen un lugar fijo y en vez de
esto el servidor central proveedor del la conexin transmite su seal dentro de un radio en
especfico permitiendo a los clientes acceder desde cualquier lugar, siempre y cuando
cuenten con un dispositivo que permita establecer tal enlace. Muchos computadores
porttiles y equipos de telefona mvil actualmente estn dotados con elementos que
permiten la conexin a estas redes inalmbricas ampliando as la cantidad de posibles
usuarios.
Una de las premisas para el desarrollo de este proyecto, fue usar herramientas de
software libre, las cuales adems de ser seguras y robustas, por su naturaleza son flexiblesy
permiten adaptarlas fcilmente a diversas necesidades. Adems no requieren licencias.
1.5 Alcance del proyecto
El desarrollo de este proyecto le permitir a la empresa seguir mejorando todos sus
sistemas y tambin agregar un nuevo producto a su lista de servicios. En este informe slo
se reflejar el montaje e integracin de los servicios bsicos en el servidor central que
permitir la conexin a Internet de forma confiable, rpida y estable de los usuarios a
travs de nuestro punto de acceso inalmbrico. Los elementos que podran ser usados para
el control de pagos por parte de los usuarios, se realizan a base de programacin pura por lo
que esta parte se escapa del alcance del proyecto.
1.6 Limitaciones del proyecto
Las limitaciones que se encontraron durante el despliegue del proyecto fueron las
siguientes:
5

El bajo conocimiento acerca de las redes de computadoras

Como la plataforma del la red est sobre GNU/LINUX, fue necesario

invertir un tiempo apreciable que permitieran la familiarizacin y
adiestramiento en esta herramienta.

No haban los equipos suficientes como para realizar pruebas a gran escala.

El enlace que se usara para la conexin del punto de acceso no era el que
provena directamente del ISP (Proveedor de Servicio de Internet), sino el
que se obtena de una red privada razn por la cual no se pudo usar el
ancho de banda completo para realizar pruebas de consumo.

CAPITULO II:
Marco Terico
2.1 Direccin Ip
2.2 Protocolo TCP
2.3 Protocolo UDP
2.4 Protocolo ICMP
2.5 Redes Inalmbricas
2.6 Servidor DHCP
2.7 Servidor DNS
2.8 BIND-DNS
2.9 Servidor Proxy
2.10 Squid
2.11 Cortafuegos Firewall
2.12 Iptables
2.13 Software de uso libre
2.14 Apache
2.15 Tarjeta de red inalmbrica

CAPITULO II
Marco Terico
En este captulo se presentar la teora bsica y necesaria para la comprensin de
las diferentes acciones hechas durante el desarrollo del proyecto. Dada mi formacin
acadmica en la cual adquir pocos conocimientos acerca de las redes informticas, tuve
que aprender y estudiar diversos trminos, definiciones, protocolos y sistemas que se usan
constantemente en estas redes. Direccionamiento ip, protocolo tcp, clases de redes,
servidores, software libre y otros temas relacionado a las redes, son mencionados a
continuacin. Casi toda la informacin aqu propuesta se puede conseguir en la web en
sitios como: es.wikipedia.org, monografias.com, bulma.net, ecualug.org, ubuntu-es.org y
otros como los de universidades de otros pases (ver referencias bibliogrficas para ms
informacin). En resumen, este captulo servir de gua terica para comprender casi toda
la parte prctica realizada a lo largo del proyecto.
2.1 Direccin IP
En trminos simples la direccin IP (Protocolo de Internet), es la cdula de
identidad que posee cada dispositivo dentro de una red determinada. Cuando creamos una
red, los dispositivos conectados a ella deben poseer una identificacin nica que permita
ubicarlos de forma rpida y sencilla. El protocolo de Internet es el sistema de identificacin
lgica y jerrquica, que se ha estandarizado para dar direcciones a los dispositivos dentro
de una red. Esta direccin que se le da a los dispositivos de una red, generalmente se hace
por medio de un servidor DHCP (Protocolo de Configuracin Dinmica de Servidor), quien
le otorga de forma automtica todos los parmetros de identificacin que requiere la
estacin. Otra opcin es configurando todos estos parmetros de forma manual en cada
equipo de la red. Los parmetros de identificacin son establecidos de acuerdo a los
lineamientos que especifica cada versin del protocolo de internet. Existen dos versiones
actualmente utilizadas: la Ipv4 que es la utilizada comnmente, y la IPv6 que se est
empezando a implementar debido a las limitaciones de la IPv4.
8

2.1.1 IPv4
Esta versin del protocolo especifica un nmero de 32 bits para toda la direccin
total, divididas en 4 campos de un octeto. Generalmente es expresada de forma decimal con
cifras que llegan hasta 255, por cada campo de la direccin:
B3.B2.B1.B0
donde los campos B3,2,1,0= n E [0..255]
Ejemplo de una direccin ip: 192.2.3.78
Partiendo de este enunciado poseemos la cantidad de 4.294.967.296 direcciones
distintas, de las cuales la ultima cifra 255.255.255.255, est reservada para la difusin hacia
todas las mquinas cuando es requerida una identificacin IP, las direcciones 127.x.x.x
estn reservada para las llamadas internas del equipo, es decir locales; y la 0.0.0.0 es la
direccin al encender el dispositivo. Con esto se establece una clasificacin para las redes
segn sus direcciones IP (Partes de este prrafo extradas de las clases de Prof. Ricardo
Strusberg).
2.1.2 Clases de Redes
Segn la web: http://es.wikipedia.org/wiki/Direccin_IP, en la IPv4 las redes van
clasificadas de la siguiente manera:

Clase A: En una red de clase A, se asigna el primer octeto para identificar la red,
reservando los tres ltimos octetos (24 bits) para que sean asignados a los hosts, de
modo que la cantidad mxima de hosts es 224- 2 (las direcciones reservadas de
broadcast [ltimos octetos a 255] y de red [ltimos octetos a 0]), es decir,
16.777.214 hosts. El nmero posible de redes slo es hasta 126, y tiene un rango
desde la direccin 1.0.0.0 hasta la 127.255.255.255. La mscara de red que
corresponde con esta clase es 255.0.0.0.
9

Clase B: En una red de clase B, se asignan los dos primeros octetos para identificar
la red, reservando los dos octetos finales (16 bits) para que sean asignados a los
hosts, de modo que la cantidad mxima de hosts es 216- 2, o 65.534 hosts. El
nmero posible de redes es de 16.384 y tiene un rango de direcciones que va desde
128.0.0.0 hasta 191.255.255.255. La mscara de red que corresponde con esta clase
es la 255.255.0.0.

Clase C: En una red de clase C, se asignan los tres primeros octetos para identificar
la red, reservando el octeto final (8 bits) para que sea asignado a los hosts, de modo
que la cantidad mxima de hosts es 28- 2, o 254 hosts. El nmero posible de redes
es de 2.097.152 y tiene un rango que va desde 192.0.0.0 hasta 223.255.255.255. La
mscara de red correspondiente a esta clase es de 255.255.255.0.
Existen dentro de estas clases de redes ciertos rangos que son reservados para el

uso privado. Estas redes privadas tambin pueden identificarse segn su clase. Las red
privada de clase A va desde 10.0.0.0 hasta 10.255.255.255, con una mscara
correspondiente a 255.0.0.0. La red privada de clase B va desde 172.16.0.0 hasta
172.31.255.255, con una mscara de red de 255.255.0.0. La red privada de clase C va desde
192.168.0.0 hasta 192.168.255.255, con una mscara de red de 255.255.255.0.
2.1.3 Mscara de subred
La mscara de subred permite identificar en una direccin ip, cul es el nmero
que corresponde con la red solicitada. Esto se hace mediante una funcin lgica AND que
se lleva a cabo en cada interfaz de red, entre la mscara de red y su direccin ip. El
siguiente ejemplo fue tomado de una de las clases de Prof. Ricardo Strusberg, y explica
claramente el proceso por el cual se obtiene la mscara de subred:
IP: 10.0.0.5; mscara de red: 255.0.0.0; mscara de subred: ?
se realiza una AND entre la direccin IP y la mscara,
10.0.0.5 AND 255.0.0.0 = 10.0.0.0
10

mscara de subred

Aqu vemos como la mscara nos especifica cul es la red a la que pertenece la
direccin 10.0.0.5 que es la 10.0.0.0.
2.2 Protocolo TCP
El TCP Transmisin Control Protocol (Protocolo de Control de Transmisin), es
un sistema orientado al establecimiento de conexiones seguras entre dos estaciones,
actuando en la capa de transporte y conectndolo con la capa de aplicacin. Este protocolo
garantiza que cualquier conexin nueva hacia una estacin con un servicio determinado,
llegue a su destino por medio de la identificacin de los paquetes con una serie de
segmentos que contienen informacin pertinente para la orientacin de la data. En TCP ,
para realizar una conexin se identifican todos los servicios disponibles por medio de un
nmero de puerto. El nmero de puertos disponibles es de 216 = 65356, lo suficiente como
para sostener bastantes servicios individuales, y adems, no es necesario tener ms puertos
porque una aplicacin no est atada a un puerto determinado, mas bien, la aplicacin como
tal al momento de ser diseada y creada, puede elegir cualquier puerto para el
establecimiento de una conexin; claro est que la IANA Internet Assigned Numbers
Authority (Autoridad que Asigna Nmeros en Internet), ya asign puertos para distintos
servicios bsicos y comunes, y estos no pueden ser usados por una aplicacin nueva
porque creara conflictos de comunicacin. Adems de esto el protocolo TCP se encarga de
corregir errores de transmisin por medio del uso de segmentos que facilitan el seguimiento
tanto de los datos, como del enlace hecho. Las caractersticas ms resaltantes de este
protocolo son las siguientes:

Transmisin y conexin segura de datos

Multiplexacin

Control de flujo de datos

Conexin full-duplex

Correccin a perdida de datos

11

2.2.1 Transmisin y conexin segura de datos

Al momento en que se procede a enviar cierta data, el protocolo TCP utiliza unos
segmentos que le permitirn realizar una conexin previa con una estacin ubicada en otra
red, para que posterior a esto se enven los datos que se requieran. Cada uno de los
segmentos, especificados en la figura 1, cumple con una funcin de control al momento del
enlace. En alguno de los bloques de bits se expresarn nmeros especficos y en otros
bloques, los bits, se usarn individualmente para representar estados de conexin.
Bsicamente el formato de los segmentos TCP tiene las siguientes caractersticas:

Puerto de origen 16 bits

Puerto de destino 16 bits

Nmero de secuencia 32 bits

Nmero de acuse ACK 32 bits
Longitud
de cabecera
TCP 4 bits

Reservado
4 bits

Ventana 16 bits

Flags TCP 8 bit

Check-Sum 16 bits

Puntero de urgencia

Opciones y Relleno (campo opcional) 32 bits

DATOS 64 bits

Longitud total = 224 bits

Figura 1. Formato de los segmentos TCP

Puerto de origen: especifica cul es el servicio que realiza la solicitud. Se hace el

reconocimiento del servicio ya que se conoce su puerto asociado.

Puerto de destino: especifica hacia que servicio se dirige la solicitud mediante la

conexin al puerto que corresponda con la aplicacin

Numero de secuencia: indica en que orden vendrn los paquetes y adems sirve de
monitor por si algn paquete se perdi en el camino. Un flag (bandera) de
sincronismo indica el nmero de comienzo de la secuencia; si el SYN=1 entonces el
12

nmero presente en ese instante indicar el comienzo de la secuencia, asegurando

que el primer dato vendr identificado con ese nmero ms 1. Cuando SYN=0
entonces el nmero presente en ese instante indicar el nmero de la secuencia del
primer byte de datos .

Nmero de acuse de recibo ACK: ste, seala el nmero de secuencia del ltimo
byte de datos que se espera.

Longitud de la cabecera TCP: indica que cantidad de bytes existe entre la cabecera
de la trama TCP y el segmento de los datos. Es muy importante esta informacin
debido a que el campo opcional generalmente varia de tamao.

Reservado: ste es reservado para uso futuro.

Flags (banderas): tienen una longitud de 8 bits y cada uno de ellos indica una
funcin distinta dependiendo de si se activan o no:
ACK: si est activo, indica el acuse de recibo
URG: si est activo, indica que el paquete es urgente
PSH: si est activo, indica que los datos deben ser enviados inmediatamente al
buffer
SYN: si est activo, indica una llamada para el inicio de una conexin
RST: si est activo, indica que la conexin se cay y continu de nuevo
FIN: si est activo, indica que la conexin ya se cerr
CWR: si est activo en el emisor, indica que se a recibido un bit de ECE por parte
del receptor. Este bit sirve para saber el congestionamiento de la red
ECE: si est activo en el receptor, indica que el receptor puede enviar estas
banderas constantemente

Ventana: en este campo se escribe la longitud de datos que el receptor espera recibir.

Check Sum (suma de chequeo): aqu se coloca unos nmeros que sirven para
comprobar si existen errores en los datos enviados o en la cabecera TCP.

Puntero urgente: este campo contiene un nmero que indica la longitud que hay
desde un ltimo nmero de secuencia de paquete de datos con flag URG hasta el
prximo que vendr.

13

Relleno y opciones: aqu se colocan mltiples opciones con una longitud de bits que
sea mltiplo de 32, si no es as se aproxima el nmero hasta la cifra mltiplo ms
cercana.
2.2.1.1 Inicio de conexin Three-Way-Handshake
El inicio de una conexin TCP se hace por el mtodo de Three-Way-Handshake

(negociacin en tres pasos). El nodo transmisor enva una seal de SYN al nodo receptor,
si el receptor acepta la conexin ste devuelve una seal de acuse de recibo ACK ms la
seal de SYN, cuando el nodo transmisor recibe todo esto procede a enviar su acuse de
recibo en conjunto con los datos que se quieren enviar. Con estos tres simples pasos se
asegura una conexin de forma rpida. Dentro de estos pasos siempre se envan nmeros de
secuencia que permitirn llevar el conteo de los paquetes de datos en transferencia y as
tener cierto control de errores. Cuando nos referimos al nmero de secuencia que lleva el
transmisor lo denominamos nmero de secuencia y cuando hablamos del receptor, el
nmero se llama nmero de asentimiento. En conjunto con esto se enva la suma de
verificacin que permite saber la integridad de los datos de un paquete TCP. El chek-sum
abarca casi toda la cabecera del TCP, es decir los primeros 96 bits del paquete; con lo que
proporciona un chequeo de errores para los segmentos de destino, origen, nmeros de
secuencia y nmero de acuse de recibo ACK.
SYN seq=z

SYN =1 AC

y+1
K=z+1 seq=

DAT O S

Nodo
Transmisor

SYN =0 AC K=
y+1 seq=z+
1

Figura 2. Negociacin en tres pasos

14

Nodo
Receptor

Otra de las ventajas de TCP es que puede realizar un reconocimiento acumulativo

de tal forma que el receptor avise hasta que flujo de bytes se recibieron los datos completos.
En el instante en que el nodo emisor transmite los datos, un temporizador es activado a la
espera de que se reciba una seal por parte del receptor de que los datos se recibieron
correctamente; si el emisor termin su conteo y aun no se a recibido ningn tipo de aviso,
ste proceder al reenvo de los datos. Si se recibe una seal de confirmacin de que los
datos fueron recibidos el temporizador regresa a cero.
2.2.1.2 Fin de la conexin
La finalizacin de una conexin, se realiza con la misma cantidad de pasos que se
requieren para el inicio de una conexin. Un nodo transmisor enva una seal de FIN-WAIT
para avisar que est apunto de cerrar la conexin en cuestin, cuando el nodo receptor
recibe esta seal, procede al envo de una seal de acuse de recibo ms otro aviso de
finalizacin de conexin, FIN-WAIT. La conexin termina al momento en que el nodo
transmisor acepta esta seal y procede al envo de la bandera de cierre de la conexin;
CLOSE.

FIN- WAIT 1

FIN -WAIT

CLO SE

Nodo
Receptor

Nodo
Transmisor

Figura 3. Finalizacin de la conexiones

15

2.2.2 Multiplexacin
La capacidad de multiplexacin que posee el protocolo TCP se refiere a la
cantidad de puertos que puede utilizar un usuario a la vez. En la capa de aplicacin hay
diversos servicios que usan un determinado puerto para comunicarse. Un usuario puede
estar manipulando varios a la vez y un slo canal de salida para varias aplicaciones sera
algo problemtico a la hora de la identificacin. Es por eso que TCP ofrece mltiples
puertos que permiten etiquetar todos los servicios que puedan existir.
Usualmente los sistemas operativos designan algunos puertos para uso de sus
aplicaciones, y en ocasiones, las mismas aplicaciones vienen con su nmero de puerto
designado a usar, en caso de que no sean originarias del sistema.
La cantidad de puertos posibles es de 216 puertos, por lo que en total existe un
nmero de 65.536 puertos habilitados y disponibles. Los primeros 1023 puertos se
denominan puertos reservados o seguros. Estos puertos son usados por las aplicaciones del
bsicas del sistema y generalmente estn en modo listening (escuchando) o a la espera de
solicitudes. Los puertos que van desde 1024 hasta 49151 son los llamados puertos
registrados, usados por aplicaciones de origen externo al sistema y los puertos dinmicos o
privados, son aquellos que van desde 49152 hasta 65535.
La IANA Internet Assigned Numbers Authority (Autoridad que Asigna Nmeros
en Internet), asign una amplia cantidad de puertos para diversos servicios comunes que
funcionarn en cualquier sistema. En la tabla nmero 1 se puede apreciar una serie de
puertos asignados a servicios bsicos:

16

Tabla 1. Algunos puertos bsicos asignados por IANA

(fuente:wikipedia.org)

2.2.3 Control de flujo de datos

Esta caracterstica del TCP tiene la funcin de controlar la cantidad de datos
enviados por el emisor y por ende controlar el ancho de banda de la conexin. Cuando un
nodo transmisor enva una serie de datos, el receptor, previamente debe establecer que
cantidad de datos puede almacenar en su buffer1, para que as el nodo transmisor pueda
controlar el flujo en base a lo que sabe de su receptor. Hay varios mtodos que implementa
el TCP para lograr el control de la tasa de transferencia y estos mtodos son los siguientes:
1 Buffer es el trmino designado para nombrar a cierta parte de una memoria de computadora, que trabaja
con datos de informacin temporales.

17

2.2.3.1 Mtodo de la ventana deslizante

Este mtodo consiste en fijar un lmite a la cantidad de datos enviados y desplazar
este lmite conforme se reciba una seal de confirmacin.
Tamao de ventana = n
P0

P1

P2

P3

P4

P5

P6

P7

P8

P9

P10

Pn

Longitud mxima de datos aceptados del receptor Pn

Figura 4. Mtodo de ventana deslizante

Ms explcitamente, cuando se fija un tamao de ventana en el emisor
correspondiente a la capacidad de datos que puede soportar el receptor, los paquetes son
enviados a medida que el receptor mande una confirmacin de ACK. Se pueden enviar
varios paquetes sin confirmacin de recibo, pero slo hasta el lmite de la longitud de la
ventana. Cuando llega la bandera de ACK, la ventana se desliza y existe la oportunidad de
enviar otro paquete porque una casilla va quedando vaca. En la figura 5 se puede ver como
P0 ya ha sido enviado, la ventana se desplaz por una seal de ACK y hay, tanto 3 casillas
llenas como una casilla nueva disponible que corresponde con la P4.
Tamao de ventana = P3
P0

P1

P2

P3

P4

P5

P6

P7

P8

P9

P10

Pn

ACK= 1

Desplazamiento de ventana

Longitud mxima de datos aceptados del receptor Pn

Figura 5. Proceso de deslizamiento

Este proceso controla directamente la tasa de transferencia, lo nico que aqu no se
especifica, es qu tamao tendr la ventana o quin le dice a la ventana su longitud de
18

configuracin.
2.2.3.2 Mtodo de sistemas de crdito
Este sistema advierte al emisor sobre que cantidad de paquetes que puede enviar
en un slo instante. Cuando el tamao de la ventana es marcado, se indica que cantidad
mxima de paquetes podrn ser enviados. El receptor, cede unos certificados para llevar el
control de paquetes recibidos. Los certificados se envan antes de que se emita algn tipo de
confirmacin de recibo ACK. Esto le permite al nodo transmisor enviar datos aunque los
datos precedentes no hayan sido todava acusados, confiando que llegar su acuse antes del
tiempo lmite establecido.
2.2.4 Conexin Full-Duplex
Las estaciones que han establecido una conexin exitosa, pueden ahora
intercambiar datos y seales de control al mismo tiempo. Los nodos estn en puertos
distintos, lo que permite la entrada y salida simultanea de datos. Al momento de que un
nodo habla, puede al mismo tiempo estar escuchando a la estacin remota. Esto permite
mucha versatilidad de TCP y adems le da una velocidad de respuesta de control excelente.
2.2.5 Correccin a perdida de datos
Una de la forma que TCP adopta para corregir la perdida de datos, es mediante el
reenvo de los paquetes. Los paquetes de datos siempre sufren desordenes durante su paso
por los medios fsicos. En las conexiones establecidas y en proceso, banderas de ACK,
SYN, RST y nmeros de secuencia permiten recuperar los datos. Si un paquete es enviado
y por alguna razn se pierde en el camino, el receptor del paquete no recibe nada y por ende
no puede enviar confirmacin de recibo. La estacin receptora sabe que no ha recibido
nada y tambin sabe que la informacin no est completa del todo, porque lleva la cuenta
de los paquetes que llegarn mediante los nmeros de secuencia. El nodo transmisor est
19

esperando el acuse de recibo por parte del receptor para continuar con la transmisin
normal de la data. Si no se ha obtenido el acuse an, un timer2 ya iniciado, incrementa sus
dgitos hasta que llegue al final. Si el contador termina su cuenta y an no existe acuse de
recibo, la data se vuelve a reenviar.
2.3 Protocolo UDP
El UDP User Datagram Protocol (Protocolo del datagrama de usuario) es un
protocolo orientado al intercambio de datos en la red sin tener conexin alguna. Este
protocolo no asegura la transferencia de informacin de forma segura ya que no posee
ningn tipo de mecanismos de control.
Puerto de origen 16 bits

Puerto de destino 16 bits

Longitud de trama 16 bits

Suma de verificacin 16 bits

DATOS

Figura 6. Formato UDP

La idea del UDP es que los datos fluyan libremente entre las estaciones, sin reglas
complejas como las determinadas por el TCP. Esto da cabida para que el protocolo tenga un
porcentaje de velocidad alto. El UDP generalmente se usa para manejo de audio y vdeo,
donde es necesario que la tasa de transferencia sea relativamente alta y adems se requiere
que la informacin llegue sin retraso alguno. Proporciona tambin un enlace entre la capa
de aplicacin y la capa de red. Los campos del formato UDP son los siguientes:

Campo de origen: Indica el puerto de origen. Este campo mucha veces no es

necesario, por lo que se debe llevar a 0 cuando sea as.

Campo de destino: Este campo indica el destino del paquete como tal. En el se
especifica el nmero de puerto al que se habla.

2 Termino usado para referirse a un reloj de conteo o temporizador.

20

Campo de longitud de trama: Especifica qu longitud posee el datagrama en

cuestin.

Campo de suma de verificacin: este campo no es tan necesario tampoco, slo

posee un suma de verificacin de integridad de la misma forma que lo hace TCP y
es el nico mecanismo de comprobacin que posee UDP. Si la suma de control
calculada es cero, se transmite como un campo de unos (el equivalente en la
aritmtica del complemento a uno). Un valor de la suma de control trasmitido
como un campo de ceros significa que el el emisor no gener la suma de control
(par depuracin o para protocolos de ms alto nivel a los que este campo les sea
indiferente).
2.4 Protocolo ICMP
ICMP Internet Control Menssage Protocol (Protocolo de Mensajes de Control en

Internet), es usado para enviar mensajes de error en los paquetes de datos al momento de
una transferencia, para saber si se ha vencido el tiempo de vida de una solicitud, para
identificar una conexin reciente o para el seguimiento de rutas que puede tomar un
paquete cuando por cualquier razn de pierde en el camino. ICMP, slo se genera al
momento de un error en la recepcin de un paquete y esto se hace de forma automtica
durante la comunicacin, lo que significa que el usuario no interviene directamente con el
protocolo en ese instante. El usuario slo usa el ICMP cuando quiere saber la existencia de
otro hosts (nodos) o quiere conocer los sitios por donde pasa un paquete. Es aqu donde se
puede interactuar con ICMP especficamente por medio del uso de ping o traceroute3. Todo
su funcionamiento se ubica en la capa de transporte del modelo OSI.
Tipo (8 bits)

Cdigo (8 bits)

Suma de verificacin (16 bits)

Datos (opcionales)

Figura 7. Formato ICMP

3 Ping y traceroute son comandos en consola usados en los sistemas operativos de LINUX, para monitorear
el estado de ciertas conexiones.

21

El segmento Tipo aloja nmeros que indican mensajes de informacin en

especfico. El segmento Cdigo contiene nmeros que hacen referenciamensajes de
errores y por supuesto el check-sum para verificar la integridad del paquete ICMP. En las
siguientes tablas se muestran los nmeros con sus respectivos significados:
Tabla 2. Mensajes informativos

Tabla 3. Cdigos de error

Echo Reply (respuesta de eco)

no se puede llegar a la red

Destination Unreacheable(destino inaccesible)

Source Quench (disminucin del trfico desde

el origen)

no se puede llegar al host o aplicacin de

destino

el destino no dispone del protocolo solicitado

Redirect (redireccionar - cambio de ruta)

Echo (solicitud de eco)

no se puede llegar al puerto destino o la

aplicacin destino no est libre

11

Time Exceeded (tiempo excedido para un

datagrama)

no se puede llegar al puerto destino o la

aplicacin destino no est libre

12

Parameter Problem (problema de parmetros)

la ruta de origen no es correcta

13

Timestamp (solicitud de marca de tiempo)

no se conoce la red destino

14

Timestamp Reply (respuesta de marca de

tiempo)

no se conoce el host destino

el host origen est aislado

15

Information Request (solicitud de informacin) obsoleto

la comunicacin con la red destino est

prohibida por razones administrativas

16

Information Reply (respuesta de informacin) obsoleto

10

la comunicacin con el host destino est

prohibida por razones administrativas

17

Addressmask (solicitud de mscara de

direccin)

11

no se puede llegar a la red destino debido al

Tipo de servicio

18

Addressmask Reply(respuesta de mscara de

direccin

12

no se puede llegar al host destino debido al

Tipo de servicio

2.5 Redes inalmbricas

Las redes inalmbricas son configuraciones de dispositivos conectados entre s
utilizando nicamente el espectro radioelctrico como medio para la transferencia de
informacin entre ellos. Al igual que una red sencilla con medios almbricos, esta sigue los
estndares establecidos por el modelo OSI en cuanto al procesamiento de los datos,
establecimiento de conexiones, traduccin de sintaxis de datos y todos los procesos
implcitos en las primeras 5 capas (BUETTRICH y ESCUDERO. Octubre 2006).

22

INTERNET

Figura 8. Red inalmbrica

Desde el punto de vista de eficiencia, las redes inalmbrica an no superan a las

redes almbricas, debido a limitaciones fsicas por parte de los medios sin cables.
Usualmente una conexin de dispositivos por medio de cables puede llegar a una tasa de
transferencia de informacin de 100 Mbps y 1Gbps. Algunas de las redes wireless
(inalmbricas), estn basadas en el protocolo IEEE 802.11b y g (ver captulo 1, IEEE
802.11), por lo que no superan a estas redes. No obstante, existen otro tipo de redes
wireless basadas en el protocolo IEEE 802.11n que est alrededor de 600Mbps tericos que
supera los 100Mbps de algunas redes, ms no los 1Gbps de otras redes de ethernet4. Sin
embargo las ventajas que tienen las redes sin cables son muchas, desde la posibilidad del
desplazamiento de las estaciones, hasta el acceso al medio desde cualquier lugar,
4 Segn la web: http://es.wikipedia.org,ethernet es un estndar de redes de computadoras de rea local con
acceso al medio por contienda CSMA/CDes (Acceso Mltiple por Deteccin de Portadora con Deteccin
de Colisiones), es una tcnica usada en redes Ethernet para mejorar sus prestaciones.

23

dependiendo de la configuracin de los puntos de acceso.

Fundamentalmente, las ventaja ms grande que trae ese tipo de redes es la
movilidad y disponibilidad que pueden tener. El diseo de una red cableada de rea local,
por lo general lleva mucho ms esfuerzo de planificacin comparado con una red WLAN.
En la red cableada se necesitan establecer las tarjetas de red, los sistemas de cableado, los
dispositivos enrutadores, los puntos de conexin y otros elementos necesarios, para que as
funcione adecuadamente la red y podamos ofrecer los servicios a usuarios. En cambio una
red wireless no requiere tanto esfuerzo de diseo ni montaje debido que slo se necesita
una tarjeta que sirva de punto de acceso, y otras que puedan acceder al punto. Aqu no se
necesita pensar donde termina un punto de acceso para una conexin, ni a que distancia se
encuentra de la estacin servidora, porque el enlace se puede hacer desde cualquier sitio
dentro del rango de radiacin del transmisor, incluso, puedes mover el punto de donde estas
conectado, sin lmite, ms que el del alcance de la seal del punto servidor, que
normalmente es bastante amplio.
2.5.1 IEEE 802.11
Es un estndar de comunicacin que especifica los modos de trabajo para redes
inalmbricas en sus capas inferiores segn el modelo OSI: la capa de enlace y la capa
fsica. Dentro de esta especificacin se menciona todo lo relacionado con redes que trabajen
de forma inalmbrica. Hay muchas extensiones de este estndar, debido a la multiplicidad
de caractersticas que presentan estas redes. Existen varios protocolos dentro de la IEEE
802.11 y un resumen de estos, extraidos de : http://es.wiquipedia.org, se presenta a
continuacin:

802.11 legacy, esta corresponde a la primera versin con transferencias de 1 Mbps y

2 Mbps bajo trasmisin infrarroja usando CSMA/CA.

802.11a, con velocidad mxima de 54 Mbps, operacin en la banda de 5 Ghz,

capacidad de 12 estaciones solapadas, 8 inalmbricas y 4 punto a punto.

802.11b, con velocidad mxima de 11 Mbps y 5.4 Mbps en la prctica, operacin

24

en la banda de 2.4 Ghz y utiliza el mtodo CSMA/CA como acceso al medio.

802.11c, slo especifica la conectividad entre dos estaciones de distintas

caractersticas.

802.11d, especifica bandas de frecuencia para las estaciones, segn sea su ubicacin
geogrfica.

802.11e, introduce nuevos parmetros en cuanto a la calidad de servicio de una

conexin. Da soporte para aplicaciones en tiempo real mediante el uso de garantas
de Servicio de Calidad QoS.

802.11f, integra todas las marcas de interfaces de red inalmbricas, para hacerlas
compatibles y evitar la necesidad de que un punto de acceso tenga problemas por su
cambio de conexin raz.

802.11g, es una mejora del estndar 802.11b. Trabaja en la banda de 2.4 Ghz, con
velocidad mxima de 54 Mbps terica y 22 Mbps prcticas.

802.11h, integra el cambio dinmico de la banda de transmisin, as como de la

potencias de transmisin.

802.11i, integra nuevos sistemas de cifrados para aumentar las seguridad de los
puntos de acceso.

802.11j, similar al la 802.11h, pero implementada y determinada por japn

802.11n, especifica una velocidad terica de 600 Mbps, operando en la banda de 2,4
Ghz y 5 Ghz. Adems de esto, implementa una nueva tecnologa llamada MIMO
Mltiple Input-Mltiple Output (Mltiple entrada-Mtiple salida), permitiendo
utilizar varias bandas para el envo y recibo de datos al mismo tiempo.

802.11p, especifica una nueva frecuencia de transmisin de 5,9 Mbps, para

transferencias de corto alcance.

802.11r, permite establecer configuraciones de seguridad a dispositivos que se

cambien de puntos de accesos.

802.11s, permite que los fabricantes de puntos de acceso puedan operar con formas
distintas de topologas inalmbricas.

802.11y, especifica una nueva frecuencia de operacin ubicada en la banda de 3650

25

a 3700 Mhz.

802.11v,w; estn en proceso de investigacin pero ya cuentan con pautas que

sealizan sus funciones.

En esta norma, las frecuencias de operacin para la trasmisin y recepcin estn

reflejadas en las siguientes tablas:
Tabla 4. Canales de operacin para 2.4 Ghz

26

Tabla 5. Canales de operacin para 5 Ghz

2.5.2 Protocolos de Seguridad y Acceso en redes wireless

Son todos aquellos sistemas que siguen un conjunto de reglas, para asegurar la
integridad de todos los procesos implcitos en la comunicacin de las redes inalmbricas.
WEP. Wired Equivalent Privacy (Privacidad Equivalente a Cableado) es un
protocolo usado para cifrar toda la informacin de intercambio que exista entre los

27

dispositivos

conectados

en

http://es.wikipedia.org/wiki/WEP:

una

red

no

cableada.

Segn

la

pgina

WEP usa el algoritmo de cifrado RC4 para la

confidencialidad, mientras que el CRC-32 proporciona la integridad. El RC4 funciona

expandiendo una semilla ("seed" en ingls) para generar una secuencia de nmeros
pseudoaleatorios de mayor tamao. Esta secuencia de nmeros se unifica con el mensaje
mediante una operacin XOR para obtener un mensaje cifrado. Uno de los problemas de
este tipo de algoritmos de cifrado es que no se debe usar la misma semilla para cifrar dos
mensajes diferentes, ya que obtener la clave sera trivial a partir de los dos textos cifrados
resultantes. Para evitar esto, WEP especifica un vector de iniciacin (IV) de 24 bits que se
modifica regularmente y se concatena a la contrasea (a travs de esta concatenacin se
genera la semilla que sirve de entrada al algoritmo). El estndar WEP de 64 bits usa una
llave de 40 bits (tambin conocido como WEP-40), que es enlazado con un vector de
iniciacin de 24 bits (IV) para formar la clave de trfico RC4. Al tiempo que el estndar
WEP original estaba siendo diseado, llegaron de parte del gobierno de los Estados Unidos
una serie de restricciones en torno a la tecnologa criptogrfica, limitando el tamao de
clave. Una vez que las restricciones fueron levantadas, todos los principales fabricantes
poco a poco fueron implementando un protocolo WEP extendido de 128 bits usando un
tamao de clave de 104 bits (WEP-104).
Una clave WEP de 128 bits consiste casi siempre en una cadena de 26 caracteres
hexadecimales (0-9, a-f) introducidos por el usuario. Cada carcter representa 4 bits de la
clave (4 x 26 = 104 bits). Aadiendo el IV de 24 bits obtenemos lo que conocemos como
Clave WEP de 128 bits. Un sistema WEP de 256 bits est disponible para algunos
desarrolladores, y como en el sistema anterior, 24 bits de la clave pertenecen a IV, dejando
232 bits para la proteccin. Consiste generalmente en 58 caracteres hexadecimales. (58 x 4
= 232 bits) + 24 bits IV = 256 bits de proteccin WEP.
En el sistema WEP existen dos formas para la autenticacin de las estaciones:
Sistema Abierto y de Clave Compartida.

Sistema Abierto: en este sistema la estacin que se autenticar no tiene la necesidad

de establecer una comunicacin previa con la estacin servidora para poder
28

autenticarse; simplemente a la estacin cliente se le cede la clave WEP previamente

y sin mediar, esta accede al punto.

Clave Compartida: en este sistema la estacin cliente solicita acceso a la estacin

servidora mediante el intercambio de paquetes de texto. El servidor entrega un texto
base al cliente, para que sea cifrado va WEP. Una vez cifrado, el cliente le regresa
el paquete al servidor y ste lo compara con el que el tiene. Si es correcto el cifrado
se le otorga o niega el acceso al nodo solicitante.
Adems del mecanismo de encriptacin WEP, tambin existen otros mucho ms

seguros y usados en la actualidad. Los mtodos de encriptacin WAP y WAP2, son lo que
se implementan en casi todos los dispositivos enrutadores inalmbricos debido a que su
nivel se seguridad es mucho ms alto y cubre los fallos de seguridad del mtodo WEP.
Estos mtodos pueden ser usados en conjunto con un servidor externo que se encargar de
la gestin de los accesos al servidor central, sin embargo, casi siempre se usan por si solos
implementando las distribuciones de los accesos por clave pre-compartida similar a la
usada en WEP. Algunos dispositivos de generaciones pasadas como tarjetas inalmbricas
para PC de escritorio usadas como puntos de acceso, slo pueden trabajar con claves a base
de WEP. La tarjeta usada en este proyecto slo soporta WEP para la encriptacin de los
datos y por eso es que se especifica ms informacin sobre este mtodo que sobre los
dems.
2.6 Servidor DHCP
Dynamic Host Configuration Protocol (Protocolo de Configuracin Dinmica de
Servidor), es un sistema que posibilita la configuracin Ip para una estacin cliente de
forma dinmica. Cuando un nodo accede a la red, ste necesita una direccin Ip que puede
ser configurada de forma manual o automtica. Si la asignacin no es de forma manual, el
nodo cliente enva una seal de difusin a todos los nodos de la red. Cuando un servidor
DHCP puede dar el servicio, responde a la llamada y provee la Ip si el nodo cliente est
autorizado para recibirla. El servidor DHCP puede asignar direcciones de forma automtica
29

y a la vez dinmica, aprovechando as la cantidad de direcciones disponibles. Los

parmetros que puede configurar el servidor DHCP en los clientes, no estn limitados
nicamente a una direccin de red. Parmetros como: servidor DNS, servidor DNS
emergente, servidor SMTP, tiempo mximo de resolucin, mscara de red, mscara de subred, direccin de broadcast (difusin) y otros, son configurables mediante el servidor
DHCP.
El protocolo DHCP incluye tres mtodos de asignacin de direcciones IP segn
http://es.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol:

Asignacin manual o esttica: Asigna una direccin IP a una mquina

determinada. Se suele utilizar cuando se quiere controlar la asignacin de direccin
IP a cada cliente, y evitar, tambin, que se conecten clientes no identificados.
Asignacin automtica: Asigna una direccin IP de forma permanente a
una mquina cliente la primera vez que hace la solicitud al servidor DHCP y hasta
que el cliente la libera. Se suele utilizar cuando el nmero de clientes no vara
demasiado.
Asignacin dinmica: el nico mtodo que permite la reutilizacin
dinmica de las direcciones IP. El administrador de la red determina un rango de
direcciones IP y cada computadora conectada a la red est configurada para solicitar
su direccin IP al servidor cuando la tarjeta de interfaz de red se inicializa. El
procedimiento usa un concepto muy simple en un intervalo de tiempo controlable.
Esto facilita la instalacin de nuevas mquinas clientes a la red.
2.6.1 Pasos para realizar una conexin por DHCP
En la figura 9, se observan los pasos para la obtencin de una direccin Ip.

30

Discovery
Broadc as t
O ffer
Unic as t

Request
Unic as t
dge
Acknow le
Unic as t
Nodo
Cliente

Servidor
DHCP

Figura 9. Pasos para de negociacin DHCP

Segn el sitio: http://es.wikipedia.org/wiki/Dhcp, los pasos se definen de la

siguiente forma:
Discovery: El cliente enva un paquete DHCPDISCOVER. Las direcciones IP
origen y destino de dicho paquete sern 0.0.0.0 y 255.255.255.255 (broadcast)
respectivamente. El servidor almacena los campos del paquete CHADDR (direccin
Ethernet origen, MAC) y el de identificacin del cliente.
Offer: El servidor determina la configuracin basndose en la direccin del
soporte fsico de la computadora cliente especificada en el registro CHADDR. El servidor
especifica la direccin IP en el registro YIADDR, como la que se ha dado en los dems
parmetros.
Request: El cliente selecciona la configuracin de los paquetes recibidos de
DHCP Offer. Una vez ms, el cliente solicita una direccin IP especfica que indic el
servidor
Acknowledge: Cuando el servidor DHCP recibe el mensaje DHCPREQUEST del
cliente, se inicia la fase final del proceso de configuracin. Esta fase implica el
31

reconocimiento DHCPACK el envo de un paquete al cliente. Este paquete incluye el

arrendamiento de duracin y cualquier otra informacin de configuracin que el cliente
pueda tener solicitada. En este punto, la configuracin TCP / IP proceso se ha completado.
El servidor reconoce la solicitud y la enva acuse de recibo al cliente. El sistema en su
conjunto espera que el cliente tenga su interfaz de red con las opciones suministradas. El
servidor DHCP responde a la DHCPREQUEST con un DHCPACK, completando as el
ciclo de iniciacin. La direccin origen es la direccin IP del servidor de DHCP y la
direccin de destino es todava 255.255.255.255. El campo YIADDR contiene la direccin
del cliente, y los campos CHADDR y DHCP: Client Identifier (identificador de cliente)
campos son la direccin fsica de la tarjeta de red en el cliente. La seccin de opciones del
DHCP identifica el paquete como un ACK.
2.7 Servidor DNS
DNS Domain Name Server (Servidor de Nombres de Dominio), es un sistema
implementado para la resolucin de nombres en internet. Cuando un nodo conectado a
Internet intenta llegar al otro por medio de un nombre de host asociado, es el servidor DNS
quien tiene la capacidad de traducir este nombre con una direccin Ip asociada.
Segn el sitio http://www.dcc.uchile.cl/~jpiquer/Internet/DNS/node2.html, el DNS:
es un sistema distribuido, jerrquico, replicado y tolerante a fallas. Aunque parece muy
difcil lograr todos esos objetivos, la solucin no es tan compleja en realidad. El punto
central se basa en un rbol que define la jerarqua entre los dominios y los sub-dominios.
En un nombre de dominio, la jerarqua se lee de derecha a izquierda. Por ejemplo, en
dcc.uchile.cl, el dominio ms alto es cl. Para que exista una raz del rbol se puede ver
como si existiera un punto al final del nombre: dcc.uchile.cl., y todos los dominios estn
bajo esa raz (tambin llamada ``punto"). Cada componente del dominio (y tambin la raz)
tiene un servidor primario y varios servidores secundarios. Todos estos servidores tienen la
misma autoridad para responder por ese dominio, pero el primario es el nico con derecho
para hacer modificaciones en l. Por ello, el primario tiene la copia maestra y los
secundarios copian la informacin desde l.
32

En los DNS, adems de los datos de los nombres de cada host en internet, existen
otros tipos de datos que contiene informacin acerca de cada dominio registrado. Cada una
de esas unidades de datos es llamada Recurso de Registro (RR). Cada registro contiene un
tipo de dato asociado a ste y adems pertenece a una clase que especifica a qu sistema es
aplicable tal registro. En la pgina http://es.wikipedia.org/wiki/Domain_Name_System
estn especificados los siguientes registros:

A= Address (Direccin) Este registro se usa para traducir nombres de hosts a

direcciones IPv4.

AAAA= Address (Direccin) Este registro se usa para traducir nombres de hosts
a direcciones IPv6.
CNAME= Canonical Name (Nombre Cannico) Se usa para crear nombres de
hosts adicionales, o alias, para los hosts de un dominio. Es usado cuando se estn
corriendo mltiples servicios (como ftp y web server) en un servidor con una sola
direccin ip. Cada servicio tiene su propia entrada de DNS (como ftp.ejemplo.com.
y www.ejemplo.com.). esto tambin es usado cuando corres mltiples servidores
http, con diferente nombres, sobre el mismo host.
NS= Name Server (Servidor de Nombres) Define la asociacin que existe entre
un nombre de dominio y los servidores de nombres que almacenan la informacin
de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de
servidores de nombres.
MX (registro)= Mail Exchange (Registro de Intercambio de Correo) Asocia un
nombre de dominio a una lista de servidores de intercambio de correo para ese
dominio.
PTR= Pointer (Indicador) Tambin conocido como 'registro inverso', funciona a
la inversa del registro A, traduciendo IPs en nombres de dominio.
SOA= Start of authority (Autoridad de la zona) Proporciona informacin sobre la
zona.
HINFO= Host INFOrmation (Informacin del sistema informtico) Descripcin
33

del host, permite que la gente conozca el tipo de mquina y sistema operativo al que
corresponde un dominio.
TXT= TeXT - (Informacin textual) Permite a los dominios identificarse de modos
arbitrarios.
LOC= LOCalizacin - Permite indicar las coordenadas del dominio.
WKS- Generalizacin del registro MX para indicar los servicios que ofrece el
dominio. Obsoleto en favor de SRV.
SRV= SeRVicios - Permite indicar los servicios que ofrece el dominio.
SPF= Sender Policy Framework - Ayuda a combatir el Spam. En este registro se
especifica cul o cules hosts estn autorizados a enviar correo desde el dominio
dado. El servidor que recibe consulta el SPF para comparar la IP desde la cual le
llega, con los datos de este registro.
2.8 BIND DNS
BIND (Berkeley Internet Name Domain, anteriormente : Berkeley Internet Name
Daemon) es el servidor de DNS ms comnmente usado en internet, especialmente en
sistemas Unix, en los cuales es un estndar de facto. Es patrocinado por la Internet Systems
Consortium. BIND fue creado originalmente por cuatro estudiantes de grado en la
University of California, Berkeley y liberado por primera vez en el 4.3BSD. Paul Vixie
comenz a mantenerlo en 1988 mientras trabajaba para la DEC,(extrada textualmente de
la pgina http://es.wikipedia.org).
2.9 Servidor Proxy
Es un dispositivo intermediario que tiene la capacidad de filtrar el contenido de
peticiones a la red de internet, implementando reglas de control para cada tipo de solicitud.
Adems de esto, el servidor proxy puede de acelerar el proceso de solicitud de un dominio
por medio de la implementacin de un sistema de cach, el cual podemos modificar para
acelerar el proceso de manejo de objetos en la memoria del servidor. Cuando se configura
34

un servidor proxy todas las peticiones a servicios en Internet pasan por l, garantizando el
control y manejo del trfico entre un cliente y la red de internet.
Administrando algunos de los protocolos que intervienen en los sistemas
servidores de los diversos servicios en internet, el proxy, puede aumentar la seguridad y
eficacia de los mismos. Algunos de los protocolos que intervienen en tales sistemas son los
siguientes:

HTTP: (Hypertext Transfer Protocol) Protocolo de Transferencia de Hipertexto,

usado para la transferencia de datos dentro de la World Wide Web.

HTCP: (Hypertext Caching Protocol) Protocolo de Cacheo de Hipertexto, usado en

la administracin

y consulta de servidorescach de HTTP, en Internet

(es.wikipedia.org, Septiembre 2009).

FTP: (File Transfer Protocol) Protocolo de Transferencia de Archivos, usado en la

transferencia de archivos

entre nodos conectados a travs del protocolo tcp,

siguiendo un sistema de trabajo cliente-servidor.

CARP: (Cache Array Routing Protocol) Protocolo de Seleccin de Enrutamiento

Cache, se usa para el balanceo de carga de las peticiones realizadas a un servidor
HTTP, sobre varios proxies cache.

SNMP:

(Simple

Network

Management

Protocol)

Protocolo

Simple

de

Mantenimiento de la Red, usado para intercambiar informacin de mantenimiento,

entre los diversos dispositivos de red.
2.9.1 Funcionamiento
1. El cliente realiza una peticin de un recurso de Internet (una pgina web o
cualquier otro archivo) especificado por una URL.
2. Cuando el proxy cach recibe la peticin, busca la URL resultante en su
cach local. Si la encuentra, contrasta la fecha y hora de la versin de la pgina
demanda con el servidor remoto. Si la pgina no ha cambiado desde que se cargo en
cach la devuelve inmediatamente, ahorrndose de esta manera mucho trfico pues
35

slo intercambia un paquete para comprobar la versin. Si la versin es antigua o

simplemente no se encuentra en la cach, lo captura del servidor remoto, lo
devuelve al que lo pidi y guarda o actualiza una copia en su cach para futuras
peticiones.
El cach utiliza normalmente un algoritmo para determinar cundo un documento
est obsoleto y debe ser eliminado de la cach, dependiendo de su antigedad, tamao e
histrico de acceso. Dos de esos algoritmos bsicos son el LRU (el menos usado
recientemente, en ingls "Least Recently Used") y el LFU (el menos usado frecuentemente,
"Least Frequently Used").
Los proxies web tambin pueden filtrar el contenido de las pginas web servidas.
Algunas aplicaciones que intentan bloquear contenido web ofensivo estn implementadas
como proxies web. Otros tipos de proxy cambian el formato de las pginas web para un
propsito o una audiencia especficos, para, por ejemplo, mostrar una pgina en un telfono
mvil o una PDA. Algunos operadores de red tambin tienen proxies para interceptar virus
y otros contenidos hostiles servidos por pginas Web remotas.
Un cliente de un ISP (Proveedor del Servicio de Internet) manda una peticin a
Google la cual llega en un inicio al servidor proxy que tiene este ISP, no va directamente a
la direccin IP del dominio de Google. Esta pgina concreta suele ser muy solicitada por un
alto porcentaje de usuarios, por lo tanto el ISP la retiene en su proxy por un cierto tiempo y
crea una respuesta en mucho menor tiempo. Cuando el usuario crea una bsqueda en
Google el servidor proxy ya no es utilizado; el ISP enva su peticin y el cliente recibe su
respuesta ahora s desde Google.
2.10 Squid
Squid es un popular programa de software libre que implementa un servidor proxy
y un dominio para cach de pginas web, publicado bajo licencia GPL. Tiene una amplia
variedad de utilidades, desde acelerar un servidor web, guardando en cach peticiones
repetidas a DNS y otras bsquedas para un grupo de gente que comparte recursos de la red,
36

hasta cach de web, adems de aadir seguridad filtrando el trfico. Est especialmente
diseado para ejecutarse bajo entornos tipo Unix.
Squid ha sido desarrollado durante muchos aos y se le considera muy completo y
robusto, aunque orientado principalmente a HTTP y FTP es compatible con otros
protocolos como Internet Gopher. Implementa varias modalidades de cifrado como TLS,
SSL, y HTTPS.
2.10.1 Caractersticas

Proxy y Cach de HTTP, FTP, y otras URL: Squid proporciona un servicio de

Proxy que soporta peticiones HTTP, HTTPS y FTP a equipos que necesitan acceder
a Internet y a su vez provee la funcionalidad de cach especializado en el cual
almacena de forma local las pginas consultadas recientemente por los usuarios. De
esta forma, incrementa la rapidez de acceso a los servidores de informacin Web y
FTP que se encuentra fuera de la red interna.

Proxy para SSL: Squid tambin es compatible con SSL (Secure Socket Layer) con
lo que tambin acelera las transacciones cifradas, y es capaz de ser configurado con
amplios controles de acceso sobre las peticiones de usuarios.

Jerarquas de cach: Squid puede formar parte de una jerarqua de caches.

Diversos proxys trabajan conjuntamente sirviendo las peticiones de las pginas. Un
navegador solicita siempre las pginas a un slo proxy, si ste no tiene la pgina en
la cach hace peticiones a sus paress, que si tampoco las tienen las hacen a su
padre . Estas peticiones se pueden hacer mediante dos protocolos: HTTP e ICMP.

ICP, HTCP, CARP, cach digests: Squid sigue los protocolos ICP, HTCP, CARP
y cach digests que tienen como objetivo permitir a un proxy "preguntarle" a otros
proxys cach si poseen almacenado un recurso determinado.

Cach transparente: Squid puede ser configurado para ser usado como proxy
transparente de manera que las conexiones son enrutadas dentro del proxy sin
configuracin por parte del cliente, y habitualmente sin que el propio cliente
conozca de su existencia. De modo predefinido Squid utiliza el puerto 3128 para
37

atender peticiones, sin embargo se puede especificar que lo haga en cualquier otro
puerto disponible o bien que lo haga en varios puertos disponibles a la vez.

Control de acceso: Ofrece la posibilidad de establecer reglas de control de acceso.

Esto permite establecer polticas de acceso en forma centralizada, simplificando la
administracin de una red.

Aceleracin de servidores HTTP: Cuando un usuario hace peticin hacia un

objeto en Internet, ste es almacenado en el cach, si otro usuario hace peticin
hacia el mismo objeto, y ste no ha sufrido modificacin alguna desde que lo
accedi el usuario anterior, Squid mostrar el que ya se encuentra en el cach en
lugar de volver a descargarlo desde Internet. Esta funcin permite navegar
rpidamente cuando los objetos ya estn en el cach y adems optimiza
enormemente la utilizacin del ancho de banda.

SNMP: Squid permite activar el protocolo SNMP, ste proporciona un mtodo

simple de administracin de red, que permite supervisar, analizar y comunicar
informacin de estado entre una gran variedad de mquinas, pudiendo detectar
problemas y proporcionar mensajes de estados.

Cach de resolucin DNS: Squid est compuesto tambin por el programa

dnsserver, que se encarga de la bsqueda de nombres de dominio. Cuando Squid se
ejecuta, produce un nmero configurable de procesos dnsserver, y cada uno de ellos
realiza su propia bsqueda en DNS. De ste modo, se reduce la cantidad de tiempo
que la cach debe esperar a estas bsquedas DNS.
2.11 Cortafuegos. Firewall
Es un sistema de seguridad a nivel de programacin usado para restringir el acceso

a un nodo en especfico o a un sistema de red. Este sistema contiene reglas estrictas en las
que se indican quin o qu, puede entrar a un host en particular. Los cortafuegos poseen dos
polticas de trabajo en cuanto al acceso se refiere, y estas polticas son la de negacin y
aceptacin. En la poltica de negacin, todos los caminos posibles se cierran y slo son
abiertos los indispensables segn los requerimientos. Esta poltica es muy segura a la hora
38

de restringir el paso, pero a la par, es bastante compleja a la hora de su administracin. La

poltica de aceptacin es ms sencilla a la hora de su gestionamiento, pero por su sencillez,
es mucho menos segura y por lo general es ms propensa a ataques. En esta poltica se
restringe el paso de forma puntual, es decir, que se niega el acceso a paquetes o servicios en
particular, dejando a otros el acceso total a nuestro sistema.
Existen varios tipos de Firewall reseados a continuacin:

Filtrado de Paquetes. Para escoger los paquetes netamente necesarios

Proxy-Gateways de Aplicaciones. Funciona como filtro en la capa de aplicaciones

Dual-Homed Host. Permite que una estacin actu como un host doble

Inspeccin de Paquetes. Verifica la integridad de los paquetes, llegando a veces a

modificarlos
As como existen tipos de firewalls, tambin existen distintas configuraciones

clasificadas segn sea su disposicin en la red.

2.11.1 Configuraciones comunes de los firewall.
Algunas de estas configuraciones son aplicadas a simples redes de oficina, otras a
servidores dedicados y otras a servidores de base de datos. En resumen las ms usadas son
las siguientes:
Disposicin sencilla: Esta es la configuracin ms comn para la disposicin del
firewall se encuentra entre el router y la red LAN. Aqu, nicamente se restringe el paso de
los paquetes de salida y entrada de la red.

39

Red Lan
Internet

Router

Firewall

Figura 10. Disposicin tpica para un firewall

Disposicin con desvo a DMZ: DMZ (Zona Desmilitarizada) es una regin dentro
de la topologa entera de la red, en la que se encuentran algunos servidores dedicados a los
que se necesita tener acceso constantemente desde el exterior. El firewall est dispuesto de
tal forma que encamine los paquetes hacia el destino que se especifique en el paquete.

Firewall
Red Lan
Internet

Router
DMZ

Figura 11. Disposicin con desvo hacia una DMZ

Disposicin de doble firewall: este esquema de conexin muestra dos firewall que
restringen el paso, tanto a la DMZ como a la red LAN protegiendo de forma efectiva ambas
40

partes. Esta configuracin es muy ventajosa y posible, siempre y cuando tengamos la

cantidad necesaria de tarjetas de redes para poder realizarla.

Firewall 1

Firewall 2
Red LAN

Internet

Router
DMZ

Figura 12. Disposicin con doble Firewall

Estas disposiciones son las ms usadas en los montajes de las topologas de una
red. Otras disposiciones son slo vertientes de estas que se mencionaron. En el proyecto se
trabaj pensando en la primera estructura correspondiente a la colocacin bsica del
firewall entre el router y la red LAN (PELLO, Marzo 2010).
2.12 Iptables
Segn la pgina: http://es.wikipedia.org, Ipatables: Es un framework disponible
en el ncleo Linux que permite interceptar y manipular paquetes de red. Dicho framework
permite realizar el manejo de paquetes en diferentes estados del procesamiento. Iptables
posibilita al administrador del sistema definir reglas acerca de qu hacer con los paquetes
de red. Las reglas se agrupan en cadenas: cada cadena es una lista ordenada de reglas. Las
cadenas se agrupan en tablas: cada tabla est asociada con un tipo diferente de
procesamiento de paquetes.
Cuando un paquete quiere entrar al sistema ste pasa por una serie de reglas que
estn contenidas en una cadena con caractersticas especificas determinadas por las tablas.
41

Las tablas le dan estructuras especificas a las cadenas, es decir, que cada tabla indica que se
puede y que no se puede colocar en una determinada cadena. En base a esto, las cadenas,
contiene una serie de reglas que permitirn hacerle las comparaciones a los paquetes que
van entrando al sistema. Por lo general los paquetes entrantes contienen informacin en la
cabecera tcp, usada para hacer tales comparaciones con las reglas. Cuando un paquete
cumple cada una de las reglas que se especifican en la cadena, la misma, contiene un
destino que decide que hacer con el paquete, dependiendo de las caractersticas que le haya
otorgado cierta tabla. Cuando un paquete no cumple con ninguna regla de una cadena, los
destinos del paquete son determinados por una poltica global que decide qu se debe hacer
con ese paquete. Un ejemplo muy anlogo al sistema de trabajo de iptables es el siguiente:
Imagine que nuestro sistema es un pequeo pas el cual necesita de unos
determinados recursos (los paquetes de datos), para desarrollar su nacin. La nica entrada
y salida de recursos que posee ese pas es un aeropuerto. De acuerdo con las necesidades
del pas, el gobierno designa un ente que administre el trfico de los recursos; que para este
caso ser la aduana (iptables). Una vez designado quin gestionar el trfico de los
recursos; el gobierno procede a designar qu se necesita para el desarrollo del pas y en esta
ocasin se dice que es agua, comida, oro, y hierro, proveniente de Pekin y Groenlandia. La
aduana posee dos sistemas de trabajo que son el rojo y el amarillo (tablas). El sistema rojo
puede trabajar con cualquier tipo de recurso, entrante o saliente, proveniente de donde sea
(reglas) y adems sol es capaz de distribuirlo uniformemente por todo el pas (destino). El
sistema amarillo puede trabajar con cualquier tipo de recursos, entrantes o salientes,
provenientes de donde sea y adems sol es capaz de dirigirlos a una zona en especfico del
pas. Sabiendo esto la aduana procede a trabajar de la siguiente forma:

Para evitar el contrabando, la aduana negar cualquier paquete entrante (politicas) y

sol pasarn los que cumplan con lo especificado en las cadenas hechas con reglas
de alguno de las dos sistemas de trabajo.

Las cadenas de trabajo son las siguientes: usando el sistema rojo, dejaremos pasar
agua y comida, de Pekin y Groenlandia para distribuirla por todo el pas. Usando el
42

sistema amarillo dejaremos pasar oro y hierro, proveniente de Pekin y Groenlanda,

dirigindolo hacia la zona industrial del pas nada ms.
Con estas sencillas cadenas se podr desarrollar el pas como es necesario. Todos
los paquetes que coincidan con lo establecido en las cadenas, seguirn el destino que se le
designe, sino, simplemente tomaran el destino establecido en las polticas. Ntese que para
este caso se usaron los dos sistema disponibles; si hubiesen existido otras necesidades ms
complejas y otros sistemas (tablas), las cadenas se hubiesen estructurado en base a eso para
facilitar el trabajo o satisfacer las necesidades del pas. Muy parecido a este ejemplo
planteado es el modo de trabajo de iptables. Su estructura est formada por ciertos
parmetros, los cuales se usan para la administracin de los paquetes entrantes al sistema,
en la tercera capa del modelo OSI.
Combinando las polticas, tablas, cadenas y reglas se puede crear un sistema de
seguridad bastante complejo para implementarlo en cualquier plataforma que se desee y
adems tambin se pueden disear sistemas de rutas para redes que lo requieran.
2.13 Software de uso libre
Son todos aquellos programas cuya licencia no es restringida y su cdigo es
conocido y abierto a cualquiera. Los desarrolladores generalmente son programadores de
todo el mundo y en ocasiones organizaciones sin fines de lucro. Hay mltiples aplicaciones,
entre ellas sistemas operativos completos; que son de uso libre y su disponibilidad es
grande.
2.13.1 GNU/GPL
La Licencia Publica General GNU, es una licencia creada por la Free Software
Foundation en 1989 (la primera versin), y est orientada principalmente a proteger la libre
distribucin, modificacin y uso de software. Su propsito es declarar que el software
cubierto por esta licencia es software libre y protegerlo de intentos de apropiacin que
43

restrinjan esas libertades a los usuarios.

2.13.2 Linux
Segn http://es.wikipedia.org, Linux se define de la siguiente forma:
Una distribucin Linux o distribucin GNU/Linux (coloquialmente llamadas
distros) es una distribucin de software basada en el ncleo Linux que incluye
determinados paquetes de software para satisfacer las necesidades de un grupo especfico
de usuarios, dando as origen a ediciones domsticas, empresariales y para servidores. Por
lo general estn compuestas, total o mayoritariamente, de software libre, aunque a menudo
incorporan aplicaciones o controladores propietarios.
Actualmente Linux es un ncleo monoltico hbrido. Los controladores de
dispositivos y las extensiones del ncleo normalmente se ejecutan en un espacio
privilegiado conocido como anillo 0 (ring 0), con acceso irrestricto al hardware, aunque
algunos se ejecutan en espacio de usuario. A diferencia de los ncleos monolticos
tradicionales, los controladores de dispositivos y las extensiones al ncleo se pueden cargar
y descargar fcilmente como mdulos, mientras el sistema contina funcionando sin
interrupciones. Tambin, a diferencia de los ncleos monolticos tradicionales, los
controladores pueden ser prevolcados (detenidos momentneamente por actividades ms
importantes) bajo ciertas condiciones. Esta habilidad fue agregada para gestionar
correctamente interrupciones de hardware, y para mejorar el soporte de multiprocesamiento
simtrico.
Linux debe su nombre a su desarrollador original, Linus Torvalds,
que

era estudiante de Informtica en una universidad de Helsinki (Finlandia) cuando en

1991 se decidi a hacer un ncleo de sistema operativo que funcionara como MINIX (un
derivado de UNIX) (ROBLES, Enero 2009)

44

2.14 Apache
Apache es una un software dedicado para el montaje de servidores web
desarrollado por la Apache Software Foundation. Est disponible para todas las plataformas
que se desee, privadas o libres, de forma gratuita. Posee una serie de mdulos que permiten
la integracin de otros softwares, para posibles mejoras del servidor, y adems posee una
serie de directivas que posibilitan el control de los accesos al servidor web, mejorando en
gran cantidad la seguridad del sistema. Segn la pgina web del instituto Tecnolgico de
Massachussets

(http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/ch-httpd.html),

Apache posee las siguientes caractersticas:

Los mdulos Apache API Se utiliza un nuevo conjunto de interfaces de

programacin de aplicaciones (APIs).

Filtrado Los mdulos pueden actuar como filtros de contenido.

Soporte a Ipv6 Se soporta la prxima generacin de formato de direcciones IP.

Directrices simplificadas Se han eliminado una serie de directrices complicadas y
otras se han simplificado.
Respuestas a errores en diversos idiomas Cuando usa documentos Server Side
Include (SSI), las pginas de errores personalizadas se pueden entregar en diversos
idiomas
2.15 Tarjeta de red inalmbrica
Es un dispositivo electrnico que permite el intercambio de datos entre
computadores, usando como medio de comunicacin el espectro radioelctrico. Estas
tarjetas por lo general son conectadas a la Pc por el puerto de la conexin de perifricos
PCI, pero tambin existen tarjetas que son conectadas por otros puertos. El modelo de
funcionamiento de estos dispositivos y sus especificaciones, para la transmisin de datos
dentro de los sistemas de redes computacionales, estn ubicadas en las dos ltimas capas

45

del modelo OSI. En la siguiente figura se pueden observar distintas tarjetas de red
inalmbricas:

Figura 13. Tarjetas de red inalmbricas

Estas tarjetas bsicamente sirven para conectarse a puntos de acceso inalmbricos
de internet, pero algunas de ellas pueden actuar como el punto de acceso que provee la
salida hacia internet. No todas las tarjetas poseen esta funcionalidad debido a que su
hardware no se o permite y hay que tomar en cuenta que muchas otras funciones de los
sistemas actuales de comunicacin estn atadas a esta caracterstica. Alguna de las tarjetas
inalmbricas no tienen integrado totalmente el modulo transmisor-receptor, sino que mas
bien lo integran mediante su conexin por un puerto especial llamado PCMCIA,
encontrado en algunas Laptops de modelos pasados con respecto a los de hoy en da.

46

CAPITULO III:
Cronologa de las actividades e Integracin a la
empresa
3.1 Tiempo de las actividades
3.2 Familiarizacin con la empresa
3.3 Familiarizacin con los clientes de la empresa

47

CAPITULO III
Cronologa de las actividades e Integracin a la empresa
3.1 Tiempo de las actividades
Las actividades realizadas en la empresa Corvus Latinoamrica, C.A., tienen un
lapso de trabajo de 12 semanas activas, comenzando el 25 de Febrero de 2010 y
culminando el 23 de Abril del mismo ao. En ellas se desarrollaron todas las labores
implcitas con el diseo e implementacin de un servicio proveedor de Internet de forma
inalmbrica, basado en la plataforma GNU/LINUX con la tarjeta de red inalmbrica DLINK DW-500. A continuacin se presentar una tabla describiendo las actividades hechas
por fases y etapas, para luego, mediante un diagrama de Gantt, indicar la cronologa de las
mismas:
Tabla 5. Descripcin de actividades
Fase

Etapa

Tareas

Familiarizacin con la
empresa

Familiarizacin con los - Conocimiento de todos los clientes a quienes la empresa le presta sus servicios
clientes de la empresa

Descripcin
- Recorrido por los laboratorios
- Recorrido por el cuarto de servidores
- Reconocimiento de las oficinas administrativas
- Recorrido e instauracin en el departamento de desarrollo

Instalacin y
aprendizaje del
sistema operativo
LATINUX

Configuracin de los
parmetros de red en
el S.O. LATINUX

Diseo y configuracin - Investigacin sobre Firewall

de un Firewall
- Investigacin de la herramienta Netfilter/Iptables
- Manejo e implementacin de tablas, cadenas y reglas bsicas en Iptables
- Manejo e implementacin de mdulos de Iptables
- Configuracin y diseo del Firewall, mediante el uso de Ipatables

II

III

1
Configuracin DHCP

IV

2
Configuracin DNS

- Instalacin del Sistema Operativo Latinux

- Conocimientos de las herramientas bsicas sobre Latinux

- Configuracin de los parmetros de red

- Configuracin de las tarjetas de red

- Investigacin sobre DHCP

- Instalacin y configuracin del servicio dhcp-server
- Instalacin de una peque red con topologa en rbol
- Pruebas del servidor dhcp
- Investigacin sobre Servidores DNS
- Investigacin del servidor BIND-DNS
- Manejo, instalacin y configuracin del servidor BIND-DNS
- Pruebas al servidor DNS

48

3
V

Configuracin Proxy

4
Configuracin de
Apache
VI

Configuracin de la
tarjeta de red
inalmbrica

VII

Integracin de la
Solucin

- Investigacin sobre los servidores Proxy

- Investigacin sobre el servidor Proxy Squid
- Instalacin y configuracin bsica de Squid
- Configuracin de listas de acceso en Squid
- Configuracin de los logs de Squid
- Configuracin de manejo de objetos en lacach de Squid
- Instalacin y configuracin del mdulo para Squid: SquidGuard
- Pruebas del servidor Proxy Squid
- Investigacin sobre servidor Web
- Investigacin del servidor Web Apache
- Instalacin, configuracin y manejo bsico del servidor Apache
- Pruebas al servidor Web Apache
- Investigacin sobre la IEEE 802.11
- Investigacin de las caractersticas de la tarjeta de red inalmbrica D-Link
DWL-500
- Instalacin y configuracin del mdulo hostapd
- Pruebas de la tarjeta de red inalmbrica D-Link
- Esquema de funcionamiento del punto de acceso
- Pruebas del punto de acceso

Tabla 6. Diagrama de Gantt

Fase Etapa

Familiarizacin con la
empresa

Familiarizacin con los

clientes de la empresa

II

III

IV

Tareas

Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem
1
2
3
4
5
6
7
8
9
10
11
12

Instalacin y aprendizaje del

sistema operativo GNU/LINUX
Configuracin de los
parmetros de red en el S.O.
GNU/LINUX

Diseo y configuracin de un
Firewall

Configuracin DHCP

Configuracin DNS

Configuracin Proxy

Configuracin de Apache

49

VI
5
VII

Configuracin de la tarjeta de
red inalmbrica
Integracin de la Solucin

3.2 Familiarizacin con la empresa

Esta etapa se llev a cabo durante una semana, desde 25/01/10 hasta 29/01/10 y
permiti la integracin efectiva a la empresa como paso inicial para el comienzo del
proyecto. En dicha etapa se llev a cabo la familiarizacin con las instalaciones de la
empresa, conocimiento de todo el personal y sus actividades, y conocimiento de los
proyectos que se desarrollaban para ese momento. Estas instalaciones cuentan con 4
laboratorios disponibles y operativos, 2 salones de conferencia y 2 salones de clases.

Lab. Tux

Lab. Latinux

Lab. Gimp
Lab. Apache

Figura 14. Laboratorios de la empresa

Todos los laboratorios estn dotados de computadores, los cuales son usados por el
ISEIT para impartir los programas de estudios que poseen. Dentro de las instalaciones est
situado un cuarto de servidores de donde brindan soporte Web y servicio de correo para
varios de sus clientes. La red que proporciona conexin a Internet para cada uno de los
laboratorios, est conectada a este cuarto de servidores y es administrada desde all. El
50

cuarto de servidores est dotado de 5 switches, 2 de ellos con conexin por fibra ptica, y
varias mquinas en donde se encuentran alojados los servidores y se distribuyen los puntos
de conexin para todos los laboratorios.

Figura 15. Cuarto de servidores

3.3 Familiarizacin con los clientes de la empresa
Son varios los clientes de la empresa Corvus Latinoamrica a los que se les ofrece,
adems de servidores Web y Mail, experiencia en proyectos de consultora, implantacin y
soporte para software de uso libre. Adems de esto tambin realizan actividades de diseo,
montaje y mantenimiento de redes LAN, VLAN y WAN. La integracin de los sistemas y
el desarrollo de plataformas de uso libre forman parte de los objetivos principales de esta
organizacin. Dentro de la empresa se encuentra personal especializado y calificado en
programacin

avanzada

en las principales herramientas de uso libre, as como en

utilidades en el manejo de base de datos. Las siguientes empresas son algunos de los
clientes de Corvus Latinoamrica:

Venamcham

Graffiti C.A.

Hotel Altamira Suites

Iseit

51

Grupo Zoom

Existen otras reas dentro de la empresa destinadas a la administracin y para el

rea de desarrollo. En el rea de desarrollo se encuentra el personal especializado para la
formulacin de los distintos proyectos que ofrece la empresa. En esta rea se me asign un
espacio fsico donde realizara mis actividades de pasanta.

52

CAPITULO IV:
Elementos bsicos para el montaje del punto de
acceso inalmbrico
4.1 Descripcin de las partes del punto de acceso
4.2 Sistema Operativo LATINUX
4.2.1 Capacitacin bsica
4.2.2 Instalacin
4.3 Configuracin de la tarjeta de red
4.3.1 Pasos previos
4.3.2 Configuracin

53

CAPITULO IV
Elementos bsicos para el montaje del punto de acceso inalmbrico
El servicio de acceso a Internet de forma inalmbrica deber ofrecer estabilidad en
todo momento para los clientes que se conecten, por lo que para su desarrollo se necesitar
que cuente con unas caractersticas que brinden tal estabilidad. Las caractersticas son las
siguientes:
1. Seguridad a nivel de la capa de red ante posibles ataques al servidor principal y sus
clientes.
2. Enrutamiento de paquetes para facilitar el trabajo de algunos servicios e
inicialmente darle salida a las peticiones http de los clientes hacia el internet.
3. Capacidad de distribuir y gestionar las direcciones lgicas de la red y sus
parmetros implcitos (direccin ip, mscara de subred, mscara de red, direccin de
broadcasting, servidores DNS y gateway).
4. Aceleracin en la resolucin de nombres de dominio y por ende el aumento de las
respuestas de solicitudes http.
5. Filtro y gestin de contenidos a nivel de la capa de aplicacin.
6. Control de acceso a los usuarios que requieran conexin con el servidor y hacia
otros servidores.
7. Host virtual para responder las solicitudes a pginas bloqueadas.
De acuerdo a estas caractersticas se configuraran los dispositivos y servicios que
pondrn en funcionamiento el servidor central.
4.1 Descripcin de las partes del punto de acceso
El servidor central del punto de acceso est compuesto con los siguientes
elementos y servicios:

54

Hardware: Contara con un computador equipado con la tarjeta inalmbrica D-LINK

DWL-500 por donde se conectarn los clientes y una tarjeta de red convencional
donde estar el enlace principal que sale a internet.

Software: La plataforma que soportar los servicios ser un servidor operado por el
S.O. LATINUX donde se instalarn los servidores DHCP, DNS, Proxy, Firewall y
Web que permitirn el funcionamiento pleno de la red para el intercambio de los
datos.
Con estos elementos se construir el punto de acceso inalmbrico para que los

usuarios puedan salir a Internet de forma segura.

4.2 Sistema Operativo LATINUX
El Sistema Operativo LATINUX es el software en donde trabajaran todos los
procesos correspondientes al sistema del punto de acceso inalmbrico, por esta razn se
requiri la capacitacin bsica en este sistema y su constante aprendizaje. Este sistema est
licenciado en GPL y su codificacin est basada en sistemas de Linux (ver captulo II.
Software de uso libre). LATINUX es una Meta-distribucin de Linux basada en Ubuntu
9.04 por lo que contiene

caractersticas similares a este, en conjunto con otras

modificaciones.
4.2.1 Capacitacin bsica
Esta capacitacin est dentro de la primera etapa de la segunda fase del proyecto y
se extiende a lo largo de este. El aprendizaje de LATINUX se comenz realizando la
instalacin desde su inicio. Para esto fue necesario hacer un entrenamiento previo sobre el
proceso de instalacin desde cero del software. Consultando al tutor de la pasanta Jos
Zamora se obtuvo la siguiente informacin:

Se requiere un computador con un procesador de 700 Mhz, 64M de memoria y 5Gb

55

de disco duro como mnimo para que corra bien el sistema.

Se necesita que la mquina inicie desde la unidad de CD.

Luego de esto se debe seguir las instrucciones que va generando la interfaz del
programa a travs de todo el proceso de instalacin.
En base a est informacin se procedi a la instalacin del sistema sobre el

computador donde se realiz el proyecto.

4.2.2 Resumen de la instalacin
El proceso de instalacin del sistema operativo es bastante sencillo, y adems,
posee una interfaz grfica que facilita an ms este paso. La mquina donde se alojara el
sistema operativo cuenta con un procesador Intel Pentium III, 512Mb de memoria RAM y
40Gb de disco duro. En cada una de las etapas de la instalacin se van generando ventanas
instructivas que nos guiarn a lo largo del todo el proceso (ver anexo 2. Instalacin del
sistema operativo LATINUX). La plataforma posea al final de la instalacin, una sola
particin donde est el sistema de ficheros de linux, una clave de acceso para el
administrador y un rea de intercambio para solventar las saturaciones de la memoria al
momento de ejecutar algn proceso.
Entrando en el sistema, se procedi a un reconocimiento breve

de las

aplicaciones bsicas del sistema LATINUX (ver anexo 3. Aplicaciones bsicas de

LATINUX). Una de las aplicaciones ms importantes usadas durante el desarrollo del
proyecto es la de terminal debido a que casi todos los servicios, incluyendo el sistema
operativo como tal, se controlan por medio de la misma.
4.3 Configuracin de la tarjeta de red
4.3.1 Pasos previos
Fue necesario configurar los parmetros en la tarjeta de red inalmbricapara poder
56

establecer la direccin del servidor central. Para esto se trabaj sobre la terminal, dentro del
sistema de configuracin de LATINUX usando algunos de sus comandos bsicos. En el
servidor se tenan conectadas dos tarjetas de red identificadas por el sistema como eth0 y
wlan0, siendo la primera una tarjeta ethernet simple y la segunda nuestra D-LINK DWL500. En este punto ya est definido cules sern las direcciones privadas que se usarn para
el establecimiento de la red: Sub-red: 10.0.0.0, con una mscara de 255.255.255.0,
partiendo desde la direccin 10.0.0.10 para los clientes y culminando en la 10.0.0.20. La
direccin del servidor central ser 10.0.0.1/24. Se realiz la distribucin de la red con estas
direcciones ya que es una de las establecidas para el montaje de redes privadas (ver captulo
II, Clases de redes). Con esta informacin se procedi a la configuracin.
4.3.2 Configuracin
La configuracin est descrita en los siguientes puntos fundamentales:
1. Uso del terminal y comandos bsicos Se abri una ventana de terminal por medio
del men Aplicaciones-Accesorios-Terminal. Una vez aqu, se procedi a la
identificacin del usuario como el administrador del sistema mediante el comando
sudo -i. El comando sudo permite la ejecucin de acciones como el administrador
del sistema, solicitando siempre la clave del mismo; y el parmetro -i, indica el
inicio de una sesin, que en este caso ser como administrador

del sistema.

Generalmente los comandos en consola de LINUX, estn asociados a parmetros

que le dan diversas opciones a cada uno de ellos, como en este caso en donde sudo,
est bajo el parmetro -i, lo que se traduce al inicio de sesin en el sistema como el
administrador.
Estando en el sistema como administrador, se procedi al acceso del directorio
contenedor de los archivos de configuracin del sistema llamado /etc, mediante el
uso del comando cd que permite avanzar sobre los directorios, dependiendo de la
ruta que se tome. Estando ubicados en el directorio /etc, se procedi a listar las
carpetas que se encuentran dentro de l, para observar los directorios que configuren
57

los parmetros de red. Los archivos responsables de la gestin de los parmetros de

red, ms especficamente las interfaces, son el network, NetworkManager, networks
y el init.d. En la figura 14 se puede ver la ejecucin de los comandos en la consola.

Figura 16. Ejecucin de comandos en terminal

2. Edicin del archivo /etc/network/interfaces. ste es uno de los archivos ms
importantes encontrados en el directorio /etc, ya que por medio de l podemos
identificar nuestras tarjetas con casi todos lo parmetros de red como: direccin ip,
mscara de red, direccin de difusin, nombre de la tarjeta, puente de salida, modo
de conexin etc., habilitando a la mquina para la conexin a una red en especifico.
Mediante el uso del editor vi se modific la configuracin por defecto de las
tarjetas, para que al momento en que se monte el servidor DHCP, el servicio tenga
como puente de salida la direccin de una de las tarjetas que se designe en esta
modificacin. Hay otros editores ms amigables y fciles de manejar como el gedit
y el nano.

a)
58

b)
Figura 17. a) Comando vi b) Ejecucin del comando vi

Los campos originales del archivo /etc/network/interface, normalmente son: el de

auto lo y por debajo el de iface lo inet loopback, indicando la configuracin del la
interfaz de retroalimentacin lo, referente a local-host. Los campos significan que la
tarjeta lo ser configurada automticamente con una retroalimentacin que le
proporcionar su Ip. Esta direccin de loopback es usada para el diagnostico de los
protocolos de comunicacin usados localmente. Ntese que en la figura anterior hay
campos que hacen referencia a otra interfaz de red. Estos campos son los que se
agregaron para la configuracin de la interfaz de red que se us para hacer una
pequea conexin entre varias mquinas en forma de pruebas.

59

Terminal

Configuracin automtica eth1

auto eth1
iface eth1 inet static
address 10.0.0.1
netmask 255.255.255.0
gateway 172.16.1.153

Forma esttica
Con Ip: 10.0.0.1
Mascara de red:255.255.255.0
Pasarela: 172.16.1.153

Figura 18. Significados de los campos

Levantamiento de interfaces y visualizacin sus propiedades. Despus de la
modificacin del archivo /etc/network/interface que configura los dispositivos de
red que estn especificados en l de forma permanente; se continu con el
levantamiento de la tarjeta mediante el reinicio del networking, una aplicacin
situada en el init.d del directorio /etc. En el /etc/init.d, se encuentran todas las
aplicaciones bsicas que se tienen que correr al inicio del sistema operativo, pero en
este caso no interesaba reiniciar todas las aplicaciones, sino nicamente la que
intervena con el levantamiento de los dispositivos de red. El levantamiento se
realiz de la siguiente manera:
root@iseit:~# cd /etc/init.d
root@iseit:/etc/init.d# bash networking restart
* Reconfiguring network interface...

[ok]

La primera lnea nos sita en el directorio de init.d. La segunda lnea reinicia

aplicacin

mediante la orden bash y el parmetro restart, trabajando sobre

networking. La tercera lnea nos indica que la accin ha sido un xito. Se comprob
luego el levantamiento de las interfaces mediante el comando ifconfig eth1 que
arroja los siguientes mensajes:

60

Terminal
root@iseit:/etc/init.d# ifconfig eth1
eth1

Link

encap:Ethernet

direccinHW

Direc.inet:10.0.0.1

00:26:9e:89:97:d4
Difus.:10.0.0.255

Msc:255.255.255.0
ACTIVO DIFUSIN MULTICAST

MTU:1500

Mtrica:1

Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0

Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
colisiones:0 long.colaTX:1000
Bytes RX:0 (0.0 B)

TX bytes:0 (0.0 B)

Interrupcin:30 Direccin base: 0xe000

Figura 19. Mensajes de ifconfig

Una vez configurado el sistema operativo y la tarjeta, se pudo continuar con los
siguientes pasos los cuales consistieron en el montaje de los servidores y herramientas de
filtrado.

61

CAPITULO V:
Configuracin bsica de seguridad para el punto
de acceso
5.1 Paso previo
5.1.1 Bsqueda de informacin sobre Firewall y la herramienta
Netfilter/Iptables
5.2 Configuracin
5.2.1 Manejo e implementacin de las tablas, cadenas y reglas de Iptables
5.2.2 Manejo e implementacin de algunos mdulos de Iptables

62

CAPITULO V
Configuracin bsica de seguridad para el punto de acceso

Esta fase corresponde a la fase II del proyecto y se lleva a cabo durante lapsos
distintos de tiempo, debido a que en primera instancia se realiz una configuracin de
seguridad que servira nicamente para pruebas y luego se replante el sistema al final del
desarrollo del punto de acceso . En esta fase se encuentra lo respectivo al primer sistema de
seguridad del punto de acceso, en este caso el Firewall como tal. Este Firewall fue hecho a
base de aspectos bsicos de seguridad, y adems hay que destacar, que cualquier sistema de
seguridad a disear va de la mano siempre a los requerimientos de la red, usos y finalidad
de la misma. Para esta ocasin el Firewall se implement con un paquete incluido en el
kernel de los sistemas Linux, desde la versiones 2.4 en adelante. No se uso otro debido a
que ste es bastante completo, ofrece una gran cantidad de instrucciones para distintas
formas de estructuracin y tambin fue el designado por el tutor industrial para realizar el
cortafuegos.
5.1 Paso previo
5.1.1 Bsqueda de informacin sobre Firewall y herramienta Netfilter/Iptables
El tema de seguridad y el uso de herramientas sofisticadas como Iptables requiri
de un gran esfuerzo traducible en tiempo para estudiarlo y alcanzar el suficiente nivel
operativo que permitiera el uso de tal herramienta(ver anexo 4. Netfilter/Iptables y
Firewall). El trfico entrante y saliente al punto de acceso, destinado a la red LAN, pasar
siempre por este punto y es por esto que mediante operaciones bsicas de Iptables (ver
captulo II. Iptables) se pudo crear una especie de estacin de control que censa y concede
accesos al trfico en general proveniente de internet, para de esta forma proteger la red
LAN en tal caso que dentro de ella se encuentren datos de sumo cuidado. Precisamente los
Firewalls son esos puntos de control por donde pasa el trfico proveniente de la internet.
63

Estos Firewalls son simples servidores dedicados de pueden operar en varias capas del
modelo OSI para as intensificar los niveles de seguridad. La disposicin de tales puntos o
Firewalls va a depender de las polticas para el diseo de la red. Existen distintas
configuraciones estndares que son aplicables para casos sencillos como proteccin de
datos a otro servidor dedicado o el enrutamiento de paquetes (ver anexo 4.
Netfilter/Iptables y Firewall).
5.2 Configuracin
5.2.1 Manejo e implementacin de las tablas, cadenas y reglas de Iptables
Iptables, es un software diseado para el filtrado de los paquetes a nivel de la capa
3 del modelo OSI. Este software viene por defecto en las versiones de ncleos 2.4x y 2.6x,
lo que posibilita que todas las distribuciones cuenten con este instrumento. Tiene mltiples
opciones para la construccin de las cadenas y posibilita el monitoreo de estas

por

individual mediante la creacin de logs. La implementacin y el manejo, se llevaron a cabo

por medio de unas pruebas iniciales que permitieron el entendimiento de una buena
cantidad de caractersticas bsicas de las cadenas, reglas y tablas de iptables. Las pruebas
estn descritas en los siguientes prrafos:
Polticas de las cadenas: esta prueba consisti en el uso de las polticas que
pueden usarse en una determinada cadena. INPUT, OUTPUT y FORWARD (entradas,
salidas y desvos); son las cadenas bsicas que se pueden configurar dentro de la tabla
filter. DROP y ACCEPT (negar y aceptar); son las polticas que se le aplican a cierta regla.
El conector que indica la entrada de una poltica en una cadena es (-P). Dentro de la
consola y como el administrador se procedi as:
root@PAcceso:~# iptables -P INPUT DROP
root@PAcceso:~# iptables -P OUTPUT DROP

64

La prueba tuvo como consecuencia el bloqueo total de todos los puertos tcp dentro
de la mquina. Las salidas y entradas de paquetes fueron rechazadas y por ende no exista
comunicacin entre la red de Internet y la mquina. La comprobacin de esta prueba fue
realizada mediante la herramienta iptraf y tambin por medio del establecimiento de
conexiones bsicas requeridas por la mquina para salir a internet. Para el inicio de iptraf,
se escribi en la consola su propio nombre que es el comando que lo ejecuta:

Figura 20. Iptraf

Traduccin de los campos:
1. Debajo de este campo se visualizan las conexiones tcp y sus direcciones ip , junto
con sus puertos de orgenes.
65

2. Indica el nmero de paquete.

3. Indica la cantidad de bytes descargados, flags activos en la conexin lgica y la
interfaz en donde se realiza el la conexin
4. Aqu se indica los intercambios de datos sobre udp, se observa la direccin de
origen, el destino y el puerto asociado.
Iptraf, en el instante que se intent acceder a un recurso en la web, no mostr
respuesta alguna en el campo 1, que es donde se visualizan las conexiones lgicas hechas y
adems de esto tampoco logr conexin con un servidor ftp que estaba situado dentro de su
LAN.
Las polticas son decisiones finales cuando un paquete no coincide con las reglas
de una cadena en especifico. Una cadena es una combinacin de reglas configuradas para
realizar comparaciones entre ellas y los paquetes, y as tomar una decisin sobre el destino
que tendr. Los paquetes que no cumplan con alguna regla determinada de una cadena, por
ejemplo una ip de origen de paquete, sern destinados segn sea la poltica establecida. Se
necesita configurar estas cadenas para aumentar el nivel de seguridad del sistema evitando
posibles ataques y realizar enrutamiento de paquetes a algunos servicios que lo requieren,
como por ejemplo el desvo de las solicitudes http hacia el puerto tcp 3128 de Squid. :

Politica Drop
root@PAcceso:~# iptables -P INPUT DROP
Cadena
root@PAcceso:~# iptables -A INPUT -s 172.16.1.156 -j ACCEPT
No coincide
El paquete pasa por la
cadena

Paquete de datos
Ip: 172.16.1.153

El paquete va a DROP segn

la poltica de INPUT

Se compara para ver si coincide

Figura 21. Poltica de regla y match de paquete

66

Tablas, reglas y destinos: La prueba se bas en la verificacin de las tablas, reglas

y destinos usados en iptables para filtrar los paquetes por medio de la realizacin de
comparaciones entre cadenas y tramas de datos. Todos los comandos se ejecutaron como el
administrador del servidor, es decir como root y aadido a esto la poltica que se estableci
fue la de ACCEPT. Las pruebas son las siguientes:
1.iptables -A INPUT -d 172.16.1.153 -i eth0 -p tcp -sport 80 -j
DROP
2.iptables

-A

OUTPUT

-s

172.16.1.153

-o

eth0

-p

tcp

-sport

49151:65535 -j DROP

1. Esta cadena bloque la entrada de paquetes para una llamada el puerto 80, del
protocolo tcp. (-A) agrega una cadena, (-d) es un conector que permite especificar
una direccin ip de destino impresa en los datos del datagrama, (-i) indica la interfaz
por la cual entra el paquete, (-p) define un el protocolo a usar, (--sport) indica el
puerto de donde proviene, (-j) sugiere un salto hacia un destino en especfico y por
ltimo tenemos el DROP sealando el destino del paquete. Los destinos ms
utilizados son el ACCEPT, DROP y REJECT. Tambin hay otra clases de destinos
que corresponden a una cadena determinada, como por ejemplo el destino
MASQUERADE que va con la cadena PREROUTING de la tabla nat.
Esta primera cadena bloque los paquetes pertenecientes al protocolo tcp con puerto
de origen 80 entrantes por la interfaz eth0, dirigidos hacia nuestro local host:
172.16.1.153. Los paquetes que no coincidan con esta cadena, se regirn por la
decisin de las polticas establecidas previamente, que en este caso son de ACCEPT
o aceptar.
2. Esta cadena contiene algunas reglas distintas de la primera. En este caso la cadena
no es una de entrada, lo que cambia un poco el significado de ciertas reglas. La
regla (-s) especifica la direccin ip donde se origina el paquete, (-o) indica la
interfaz por donde saldr el paquete y (--sport) dice de que puerto se origina el
paquete. La cadena completa bloque las salidas para el rango de puertos que se
seal en el campo de (--sport), originadas en el localhost 172.16.1.153 y por la
67

interfaz eth0.
En la prueba anterior las dos cadenas tienen casi la misma funcin, ya que se le
coloc un bloqueo a las peticiones web. Tales pruebas se hicieron para comprobar el
correcto funcionamiento de algunas reglas y tablas de iptables, y adems para visualizar
como se realiza una conexin real de un cliente con un servidor web. En una conexin web
entre dos estaciones, un cliente hace la solicitud a travs de los puertos restringidos o
privados tcp hacia el puerto www de la estacin servidora. El protocolo tcp posee una serie
de bloques de datos con caractersticas nicas, que permite a iptables realizar
comparaciones contra estos bloques (ver captulo II. Protocolo TCP). Las conexiones
salientes se pueden bloquear por medio de la trama de destino donde se aloja el puerto de
llegada que en este caso es el 80. Otra forma de bloquear esta conexin, sera a partir de los
paquetes entrantes.
Todo paquete dirigido hacia nuestro localhost vendr con una trama indicando
cul es su origen, que para este caso ser de nuevo el puerto 80. La cadena 1 bloque las
peticiones www de una forma bastante explicita debido a que se restringi un paquete con
origen de puerto en especifico. Otros paquetes podrn ser aceptados, mas no el proveniente
del puerto http. La cadena 2 no es tan explicita y adems es ineficiente ya que su funcin es
bloquear todas las nuevas conexiones que se puedan establecer por el rango de puertos
asignados y no simplemente las que van dirigidas al puerto 80.
Aadido a esta problemtica est la de que las conexiones se podan establecer en
puerto por debajo de estos; la peticiones hacia un servicio web generalmente se originan el
los puertos restringidos y dinmicos.
En la figura 22 se hicieron las entradas de las cadenas y se verific si fueron
escritas en el sistema. La opcin para mostrar el estado de las cadenas es de esta forma. La
opcin -L te lista los parmetros de iptables dependiendo de su opcin acompaante, que en
este caso, es (-n) que significa que la opcin de listados va a ser de forma numrica. En la
figura 23 el iptraf muestra datos de ejemplo, de una conexin hecha a un sitio web.

68

Figura 22. Introduccin de las cadenas en terminal

Figura 23. Visualizacin en el iptraf

69

El iptraf mostr que nuestro host enviaba la bandera de SYN por un puerto fuera
del rango especificado. El servidor, que en este caso corresponde a www.google.com; enva
las banderas de SYN+ACK para confirmar recibo. Estas no llegan jams a entrar a nuestro
sistema debido a que la cadena 1 actu, descartando este paquete y dejando inhabilitada la
conexin. Una conexin web real se hace siguiendo el siguiente esquema; claro est que se
indican las rutas y algunas de las banderas implcitas en esta operacin, mas no se indican
todos los dems factores que tambin estn incluidos en esta accin:
Servidores
DNS

Gateway

Cliente

a).Consulta DNS
b).Consulta DNS
c). Respuesta DNS
d).Consulta al servidor Web
e).Respuesta del servidor

Servidor Web

Figura 24. Establecimiento de conexin

a)El cliente solicita la resolucin del nombre google.com a sucach por medio de
una solicitud udp originada en uno de los puertos reservados o privados, con destino al
puerto 53.
b)Elcach no es capaz de resolverlo, por lo que se delega la tarea al gateway
(puente de salida).
c)Este no consigue la direccin del nombre por lo que hace una peticin a sus
servidores DNS. Estos servidores contestan con la locacin e Ip del nombre solicitado,
respondiendo as a la llamada del gateway y a su vez ste ltimo responde a la peticin que
le hizo el cliente con anterioridad.
d)El cliente abre otra conexin por los puertos restringidos pero esta vez ya no es
con el protocolo udp sino mas bien con el tcp. El envo esta acompaado con un destino
correspondiente al puerto 80 y una bandera de SYN, pasando por el gateway y dirigidos al
70

servidor web.
e)El servidor atiende la llamada por el puerto 80 enviando un acuse de recibo y
seal de sincronismo (ACK+SYN). El paquete pasa por el gateway, llega a la interfaz del
cliente y segn sea la configuracin de su firewall, ste lo aceptar o no.
Esta prueba fue una de las ms simples que se realiz. Se hicieron otras con el
mismo principio a la anterior pero en base a otros puertos para verificar algunos servicios
bsicos.
La tabla de filtro (filter), contiene cadenas diseadas para cuando el paquete se
encuentre en la puerta de entrada de la interfaz y en la salida de la misma, o simplemente
no pase por el sistema y sea redirigido. Existen otras tablas que son usadas para acciones
un poco ms complejas como la reescritura de un paquete de datos. La tabla de nat es una
de ellas. El NAT Network Address Translator es un sistema de intercambio de direcciones
en los paquetes de datos, con el fin de comunicar redes incompatibles. Iptables incluye esta
caracterstica de traduccin de direcciones en sus tablas. En la tabla nat hay cadenas de
entradas totalmente distintas a las existente en la tabla filter.
El diseo del servicio de acceso inalmbrico a Internet conlleva a la conexin de la
red LAN con las dems redes de internet, por esta razn es necesario implementar el
intercambio de direcciones ip. Las pruebas sobre la tabla de nat en conjunto con otras
adicionales de la filter estn descritas en breve:
1.iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j LOG
--log-prefix nat de paquetes salientes --log-level 4
iptables

-t

nat

-A

POSTROUTING

-s

10.0.0.0/24

-o

eth0

-j

MASQUERADE
2.iptables -t nat -A PREROUTING -i eth1 -p tcp -dport 80 -j LOG
log-prefix desvo de paquetes --log-level 4
iptables -t nat -A PREROUTING -i eth1 -p tcp -dport 80 -j
REDIRECT --to-port 3128

71

1. Esta cadena se implement para lograr que los computadores de la LAN que se
montara para pruebas, pudieran salir a la red de Internet sin tener ningn conflicto
por direcciones ip, adems de esto tambin se us para ver quin realiza tal accin
por medio de la observacin de los registros (logs) que dejan en el sistema y as
realizar mas adelante algn programa que tome los datos de estos registro y
tarifique el consumo. La primera cadena escribe en los logs de iptables los paquetes
salientes con mscaras hechas. Los logs son registros de procesos que se dan en el
sistema Linux. Tienen distintos niveles de avisos y se usan para monitorear eventos
dentro del sistema, que de alguna forma u otra alteren el mismo. En Linux se puede
crear un log exclusivo para el uso de iptables, muy ventajoso para llevar informes
del servidor o conteo de accesos. Cuando hicimos uso de los logs para iptables, fue
necesario crearlos y agregarlos al sistema de la siguiente manera:
Terminal
root@PAcceso:~# cd /var/log/
root@PAcceso:/var/log#
root@PAcceso:/var/log# touch iptables.log
root@PAcceso:/var/log# cd /etc
root@PAcceso:/etc#
root@PAcceso:/etc#vi syslog.cof

Figura 25. Creacin de un log para iptables

Esto crea el archivo donde los logs de iptables escribirn. La ultima lnea de la
terminal arroja el siguiente resultado, que es la visualizacin del archivo
syslog.conf:

72

Terminal
# Default rules for syslog.
#
#
For more information see syslog.conf(5)
and /etc/syslog.conf
#
# First some standard log files. Log by facility.
#
auth,authpriv.*
/var/log/auth.log
*.*;auth,authpriv.none
-/var/log/syslog
#cron.*
/var/log/cron.log
daemon.*
-/var/log/daemon.log
kern.*
-/var/log/kern.log
lpr.*
-/var/log/lpr.log
mail.*
-/var/log/mail.log
user.*
-/var/log/user.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
mail.info
mail.warn
mail.err
#LOG DE IPTABLES
kern.warn
# Logging for INN news system.
news.crit
news.err
news.notice
# Some "catch-all" log files.
#
*.=ddebug;\
auth,authpriv.none;\
news.none;mail.none
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\

-/var/log/mail.info
-/var/log/mail.warn
/var/log/mail.err
/var/log/iptables.log
/var/log/news/news.crit
/var/log/news/news.err
-/var/log/news/news.notice

-/var/log/debug

Figura 26. Archivo /etc/syslog.conf

La columna de la izquierda indica el quin escribe sobre log y el nivel de avisos que
escribir en l. Existen 4 niveles siendo warn el de ms alto rango. La columna de la
izquierda fija la ruta donde se encuentra el archivo que alojar los mensajes. Una
vez agregado el log, es necesario reiniciar la aplicacin que arranca el sistema de
logs /etc/init.d/syslog, por medio de la orden: bash /etc/init.d/syslog restart.
73

Culminada la creacin del iptables.log, ya puede ser usado por las cadenas que se
configuren para dejar sus registros en este archivo. La cadena nmero 1 se
construy para que pudiera dejar registros los paquetes que salieran a la red de
internet. Cada vez que se requiera que una cadena deje su registro en el log de
iptables, la misma se debe escribir dos veces; la primera con un destino -j LOG (con
sus parmetros completos --log-prefix y --log-level), y la siguiente deber tener el
destino original como por ejemplo -j DROP. En la prueba se us la tabla (-t) de nat
(nat), con la cadena de entrada para paquetes que an no han llegado a la salida del
sistema (POSTROUTING), la regla (-s) indicando las direcciones a las que se le
harn nat, el (-o) indicando la interfaz de salida, (-j) el salto hacia al destino fijado y
el destino LOG donde se especifica el --log-prefix correspondiente a el nombre con
que se identificar el mensaje dentro del log y su nivel de aviso que es el 4 o de
warn indicado en --log-level. En esta primera cadena sol especific a quin se le
hizo un log, la segunda es la verdadera cadena con la cual se hacen las
comparaciones y coincidencias de los paquetes que estn previos a salir de la red. El
destino de esta segunda lnea es el que realiza la mscara a cada paquete, mediante
el destino MASQUERADE. Este destino sol est disponible para la cadena de
POSTROUTING.
2. En esta segunda prueba tambin se implementaron los log pero esta vez para otra
cadena de la tabla nat llamada PREROUTING. Esta cadena le hace un match a
todos los paquetes antes de la entrada al sistema por medio de eth1, dirigidos hacia
el puerto 80 del protocolo tcp. Si cumplen con estas reglas al paquete se redirige
hacia el destino REDIRECT, que desva su puerto destino al que est presente en la
regla --to-port.
Esta ultima prueba permiti conocer otras cadenas y tablas con destinos fijos y
nicos para ellos.

74

5.2.2 Manejo e implementacin de algunos mdulos de iptables.

Mdulo multiport. Este mdulo permite la especificacin de varios puertos
individuales en una sola lnea, es decir, que en una sola cadena podemos bloquear o aceptar
paquetes, con un lmite de entradas de puertos de 15, util para evitar que el script5 final de
iptables se extienda demasiado y sea incomprensible. Adems de eso permite colocar en un
slo parmetro los puertos de destino y los puertos de origen, permitiendo bloquear de
forma definitiva paquetes dirigidos o provenientes de un puerto tcp en especifico. La
prueba realizada fue la siguiente:
iptables -A OUTPUT -s 172.16.1.153 -o eth0 -m multiport -p tcp
--dport 53,67,68,110,220,443,993,995,1863 -j ACCEPT

Con una poltica de negacin en todos los puertos, esta regla permiti que una
comunicacin bsica se estableciera con el servidor. Los puertos que estn especificados en
la cadena, pertenecen a puertos usados de forma local, es decir por las aplicaciones
presentes en el sistema operativo. Esta prueba permiti que el cliente obtuviera una
direccin ip del servidor, se pudiera comunicar con su servidores DNS, posibilidades del
servicio de correo POP3, POP3S, imap3 y mensajera instantnea. El parmetro de entrada
para especificar mltiples puertos es (-m, --module), y luego de ste se coloca cul es el
mdulo a usar, en esta ocasin se uso el multiport.
Mdulo conntrack. Este mdulo permite el seguimiento de las conexiones que se
realizan mediante el uso de la

opcin --ctstate. Los estados de las conexiones son

mltiples, pero los ms usados son: NEW nueva conexin, ESTABLISHED conexin
establecida, RELATED conexin relacionada, e INVALID conexin no valida. A partir de
estos, pueden o no establecerse enlaces con otras mquinas por medio del protocolo tcp.
Mayormente es usado en las conexiones a travs del puerto 80 y 443, que son los puertos
correspondiente con el servicio web o http. Para implementar este mdulo se ejecut la
siguiente prueba:
5 Un script es una serie de ordenes contenidas en un archivo que se ejecutan paso a paso.

75

1.iptables

-A

OUTPUT

-s

172.16.1.153

-o

eth0

-p

tcp

--sport

1024:65535 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

iptables

-A

OUTPUT

-s

172.16.1.153

-o

eth0

-p

udp

--sport

-i

eth0

-p

tcp

--dport

1024:65535 -j ACCEPT
2.iptables

-A

INPUT

-d

172.16.1.153

1024:65535 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables

-A

INPUT

-d

172.16.1.153

-i

eth0

-p

udp

--dport

1024:65535 -j ACCEPT

1. En esta cadena se puso a prueba el mdulo conntrack con la opcin --ctstate que
permite el seguimiento de las conexiones. Bajo una poltica DROP los puertos
restringidos y privados fueron habilitados, permitiendo nicamente las conexiones
nuevas y establecidas. Con esta declaracin se logr que la estacin pudiera enviar
peticiones de nuevos enlaces a servidores web, servidores streaming6, servicio de
mensajera instantnea, servidores DNS y otros. El nodo de origen (-s)
172.16.1.153, con salida (-o) por eth0, para los protocolos (-p) udp y tcp, con
puertos de origen 1024:65353 (--sport), puede crear conexiones de estados nuevo y
estable (--ctstate NEW, ESTABLISHED).
2. Esta cadena permiti la conexin total del nodo cliente con cualquier otra estacin
de la red, debido a que posibilit que las peticiones hechas en la primera cadena,
fueran contestadas, pudiendo entrar al sistema sin ningn tipo de restriccin.
Habilitando las entradas a conexiones establecidas y relacionadas, se permiti que
los servidores puedan enviar la el paquete de datos con el acuse de recibo y la seal
se sincronismo (ACK y SYN), ms no que los mismos por cualquier razn crearn
conexiones nuevas. Los servidores podan enviar tramas icmp de errores para
controlar algn desperfecto presente en los paquetes de datos, haciendo lo que se
llama una conexin relacionada (RELATED).
Estas pruebas se realizaron para el entendimiento y familiarizacin con las
6 Streaming se define segn: http://es.wikipedia.org, como la transmisin sin interrupciones de audio y
vdeo por internet

76

caractersticas bsicas que provee iptables, as como establecer una pequeo sistema de
seguridad el cual nos permita controlar los accesos a ciertas aplicaciones de la red. Existen
muchas ms reglas y mdulos que se pueden implementar para plantear un Firewall de alto
nivel de seguridad mediante iptables, pero para los efectos de un montaje sencillo bast con
usar estas que se explicaron.

77

CAPITULO VI:
Distribucin lgica de la red y registro del
dominio principal
6.1 Servicio DHCP
6.1.1 Instalacin y configuracin del servicio dhcp3-server
6.1.2 Instalacin de una pequea red con topologa rbol
6.1.3 Pruebas
6.2 Servicio DNS
6.2.1 Pasos previos al manejo, configuracin e instalacin
6.2.2.Manejo, configuracin e instalacin de BIND-DNS
6.2.3 Pruebas al servidor

78

CAPITULO VI
Distribucin lgica de la red y registro del dominio principal
Para todo servicio de punto de acceso a Internet es necesario un proveedor que
configure los parmetros de red de los nodos a conectar de forma automtica o manual.
Cuando un cliente va a conectarse hacia una red necesita identificarse con una direccin ip,
mscara de la red, gateway de salida y servidores DNS si requiere resolver algn dominio.
Estos parmetros los puede configurar el administrador de la red directamente en la
mquina del usuario o puede implementar un servicio automtico que realice esta accin,
como por ejemplo un servidor DHCP. Tomando en cuenta este punto, se procedi a la
descarga de un servicio DHCP que es el programa que cumple con tales puntos de
administracin. Una vez descargado el paquete se continu con la configuracin del
servidor DHCP de acuerdo a parmetros establecidos para la red de nuestro punto de acceso
como son: direccin del servidor DHCP, direccin de los servidores DNS, rango de Ips
entregadas a la red, tiempo de vida de una Ip, puente de salida, direccin de red y mscara
de la sub-red. El paquete del servicio DHCP a instalar sera el dhcp3-server debido a que es
el ms usado y proporciona una serie de caractersticas configurables que se necesitaron
durante el desarrollo el proyecto.
6.1 Servicio DHCP
6.1.1 Instalacin y configuracin del servicio dhcp3-server
La instalacin y configuracin de el servidor se realiz de la siguiente manera:
1. Descarga e instalacin del paquete dhcp3-server: se procedi a la descarga del
servicio dhcp3-server mediante el uso del gestor de descargas en consola de ubuntu
aptitude. Se abri una terminal y luego de entrar como el administrador del sistema
root se escribi el siguiente comando: aptitude search junto a la palabra dhcp, lo
que arroj una lista de paquetes que coinciden con la palabra dhcp en su nombre.
79

root@PAcceso:~# aptitude search dhcp

p
autodns-dhcp
- Automatic DNS updates for DHCP
p
dhcp-client
- DHCP client transitional package
p
dhcp-helper
- A DHCP relay agent
p
dhcp-probe
- network dhcp or bootp server discover
i
dhcp3-client
- DHCP client
i
dhcp3-common
- common files used by all the dhcp3* packa
p
dhcp3-dev
- API for accessing and modifying the DHCP
p
dhcp3-relay
- DHCP relay daemon
p
dhcp3-server
- DHCP server for automatic IP address as
p
dhcp3-server-ldap
- DHCP server able to use LDAP as backend
p
dhcpcd
- DHCP client for automatically configuring
p
dhcpdump
- Parse DHCP packets from tcpdump
p
dhcping
- DHCP Daemon Ping Program
p
ebox-dhcp
- eBox - DHCP Service
p
gadmin-dhcpd
- GTK+ configuration tool for dhcpd3-server
p
gadmin-dhcpd-dbg
- GTK+ configuration tool for dhcpd3-server
p
libnet-dhcp-perl
- Interface for handling DHCP packets
p
libtext-dhcpleases-perl - Perl module to parse DHCP leases file f
p
udhcpc
- very small DHCP client
p
udhcpd
- very small DHCP server
p
wide-dhcpv6-client
- DHCPv6 client for automatic IPv6 h
p
wide-dhcpv6-relay
- DHCPv6 relay for automatic Ipv6
p
wide-dhcpv6-server
- DHCPv6 server for automatic IPv6

Figura 27. Comando aptitude search

En esta lista se puede visualizar todos los paquetes que estn instalados en nuestro
sistema (i), as como los que no estn (p). El paquete que se encuentra sombreado
en magenta corresponde con el servicio dhcp3-server y adems se observ que no
est instalado por lo que se procedi descargarlo por medio del siguiente comando:
aptitude install dhcp3-server. Este comando descarg el paquete en su totalidad,
pero al momento de su instalacin arroj el siguiente mensaje de importancia:

80

Terminal
root@PAcceso:~# aptitude install dhcp3-server
Leyendo lista de paquetes... Hecho
Creando rbol de dependencias
Leyendo la informacin de estado... Hecho
Leyendo la informacin de estado extendido
Inicializando el estado de los paquetes... Hecho
Se instalarn los siguiente paquetes NUEVOS:
dhcp3-server
0 paquetes actualizados, 1 nuevos instalados, 0 para eliminar
y 20 sin actualizar.
Necesito descargar 398kB de ficheros. Despus de desempaquetar se
usarn 918kB.
Escribiendo informacin de estado extendido... Hecho
Des:1 http://archive.ubuntu.com/ubuntu/ lucid/main dhcp3-server
3.1.3-2ubuntu3 [398kB]
Descargados 398kB en 6s (62,3kB/s).
Preconfigurando paquetes ...
Seleccionando el paquete dhcp3-server previamente no seleccionado.
(Leyendo la base de datos ... 00%
170293 ficheros y directorios instalados actualmente.)
Desempaquetando dhcp3-server (de .../dhcp3-server_3.1.32ubuntu3_i386.deb) ...
Procesando disparadores para man-db ...
Procesando disparadores para ureadahead ...
Configurando dhcp3-server (3.1.3-2ubuntu3) ...
Generating /etc/default/dhcp3-server...
* Starting DHCP server dhcpd3
* check syslog for diagnostics.
[fail]
invoke-rc.d: initscript dhcp3-server, action "start" failed.
Leyendo lista de paquetes... Hecho
Creando rbol de dependencias
Leyendo la informacin de estado... Hecho
Leyendo la informacin de estado extendido
Inicializando el estado de los paquetes... Hecho
Escribiendo informacin de estado extendido... Hecho
root@PAcceso:~#

Figura 28. Comando aptitude install

En el momento de instalacin del servicio ste fall debido a que an no ha sido
configurado. Los archivos ms importantes que se instalaron durante el proceso son:
/etc/dhcp3/dhcp.conf , /etc/default/dhcp3-server y /etc/init.d/dhcp3-server.
2. Configuracin del servidor DHCP: mediante la manipulacin de los archivos de
81

configuracin que se instalaron y un ltimo que slo pertenece al sistema operativo

/etc/sysctl.conf, se procedi a la configuracin del servidor, para identificar dentro
de la red a los nodos que se conecten. Primero se plantearon una serie de
propiedades correspondiente a la red que ayudaran a la configuracin sin errores
del servidor:
a) Numero de nodos: 20.
b) Red privada clase A: 10.0.0.0, con mscaras de 255.255.255.0, con un
rango de 10.0.0.10 hasta 10.0.0.30, direccin de broadcast: 10.0.0.255,
router: 10.0.0.1 y servidor DNS: 172.16.1.153.
c) Interfaz servidora: eth1, direccin Ip: 10.0.0.1 mscara de red:
255.255.255, gateway: 172.16.0.1
d) Modo DHCP: dinmico.
Con estas caractersticas, el primer archivo editado fue el /etc/dhcp3/dhcp.conf,
donde se especificaron los datos correspondientes a las propiedades a y b
anteriormente nombradas. A continuacin las lneas ms importantes del archivo
/etc/dchp3/dhcp.conf:
Terminal
#
#
#
#
#
#
#

Sample configuration file for ISC dhcpd for Debian

Attention: If /etc/ltsp/dhcpd.conf exists, that will be used as
configuration file instead of this file.
$Id: dhcpd.conf,v 1.1.1.1 2002/05/21 00:07:44 peloy Exp $

# The ddns-updates-style parameter controls whether or not the server

will
# attempt to do a DNS update when a lease is confirmed. We default
to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

a)
82

# option definitions common to all supported networks...

option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;
default-lease-time 600;
max-lease-time 7200;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
# A slightly different configuration for an internal subnet.
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.10 10.0.0.30;
option domain-name-servers 172.16.1.153;
# option domain-name "internal.example.org";
option routers 10.0.0.1;
option broadcast-address 10.0.0.255;
default-lease-time 600;
max-lease-time 7200;
}

b)
Figura 29. a y b. Archivo dhcp.conf.
Las lneas sombreadas en azul celeste forman parte del archivo por defecto y el
hecho de que no estn comentadas con el carcter numeral (#) significa que la lnea
est activa. Estas lneas configuran de forma comn para todas las redes colocadas
en este archivo, los parmetros de servidor DNS, DNS emergente, tiempo de
asignacin por defecto y tiempo mximo de asignacin, por lo que fue necesario
comentarlas y as desactivarlas para no crear conflicto posteriores. La primera lnea
sombreada en magenta, por defecto estaba comentada con (#) y eso indicaba que la
lnea no estaba activada. Esta lnea es muy importante ya que autoriza a nuestro
servidor dhcp local como el servidor oficial de toda la red, permitiendo que pueda
proveer los datos de red a las estaciones que se lo pidan. Las lneas siguientes que
estn sombreadas tambin estn comentadas al igual que la anterior. Para nuestros
efectos estas se habilitaron y configuraron segn los parmetros establecidos
83

anteriormente para la disposicin lgica de la red. En la primera lnea se coloc la

red que se creara (subnet) y la mscara de red que tendra cada estacin (netmask).
En la segunda lnea se design el rango de direcciones de donde se tomaran las ip
para cederlas a los nodos que necesiten (range), en la tercera lnea se escribi qu
servidor DNS resolvera los nombres, que en este caso es nuestro propio servidor;
en la quinta lnea se configur el punto que enruta a los paquetes (router), en la
siguiente lnea se coloc la direccin para los broadcast, y las dos ltimas
corresponden a los tiempos en la que una direccin estar asignada a una estacin
en especfico.
Luego de que se edit el archivo de configuracin dhcp.conf, se continu con la
designacin de la tarjeta servidora y por ende la estructuracin de los parmetros de
red del host asociado. Primero nos situamos sobre el archivo /etc/default/dhcp3server que contiene lo siguiente:
Terminal
Defaults for dhcp initscript
# sourced by /etc/init.d/dhcp
# installed at /etc/default/dhcp3-server by the maintainer scripts
#
# This is a POSIX shell fragment
#
# On what interfaces should the DHCP server (dhcpd) serve DHCP
requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES="eth1"

Figura 30. Archivo /etc/default/dhcp3-server

En el campo INTERFACES se design la interfaz servidora, la cual era la segunda
interfaz presente en la mquina servidor eth1. Tambin en este campo se pueden
asignar ms interfaces que sern servidoras DHCP en tal caso de que existan varias
redes en el archivo /etc/dhcp3/dhcp.conf. Luego de editar el archivo, se guard y se
continu con la edicin del archivo /etc/network/interface, esta vez con los
parmetros que se designaron al momento del planteamiento de la red (ver captulo
IV, configuracin de la tarjeta de red). Con los siguientes elementos qued
84

configurado el archivo interface:

auto eth1;
iface eth1 inet static;
address 10.0.0.1;
netmask 255.255.255.255;
gateway 172.16.0.1.

Culminada esta accin se continu con la activacin de los desvos para la ipv4.
Estos desvos son necesarios a la hora de que los host de la red LAN necesiten
conectarse con otras redes presentes el internet. Estos desvos se habilitaron en el
archivo de configuracin /etc/sysctl.conf. Parte de ese archivo contiene la siguiente
informacin:
Terminal
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#
#kernel.domainname = example.com
# Uncomment the following to stop low-level messages on console
#kernel.printk = 4 4 1 7
##############################################################3
# Functions previously found in netbase
#
# Uncomment the next two lines to enable Spoof protection (reversepath filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1
# Uncomment the next line to enable TCP/IP SYN cookies
#net.ipv4.tcp_syncookies=1
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

Figura 31. Archivo /etc/sysctl.conf

85

La lnea que est sombreada con magenta por defecto est comentada y por ende
desactivada. Al momento de la edicin esta se descoment, habilitando de esa forma
los desvos para las ipv4.
El ltimo paso que se dio para la configuracin del servidor dhcp, fue el de reiniciar
la aplicacin por medio del archivo de inicio

/etc/init.d/dhcp3-server, bajo la

opcin restart.
6.1.2 Instalacin de una pequea red con topologa en rbol
Esta red se instal con el fin de realizar las pruebas del servidor DHCP y los
servicios que se instalaron posterior a este. La red no consta de los host completos que se
especificaron, sino que slo se arm con 2 computadores disponibles que haban en el
laboratorio. La disposicin de fsica de la red fue la siguiente:
C1

Gateway

C2

Servidor
DHCP

Eth1

Internet

Eth0

Switch

Figura 32. Disposicin fsica de la red

Bajo esta disposicin se conectaron los equipos presentes en el laboratorio. La
especificacin de los equipos usados es la siguiente:

las estaciones C1 y C2 son computadores IBM con procesadores Intel

Pentium II

el switch7 tiene 15 puertos ethernet de salida a una velocidad de 10 Mbps

el servidor DHCP posee dos tarjetas de red: Eth1 con direccin ip 10.0.0.1,

7 El switch o conmutador segn la web: es.wikipedia.org, es un dispositivo digital de lgica de

interconexin de redes de computadores que opera en la capa 2 (nivel de enlace de datos) del modelo
OSI.

86

netmask 255.255.255.0

y Eth0 con direccin ip 172.16.1.153, netmask

255.255.0.0. Un procesador Intel Pentium III

Gateway

Cables de red construidos segn la norma T568b en ambas puntas

Descripcin del la conexin del montaje: El primer paso que se dio para el montaje
de la red, fue el de la conexin del gateway por medio de un cable de red simple con la
tarjeta de red Eth0 del servidor principal. Despus de este paso se conecta la tarjeta de red
Eth1 a uno de los puertos del conmutador o switch, permitiendo que cualquier estacin que
se conecte a uno de los puertos pueda hablar al servidor haciendo un broadcasting para
obtener los datos de red que necesitan Luego de esto se procedi a conectar cada una de las
estaciones de prueba, en un puerto correspondiente del conmutador.
6.1.3 Pruebas
Las pruebas que se realizaron en esta etapa son bastantes sencillas y esencialmente
se basaron en la conexin de los host al punto de acceso. Cuando se estableca un enlace
por parte del usuario al servidor, en la mquina se verificaba si exista o no una direccin
ip, mscara de red y servidores DNS que son los parmetros brindados y configurados por
nuestro servidor.
6.2 Servicio BIND-DNS
6.2.1 Pasos previos al manejo, configuracin e instalacin del servidor BINDDNS
Se realiz una bsqueda de informacin sobre los servidores DNS, debido a que
fue necesario el montaje de uno para acelerar las respuestas a las peticiones http,
implementando un servicio de resolucin de nombres de forma local, y adems tambin se
requera resolver el nombre de un host web, que se usar para respuestas a las solicitudes de
87

pginas bloqueadas. Los trminos ms importantes sobre la investigacin son los

siguientes:
Los Servidores de Nombres de Dominio son estaciones dedicadas compuestas con
un sistema que permite la resolucin de direcciones y nombres en la red de internet. Estos
servidores tienen la capacidad de proporcionar informacin sobre un host, su locacin, su
direccin, sus servidores asociados, su zona de autoridad, su tiempo de vida, su tiempo de
refresco, tiempo de expiracin, su puntero de resolucin inversa y servicio de correo
asociado. Existen tres trminos bsicos designados a una estacin que se relacione con el
servicio DNS. Estos trminos permiten identificar qu posicin toma una estacin a la hora
de una transaccin de resolucin de nombres. Cliente DNS, servidor DNS y zona de
autoridad, son los trminos que diferencian a una estacin de otra. El cliente siempre genera
las peticiones, mientras que el servidor las resuelve y las zonas de autoridad son los
espacios de donde se suministra la informacin para la resolucin de los nombres. Cuando
un servidor va a resolver un nombre de dominio, lo hace de forma jerrquica comenzando
con los campos de menor nivel hasta llegar a los de nivel superior o la raz (ver captulo II.
Servidor DNS).
Luego de esto se invirti un tiempo especfico para el aprendizaje del servicio
BIND-DNS donde se resalta lo siguiente:
BIND-DNS es un servicio que resuelve direcciones ip a partir de un nombre de
dominio asignado, creado por estudiantes de la Universidad de California Berkeley (ver
captulo II. BIND-DNS). Esta aplicacin tiene la capacidad de alojar mltiples zonas de
autoridad y configurarlas de forma jerrquica. Es una distribucin que se usa mayormente
para los sistemas de entornos libres y es muy versaltil en cuanto al manejos de sus host
alojados en l. La aplicacin trabaja con varios ficheros de configuracin los cuales
permiten organizar de forma individual los dominios que se deseen ingresar al servidor.
Posee un archivo de configuracin principal en donde se agregan los host y se les concede
o no, la capacidad de ser resueltos.

88

6.2.2 Manejo, instalacin y configuracin del servidor BIND-DNS

Uno de las etapas ms sencillas durante el desarrollo del proyecto fue la
instalacin del servidor DNS a base del servicio Bind9. Los pasos para la instalacin,
manejo y configuracin del servicio de resolucin de nombres, se ejecutaron de la siguiente
manera:
1. Descarga e instalacin del paquete Bind9: Se procedi a la descarga del paquete
Bind9 por medio del gestor de descargas en consola aptitude. Bajo el parmetro de
install se ejecut en consola el siguiente comando: aptitude install bind9. La
ejecucin de este comando arrojo el siguiente resultado:
Terminal
root@PAcceso:~# aptitude install bind9
Leyendo lista de paquetes... Hecho
Creando rbol de dependencias
Leyendo la informacin de estado... Hecho
Leyendo la informacin de estado extendido
Inicializando el estado de los paquetes... Hecho
Se instalarn los siguiente paquetes NUEVOS:
bind9 bind9utils{a}
0 paquetes actualizados, 2 nuevos instalados, 0 para eliminar y
20
sin actualizar.
Necesito descargar 460kB de ficheros. Despus de desempaquetar
se
usarn 1425kB.
Quiere continuar? [Y/n/?] y
Escribiendo informacin de estado extendido... Hecho
Des:1 http://archive.ubuntu.com/ubuntu/ lucid/main bind9utils
1:9.7.0.dfsg.P1-1 [117kB]
Des:2 http://archive.ubuntu.com/ubuntu/ lucid/main bind9
1:9.7.0.
dfsg.P1-1 [343kB]
Descargados 460kB en 4s (93,7kB/s).
Preconfigurando paquetes ...
Seleccionando el paquete bind9utils previamente no
seleccionado.
(Leyendo la base de datos ... 00%
171823 ficheros y directorios instalados actualmente.)
Desempaquetando bind9utils (de
.../bind9utils_1%3a9.7.0.dfsg.P1-1_amd64.deb) ...

a)
89

Seleccionando el paquete bind9 previamente no seleccionado.

Desempaquetando bind9 (de .../bind9_1%3a9.7.0.dfsg.P1-1_amd64.deb)
Procesando disparadores para man-db ...
Procesando disparadores para ufw ...
Procesando disparadores para ureadahead ...
ureadahead will be reprofiled on next reboot
Configurando bind9utils (1:9.7.0.dfsg.P1-1) ...
Configurando bind9 (1:9.7.0.dfsg.P1-1) ...
Aadiendo el grupo bind (GID 126) ...
Hecho.
Aadiendo el usuario del sistema `bind' (UID 117) ...
Aadiendo un nuevo usuario bind (UID 117) con grupo bind ...
No se crea el directorio personal /var/cache/bind.
wrote key file "/etc/bind/rndc.key"
* Starting domain name service... bind9
[ OK ]
Leyendo lista de paquetes... Hecho
Creando rbol de dependencias
Leyendo la informacin de estado... Hecho
Leyendo la informacin de estado extendido
Inicializando el estado de los paquetes... Hecho
Escribiendo informacin de estado extendido... Hecho
root@PAcceso:~#

b)
Figura 33. a y b. Proceso de descarga e instalacin del paquete Bind9
Durante el proceso de descarga, el sistema instal automticamente los paquetes
bajados. En este punto tambin se inicializ de forma instantnea la aplicacin
correspondiente a la descarga; en este caso el servicio Bind9. Los archivos ms
destacados durante la instalacin y para la configuracin del servidor, son:
/etc/bind/, /etc/default/bind9, /etc/init.d/bind9, db.root, named.conf.default-zones,
named.conf.local, named.conf.options.
2. Manejo y configuracin de sus archivos principales: Para la configuracin y
montaje del servidor slo fue necesario el planteamiento de un nombre de dominio
que identificara inequvocamente a nuestro host, dentro de nuestra red. El nombre
de dominio que se design fue el de accipoint.net, el cual servira para designarlo
como zona de autoridad. Adems de esto el dominio no poseera ningn servicio de
correo vinculado y tendra una nica direccin como host para la resolucin. En
base a esto se procedi inicialmente a la configuracin del archivo
named.conf.default-zones, de la siguiente forma:
90

Terminal
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones,
and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
// CONFIGURACION PARA NUESTRO DOMINIO LOCAL
zone "accipoint.net" {
type master;
file "/etc/bind/db.accipoint";
};

Figura 34. Archivo named.conf.default-zones

En este archivo se especifican las zonas que se van agregar al servidor, as como
tambin se designa el carcter jerrquico de la zona, bien sea como maestro o
esclavo. Nuestra zona es de nivel maestro ya que no depender de ningn otro
dominio para recibir peticiones de resolucin de nombres. Aqu tambin se
especific el archivo que contiene el esqueleto y la informacin del servidor. En el
parmetro zone se design el nombre de la zona. El parmetro type indica la
modalidad jerrquica del servidor, y en parmetro file designamos el archivo que
contendr los datos del dominio.
Luego de la edicin de este archivo, se continu con la creacin del archivo que
91

llevara el esqueleto del dominio. Para esto fue necesario situarnos dentro del
directorio /etc/bind/, y una vez en l, ejecutar un comando perteneciente al sistema
Linux llamado touch. El touch permite la generacin de archivos nuevos en el
directorio donde se encuentre ubicado el usuario. El nombre que llevar el archivo
se especifica enseguida luego del comando:
root@PAcceso:~# touch db.accipoint

Una vez creado el archivo para la configuracin de la zona, se procedi a configurar

los parmetros de la misma. Para tener una referencia de los parmetros estos fueron
copiados a partir del archivo /etc/bind/empty.db. El archivo empty no cumple
funcin alguna en el proceso de resolucin de nombre, mas sirve de esqueleto al
momento de montar un servidor cualquiera. Las caractersticas del nuevo archivo
generado son las siguientes:
Terminal
; Configuracin de nuestro dominio local
;
$TTL
86400
@
IN
SOA
accipoint.net. root.accipoint.net. (
4
; Serial
604800
; Refresh
86400
; Retry
2419200
; Expire
86400 )
; Negative Cache TTL
;
@
IN
NS
accipoint.net.
@
IN
A
172.16.1.153
~

Figura 35. Archivo db.accipoint

Los campos en magenta son los que se reescribieron para la configuracin de
nuestro dominio. En estos campos se especifica el nombre que se resolver
especificando el nivel de jerarqua y la raz correspondiente al punto ( . ). Con estos
parmetros colocados en esta disposicin, se procede a guardar el archivo y a
reiniciar el servidor DNS. El proceso de reinicio de la aplicacin se realiz de la
92

misma forma que se hizo en las etapas anteriores, por medio del uso de los archivos
de configuracin al inicio ubicados en /etc. Para reiniciar se ejecuta la siguiente
orden: /etc/init.d/bind9 restart.
6.2.3 Pruebas al servidor DNS
Una vez que se reinici la aplicacin sin encontrar ningn problema, se ejecutaron
varios comandos en Linux que permiten las pruebas de los servicios de resolucin de
nombre. Para comenzar se insert en el archivo /etc/resolve.conf, las siguientes lneas:
domain accipoint.net
search accipoint.net
nameserver 190.204.226.8

En este archivo se encuentran todos los servidores DNS del sistema. Existen
dentro se este, algunos servidores DNS que son proporcionados por nuestros proveedores
de servicio de Internet debido a que estos poseen un servidor DHCP que configura este
parmetro para usar sus servidores DNS en la resolucin de nombres de dominio. Cuando
se colocaron estas lneas, se agreg tambin nuestro servidor DNS como servidor de
resolucin de nombres adicional para que los usuarios lo utilicen y aumenten su velocidad
de navegacin, debido a que este servidor se encuentra localmente y por ende las respuestas
son ms rpidas en comparacin con la respuesta de los servidores del ISP. Una vez que
insertaron las lneas en el archivo, se continuo con la reescritura de ste la momento del
guardado. Los comandos que se usaron para la prueba son el comando dig y el comando
host. El primer comando se ejecut de esta forma:

93

Terminal
root@PAcceso:~# dig accipoint.net
; <<>> DiG 9.7.0-P1 <<>> accipoint.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28963
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1,
ADDITIONAL: 0
;; QUESTION SECTION:
;accipoint.net.

IN

;; ANSWER SECTION:
accipoint.net.

86400

IN

190.204.226.8

;; AUTHORITY SECTION:
accipoint.net.

86400

IN

NS

accipoint.net.

;;
;;
;;
;;

Query time: 0 msec

SERVER: 190.204.226.8#53(190.204.226.8)
WHEN: Sun May 16 17:17:11 2010
MSG SIZE rcvd: 61

root@PAcceso:~#

Figura 37. Comando dig

Este comando permiti comprobar el perfecto funcionamiento del servidor DNS.
Ntese que el comando en principio identific el nombre del dominio servidor, luego en el
campo QUERY:1; indica que paso por una cadena de consulta dando como resultado una
respuesta ANSWER:1; encontrando a una zona de autoridad responsable AUTHORITY:1.
Con estos 3 simples campos se verific que el dominio est activo ya que al momento de
pasar por la cadena de consulta, la misma, arroj resultados positivos encontrando
elementos relacionados a la bsqueda. Los siguientes campos especificaron donde se hizo
la consulta, quin respondi a la consulta y quin es la zona de autoridad de la respuesta,
que para entonces perteneca a nuestro servidor DNS accipoint.net. Adems de esto el
tiempo de respuesta es casi nulo, es decir, que no se tardo nada en resolver el nombre;
indicando as que las bsquedas se aceleran en una gran medida. Esta es la prueba que ms
datos proporcion sobre el funcionamiento del servidor DNS. La que le sigui fue hecha
con el comando host y se realiz escribiendo sobre la consola lo esto:
94

root@PAcceso:~# host accipoint.net

Lo que nos da un resultado de:

accipoint.net has address 190.204.226.8

Esta prueba es menos informativa pero fue otra forma de probar la respuesta del
servidor. El comando simplemente resolvi el nombre de dominio, preguntando a los
servidores DNS del sistema. La direccin asociada fue la respuesta que se encontr para la
solicitud hecha. Cuando no se encuentra ninguna direccin asociada, el comando nos da un
mensaje de error:
root@PAcceso:~# host accipoint.net
Host accipoint.net not found: 3(NXDOMAIN)

De esta forma se culminaron las pruebas y el montaje del servidor DNS, logrando
el entendimiento del mismo e instaurando la configuracin final que usarn los usuarios al
momento de conectarse a nuestro servidor. El montaje y las pruebas no tuvieron un grado
de dificultad mayor debido a que es bastante sencillo y verstil, el uso de esta aplicacin de
servidores.

95

CAPITULO VII:
Gestin de contenidos en la capa de aplicacin
7.1 Proxy
7.1.1 Pasos previos a la configuracin e instalacin de Squid
7.1.2 Instalacin y configuracin bsica de Squid
7.1.3 Configuracin de las listas de acceso de Squid
7.1.4 Configuracin de los Logs de Squid
7.1.5 Configuracin del manejo de objetos en lacach de Squid
7.1.6 Instalacin y configuracin del mdulo de Squid:SquidGuard
7.1.7 Pruebas al servidor de Squid
7.2 Apache
7.2.1 Pasos previos a la instalacin, manejo y configuracin bsica de
Apache
7.2.2 Instalacin, manejo y configuracin de Apache
7.2.3 Pruebas del servidor Apache

96

CAPITULO VII
Gestin de contenidos en la capa de aplicacin
Antes de la instalacin se realiz una busqueda de informacin acerca de los
servidores Proxy para tener una idea del funcionamiento de los mismos y as realizar una
rplica de su operacin mediante la herramienta de Squid. Lo que se hizo con el montaje de
servidor Proxy es atender y filtrar las peticiones a pginas web por parte de los usuarios
que estarn conectados al punto de acceso. Este manejar objetos almacenndolos en su
cach aumentando la rapidez en la solicitudes de bsquedas generadas por las estaciones
que estn conectadas a travs de l.
C1

C2

Solicitud

Servidor
Proxy

Internet

?
Solicitud

Figura 38. Analoga de un servidor Proxy

7.1 Proxy
7.1.1 Pasos previos a la instalacin y configuracin de squid
El Proxy Squid es un servicio que proporciona una serie de reglas para que
podamos ejecutar las acciones de filtrado y registro encach de una manera controlada.
Squid es el servicio Proxy ms usado en todos los servidores a nivel mundial por su alto
nivel de seguridad. Esta aplicacin es de uso libre, funciona casi sobre cualquier plataforma
y es muy usada para el montaje de servidores proxy-cache y proxy-transparente. Tiene la
97

capacidad de acelerar las bsquedas por medio del manejo de objetos dentro de su ncleo
as como tambin ofrece un sistema de acceso controlado para ciertos protocolos en donde
se encuentran los: TCP, HTTP, FTP, y HTTPS. Posee tambin un sistema para el control de
ancho de banda y servicio DNS incluido.
Su configuracin se hace mediante un slo archivo que abarca todas las funciones
que posee este servidor. Es bastante robusto y ofrece su expansin mediante el uso de
mdulos. Es un sistema multi-hilo ya que responde a solicitudes por varios puerto a la vez.
A medida que se desarrolle la etapa se irn esclareciendo varias caractersticas ms sobre
este servidor.
7.1.2 Instalacin y configuracin bsica de Squid
Para la descarga e instalacin de Squid, hay dos formas en las que se puede
proceder: descargando directamente desde los repositorios con el comando aptitude y
bajando los paquetes desde la pgina oficial http://www.squid-cache.org/. Usando la
segunda forma es necesario compilar el paquete, es decir que se debe construir a mano. El
paquete se instal haciendo la descarga desde los repositorios de esta manera:
root@PAcceso:~# aptitude install squid3

En este proceso se generaron una serie de mensajes que permiten el seguimiento

de la descarga completa del paquete. Los mensajes no sern colocados debido a que el
archivo es bastante extenso. Una vez que se complet el proceso de instalacin los archivos
ms importantes que se generaron son los siguientes:

/etc/squid3/squid.conf

/etc/init.d/squid3

/var/log/squid3/cache.log

/var/log/squid3/access.log

/var/log/squid3/store.log

98

Los tres ltimos archivos corresponden a los registros de mensajes en donde

squid3 escribe constantemente cualquier eventualidad dependiendo de la configuracin que
le haya dado. La configuracin directa se realiz sobre el primer archivo de la lista y se
realiz de la siguiente manera:
1. Funcionalidad de servidor Proxy: Fue necesario plantear la funcionalidad especfica
que cumplira el servidor dentro de la red. El servidor se configurar para actuar
como:

Filtro de contenido en la capa de aplicacin

Proxy de cacheo

Proxy transparente

Estas funciones son designadas a partir de el tipo de red. Como el punto de acceso
wireless estaba disponible para la conexin constante de varios usuarios, fue
necesario el control del contenido de ellos por medio de filtro de las solicitudes web.
Este procedimiento se realiz de forma transparente, es decir, que no se necesit de
la configuracin manual de los navegadores de cada estacin que entrara al punto
wireless. Debido a que exista un slo canal de comunicacin con un ancho de
banda limitado, se implemento el uso delcach de los objetos para acelerar el
proceso de bsqueda y no generar peticiones innecesarias.
2. Configuracin de parmetros de red bsicos: Dentro del archivo squid.conf se
editaron las lneas correspondientes a los parmetros de acceso de redes
determinadas, de la siguiente forma:
Terminal
#Recommended minimum configuration:
acl local src 0.0.0.0/0
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
# Example rule allowing access from your local networks.

a)
99

# Adapt to list your (internal) IP networks from where browsing

# should be allowed
#acl localnet src 10.0.0.0/8
# RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
#acl localnet src 192.168.0.0/16
# RFC1918 possible internal
#network
acl SSL_ports port 443
acl Safe_ports port 80
# http
acl Safe_ports port 21
# ftp
acl Safe_ports port 443
# https
acl Safe_ports port 70
# gopher
acl Safe_ports port 210
# wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280
# http-mgmt
acl Safe_ports port 488
# gss-http
acl Safe_ports port 591
# filemaker
acl Safe_ports port 777
# multiling http
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports
#
# We strongly recommend the following be uncommented to protect
innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP
networks
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
http_access allow local
# And finally deny all other access to this proxy
http_access allow all

b)
Figura 39. a y b. Lneas de parmetros de red del squid.conf
Antes de dar la explicacin de este archivo es necesario conocer los siguientes
trminos con los que squid trabaja. El parmetro acl designa un nombre para el
archivo de acceso, src indica las direcciones de origen que pueden entrar al proxy,
dst indica las direcciones de destino que pueden pasar por el proxy, http_access
100

autoriza o desautoriza una lista o nombre de acceso mediante los conectores allow y
deny; y finalmente el conector port designa puertos tcp que puedan o no acceder al
proxy. A partir de esta aclaracin procedemos a la explicacin de archivo: la primera
lnea sombreada en magenta, fue agregada y no estaba por defecto en el archivo
original. Esta lnea agrega al proxy todas las redes posibles que puedan haber, con el
fin de que ninguna direccin se quede sin pasar por el proxy. En otro tipo de
configuracin, las direcciones se puede limitar nicamente a la red que nosotros
queramos montar, pero para nuestros efectos se necesit que todas las redes de
origen de una peticin pasaran por el proxy y fuesen filtradas. En las dos ltimas
lneas sombreadas se agrega al proxy las direcciones locales de loopback para que
paquetes que tengan como origen o destino estas direcciones, puedan pasar o no por
el proxy. El conjunto de listas sombreadas en azul celeste designa un nombre
genrico para los puertos, que se le aceptar o se le negar, el acceso de flujo http
por medio del proxy. Las ltimas lneas sombreadas en azul-celeste no fueron
modificadas debido a que para nuestro caso no era necesario la eliminacin de estas
porque no se necesit volver a filtrar el contenido de la capa de red.
La segunda parte del archivo es la que permite o no, el acceso a las listas designadas
en la primera parte. Por defecto estas lneas ya estaban configuradas tal y como se
ve en el ejemplo del archivo, no fue necesaria su modificacin por razones de que
las listas especificadas ah, cumplan con los parmetros de diseo que se
nombraron al principio de la etapa. Las dos lneas finales fueron agregadas para
terminar la configuracin completa de los parmetros de red. Aqu, las listas de
local y todas las dems posibles son aceptadas para que puedan pasar por el proxy y
ser verificadas.
Otra lnea de mucha importancia dentro del archivo de configuracin squid es la
siguiente:
http_port 3128 transparent

Por este puerto es que squid atiende las solicitudes http. El parametro transparent se
101

le agreg para que el proxy pueda actuar de forma transparente, al momento de que
las solicitudes le lleguen provenientes de los desvos del firewall. Como squid es
una aplicacin multi-hilo8, se pueden designar otros puertos por los cuales se
recibirn solicitudes.
Estos son parmetros bsicos que permitieron que squid pudiera atender cualquier
peticin hecha por una estacin de la red que estuviera conectado al proxy.
7.1.3 Configuracin de las listas de acceso de Squid
Con las mismas instrucciones que se usaron para la configuracin bsica del
proxy , se crearon listas de acceso para el filtrado de su contenido. Tales listas de acceso son
archivos que se crearon dentro del directorio /etc/squid3/, y que contienen direcciones urls
de pginas a las que se le desea aplicar un control. Estas listas son:

listablanca: donde se alojara a los host: google.com, yahoo.com, msn.com,

hotmail.com, gmail.com,

listanegra: donde se encontraran los host: facebook.com, myspace.com, flickr.com,

hi5.com, badoo.com, metroflog.com

listaprohibida: donde se alojaran trminos de pginas de sexo y pornografa

Las listas se crearon mediante el uso del comando touch y luego se editaron con la

herramienta vi. Una vez que las listas fueron hechas junto con su contenido se procedi a la
escritura de las listas de acceso mediante la edicin del archivo squid.conf donde se
agregaron estas lineas:

8 Multi-hilo: Programa que divide su carga de ejecucin en varias unidades. Para mas informacin consulte
el sitio: http://es.wikipedia.org/wiki/Multihilo.

102

Terminal
acl listablanca dstdomain /etc/squid/listablanca
acl listanegra dstdomain /etc/squid/listanegra
acl listaprohibida dst_regex /etc/squid/listaprohibida
http_access allow listablanca
http_access deny listanegra
http_access deny listaprohibida

Figura 40. Listas de acceso agregadas

En la primera lnea mediante del uso del conector dstdomain, se especific que la
lista de acceso contendra direcciones de dominios de destino, es decir, que cuando se citara
tal direccin, en nuestro caso, deberamos aceptar las conexiones a tales dominios ya que
por medio de http_acces se le concede el permiso (allow). La segunda lnea agregada es
similar a la primera, pero contiene distintos dominios a los cuales ms abajo se les neg el
acceso. En la tercera lnea mediante dst_regex, se leen trminos relacionados con las
pginas a las cuales en la lnea final se les niega el acceso.
De esta forma se pueden configurar mltiples listas para distintas funciones,
dependiendo del uso primordial que requiera la red a determinados recursos. Para efectos
de prueba estas listas quedaron as por un tiempo. Luego fueron sustituidas por una base de
datos bastante amplia que permita la restriccin de pginas de forma ms adecuada y
eficiente.
7.1.4 Configuracin de los logs de Squid
Por defecto, la escritura sobre las listas cache.log y store.log de squid est
deshabilitada. La cache.log es en donde se escriben mensajes de alerta sobre el movimiento
de los objetos sobre lacach y la carga de listas en caso de que exista alguna, la access.log
es donde se llevan los registros de los accesos y rechazos del contenido de las listas
especificadas, y por ltimo el store.log es en donde se escribe la informacin acerca de los
objetos almacenados. En el squid.conf, se habilitan o deshabilitan las opciones para la
escritura de estos registros, adems de poder configurar lo que queremos que se escriba
sobre ellos. La configuracin se llev a cabo de la siguiente manera:
103

1. Ubicacin y habilitacin del cache.log y store.log: Las opciones estaban ubicadas

en la opciones de cache_log y cache_store_log visualizadas en la siguiente figura:

# TAG:
#
#
data
#

Terminal

cache_log
Cache logging file. This is where general information about
your cache's behavior goes. You can increase the amount of
logged to this file with the "debug_options" tag below.

#Default:
# cache_log /var/log/squid3/cache.log
# TAG: cache_store_log
#
Logs the activities of the storage manager. Shows which
#
objects are ejected from the cache, and which objects are
#
saved and for how long. To disable, enter "none". There are
#
not really utilities to analyze this data, so you can safely
#
disable it.
#
#Default:
# cache_store_log /var/log/squid3/store.log

Figura 41. Squid.conf: opcin cache_log y store_log

El parmetro cache_log determina en qu ubicacin se encuentra el archivo donde
se harn los registros de cacheo y el de cache_store_log cumple la misma funcin.
Al momento de la modificacin de esta parte del squid.conf, las lneas que habilitan
la escritura de logs estn comentadas, por lo que se procedi a borrar este carcter y
disponer de la escritura sobre ellos.
2. Formatos de escritura de logs en squid: una vez que se habilitaron la escritura en los
logs de squid, se procedi luego a la definicin del formato de escritura sobre ellos
siguiendo estas caractersticas:
logformat squid %ts.%03tu %6tr %>a %Ss/%03Hs %<st %rm %ru %un %Sh/
%<A %mt

Esta lnea esta contenida el archivo de configuracin de squid en la seccin de

104

logformat (formatos para los log) y se tradujo de la siguiente manera:

el tiempo de inicio ser de 3 milisegundos (%03tu)

el tiempo de respuesta ser de 6 milisegundos (%6tr)

se mostrar la direccin de origen del cliente usuario (%>a)

se mostrar los estados de las solicitudes (%Ss)

mostrar el cdigo de estado http (%03Hs)

tamao de las solicitudes http y sus cabeceras (%<st)

cualquier mtodo de solicitud (%rm)

la URL solicitada (%ru)

el nombre del usuario (%un)

jerarqua (%Sh)

nombre completo del dominio (%<A)

que contenido mime se est gestionando (si existe) (%mt)

Este formato de log fue el que se utiliz para la escritura de los mensajes, debido a
que mostraba una serie de avisos, como el origen del cliente, estados de solicitudes,
URL de la solicitud, nombre del solicitante y otros; que permitan monitorizar las
conexiones, en caso de fallas de navegacin en el servidor.
7.1.5 Configuracin del manejo de objetos en lacach de Squid
Esta configuracin se realiz, con el fin de acelerar de forma efectiva las
bsquedas en la red, as como la disminucin del consumo del canal debido a las peticiones
sin necesidad. Para el manejo de objetos basta con saber qu contenidos manejara la red al
momento de una sesin. La configuracin del manejo de objetos se basa en la
administracin de la retencin en la memoriacach de los elementos consultados
dependiendo de su tamao. La configuracin que fue establecida es la siguiente:

105

Terminal
# MEMORY CACHE OPTIONS
# TAG: cache_mem
(bytes)
#Default:
cache_mem 128 MB
# TAG: maximum_object_size_in_memory
#Default:
maximum_object_size_in_memory 100 KB

(bytes)

# TAG: memory_replacement_policy
#Default:
memory_replacement_policy heap GDFS
# DISK CACHE OPTIONS
# TAG: cache_replacement_policy
#Default:
cache_replacement_policy heap LFUDA
# TAG: cache_dir
#Default:
cache_dir ufs /var/spool/squid3 100 16 256
# TAG: minimum_object_size
#Default:
minimum_object_size 8 KB

(bytes)

# TAG: maximum_object_size
(bytes)
#Default:
maximum_object_size 4096 KB
# TAG: cache_swap_low (percent, 0-100)
# TAG: cache_swap_high (percent, 0-100)
#Default:
cache_swap_low 90
cache_swap_high 95

Figura 42. Lneas de configuracin para el manejo de objetos

Tag: cache_mem. Aqu se configur la mxima capacidad que ocupar lacach en

la memoria RAM. Se especific una capacidad mxima de 128M debido a que el
servidor est dotado de una cantidad mayor de memoria

Tag: maximum_object_size_in_memory. Aqu se configur la capacidad mxima

de un objeto sobre la memoria. Se especific una cantidad mxima de 100K para as
no saturar, de forma inmediata, la capacidad mxima de memoria.

Tag: memory_replacement_policy. En este campo se especific la poltica para el

remplazo de los objetos en memoria. Las polticas son tres: lru correspondiente a los
106

objetos recientemente usados, heap GDFS correspondiente a la retencin de los

objetos de menor tamao, desechando los grandes, y heap LUFDA correspondiente
a la retencin de los objetos de gran tamao en la memoria. La poltica que se
escogi fue la de al retencin de los objetos de menor tamao en la memoria,
logrando as optimizar la rapidez de la misma, a pesar de su pequeo espacio.

Tag: cache_replacement_policy. En este campo se especific la poltica de

reemplazo en el disco cache. La que se eligi fue la poltica de almacenamiento de
los objetos grandes debido a que el espacio de memoria esta vez es mucho ms
amplio, por ser el disco duro quien cede el lugar.

Tag: cache_dir. Aqu se especific el formato de los objetos a guardar y la ruta raz

Tag: minimum_object_size. En este campo se configur el tamao de los objetos,

ms pequeos a retener en el disco el cual fue de 8K, suficiente para no tener tantos
objetos pequeos.

Tag: maximum_object_size. En ste se configur el tamao mximo de los objetos

a retener en el disco. El tamao es cogido fue el de 4M debido a la capacidad del
disco.

TAG: cache_swap_low (percent, 0-100). aqu se configur el rendimiento mximo

de la cache.

TAG: cache_swap_high (percent, 0-100). aqu se especific el rendimiento

mximo de la memoria cache.
De esta forma se optimiz la rapidez de respuestas para las peticiones http y se

comprob mediante una encuesta informal en usuarios que usaron el servidor proxy para
navegar.
7.1.6 Instalacin y configuracin del mdulo para Squid: SquidGuard
El mdulo squidGuard, permite el filtrado de contenidos web a partir del uso de
bases de datos que contienen una gran mayora de pginas del mundo entero. Para la
descarga e instalacin de este mdulo se us el gestor de descargas en consola aptitude.
107

Bajo el siguiente comando se descarg e instal automticamente el mdulo completo:

aptitude install squidGuard. Los archivos ms importantes que se crearon durante la
instalacin del mdulo fueron: /etc/squid/squidGuarg y /var/lib/squidguard/db/.
Antes de la configuracin del archivo /etc/squid/squidGuarg.conf, fue necesario
descargar las listas que contienen las bases de datos correspondientes a los dominios que se
requieran bloquear o ceder el acceso. La base de datos est disponible en la pgina oficial
de squidGuard http://www.squidguard.org/blacklists.html, donde se encuentran 4 links ms
de donde se pueden descargar distintas bases de datos. Los paquetes que se descargaron
fueron los de la Universidad de Tolouse, Shallas Blacklist y URLBlacklist. Completada la
descarga se procede a la descompresin de los archivos con el comando tar xvzf sobre la
ubicacin /var/lib/squidguard/db/:
root@PAcceso:/var/lib/squidguard/db/# tar xvzf blacklist.tgz
Ubicacin

Comando

Paquete

Culminada la descompresin de los 3 paquetes descargados, procedemos a

verificar la lista de bases de datos que se gener.

Figura 43. Lista de bases de datos

108

A partir de estas listas se tomaron en cuenta las que eran de vital necesidad para el
filtrado de contenido de los host conectados al proxy. Estas bases de datos contiene un
grupo grande de dominios alojados sobre todo el territorio mundial. Los dominios son
proporcionados por robots o programas de bsqueda avanzados. La mayora de estas listas
son constantemente actualizadas debido a que los web servers estn al tanto de que sus
sitios caen dentro de una lista negra y por ende cambian muy a menudo de dominio. Las
bases de datos que se tomaron en cuenta al momento de realizar el control de acceso,
fueron las que de alguna forma u otra podan perjudicar el funcionamiento de la red.
En la configuracin del archivo squidGuard.conf se consideraron ciertos factores
que permiten el manejo del archivo sin cabida a errores. En este archivo existe una seccin
en donde se declaran las listas de acceso a trabajar y luego de esta, hay un campo en donde
se realiza la parte de control de acceso.
Terminal
# CONFIG FILE FOR SQUIDGUARD
dbhome /var/lib/squidguard/db/blacklists
logdir /var/log/squid/squidGuard.log
# DESTINATION CLASSES:
dest hacking {
domainlist
hacking/domains
urllist
hacking/urls
}
dest malware {
domainlist
malware/domains
expressionlist malware/expressions
urllist
malware/urls
}
dest onlinegames {
domainlist
onlinegames/domains
urllist
onlinegames/urls
}
dest porn {
domainlist
porn/domains
urllist
porn/urls
expressionlist porn/expressions
}
dest socialnetworking {
domainlist
socialnetworking/domains
urllist
socialnetworking/urls
dest spyware {
domainlist
spyware/domains
urllist
spyware/urls
}

a)
109

dest adult {
domainlist
adult/domains
urllist
adult/urls
}
dest virusinfected {
domainlist
virusinfected/domains
urllist
virusinfected/urls
}
dest warez {
domainlist
warez/domains
urllist
warez/urls
}
dest blog {
domainlist
blog/domains
urllist
blog/urls
}
dest artnudes {
domainlist
artnudes/domains
urllist
artnudes/urls
}
acl {
default {
pass
!hacking !malware !onlinegames !porn !
socialnetworking !spyware !adult !virusinfected !warez !blog !
artnudes all
redirect http://accipoint.net
}
}

b)

Figura 44. a y b. Archivo squidGuard.conf

Todas las listas especificadas luego de DESTINATION CLASSES son las que se
seleccionaron para hacer el filtro. En el campo dest se especifica la lista que ser cargada y
en los siguientes campos domainlist y urllist, designa cuales listas correspondern a
dominios y cuales a URLs. En la ultima parte del archivo acl se conceden los permisos a las
listas seleccionadas anteriormente por medio de la opcin pass. En esta lnea se colocaron
las listas y se les dio acceso a cualquier otra menos a las comentadas por (!).
Luego de este paso se procedi a la conexin del servidor de squid3 con el mdulo
de squidGuard agregando la siguiente lnea dentro del archivo de configuracin:
redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

Para cargar las listas e iniciar el squidGuard, basta con reiniciar el servidor de
110

squid o manualmente por medio del comando squidGuard -d.

7.1.7 Pruebas al servidor Squid
La primera prueba que se realiz para corroborar el funcionamiento de squid, se
realiz por medio de la observacin de los procesos dentro del sistema. Para poder
visualizar estos procesos fue necesario el uso del comando top de Linux, que genera una
lista activa en donde se observa ciertas particularidades de los mismos. Al iniciar el
servidor proxy tambin se inicia el mdulo que se le fue aadido. Los procesos que se
activan al momento de cargar las listas de acceso de squidGuard son seis y a veces existen
otro ms dependiendo de la cantidad de listas. Una vez que se han cargado todas estas listas
los procesos desaparecen. A continuacin se puede visualizar el inicio del servidor
mediante la observacin de los procesos:

Figura 45. Visualizacin de los procesos de Squid

Evidentemente con esta prueba no se comprob el total funcionamiento del
servidor. La segunda prueba ms real de que el sistema proxy squid estaba en
111

funcionamiento fue hecha a travs de la configuracin manual del navegador en uno de los
computadores de la pequea red que se haba montado. El navegador debe estar
configurado para que las peticiones web sean atendidas por el proxy. En las opciones o
preferencias de los navegadores generalmente existe un campo donde se puede especificar
la direccin del servidor proxy as como su puerto de conexin. El servidor squid viene
configurado por defecto para escuchar mediante el puerto 3128, por lo que en el navegador
debe especificarse que ste es el puerto por donde se enlazar con el servidor. Un ejemplo
de la configuracin del navegador se puede observar en breve:

Figura 44. Configuracin del navegador para uso de proxy

112

Una vez que se termin la configuracin del navegador para el uso de un proxy
local, se guardan los cambios y se procede al ingreso de una URL que est restringida para
comprobar que el servidor est haciendo su tarea. La direccin que se tom de prueba fue la
de youtube.com. Esta pgina es una pgina en donde se pueden ver vdeos que aaden
comnmente los usuario. Como este dominio fue restringido por el proxy, segn la lista de
acceso, la pgina no mostrara ningn contenido y se visualizara el siguiente mensaje de
error:

Figura 45. Mensaje de error que genera el squid

113

De esta manera se comprob que la configuracin del servidor squid fue efectiva y
ser la utilizada para el montaje final de toda la red.
7.2 Apache
7.2.1 Pasos previos a la instalacin, manejo y configuracin bsica de Apache
Durante el desarrollo del punto de acceso fue necesario el montaje de un servidor
web de bajas prestaciones, que servira como punto de redireccin a peticiones negadas por
el servidor proxy. Por esta razn se realiz un estudio acerca de los servidores web. Un
servidor web no es ms que una estacin dedicada, usada nicamente para el manejo
constante de hipertexto sobre la red. A partir de diversas configuraciones y esquemas de
diseos planteados en HTML (Lenguaje de Marcado de Hipertexto), un servidor web puede
proveer varias aplicaciones adaptadas a las necesidades de los clientes. La comunicacin
entre dos nodos donde una es un cliente y otro un servidor, se realiza en base lo que se
denomina protocolo de la transferencia de hipertexto, donde ambas, tienen un enlace
constante intercambindose cdigos HTML. Bsicamente un servidor web contiene toda
una serie de servicios y aplicaciones a base de HTML, los cuales pueden ser consultado por
nodos de redes exteriores si cuentan con la autorizacin requerida.
Luego de esto, se recaud informacin sobre el servidor web Apache, con el fin de
la familiarizacin y posterior desempeo de sus funciones bsicas. Los aspectos ms
resaltantes de esta investigacin estn resumidos en los siguientes puntos:

Apache es un software de uso totalmente libre, diseado para casi todas las
plataformas operativas

Trabaja sobre el protocolo HTTP/1.1

Posee la capacidad de trabajar con webs fijas y dinmicas

No cuenta con una interfaz grfica para su gestin

Posee la capacidad de trabajar con diversos mdulos

114

Contiene 10 archivos importantes de configuracin: apache2.conf, envvars, magic,

mods-enabled, sites-available, conf.d, httpd.conf, mods-available, ports.conf y
sites-enabled

Y funciones de autenticacin y gestin de contenidos

Basados en esta investigacin se procedi a la instalacin, manejo y configuracin

del servidor Apache2.

7.2.2 Instalacin, manejo y configuracin del servidor Apache
La instalacin de este servidor fue muy sencilla debido a que el gestor de descarga
aptitude se encarg de bajar y por ende instalar la aplicacin. La orden completa usada
para la descarga del paquete fue la siguiente: aptitude install apache2, este comando inici
la descarga e instalacin de la aplicacin, y adems, cre los siguientes archivos en donde
se realiza la mayor parte de la configuracin: /etc/apache2 y /var/www/.
Luego de este paso se procedi al la configuracin del servidor tomando en cuenta
las siguientes caractersticas: puerto de escucha del del servidor sera el 80, la direccin ip
correspondera con la del servidor principal 172.16.1.153, el nombre del host virtual sera
accipoint.net, slo contendra un archivo html y sera de total acceso por las mquinas de la
red local. El primer archivo que se edit fue el de /etc/apache2/ports.conf, donde se edit el
puerto por defecto de escucha de peticiones y el nombre del virtualhost:
NameVirtualHost accipoint.net:80
Listen 80

El puerto de escucha puede ser cualquiera que se requiera al igual que el nombre
del host. Para nuestros efectos no era necesario el cambio de este puerto debido a que las
peticiones al puerto 80 serian redirigidas a squid y una vez aprobadas por este, regresaran
aqu en tal caso de que la peticin involucre el virtualhost.
Siguiente a este paso se procedi a la edicin del archivo /etc/apache2/sites115

aviables/default. Este archivo contiene la configuracin de los accesos a cada una de las
secciones o directorios que tengan relacin con el virtualhost. Por medio del uso de las
directivas es posible aplicar cierto control de acceso para determinados recursos que estn
en el virtualhost. Como slo fue necesario el uso de un virtualhost sencillo de redireccin,
el archivo por default se dejo tal y como estaba excepto por las siguientes lneas donde se
especifica que nuestro servidor ser el que responda las llamadas para la URL:
http://accipoint.net/ .
<VirtualHost 172.16.1.153:80>
ServerAdmin dfourier@gmail.com
ServerName accipoint.net

En el la directiva <VirtualHost>, se especific la direccin asociada al host virtual

que se configuraba, que en ese caso fue la del servidor principal 172.16.1.153. En el
parmetro ServerAdmin se especific la cuenta de correo del administrador, y la lnea
sombreada en rojo se agreg luego debido a que en esta se especifica a qu nombre est
asociado el virtualhost. Una vez editado este archivo, se guard y se procedi al reinicio del
servidor por medio del comando apache2ctl restart. Antes de realizar la prueba se debe
aclarar que el servidor debe estar alojado en un dominio para que la resolucin de su
nombre sea efectiva. Como anteriormente ya se haba configurado un servidor DNS en el
cual tenamos registrado nuestro dominio accipoint.net, no se requiri modificar ms nada.
7.2.3 Prueba del servidor Apache
La prueba que se realiz fue bastante sencilla, nicamente se requiri realizar una
bsqueda en el navegador del virtualhost: accipoint.net, la cual arroj el cdigo html
presente en el archivo index.html ubicado en nuestro directorio raz designado en la
configuracin: /var/www.
Con la culminacin de la configuracin y prueba de los servidores Squid y Apache,
116

se pudo establecer en un sistema un filtro de contenidos y manejo de objetos en lacach del

sistema, que permitir que el servidor responda de forma rpida y efectiva, a las peticiones
que realicen los usuarios de distinto de contenido web. Adems, se pudo dar un grado de
seguridad ante posibles ataques realizados desde internet, mediante al bloqueo de pginas
que posiblemente puedan afectar las mquinas que estn conectadas en ese momento.

117

CAPITULO VIII:
Configuracin del Hardware para el punto de
acceso
8.1 mdulo Hostapd
8.1.1 Pasos previos a la instalacin y configuracin
8.1.2 Instalacin y configuracin del mdulo hostapd
6.1.3 Pruebas de la tarjeta D-LINK DWL-500

118

CAPITULO VIII
Configuracin del hardware para el punto de
8.1 Mdulo Hostapd
8.1.1 Pasos previos a la instalacin y configuracin
Muchas de las tarjetas inalmbricas son configuradas de forma automtica por el
sistema para actuar como clientes de un servicio WAP (para este caso: Wireless Access
Point), mas no se configuran de esta forma cuando tienen que actuar como el servidor
WAP, debido a que la mayora de estas tarjetas no soportan este funcionamiento. De
acuerdo con el driver de configuracin para modo Hostap (Punto de acceso), existan
muchos ms tipos de configuracin complejos y completos para funciones especficas, pero
en esta ocasin se establecieron parmetros bsicos los cuales nos permitieron desarrollar
el proyecto.
En la IEEE 802.11 se reflejan todos los aspectos concernientes a la transmisin de
datos en una red, tomando como medio el espectro radioelctrico (ver captulo II. IEEE
802.11). Es por esta sencilla razn que se investig acerca de esta norma, ya que el proyecto
est basado en la implementacin de un punto de acceso proveedor de Internet al cual los
usuarios accedan de forma inalmbrica. Lo ms destacado de esta norma es que designa
caractersticas puntuales para las dos ltimas capas del modelo OSI, la capa fsica y la capa
de enlace, en donde se sita lo relacionado con la forma y medio de transmisin de los
datos (ver anexo 1. Modelo OSI). La banda de transmisin, forma de modulacin, mtodo
de acceso al medio, medios fsicos, mecanismos de encriptacin, mecanismos de
autenticacion y velocidades maximas de transmisin de los datos, son especificados en esta
normativa.
En base a estas aclaraciones fue necesario saber cuales eran las caractersticas
fsicas soportadas por la tarjeta para su implementacin. Por lo general el sistema de Linux
ofrece soporte para casi todos los dispositivos de red que estn en el mercado. Existe un
una leve falla en esto, cuando se trata de dispositivos de mucha antigedad, o muy nuevos,
119

pero eventualmente siempre se consiguen los controladores adecuados. Para poder realizar
la gestin de un controlador cualquiera, es necesario saber qu caractersticas posee el
dispositivo a configurar. A causa de esto se requiri la bsqueda de las caractersticas de la
tarjeta D-Link DWL-500, encontrando los siguientes datos tcnicos:

Tarjeta Pcmcia con adaptador PCI

Velocidad mxima de transmisin 11 Mbps

Chipset Prims 2.5

Alcance en sitios cerrados 115-328 pies y para sitios abiertos de 328 a 984 pies de
radio

Tipo de encriptado: slo WEP

Banda de transmisin 2.4 Ghz

Tipos de funcionamiento Managed, Ad hoc y AP

Figura 46. Tarjeta D-Link DWL-500

8.1.2 Instalacin y configuracin del mdulo hostapd
El mdulo hostapd es un gestor de tarjetas inalmbricas que configura sus

120

parmetros fsicos, dependiendo del uso y finalidad que se le vaya a dar. Este mdulo
provee de soporte para chispset de la familia Prims 2.x, y permite habilitar el modo Master
en las tarjetas con el chip Prims 2.5. La instalacin de este mdulo se realiz por medio del
gestor de descargas en consola aptitude, con la orden install y el parmetro correspondiente
al nombre del controlador hostapd. Bajo consola escribimos: aptitude install hostapd, de lo
que resulta la descarga e instalacin completa del mdulo.
Terminada la descarga, los archivos ms importantes que se instalaron fueron los
siguientes: /etc/hostapd/hostapd.conf , /etc/default/hostapd y /etc/init.d/hostapd, siendo el
primero de ellos donde se realizar la configuracin fsica de la tarjeta inalmbrica. Para la
configuracin de la tarjeta se procedi de la siguiente forma:
1. Modificacin de los parmetros fsicos de la tarjeta: tal modificacin se hizo
editando las opciones contenidas en el archivo de configuracin principal para
lograr que la tarjeta acte como el proveedor de servicio que se requiere, es decir,
que esta sea el servidor que administra toda la red. Tambin se podr fijar cules
son los parmetros para la transferencia de los datos como: banda de frecuencia en
la que se realizar la transferencia, modo de trabajo segn la IEE 802.11,

administracin del trfico de datos multimedia mediante el manejo de ventanas (ver

captulo II, Protocolo TCP: control de lujo de datos). A continuacin las lneas que
se editaron:

interface=eth0. En esta lnea se estableci la interfaz a usar que al momento de la

conexin, el sistema la etiqueta como una interfaz de ethernet, pero luego de que se
ejecuta el archivo de configuracin y se reinicia la mquina la tarjeta pasa a ser
etiquetada como wlan0. Una vez etiquetada de esta forma, se requiere hacer el
cambio del nombre.

driver=hostap . Aqu se design qu controlador gestionara la tarjeta, que para sus

efecto corresponde a el hostap.

ssid=AccPoint. Aqu se design el nombre de identificacin del punto.

hw_mode=b. Determina la norma de trabajo del punto en este caso la IEEE 802.11b
121

de acuerdo con las caractersticas de nuestra tarjeta.

channel=3. Designa el canal de transmisin El canal 3 corresponde con la

frecuencia de 2,4 Ghz

basic_rates=10 20 55 110. Proporciona una cantidad de bit rates por defecto de

acuerdo con la capacidad de la tarjeta, que para este caso es de 110. Esta lnea est
comentada en el archivo original, por lo que se descoment para su activacin

WMM Wireless Multimedia. Estas opciones configuran la prioridad en el trfico

para los contenidos de audio y vdeo; garantizando de cierto modo la calidad de
servicio (QoS). Los parmetros se configuraron segn las notas que se van dejando
referente a las cantidades indicadas para IEEE 802.11b:
#----------------------------WMM---------------------------------#
wme_enabled=1
#
# Low priority / AC_BK = background
wme_ac_bk_cwmin=5
wme_ac_bk_cwmax=10
wme_ac_bk_aifs=7
wme_ac_bk_txop_limit=0
wme_ac_bk_acm=0
# Note: for IEEE 802.11b mode: cWmin=5 cWmax=10
#
# Normal priority / AC_BE = best roquefort
wme_ac_be_aifs=3
wme_ac_be_cwmin=5
wme_ac_be_cwmax=7
wme_ac_be_txop_limit=0
wme_ac_be_acm=0
# Note: for IEEE 802.11b mode: cWmin=5 cWmax=7
#

122

# High priority / AC_VI = vdeo

wme_ac_vi_aifs=2
wme_ac_vi_cwmin=4
wme_ac_vi_cwmax=5
wme_ac_vi_txop_limit=188
wme_ac_vi_acm=0
# Note: for IEEE 802.11b mode: cWmin=4 cWmax=5 txop_limit=188
#
# Highest priority / AC_VO = voice
wme_ac_vo_aifs=2
wme_ac_vo_cwmin=3
wme_ac_vo_cwmax=4
wme_ac_vo_txop_limit=47
wme_ac_vo_acm=0
# Note: for IEEE 802.11b mode: cWmin=3 cWmax=4 burst=102
#----------------------------WMM---------------------------------#

wep_default_key=1. En este campo se habilit para el uso de claves de cifrado tipo

WEP que es el nico modo soportado por la tarjeta. Adems de esto en el campo
tambin se especifica la forma en que se interpretarn los caracteres con los que se
escriba la clave. En ste, la forma es la nmero uno e indica que los caracteres que
se escribirn son de tipo ASCII.

wep_key1="Aprueba123456". En este campo se design la clave WEP a usar para

la entrada al punto de acceso, tomando en cuenta que es de tipo 1 y adems debe
contener como cantidad de caracteres las siguientes cifras: 10, 26 o 32.

eap_server=0 . Aqu se designa el servidor de autenticacion que se desee usar. En

nuestro caso ninguno.

own_ip_addr=10.0.0.3. En este campo se especific el ip de nuestro punto de

acceso en concordancia con lo establecido en los parmetros de la tarjeta de red.
Debe tomarse en cuenta que la mayora de estas opciones estaban comentadas y
123

desactivadas al momento de la edicin del archivo. Simplemente se descomentaron y

configurado conforme a lo establecido por las caractersticas del equipo.
8.1.3 Pruebas de la tarjeta inalmbrica D-Link
Una vez terminada la tarea de configuracin de las caractersticas fsicas de la
tarjeta por medio del mdulo hostapd, se continu con la carga de los parmetros escritos
por medio del reinicio del mdulo en cuestin. El reinicio se realiz por medio del archivo
presente en /etc/init.d/hostapd con el parmetro restart. Cuando se culmin el proceso de
reinicio del mdulo sin error alguno, en la tarjeta se pas el comando iwconfig wlan0 mode
master para que pudiese iniciar la transmisin de los datos a las dems estaciones.
En este punto se inici un visor de eventos sobre la tarjeta que permite identificar
las

estaciones

que

entren

al

punto.

Por

medio

del

comando

hostapd

-d

/etc/hostapd/hostapd.conf se visualiz la lista de avisos emanados del mdulo hostapd,

correspondiente con transmisiones presentes en ese instante en el dispositivo. La primera
prueba del acceso al punto se observa en la siguiente figura:

Figura 47. Ejecucin del comando hostapd -d /etc/hostap/hostapd.conf

124

En la figura anterior se visualiza como

se activa cada caracterstica que se

especific en el archivo que configuramos. Cuando una estacin intenta conectarse al

punto, los primeros paquetes de datos que se intercambian corresponde a las claves
implcitas para el acceso al medio :

Figura 48. a y b. Conexin entrante

El mdulo realiza una verificacin de las estaciones que hacen solicitudes de
conexin al punto. Cuando las solicitudes de conexin son terminadas de verificar en
conjunto con su clave encriptada WEP que ha sido establecida con anterioridad, wla0
procede a dar acceso a las estaciones que cumplan con todos los lineamientos. Esto se hace
para que otros usuarios extraos no puedan acceder a nuestro servidor. Con esta
125

configuracin se logr dar calidad de servicio en la transferencia de datos multimedia y

adems se pudo encriptar dicha informacin para que no pueda ser daada de ninguna
forma.

126

CAPITULO IX:
Integracin Final del los Componentes del
Punto de Acceso Inalmbrico
9.1 Esquema funcional del servidor central
9.2 Integracin de los servicios

127

CAPITULO IX
Integracin Final de los Componentes del Punto de Acceso Inalmbrico
A continuacin se realizar la integracin de los servidores mostrando como
trabaja cada uno de los servicios mediante un esquema y su posterior explicacin.
9.1 Esquema funcional del punto de acceso
El esquema funcional final es el siguiente:

Servidor Proxy
Squid3

Resolucin
de nombres

Virtualhost:
accipoint.net
Ip: 172.16.1.153

SquidGuard
Redireccin

Servidor Web
Apache

Servidor
DHCP

Firewall
Iptables

Base de Datos

Firewall
Iptables

Wlan0 : hostapd

Servidor DNS
Bind9

Tarjeta Wireless y Ethernet

Eth0

Solicitudes HTTP
Solicitudes Negadas HTTP
Solicitudes respondidas HTTP
Solicitudes y respuestas DHCP

LAN

Otras conexiones

Figura 49. Esquema funcional del servidor

128

INTERNET

9.2 Integracin de los servicios

A continuacin se presentaran los servicios que se montaron en el servidor central:

Firewall-Iptables: Por aqu pasarn y se filtrarn todas las conexiones que se hagan
o se pretendan hacer, tanto por parte de la LAN como por parte las redes de Internet.
El Firewall definitivo contiene las siguientes caractersticas: permite slo las
conexiones seguras http, nuevas y establecidas por parte del cliente, no existe
comunicacin por puertos de gestin remota ni hacia la LAN ni hacia internet, se
permiten los mensajes de correccin de errores (ver anexo 5. Cdigo Final del
Firewall).

Servidor DHCP: nicamente da las direcciones para las mquinas que se

conectarn de forma inalmbrica al punto de acceso. La configuracin de este
servidor qued especificada en el captulo VI. Distribucin Lgica de la Red y
Registro del Dominio Principal

Servidor Proxy Squid+SquidGuard: Este servidor qued configurado de acuerdo

con las mismas caractersticas que se plantearon en la estepa de desarrollo, las
cuales fueron: aceleracin de los parmetros de bsqueda mediante el manejo de
objetos sobre mayor memoria RAM y la memoria fsica cache, el control a bajo
nivel del ancho de banda mediante el bloqueo de ciertas pginas de contenidos
pesados y filtro de contenido web por medio del uso del SquidGuard empleando las
listas de acceso de su base de datos (ver captulo VII, Gestin de Contenido en la
Capa de Aplicacin).

Servidor DNS Bind9: El servidor qued configurado con un slo dominio en sus
archivos, que sera el que le proporcionaramos al sistema para las consultas de
resolucin de nombres (ver captulo VI, Registro del Dominio Principal).

Servidor Web Apache: Se le aadi a este servidor dos nuevos elementos en su

pgina de inicio /var/www/accipoint/index.html, donde el primero es una reescritura
del cdigo html, en el cual se hace referencia a una imagen, que es el segundo
elemento que se aadido.
129

CONCLUSION
A lo largo del desarrollo del proyecto se pudo notar que muchos de los servicios
instalados en el punto de acceso, son usados por otras plataformas de software dedicado a
servidores, lo que indica que tales paquetes son de gran calidad para el desenvolvimiento de
cualquier servidor que se desee implementar. Squid, Iptables, BIND y Apache contienen
una gran variedad de reglas que permiten su uso, bien sea de forma bsica o usando
esquemas de configuracin avanzada. En el caso de BIND y Squid, son servicios que le
brindan a cualquier red una mejora significativa en la transferencia de datos entre ella y la
red de internet, por su capacidad de almacenar contenidos web y gestionar el ancho de
banda utilizando reglas de control de flujo. Adems de esto si combinamos el trabajo a su
mximo desempeo de los paquetes Squid e Iptables podemos establecer un sistema de
seguridad de altas prestaciones, que pueda ser implementado sobre redes donde la
integridad de los datos sea prioritaria.
En la transferencia de paquetes por medio del espectro radioelctrico tambin se
deben tomar las previsiones en seguridad para la proteccin de la data, por causa de que la
misma se transmite por este medio, y prcticamente, es asequible para todo el mundo si no
se protege de manera efectiva. El mtodo de proteccin de datos usado en este proyecto fue
el WEP, que ya es bastante viejo y es muy fcil de violar, por lo que se recomienda usar
mtodos ms nuevos y de mayor nivel de seguridad como el WAP o WAP2. Se utiliz este
mtodo debido a que el dispositivo inalmbrico slo soporta este tipo de encriptacin, los
dispositivos inalmbricos de ahora ya pueden trabajar con nuevos mtodos de encriptacion
y se pueden configurar usando el mismo software que se uso en este proyecto.
Son muchos los problemas de seguridad que las redes de hoy presentan, poniendo
en riesgo la integridad de muchas empresas y personas. Es por esto que constantemente se
debe investigar acerca de nuevos programas que erradiquen tales fallas, para as no
perjudicar nuestros sistemas y los de los dems. Los conocimientos que me quedan de todo
este proyecto son muy provechosos en mi formacin profesional y adems sern tomados
como puntos de partida para el desarrollo de nuevos sistemas que puedan mejorar
significativamente los que se han establecido actualmente. Realmente me cost bastante la
130

comprensin de todos estos procesos implcitos en la informtica, debido a que es mucha la

informacin que se consigue en torno a esto. La clave de para la rpida comprensin de
todas estas teoras y su posterior implementacin, se basa en el entendimiento y dominio
de los de procesos lgicos secuenciales. Toda esta informacin es esencial para el pleno
desenvolvimiento dentro de este mundo de las redes que cada da crece ms.

131

REFERENCIAS BIBLIOGRAFICAS

SUAREZ,

I.

2006.

Redes

de

informtica.

http://www.monografias.com/trabajos40/redes-informaticas/redes-informaticas.shtml.
BUETTRICH, S. y ESCUDERO, A. Octubre 2006. Trilacar: Materiales de
Capacitacin Tcnica. http://www.wilac.net/index_pdf.html.
RICARDO,

G.

Marzo

2010.

Redes

Wireless

con

Linux.

http://bulma.net/body.phtml?nIdNoticia=1309
STINGA

RUIZ,

M.

Curso

de

Iptables.

Enero

2010.

http://yoshitinux.files.wordpress.com/2009/01/curso-de-iptables1.pdf
PELLO,

X.

Marzo

2010

Iptables:

Manual

Practico.

de

Netfilter.

http://www.pello.info/filez/firewall/iptables.html
VALERA,

R.

Febrero

2010.

Curso

Avansado

Linux:

http://www.usc.es/estaticos/atic/sistemas/cursolinux/avanzado_2a_ed/firewalls.pdf
NEGREIRA.

J.

Febrero

2010.

Iptablesdesde

Cero.

http://www.fentlinux.com/listing/manuales/iptables.pdf
ROBLES, D. Enero 2009. Implementacin de una Central Telefnica Privada
(PBX) con Tecnologa de Voz sobre Ip Usando Herramientas de Software Libre.

132