redes de informacion - trabajo final- lucero_vega

Lunes 13 de Agosto del 2012

ALUMNOS: Lucero, Fernando Ariel Vega, Daniel Maximiliano

TRABAJO

FINAL DE

REDES DE

INFORMACIÓN

INTERNET SERVICE PROVIDER

Universidad Nacional de Río Cuarto

1

TRABAJO FINAL REDES DE INFORMACIÓN

INDICE

CAPÍTULO 1: Reseñas Generales

1.1 Introducción ...................................................................................................... 3

1.2 Objetivo deltrabajo…......................................................................................... 4

1.3 Generalidades.................................................................................................... 4

1.4 Marco General................................................................................................... 4

1.5 Visión del Cliente............................................................................................... 5

1.6 Visión del Proveedor.......................................................................................... 5

CAPÍTULO 2: Internet Service Provider (ISP)

2.1 Estructura de un ISP.......................................................................................... 8

2.2 Esquema de Conexión....................................................................................... 9

2.3 Hardware Y Software utilizados...................................................................... 10

2.4 Servidores del ISP............................................................................................ 11

2.4.1 Remote Authentication Dial In User Service (RADIUS)………….......................... 11

2.4.2 Proxy Squid 3 transparente…………................................................................... 16

2.4.3 Squid Analysis Report Generator (SARG)………….............................................. 18

2.4.4 Domain Name Systen (DNS)............................................................................ 19

2.4.5 PPPoE Cliente, PPPoE Servidor (Mikrotik)....................................................... 20

2.4.6 No-IP Server…................................................................................................... 22

2.4.7 Secure Sockets Layer (SSL)...................................................................…………. 23

CAPÍTULO 3: Configuraciones

3.1 CONFIGURACION A.D.S.L ………………………………………………………………………………. 24

3.2 ROUTER MIKROTIK............................................................................................ 28


2

3.3 UBUNTU 12.04 LTS............................................................................................. 40

3.3.1 Configuración DNS…............................................................................. 40

3.3.2 Configuración RADIUS........................................................................... 41

3.4 WEBMIN............................................................................................................. 49

3.5 DaloRADIUS………………………………………………………………………………………………….. 58

Conclusión………………………………………………………………………………………………………….. 61

Anexo Wireshark..………………………………………………………………………………………………. 62

Capturas DNS…………….………………………………………………………………………………………. 63

Capturas Conexiones..……………………………………………………………………………………….. 64


3

CAPÍTULO 1

RESEÑAS GENERALES

1.1 INTRODUCCIÓN

Reseña Histórica

A mediados de la década de los ‘70, la Agencia de Proyectos de Investigación

Avanzada de Defensa de Estados Unidos (DARPA) se interesó en establecer una red

de conmutación de paquetes para proveer comunicaciones robustas entre las

instituciones de investigación civiles y militares. DARPA y otras organizaciones

gubernamentales entendieron el potencial de la tecnología de conmutación de

paquetes y estaban comenzando a enfrentar el problema de la comunicación

transparente entre sistemas de computación disímiles.

Con el objetivo de la conectividad heterogénea en mente, DARPA, consolidando las

investigaciones de la Universidad de Stanford y Bolt, Beranek and Newman (BBN),

desarrolló una serie de protocolos de comunicación. El resultado de este esfuerzo,

completado a fines de 1970, fue la familia de protocolos Internet, de los cuales el

Protocolo de Control de Transmisión (TCP) y el Protocolo Internet (IP) son los dos

más conocidos.

Durante los años 80, las tecnologías Internet y las redes fueron adoptadas por otras

agencias gubernamentales y otros países, de modo de potenciar el sector de

negocios privados y las organizaciones gubernamentales, educacionales, etc. Hoy,

las tecnologías de Internet e Intranet han encontrado aceptación masiva y son

usadas por cientos de miles de organizaciones alrededor del mundo. La organización

internacional global para la coordinación de Internet es la Sociedad Internet (ISOC).

Los primeros ISP inicialmente no estaban conectados entre sí debido a que el mayor

requerimiento de tráfico fue hacia el extranjero; esto implicaba que a menudo las

conexiones nacionales eran mucho más lentas que las internacionales. Con el pasar


4

del tiempo, el crecimiento del contenido y los servicios de información nacionales

motivaron a que los ISP interconectaran sus redes, lo que disminuyó en forma

significativa los tiempos de retardo y espera de las comunicaciones. Luego empresas

de otros rubros distintos al de las telecomunicaciones (por ejemplo empresas

comerciales o empresas de servicios informáticos), habilitaron pequeños ISP en sus

oficinas, que fueron conectados a los ISP principales, de modo que sus empleados

pudieran aprovechar las oportunidades que abre Internet, conectándose con

mayores velocidades, y aumentando la gama de servicios ofrecidos y utilizados. Así

las empresas (tanto medianas y como grandes empresas) pudieron acceder a

servicios tales como E-MAIL, WWW, FTP, noticias USENET, telnet, etc.,

administrando su información en forma local, lo que disminuye la dependencia de

estas empresas a sus proveedores Internet.

1.2 OBJETIVO DEL TRABAJO

El presente trabajo tiene como objetivo realizar la implementación de un Proveedor

de Servicios de Internet (ISP), utilizando diferentes herramientas adquiridas en la

catedra de Redes de Información, para ello utilizaremos diferentes hardware y

software de Mikrotik para su implementación. Brindando servicios para poder

controlar y administrar a los usuarios de nuestra red.

1.3 GENERALIDADES

En este trabajo pretendemos realizar una empresa que provee a sus clientes

servicios de internet y otros servicios relacionados con la web.

1.4 MARCO GENERAL

La actual convergencia que existe entre los “Sistemas de Comunicaciones” y las

“Redes de Computadores” ha permitido el surgimiento de Internet y sus servicios

desde los más fundamentales (WWW, E-mail, FTP) hasta algunos más sofisticados

tales como voz sobre IP (VoIP), mensajería multimedia unificada y otros.

Además han aparecido nuevas oportunidades de negocios. Entre la que se destaca

el surgimiento de empresas orientadas a dar conectividad a otras compañías a

Internet y a proveer los servicios de Internet. Este concepto se materializa en los ISP.


5

1.5 VISIÓN DEL CLIENTE

Los ISP deben brindar dos puntos importantes.

1. Ofrecer conectividad a Internet: Permitir acceso a Internet, para utilizar los

servicios que nos ofrecen

2. Servicios de Internet: Establecida la conexión, el ISP debe ser capaz de

mantenerla, de esta manera el cliente tendrá acceso a cualquier servicio, donde

los mas usados son los de WWW y el e-mail, Correo Electrónico, entre otros

de los servicios principales que debe tener es el FTP, Protocolo de

Transferencia de Archivos.

Los clientes de un ISP se pueden conectar desde su hogar, oficina, o lugares de

acceso público. Para esto deben de disponer del software necesario, que incluyen

un conjunto de aplicaciones para establecer y mantener la conexión.

Los softwares de conexión, en combinación con los navegadores Web o browser

permiten a los usuarios el acceso a Internet, y a sus servicios. Los navegadores

implementan HTML (Web), NNTP (Noticias), FTP (transferencia de archivos) y

MTP/POP3 (correo).

1.6 VISIÓN DEL PROVEEDOR

Es el proveedor quien se encarga de entregar la conectividad a sus clientes. No

existe una gran diferencia entre un ISP y cualquier computadora que esté en

Internet. La única funcionalidad que marca la diferencia, es que el ISP es capaz de

permitir la conexión de otras computadoras a través de él, misión que podría asumir

cualquier host que posea conexión a Internet. Esta “capacidad especial” se debe a

que el ISP, posee los permisos necesarios para interactuar con otros elementos de la

red, tales como módems, routers o switches, que son los dispositivos que permiten

el acceso a los clientes.

Los ISP ofrecen servicios de Internet, que son implementados en un grupo de

servidores, los que forman la red interna de ISP.


6

Para facilitar el análisis, el problema se subdivide en varios aspectos:

Diseño de la red interna del ISP.

Canal de conexión hacia Internet.

Canales de acceso hacia sus clientes.

Planificación de los servicios prestados.

Mecanismos de seguridad.

Los principales objetivos de un ISP son:

Siempre debe mantener la conectividad entre Internet y sus clientes.

Mantener siempre disponible los servicios básicos de un ISP.

Los elementos básicos para un ISP son:

Canal de acceso Cliente – ISP.

Canal de acceso ISP – Internet.

Servicios básicos (resolución de nombres).

Seguridades de acceso a los servicios

Para el caso en que se quieran mayores prestaciones o entregar una mejor calidad

de servicio, entra en juego el diseño de la red interna del ISP y la planificación de los

servicios que se ofrecerán a los usuarios.

En el análisis de estudio de un ISP debe considerarse lo siguiente:

Cuál es el número de clientes conmutados y dedicados.

Cuál es el ancho de banda asignado a los clientes.

Cuáles servicios se prestarán en forma local desde la red interna, y

cuáles desde Internet.

Cual es la estimación absoluta y porcentual de tráfico local y externo.

Qué tiempo promedio, y mínimo entre fallos se espera.


7

Cual será el tiempo de recuperación de en fallos.

Qué alternativas de redundancia se utilizarán, etc.

Qué nivel de tolerancia a fallas se desea para el Sitio.

Para la planificación de servicios se debe considerar desde la población los

requerimientos planteados por los clientes, hasta el nivel de servicios que ofrece la

competencia. Es importante destacar que en el corazón de los servicios se encuentra

el de resolución de nombres (DNS), pues permite la traducción de nombres a

direcciones IP y la traducción reversa, funcionalidad vital en el ambiente Internet y

es un servicio que no puede faltar en un ISP.


8

CAPÍTULO 2

Internet Service Provider (ISP)

2.1 ESTRUCTURA DE UN ISP

La estructura y los servicios básicos de un ISP lo podemos visualizar en la

siguiente figura

Firewall

Router

Proxi

Web

News

IRC

Mail

FTP

DNS

SERVICIOS

DISTRIBUCION

Administración

de Base de

Datos

Zona de

Administración

Back End

Consola

Zona de

Servicios

Front End

Nucleo

CSU/DSU

T1 / T3

Hacia el

Proveedor

RAS

La estructura de un ISP esta formado por dos zonas importantes:

Administración

Servicios.


9

La zona dedicada a los servicios es la más frágil desde el punto de vista de la

seguridad, puesto que está expuesta a todos los usuarios de Internet que quieran

acceder o utilizar un servicio determinado, comúnmente esta área se conoce como

la zona desmilitarizada (DMZ). En cambio, la zona de administración debe ser la más

protegida, de modo no recibir ataques de hackers.

En efecto, las estaciones que están en la zona de administración están facultadas a

ingresar al resto de la plataforma ISP, de modo que si alguien puede tomar el

control de las máquinas de administración, puede controlar el ISP completo.

2.2 ESQUEMA DE CONEXIÓN

INTERNET

Router

CACHE PROXI

Firewall

RAS

E1

MAIL / FTP APLICACIONES WEB SERVER

RADIUS

SWITCH

CARRIER

PBX

TELEFONIA PUBLICA

COMPUTADOR

Modem

CLIENTES

POTENCIALES


10

2.3 HARDWARE Y SOFTWARE UTILIZADOS

Definidos la arquitectura y los servicios a prestar estos son los hardwares y

softwares utilizados para realizar el trabajo:

Router Mikrotik R750

PC con Ubuntu

Otros software para configuración y pruebas:

◦ Winbox

◦ Wireshark

Winbox es un utilitario que permite la administración de Mikrotik

RouterOS empleando una sencilla interfaz gráfica (GUI). A pesar de su

origen en Win32, funciona en Linux y MAC OS mediante Wine. Algunas

configuraciones avanzadas no son posibles desde Winbox, como los

cambios de dirección de interfaz en MAC.

Wireshark, antes conocido como Ethereal, es un analizador de

protocolos utilizado para realizar análisis y solucionar problemas en

redes de comunicaciones, para desarrollo de software y protocolos, y

como una herramienta didáctica para educación. Cuenta con todas las

características estándar de un analizador de protocolos. Permite examinar

datos de una red viva o de un archivo de captura salvado en disco. Se

puede analizar la información capturada, a través de los detalles y

sumarios por cada paquete. Wireshark incluye un completo lenguaje para

filtrar lo que queremos ver y la habilidad de mostrar el flujo reconstruido

de una sesión de TCP.

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

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

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

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


11

2.4 SERVIDORES DEL ISP

Dentro de los servidores de nuestro ISP se encuentran los siguientes elementos.

2.4.1 Remote Authentication Dial in User Service (RADIUS)

RADIUS es un protocolo ampliamente usado en el ambiente de redes, para dispositivos tales como routers, servidores y switches entre otros. Es utilizado para proveer autenticación centralizada, autorización y manejo de cuentas para redes de acceso dial-up, redes privadas virtuales (VPN) y, recientemente, para redes de acceso inalámbrico. Originalmente desarrollado por Livingston Enterprises y publicado en 1997, como los RFC 2058 Y 2059.

Puntos importantes:

- Los sistemas embebidos generalmente no pueden manejar un gran número de usuarios con información diferente de autenticación. Requiere una gran cantidad de almacenamiento.

- RADIUS facilita una administración centralizada de usuarios. Si se maneja una

enorme cantidad de usuarios, continuamente cientos de ellos son agregados o eliminados a lo largo del día y la información de autenticación cambia continuamente. En este sentido, la administración centralizada de usuarios es un requerimiento operacional.

- Debido a que las plataformas en las cuales RADIUS es implementado son

frecuentemente sistemas embebidos, hay oportunidades limitadas para soportar protocolos adicionales. Algún cambio al protocolo RADIUS deberá ser compatible con clientes y servidores RADIUS pre-existentes.

Un cliente RADIUS envía credenciales de usuario e información de parámetros de conexión en forma de un mensaje RADIUS al servidor. Éste autentica y autoriza la solicitud del cliente y envía de regreso un mensaje de respuesta. Los clientes RADIUS también envían mensajes de cuentas a servidores RADIUS. Los mensajes RADIUS son enviados como mensajes UDP (User Datagram Protocol). El puerto UDP 1812 es usado para mensaje de autenticación RADIUS y, el puerto UDP 1813, es usado para mensajes de cuentas RADIUS. Algunos servidores usan el puerto UDP 1645 para mensajes de autenticación y, el puerto 1646, para mensajes


12

de cuentas. Esto último debido a que son los puertos que se usaron inicialmente para este tipo de servicio. Formato de Paquetes Los datos entre el cliente y el servidor son intercambiados en paquetes RADIUS. Cada paquete contiene la siguiente información:

Formato de Paquete RADIUS

Los campos en un paquete RADIUS son:

- Code (Código). Un octeto que contiene el tipo de paquete.

Valor Descripción 1 Access-Request

2 Access-Accept

3 Access-Reject 4 Accounting-Request

5 Accounting-Response 11 Access-Challenge

12 Status-Server (experimental)

13 Status-Client (experimental) 255 Reserved

- Identifier (Identificador). Un octeto que permite al cliente RADIUS relacionar

una respuesta RADIUS con la solicitud adecuada. - Length. Longitud del paquete (2 octetos). - Authenticator (Verificador). Valor usado para autenticar la respuesta del

servidor RADIUS. Es usado en el algoritmo de encubrimiento de contraseña.


13

- Attributes (Atributos). Aquí son almacenados un número arbitrario de atributos. Los únicos atributos obligatorios son el User-Name (usuario) y el User-Password (contraseña).

Tipos de mensajes RADIUS definidos por los RFC 2865 y 2866: Access-Request. Enviado por un cliente RADIUS para solicitar autenticación y autorización para conectarse a la red. Debe contener el usuario y contraseña (ya sea de usuario o CHAP); además del puerto NAS, si es necesario. Access-Accept. Enviado por un servidor RADIUS en respuesta a un mensaje de Access-Request. Informa que la conexión está autenticada y autorizada y le envía la información de configuración para comenzar a usar el servicio. Access-Reject. Enviado por un servidor RADIUS en respuesta a un mensaje de Access-Request. Este mensaje informa al cliente RADIUS que el intento de conexión ha sido rechazado. Un servidor RADIUS envía este mensaje ya sea porque las credenciales no son auténticas o por que el intento de conexión no está autorizado. Access-Challenge. Envío de un servidor RADIUS en respuesta a un mensaje de Access-Request. Este mensaje es un desafío para el cliente RADIUS. Si este tipo de paquete es soportado, el servidor pide al cliente que vuelva a enviar un paquete Access-Request para hacer la autenticación. En caso de que no sea soportado, se toma como un Access-Reject. Accounting-Request. Enviado por un cliente RADIUS para especificar información de cuenta para una conexión que fue aceptada. Accounting-Response. Enviado por un servidor RADIUS en respuesta a un mensaje de Accounting-Request. Este mensaje reconoce el procesamiento y recepción exitosa de un mensaje de Accouting-Response.


14

Diagrama de Secuencia El siguiente diagrama muestra la secuencia seguida cuando un cliente accede a la red y se desconecta de la misma.

1. El cliente envía su usuario/contraseña, esta información es encriptada con una

llave secreta y enviada en un Access-Request al servidor RADIUS (Fase de Autenticación).

2. Cuando la relación usuario/contraseña es correcta, entonces el servidor envía un

mensaje de aceptación, Access-Accept, con información extra (Por ejemplo: dirección IP, máscara de red, tiempo de sesión permitido, etc.) (Fase de Autorización).

3. El cliente ahora envía un mensaje de Accounting-Request (Start) con la

información correspondiente a su cuenta y para indicar que el usuario está reconocido dentro de la red (Fase de Accounting).

4. El servidor RADIUS responde con un mensaje Accounting-Response, cuando la

información de la cuenta es almacenada.


15

5. Cuando el usuario ha sido identificado, éste puede acceder a los servicios proporcionados. Finalmente, cuando desee desconectarse, enviará un mensaje de Accounting-Request (Stop) con la siguiente información:

o Delay Time. Tiempo que el cliente lleva tratando de enviar el mensaje. o Input Octets. Número de octetos recibido por el usuario. o Output Octets. Número de octetos enviados por el usuario. o Session Time. Número de segundos que el usuario ha estado conectado. o Input Packets. Cantidad de paquetes recibidos por el usuario. o Output Packets. Cantidad de paquetes enviados por el usuario. o Reason. Razón por la que el usuario se desconecta de la red.

6. El servidor RADIUS responde con un mensaje de Accounting-Response cuando la información de cuenta es almacenada.

La siguiente figura presenta una vista simple de la topología de red asumida al establecer una conexión RADIUS autenticada con un router.


16

Implementación Para la implementación del servidor RADIUS, utilizamos las siguientes herramientas de hardware y software: Una PC con Linux que funcionará como servidor RADIUS (en nuestro caso,

Ubuntu). Un Access Point. PCs con tarjetas de red utilizadas como clientes.

FreeRADIUS como servidor.

MySQL para el almacenamiento de datos de usuarios.

2.4.2 Proxy Squid 3 transparente ¿Qué es un Proxy HTTP y Cómo me puede servir?

En el contexto de servidores y servicios de Internet, un proxy es un programa que

realiza las tareas de petición y conexión a un servicio remoto, cuando un cliente

realiza una petición a un servicio de Internet a través de un proxy, el cliente en

realidad no se conecta directamente al servidor destino, en su lugar, el servidor

proxy recibe la petición y es él quien realiza la petición y conexión con el servidor

destino solicitado, un servidor proxy actúa como intermediario entre el cliente y el

servidor destino.

Entonces, un proxy HTTP ó más conocidos como proxies web es un programa que

sirve para dar acceso a servicios y recursos remotos a través del protocolo HTTP, la

mayoría de proxies HTTP tienen las capacidades de controlar el acceso a los recursos

usando diferentes criterios de acceso, registrar los accesos de los clientes para

cuestiones de administración de recursos y/o auditoría y algunos otros tienen las

capacidades de almacenar en un cache local los objetos estáticos para así ahorrar

ancho de banda y dar un mayor servicio a los clientes.

Un proxy HTTP también puede ser usado en modo interceptor o proxy transparente,

en dicho caso y a través de reglas de firewall o enrutamiento avanzado es posible

interceptar de forma transparente todo el tráfico hacía el internet con destino el

puerto 80 y re dirigido hacía un proxy HTTP local o remoto.


17

Las características principales de un Proxy HTTP son:

Controlar el acceso a sitios y contenidos Web.

Cachea el contenido estático Web solicitado.

Registra las peticiones web realizadas por los clientes.

Los beneficios que obtenemos de los controles de accesos a sitios y contenidos web

son:

Políticas de acceso y filtrado de contenido.

Mejoras en la productividad de la organización.

Asegura la red local al no permitir acceso a contenido inseguro.

Aproximadamente un 20% del contenido descargado de Internet vía HTTP es

cacheable y por lo tanto con el cache de contenido podemos obtener beneficios

como:

Almacenamiento local de los objetos estáticos más descargados.

Los usuarios tienen la percepción de que el acceso a Internet es más rápido.

Ahorro de ancho de banda que puede ser dedicado a otros servicios.

Mediante el registro de las peticiones realizadas por los clientes es posible obtener

los siguientes beneficios:

Se puede saber quien entra a que sitios y en que momento.

Generar reportes para conocer el uso de los servicios de Internet.

Útil para crear reglas y políticas de uso de servicios web.

Los proxies HTTP tienen muchos más beneficios, sin embargo dependen de la

tecnología usada y la implementación a usar, en las siguientes secciones veremos las

características principales del proxy cache Squid, una implementación robusta de un

proxy HTTP con capacidades de cache basado en software libre.


18

2.4.3 Squid Analysis Report Generator (SARG)

En esta sección veremos como usar la herramienta SARG (Squid Analisis Report

Generator) para la generación de reportes para el análisis de los accesos al proxy

Squids, con SARG vamos a poder generar reportes sobre demanda y también

generar reportes automáticos por día, semana y mes.

Introducción a SARG

SARG es una herramienta de análisis de logs de Squid, tiene soporte para generar

reportes en diferentes idiomas, mediante los reportes de uso web podremos

obtener la siguiente información:

Top Ten de sitios más visitados

Reportes diarios, semanales y mensuales

Gráficas semanales y mensuales del consumo por usuario/host

Detalles de todos los sitios a los que entro un usuario/host

Descargas

SARG será configurado para generar reportes web de los accesos a Internet de

forma periódica, además de poder ejecutarlo manualmente para generar reportes

de fechas, usuarios o dominios en específico.

Reporte Manual:

Estos reportes son aquellos creados por el administrador del sistema y

ejecutados manualmente, pueden ser personalizados en base a diferentes

criterios, son almacenados en el directorio /var/www/squid-reports/Manual,

cada reporte bajo su propio directorio.

Reporte Diario:

Estos reportes son generados automáticamente por un trabajo de CRON

diario a un determinado horario y genera un reporte del día anterior, son

almacenados en el directorio /var/www/squid-reports/Diario, cada reporte

bajo su propio directorio.


19

Reporte Semanal:

Estos reportes son generados automáticamente por un trabajo de CRON cada

semana a un determinado horario y genera un reporte del día anterior, son

almacenados en el directorio /var/www/squid-reports/Semanal, cada reporte

bajo su propio directorio.

Reporte Mensual

Estos reportes son generados automáticamente por un trabajo de CRON cada

mes a un determinado horario y genera un reporte del día anterior. Estos

reportes son almacenados en el directorio /var/www/squid-reports/Mensual,

cada reporte bajo su propio directorio.

2.4.4 Domain Name System (DNS)

El servicio DNS, se utiliza para traducir un nombre de dominio en direcciones IP. DNS

permite ya una vez configurado que tu sitio WEB y Correo sean localizados desde

cualquier parte de la WWW. Los DNS se utilizan para distintos propósitos:

Resolución de nombres.

Resolución inversa de direcciones.

Resolución de servidores de correo.

Existen varios tipos de servidores de DNS como Bind, PowerDNS, djbdns y todos

trabajan sobre el puerto 53 protocolo TCP/UDP.

Tipos de DNS

Existen 4 tipos de servidores DNS:

Maestro: Nuestro servidor se comportara como un autentico servidor DNS, ya

que atenderá las peticiones de resolución de nombres. Así mismo responde a

consultas de otros servidores DNS.

Esclavo: Este tipo de servidor solamente sirve como espejo de un servidor

DNS Maestro, cuando el servidor DNS Maestro tiene alguna modificación, se

vera reflejado en servidor DNS esclavo ya que están sincronizados.

Cache: Este tipo de servidor se utilizan dentro de una red local, cuando hace


20

una consulta a un servidor DNS Cache y no contiene la resolución envía una

petición a un DNS Maestro y la resolución quedara guardada en la cache del

DNS local hasta que expire el tiempo de vida.

Reenvío: Reenvía las peticiones a una lista especifica de servidores DNS para

la resolución de nombres.

Instalación

Instalamos el paquete dnsmasq de los repositorios oficiales de Ubuntu.

El paquete dnsmasq permite poner en marcha un servidor DNS de una forma muy

sencilla. Simplemente instalando y arrancando el servicio dnsmasq, sin realizar

ningún tipo de configuración adicional, nuestro PC se convertirá en un servidor

caché DNS y además, resolverá los nombres que tengamos configurados en el

archivo /etc/hosts de nuestro servidor. La resolución funcionará tanto en sentido

directo como en sentido inverso, es decir, resolverá la IP dado un nombre de PC y el

nombre del PC dada la IP. Adicionalmente, dnsmasq dispone de servidor DHCP y

permite resolver los nombres de los PCs a los que les ha asignado dirección IP

dinámica. A lo largo de esta sección veremos todas estas posibilidades que nos

ofrece dnsmasq.

2.4.5 PPPoE Cliente, Servidor (Mikrotik)

Configurar MikroTik en modo PPPoE-Client para Router modo Bridge

Muchos ISP utilizan el protocolo PPPoE (Ethernet) ó PPPoA (ATM) para

autenticarnos y/o encriptar nuestras conexiones hacia sus servidores para así poder

darnos acceso a un internet "seguro".

El problema viene a que estos ISP's nos venden/ceden/alquilan/regalan routers

ADSL de gama MUY baja, con muy poca capacidad de conexiones y sesiones NAT,

inclusive algunos tienden a colgarse o a dejar de aceptar nuevas conexiones cuando

son ligeramente exigidos, y esto sin contar con los bugs que algunos tienen con su

firewall integrado y en sus opciones NAT.

Nuestro MikroTik será el único que maneje estas conexiones, dejando

prácticamente "inutizado" al router que nos dió el ISP, y así poder manejar

plenamente nuestra conexión a internet sin los problemas que estos routers nos

http://www.guia-ubuntu.org/index.php?title=Añadir_aplicaciones


21

podrían dar.

A groso modo, un routerADSL ó modem/router cuenta con:

Modem ADSL (Interfaz ADSL)

Router (encargado del NAT, conexiones, firewall, etc)

Switch

Access Point

Todo integrado en un sólo equipo, del cual por configuración, sólo dejaremos

activado el modem ADSL y el switch. El trabajo de Router lo hará únicamente

nuestro MikroTik.

Montaremos un servidor PPPoE en RouterOS de MikroTik para controlar las

conexiones de nuestros clientes. Este protocolo es el más común y extendido

conjuntamente con PPP, donde el primero trabaja sobre ethernet y el segundo con

modems.

Con este protocolo daremos de alta usuarios/contraseñas y asignaremos sus anchos

de banda e incluso si recibirá una dirección estática o dinámica.

También es posible usar con PPPoE las opciones de encriptación, métodos de

autenticación y RADIUS. Esto supone un valor añadido ya que ofrece la posibilidad

de gestionar todos los clientes de forma centralizada e integrada con ERPs

A nivel de hardware el fabricante informa de los siguientes datos a tener en cuenta:

Un servidor PPPoE requiere memoria RAM adicional, 9 KB por conexión (10

KB si se usa QoS) y una CPU potente. El número máximo de conexiones

permitidas son 65535.

Para mayor información sobre este protocolo en RouterOS funciona a nivel 2, hace

uso de broadcast para que el cliente pueda contactar con el servidor.


22

A continuación se muestra un diagrama del entorno

2.4.6 No-IP Server

Una complicación que existe para que se establezca comunicación entre nuestro

proveedor de internet (Arnet o Fibertel) y los clientes de nuestro ISP, es que nuestro

ISP debe conocer la IP de nuestro proveedor, actualmente los proveedores de

internet entregan IP publicas dinámicas, es decir que nuestra IP publica va

cambiando, para ello implementamos No-IP, el cual se encarga de averiguar el IP

que se nos ha entregado y la transforma en un nombre estático del tipo

nombre.isp.org por ejemplo.

Configuración de Cuenta No-IP

1. Creamos una cuenta en la pagina no_ip.com.

2. Instalamos No-IP en Ubuntu (Adonde se aloja nuestro servidor)

$ sudo apt-get install no-ip

3. Escribimos la siguiente linea:

$ sudo no-ip –C


23

Nos preguntará por el e-mail y el password con que nos inscribimos en no-

ip.com

4. Debemos recordar que debemos tener abiertos los puertos en nuestro

firewall desde donde “salen” los servicios, para No-IP es 8245 TCP.

2.4.7 SSL (Secret Sockets Layer) en un servidor Web

Es un conjunto de tecnologías criptográficas que proporcionan autenticación,

confidencialidad e integridad de los datos. SSL suele utilizarse entre los

exploradores Web y los servidores Web para crear un canal de comunicación

seguro. También se puede utilizar entre las aplicaciones cliente y los servicios

Web.


24

CAPÍTULO 3

CONFIGURACIONES

3.1 CONFIGURACION ADSL

En este paso configuramos nuestro ISP con nuestro proveedor de servicios de

internet, es nuestro caso dicho proveedor es Arnet. Para ello debemos configurar

nuestro modem ADSL de la siguiente manera.

Ingresamos por el browser de nuestro navegador de internet (IE, Firefox,

Chrome, etc.) poniedo la siguiente línea

http://10.0.0.2

Configuramos de la siguiente manera nuestro modem ADSL

http://10.0.0.2/


25

Tildamos la configuración de PPPoE que se muestra en la siguiente figura


26

Aparecerá la siguiente configuración

La configuraremos en modo Pure Bridge para establecer un puente entre el

Mikrotik y nuestro modem de Arnet.


27

Finalmente guardamos nuestra configuración


28

3.1 CONFIGURACION ROUTER MIKROTIK

El router utilizado para nuestro trabajo es un MikroTik RB750.

Nuestro proveedor de internet asigna una IP a partir de un Servidor PPPoE al

MikroTik.

1) Descargamos la aplicación winbox.exe y la ejecutamos con la aplicación Wine,

ya que este ejecuta archivos .exe de Windows en Linux.

Pulsamos botón 1 encontramos nuestro Mikrotik


29

Usuario: admin

Password: vacio

Luego pulsamos botón Connect

2) Reseteamos para evitar problemas

En el panel lateral Pulsamos el botón New Terminal esto nos abrirá una

consola del MickroTik.

Luego ejecutamos el comando system reset. Se desconectara del MikroTik y

se reseteara.


30

3) Configuramos las Interfaces

En el panel panel lateral botón Interfaces luego doble click en la interface a

configurar.

Interface 1

Name: interface 1

Master Port: none

Interface 2

Name: interface 2

Master Port: none

Interface 3

Name: interface 3

Master Port: none


31

Interface 4

Name: interface 4

Master Port: none

Interface 5 (extensión de la interface 2)

name: interface 5

Master Port: interface 2

4) Asignamos IP a nuestras interfaces

En el panel lateral seleccionamos el botón IP opción Address, luego el boton +

En la interface 2, configuraremos a nuestro administrador

Address: 192.168.10.1/24

Network: 192.168.10.0


32

Interface: Interface 2

En la interface 3, configuraremos nuestros clientes

Address: 192.168.20.1/24

Network: 192.168.20.0


En la interface 1 no la configuraremos ya que trabaja por DHCP.

5) Configuramos cliente PPPOE

Panel lateral botón Interfaces Agregar PPPOE Client.

Name: PPPoE_Cliente



33

Luego en la pestaña Dial Out

Introducimos el usuario y la contraseña provista por nuestro proveedor de

internet.

6) Configuramos el cliente DHCP


34

Panel lateral botón IP opción DHCP Client luego el botón +


Con estos pasos el MikroTik ya está conectado a internet, para verificar esto

vamos a la consola (New Terminal) y hacemos un ping a 8.8.8.8 (dns de

google)

También veremos que en la pestana IP----> Addresses debería figurar la ip

que nos asigno el DHCP.

7) Procedemos a Crear el pool de IP para asignarle a los clientes que se conecten

a la red.

Panel lateral botón IP opción Pool Client luego el botón +

Name: PPPoE-DHCP (cualquier nombre que haga referencia)

Addresses: 192.168.20.2-192.168.20.254

Next pool: none


35

8) Configuradas las interfaces, y loguedo nuestro cliente en el servidor RADIUS,

verificamos las tablas de ruteo.

Panel lateral botón IP opción Routes.


36

9) Firewall

Panel lateral botón IP opción Firewall, seleccionamos la pestaña NAT.

En 1 proveemos de internet a toda la red, generando un Masquerade a la

interface 1.

En 2 redireccionamos todas las peticiones de los clientes con un protocolo

TCP por el puerto 80 al puerto 3128 del administrador (192.168.10.10).


37

10 ) PPP

Panel lateral botón PPP pestaña Interface, nos muestra las interfaces activas del

ISP


38

En la pestaña PPPoE Servers, definimos la interface 4 del MikroTik como interfaz

de nuestros clientes, con el perfil por defecto PPPoE.

En la pestaña Secrets, vinculamos nuestro Mikrotik con el server RADIUS


39

En la pestaña Profiles, vinculamos el perfil PPPoE Servers asignando la interface

4 para nuestros clientes

En la pestaña Active Conections, vemos los usuarios conectados a nuestro ISP


40

11 ) RADIUS

Panel lateral botón Radius, redireccionamos a nuestro administrador, y los

puertos utilizados.

3.3 UBUNTU 12.04 LTS

Nuestro ISP esta montado por cuestiones de comodidad de estudio en una pc, que

cuenta con un sistema operativo UBUNTU 12.04 LTS.

3.3.1 Configuracion del DNS

1) Instalamos el paquete dnsmasq de los repositorios oficiales de Ubuntu.

2) Copiamos /etc/resolv.conf como /etc/resolv.dnsmasq.conf.

$ sudo cp /etc/resolv.conf /etc/resolv.dnsmasq.conf

3) Editamos /etc/resolv.conf:

$ sudo gedit /etc/resolv.conf

Y añadimos la siguiente línea al principio del archivo:

nameserver 127.0.0.1

http://www.guia-ubuntu.org/index.php?title=Añadir_aplicaciones


41

3.3.2 Configuración RADIUS

Instalaremos la siguiente librería:

$sudo apt-get install debhelper libltdl3-dev libpam0g-dev libmysqlclient15-dev build-essential libgdbm-dev libldap2-dev libsasl2-dev libiodbc2-dev libkrb5-dev snmp autotools-dev dpatch libperl-dev libtool dpkg-dev libpq-dev libsnmp-dev libssl-dev

FREERADIUS

Instalamos el paquete FreeRadius con la siguiente línea:

$sudo apt-get install freeradius freeradius-mysql

Editamos el archivo “users” y creamos un usuario (al final del archivo) para hacer las pruebas de funcionamiento del radius:

$sudo gedit /etc/freeradius/users

…

vegalucero Cleartext-Password := “redes1234″

Service-Type = Framed-User,

Framed-Protocol = PPP,

Framed-Compression = Van-Jacobsen-TCP-IP

Ahora vamos a probar que esté funcionando bien el FreRadius habilitándolo en modo debug y luego haciendo la prueba:

$/etc/init.d/freeradius stop

freeradius -X

radtest vegalucero redes1234 127.0.0.1 1812 redes1234

Si todo esta bien, veremos esta información:

Sending Access-Request of id 174 to 127.0.0.1 port 1812


42

User-Name = “Massi”

User-Password = “massi″

NAS-IP-Address = 127.0.1.1

NAS-Port = 1812

rad_recv: Access-Accept packet from host 127.0.0.1 port 1812,, length=38

Service-Type = Framed-User

Framed-Protocol = PPP

Framed-Compression = Van-Jacobson-TCP-IP

En el Wireshark, hay que asegurarse que recibamos el mensaje “Access-Accept”.

MYSQL

Ahora configuraremos FreeRadius para que pueda leer la información desde

MySQL.

Editaremos el archivo /etc/freeradius/radiusd.conf y descomentamos la linea

“$INCLUDE sql.conf”

Ahora, accederemos al MySQL via CLI de la siguiente forma:

mysql -u root -p

Creamos la base de datos

CREATE DATABASE radius;

Creamos un usuario llamado “radius” con permisos totales en la base de datos que creamos:

GRANT ALL ON radius.* TO radius@localhost IDENTIFIED BY

“mypassword”;


43

Donde la Base de datos es llamada “radius”, el usuario a crear es tambien

“radius” y el password “mypassword”

Ahora nos salimos de la base de datos.

exit;

Se creará la estructura de la base de datos con un script que se encuentra en: /usr/share/doc/freeradius/examples/mysql.sql.gz

Se deberá de hacer esto:

gunzip –d /usr/share/doc/freeradius/examples/mysql.sql

mysql -u root –password=xxxx radius < /usr/share/doc/freeradius/examples

/mysql.sql

Donde “xxxx” es la contraseña de acceso a la base de datos por medio del usuario “root”.

Para comprobar lo que hemos hecho, podemos ejecutar las siguientes instrucciones:

mysql -u root -p

use radius;

show tables;

Ahora, salimos del MySQL.

quit;

Editaremos el archivo: /etc/freeradius/sql.conf

$sudo nano /etc/freeradius/sql.conf

Y configurarémos los parámetros respectivos de la conexión de la base de datos y descomentamos una línea:

…


44

# Connection info:

server = “localhost”

login = “radius”

password = “mipassword”

…

readclients = yes

Ahora, editamos el Archivo: /etc/freeradius/sites-available/default y agregamos la variable “sql” en las secciones: authorize{}, accounting{},

session{}, post-auth{}

Esto para traer los datos desde las tablas en la base de datos “radius”

$sudo gedit /etc/freeradius/sites-available/default

authorize {

preprocess

chap

mschap

suffix

eap

sql

pap

}

accounting {

detail


45

sql

}

Finalmente, agregamos un usuario de prueba a la base de datos para comprobar que funciona la autenticación:

mysql -u root –p

use radius;

INSERT INTO radcheck (UserName, Attribute, Value) VALUES (‘usuario’,

‘Password’, ’123′);

select * from radcheck where UserName=’usuario1′;

El resultado mostrará el usuario que hemos creado.

Para comprobar que todo esta funcionando bien, ejecutamos freeradius en modo debug y hacemos la prueba:

freeradius -X

radtest usuario 123 127.0.0.1 1812 testing123

radtest usuario 123 127.0.0.1 1812 testing123

Sending Access-Request of id 215 to 127.0.0.1 port 1812

User-Name = “usuario”

User-Password = “123″

NAS-IP-Address = 127.0.1.1

NAS-Port = 1812

rad_recv: Access-Accept packet from host 127.0.0.1 port 1812,, length=20

Ahora instalarémos la interfaz de administración DaloRadius. Primero debemos bajar la versión mas reciente de este paquete y descomprimirlo porque generalmente


46

viene comprimido.

cd /tmp

wget http://softlayer.dl.sourceforge.net/project/daloradius/daloradius/daloradius-0.9-8/daloradius-0.9-8.tar.gz

tar xvzf daloradius-0.9-8.tar.gz

Ahora, copiamos esta carpeta en el directorio de publicación del servidor web.

cp daloradius-0.9-8 /etc/freeradius/daloradius –R

Ahora instalamos algunas otras librerías así:

$sudo apt-get install php5 php5-mysql php-pear php5-gd php-DB

Cambiamos al usuario propietario y grupo por defecto del directorio de daloradius.

$sudo chown www-data:www-data /etc/freeradius/daloradius/ -R

Y ahora cambiamos los permisos también:

$sudo chmod 644 /etc/freeradius/daloradius/library/daloradius.conf.php

Para que Daloradius funcione correctamente, se requiere agregar algunas tablas mas a la base de datos de MySQL. Estas tablas ya estan incluidas en el directorio de DaloRadius, por lo que solo es necesario ejecutar el siguiente comando:

mysql -u root -p radius < /etc/freeradius/daloradius/contrib/db/fr2-mysql-daloradius-and-freeradius.sql

Si no hay errores, todas las tablas debieron de haber sido creadas en la base de datos. Para poder gestionar la base de datos, recomiendo usar PHPMyAdmin, el cual se puede instalar con el siguiente comando:

$sudo apt-get install phpmyadmin

Cuando ya esté instalado se puede acceder mediante la dirección:

http://localhost/phpmyadmin


49

Ahora solo nos queda reiniciar el servicio de Radius:

/etc/init.d/freeradius restart

Y acceder a la interfaz Web del Daloradius: http://localhost/daloradius

El usuario sería: Administrador

Y el Password: radius

Es recomendado borrar el usuario “liran” el cual se agrega por defecto en la instalación, dado que iba implicito en el código del creador de la aplicación.

3.4 WEBMIN

Los pasos para instalar Webmin en Ubuntu son los siguientes:

1. Actualizamos la información de los repositorios (fundamental antes de instalar cualquier aplicación):

$sudo aptitude update

2. Instalamos una serie de paquetes que nos hacen falta para la instalación de Webmin y para que se configure con SSL:

$sudo aptitude install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl apt-show-versions

3. Nos aseguramos de estar en nuestro home:

cd

4. Descargamos la última versión de Webmin (la 1.520 en este caso).

wget http://downloads.sourceforge.net/webadmin/webmin_1.520_all.deb

5. Instalamos Webmin:

$sudo dpkg -i webmin_1.520_all.deb

6. Una vez instalado podemos acceder a la interfaz web de Webmin usando un navegador y escribiendo la dirección IP del equipo donde está instalado seguido del puerto donde está escuchando, por defecto, el 10.000. Eso sí, debemos estar atentos porque en vez de usar el protocolo HTTP, usaremos el HTTPS. En mi caso la IP de mi Ubuntu Server es 192.168.1.3:

https://192.168.10.10:10000

http://www.webmin.com/download.html

https://192.168.10.10:1000/


50

Dentro del Webmin, configuramos el SARG y el Squid3.

Pagina principal

SQUID 3


51


52


53


54

SARG


55


56


57


58

3.5 DALORADIUS

DaloRadius es una interfaz grafica que nos permite administrar nuestro servidor, modificando los archivos de MySQL.

Base de datos de usuarios


59

El DaloRadius es un administrador muy fácil de utilizar, siendo muy intuitivo su uso a la hora de generar usuarios y grupos.

A la hora de administrar un usuario en el momento de su autentificación nos encontramos con el problema de que se podían ligar desde diferentes host con un mismo nombre de usuario y contraseña. La solución a este inconveniente fue setear un atributo de control de usuario, donde este consta de la autentificación de un único usuario por host


60

También es posible administrar el ancho de banda, entre otras cosas, con otro atributo


61

CONCLUSION Podemos concluir que nuestro ISP se comportó de manera estable a la hora de implementarlo ya que cumplió con todas las exigencias presentadas por los administradores, funcionando efectivamente con el control de usuario, control de ancho de banda, y caché para ahorrar tiempo de espera para el cliente. Logrando así una excelente prestación del servicio.

Cabe mencionar que las desventajas que presenta DaloRadius, es que, es una herramienta que está muy limitada en información.

Otra observación fue que Squid 3 no es puramente compatible con SARG ya que sus direcciones no eran compatibles, y tuvimos que redireccionar todas las direcciones del SARG al Squid 3.


62

ANEXO WIRESHARK


63

CAPTURAS DNS

En esta captura se aprecia como un cliente de nuestro ISP (192.168.20.254), hace

una petición a la Web, se observa que la consulta pasa primero por nuestro servidor

DNS (192.168.10.10), en este caso al DNS de Google (8.8.8.8), Google le responde a

nuestro DNS y este al Cliente.

Como datos importantes, se observan las IP de fuete y de destino, y los puertos de

escucha, el puerto 53 es de nuestro servidor.


64

CAPTURAS CONEXIONES

(COMUNICACIÓN MIKTROTIK-SERVIDOR RADIUS)

Aplicando el filtro RADIUS en nuestro Wireshark

En esta captura podemos observar como un cliente de nuestro servidor envía la

solicitud de autentificación y autorización para conectarse a la red (Access-Request).

Se aprecia como el Mikrotik (192.168.10.1) nos enlaza a nuestro servidor

(192.168.10.10) por medio del puerto UDP 1812 que es utilizado para mensaje de

autentificación.


65

En la siguiente figura podemos observar, como el servidor le responde al Access-

Request, informando que la conexión esta autentificada y autorizada, y le envía la

información de configuración para comenzar a usar el servicio (Access-Acept)

El cliente ahora envía un mensaje de Accounting-Request (Start) con la información

correspondiente a su

cuenta


66

El servidor RADIUS responde con un mensaje Accounting-Response, cuando la

información de la cuenta es almacenada.

El puerto 1813 del RAIUS es utilizado como mensaje de cuenta.

En la siguiente captura el usuario decide desconectarse enviando un mensaje de

Accounting-Request (Stop)


67

El servidor RADIUS responde con un mensaje Accounting-Response, cuando la

información de cuenta es almacenada.

Diagrama de flujo entre nuestro Mikrotik y Servidor RADIUS


68

(COMUNICACIÓN CLIENTE-MIKTROTIK)

Aplicando el filtro pppoed, podemos observar lo siguiente cuando el cliente pide ser

logueado en nuesto ISP.

El establecimiento de una conexión PPPoE se basa en 4 paquetes ó partes

fundamentales:

1. El paquete de iniciación de descubrimiento activo (PADI): Un cliente

PPPoE, envía un primer paquete de broadcast (PADI: PPPoE Active

Discovery Initiation) incluyendo el nombre de servicio al cual se quiere

registrar.

2. El paquete ofrece descubrimiento activo (PADO) de PPPoE:

El servidor PPPoE o concentrador de acceso, debe responder a la PADI

con un paquete unicast, PADO (PPPoE Active Discovery Offer), a la

dirección del host que hizo la petición anterior. Dicho paquete incluye el

nombre del Servidor, el nombre del servicio bajo el cual esta sirviendo y

los servicios que ofrece.


69

3. El paquete de solicitud de descubrimiento activo (PADR) de PPPoE:

Cuando se recibe un paquete PADO, el cliente PPPoE responde con un

paquete de PADR (PPPoE Active Discovery Request). Este paquete se

envía a la dirección de unidifusión del concentrador de acceso. El cliente

puede recibir varios paquetes PADO, pero el cliente responde a la

primera PADO válido que recibió el cliente. Si el paquete PADI inicial

tenía presentado un campo de nombre de servicio en blanco, el cliente

rellena el campo de nombre de servicio del paquete PADR con el primer

nombre de servicio que había devuelto el paquete PADO.

4. El paquete de confirmación de sesión (PADS):

Cuando se recibe el PADR, el concentrador de acceso genera una

identificación de sesión único (ID) para esta conexión y devuelve al host

un paquete PADS (PPPoE Active Discovery Session-confirmation) unicast

indicando el numero de sesión que se estableció.


70

Diagrama de flujo Cliente - Mikrotik


71

redes de informacion - trabajo final- lucero_vega

Documents