Trabajo Final Redes de Computadores

5/6/2018 Trabajo Final Redes de Computadores - slidepdf.com

http://slidepdf.com/reader/full/trabajo-final-redes-de-computadores 1/35

Universidad Técnica Federico Santa María

Sede Viña del Mar – José Miguel Carrera

Ingeniería (E) en Sistemas Computacionales

Informe final trabajo de investigación – práctico

Laboratorio de Redes de Computadores

Integrantes:

Diego López: [email protected]

Brian Román: [email protected]

Grupo: 02

Profesor: Sergio Riquelme B.

Ayudante: Alfredo Rojas I.

2011

mailto:[email protected]










2

RESUMEN

Keywords: Estructura de red, Linux Knoppix, DHCP, DNS Caché, Iptables.

El presente trabajo tiene por objetivo implementar una estructura de red definida al

inicio de la asignatura de Laboratorio de Redes de Computadores, la cual se detallará en

las páginas siguientes, utilizando sólo el software incluido en el cd de Linux Knoppix en

el equipo que cumplirá la función de servidor.

Para poder llevar adelante dicha implementación se requerirá poner en práctica los

conocimientos adquiridos durante la asignatura y la investigación personal de los puntosque se estime necesario.

El equipo servidor deberá proveer el servicio de DHCP a los equipos clientes (conexión

inalámbrica), servicio DNS Caché y manejar a través de scripts la

habilitación/denegación a los servicios de ftp, ssh y http para los equipos que pertenecen

a la red local.



3

ÍNDICE

RESUMEN

SIGLAS Y SIMBOLOGÍA

INTRODUCCIÓN

1. ESTRUCTURA Y FUNCIONAMIENTO DE LA SOLUCIÓN PROPUESTA

1.1. Estructura

1.2. Funcionamiento

1.3. Protocolos 1.4. Servicios

2. SCRIPTS Y ARCHIVOS DE CONFIGURACIÓN

2.1. Archivos de configuración

2.2. Scripts

3. PRINCIPALES COMANDOS, PROGRAMAS O APLICACIONES

UTILIZADOS

3.1. Comandos

3.2. Programas o aplicaciones

BIBLIOGRAFÍA

ÍNDICE DE FIGURAS

Figura 1: Diagrama básico de la red a implementar

Figura 2: Diagrama de red propuesta

Figura 3: Modelo OSI y protocolos usados

Figura 4: Banda 2.4 – 2.5 Ghz y canales asociados

Figura 5: Frames Ethernet

Figura 6: Cabecera IPv4

Figura 7: Cabecera TCP

Figura 8: Cabecera UDP

Figura 9: Ejemplo de DNS

Figura 10: Red con NAT

Figura 11: archivo dhcpd.conf por defecto, visto con editor nano

Figura 12: Tiempo de consulta utilizando DNS Caché



4

ÍNDICE DE TABLAS

Tabla 1: Comparación de estándares WLAN más usados

Tabla 2: Scripts para iptables y sus acciones



5

SIGLAS Y/O SIMBOLOGÍA

A. SIGLA

AP

CSMA/CD

DHCP

DNS

Eth0FTP

HTTP

ISO

IP

ISP

LAN

MAC

MTU

NAT

NEXT

OSI

SSH

SSIDTCP

UDP

URL

UTP

WLAN

: Access Point (Punto de Acceso)

: Carrier Sense Multiple Access with Collision Detection (Acceso

Múltiple por Detección de Portadora con Detección de Colisiones)

: Dynamic Host Configuration Protocol (Protocolo de Configuración

Dinámica de Host)

: Domain Name System (Sistema de Nombres de Dominio)

: Interfaz de red número 0: File Transfer Protocol (Protocolo de Transferencia de Archivos)

: Hypertext Transfer Protocol (Protocolo de Transferencia de

Hipertexto)

: International Organization for Standardization (Organización

Internacional para la Estandarización)

: Internet Protocol (Protocolo de Internet)

: Internet Service Provider (Proveedor de Servicio de Internet)

: Local Access Network (Red de Área Local)

: Media Access Control (Control de Acceso al Medio)

: Maximum Transfer Unit (Unidad de Transferencia Máxima)

: Network Address Translation (Traducción de Direcciones de Red)

: Near End CrossTalk (Paradiafonía o Diafonía de Extremo Cercano)

: Open System Interconnection (Interconección de Sistemas Abiertos)

: Secure Shell (Intérprete de órdenes Segura)

: Service Set Identifier: Transmission Control Protocol (Protocolo de Control de

Transmisión)

: User Datagram Protocol (Protocolo de Datagramas de Usuario)

: Unshielded Twisted Pair (Par Trenzado no Blindado)

: Wireless LAN (Red de Área Local Inalámbrica)

B. SIMBOLOGÍA

Mbps

Ghz

: Mega bit por segundo

: Giga Hertz



6

Introducción

Se pide implementar una estructura de red utilizando el software incluido en Linux

Knoppix en el equipo servidor de manera que éste pueda cumplir con los siguientes

requerimientos:

Los equipos conectados a la red local a través del servidor deben poder acceder a

internet y sus parámetros de red ser gestionados en forma dinámica por este

último

El equipo servidor debe proveer el servicio de DNS Caché, ser para la LAN un

servidor DNS. El equipo servidor deberá contar un servicio de cortafuego básico utilizando

iptables. Debe habilitar/restringir a todos los equipos de la red local a los

siguientes protocolos: ftp, http, ssh (todos, algunos, uno)

Los filtros del firewall se manejan mediante scripts y no deben ocupar la “fuerza

bruta”.

La estructura básica de la red a implementar es la siguiente:

Figura 1: Diagrama básico de la red a implementar / Fuente: instrucciones iniciales del trabajo



7

1. ESTRUCTURA Y FUNCIONAMIENTO DE LA SOLUCIÓN

PROPUESTA

1.1. Estructura

La estructura de red a implementar es la que se muestra en la siguiente figura:

Figura 2: Diagrama de red propuesta / Fuente: Elaboración propia

Esta red está compuesta por un equipo servidor, el cual operará con sistema operativo

Linux Knoppix 5.1.1. Dicho servidor cuenta con dos tarjetas de red, identificadas como

eth0 y eth1 por el sistema operativo. Por eth0 se realiza toda comunicación (entrada y

salida de información) hacia internet. Por su parte, eth1 permite comunicar al servidor

con el Access Point (AP), y a través de éste con toda la red local (LAN).

Ambas tarjetas de red poseen direcciones de IP estáticas, tal como se muestra en la

figura.

Existe también un Access Point conectado a la eth1 del equipo servidor. La función del

AP es proveer conexión inalámbrica a los equipos conectados a través de él. El Access

Point opera como DHCP Client, es decir, el equipo servidor le entrega una IP disponible.

Finalmente, la estructura de red, estará conformada por los equipos clientes, es decir,

aquellos equipos que se conectan inalámbricamente a la LAN a través del AP y cuyos



8

parámetros de red son gestionados por el equipo servidor, a través del servicio DHCP, el

cual se explicará oportunamente.

La red local tendrá los siguientes parámetros:

Red: 192.168.1.0/24

Puerta de enlace: 192.168.1.1 (eth1 del servidor)

IP’s disponibles para los clientes: desde 192.168.1.2 hasta 192.168.1.10

Dirección de broadcast: 192.168.1.11

1.2. Funcionamiento1

La red funcionará de la siguiente manera: el equipo servidor posee conectividad

completa, tanto para la red local (192.168.1.0/24) a través de eth1 conectada al AP,

como para internet a través de eth0.

Para conectarse inalámbricamente a la red local, los equipos clientes se conectarán a

través del servidor, quien les asignará por un tiempo determinado una dirección IP

privada del tipo 192.168.1.xxx, donde xxx pueden ser valores entre 2 y 10, y otros

parámetros de red. Lo anterior lo realiza a través del servicio de DHCP.

En Linux Knoppix funciona a través del servicio dhcp3-server .

Dicha dirección IP no les permite “salir” a internet, pues se trata de una dirección

privada y es preciso traducir esta dirección en una válida (IP pública) para poder acceder

a internet. El proceso que hace esta traducción se conoce como NAT ( Network Address

Translation). Es importante destacar que la LAN que se está creando (192.168.1.0) está

inserta dentro de otra LAN (10.3.12.0), lo cual implica que en alguna parte de esta

última red se vuelve a realizar NAT para poder convertir efectivamente esta IP en una

pública, de manera de poder acceder a internet. Sin embargo, este proceso, escapa a lo

comprendido en este trabajo.

Cada vez que un equipo consulte por la IP asociada a una dirección URL, el servidor

verificará si él tiene dicha información y en caso de tenerla responderá a la consulta. En

caso contrario, hará la consulta a los servidores DNS (y éstos a los que sean necesarios),y una vez obtenida la información, responderá la consulta y guardará la información

para una futura consulta similar. De manera que cuando se consulte nuevamente por esta

información, será el servidor DNS de la red local quien responderá, con lo cual se

optimizan los tiempos de respuesta a estas peticiones.

1 En esta sección se explicará el funcionamiento general de la red y de los servicios necesarios para

cumplir con los requerimientos especificados en los objetivos. Mayores detalles de la configuración deestos servicios se explicarán en la sección correspondiente.



9

Este servicio se conoce como DNS Caché, ya que el servidor de la LAN actúa como

servidor DNS para dicha red local, tal como se explicó anteriormente.

En Linux Knoppix funciona a través del servicio bind.

Además, el servidor tendrá activado un cortafuego básico el cual por defecto permitirá a

los equipos de la red local el acceso a cualquier protocolo, incluido los que se pide

administrar en este trabajo, a saber: http, ssh y ftp.

A través del uso de scripts tipo bash se podrá cambiar esta configuración, denegando a

todos los usuarios el acceso a uno, algunos o todos los protocolos mencionados.

En Linux Knoppix, el cortafuegos funciona a través del servicio iptables.

1.3. Protocolos

Para una mejor comprensión, analizaremos los protocolos utilizados de acuerdo al

modelo OSI2. No detallaremos todos los protocolos posibles a ser utilizados por una red,

sino que nos concentraremos en aquellos que son fundamentales para la estructura de red

a implementar y sus requerimientos.

Figura 3: Modelo OSI y protocolos usados / Fuente: elaboración propia

Cable de red UTP cat 5: cable de red utilizado en redes Ethernet 802.3. Está compuesto

por cuatro pares de conductores no blindados, diferenciados cada uno por un color (o par

2 Es un modelo de referencia de arquitectura de red creado por la Organización Internacional para laEstandarización (ISO)



10

de colores). Su ubicación en los pines del conector rj-45 pueden ser de dos maneras, de

acuerdo a la normativa vigente, aunque generalmente se suele usar la TIA/EIA 568B.

Esta categoría soporta redes Ethernet (10 Mbps), Fast Ethernet (100 Mbps) y ATM (155

Mbps) sobre cableado UTP.La certificación del cableado de esta categoría se basa en los siguientes parámetros:

diagrama de cableado, largo del cableado (máx. 100 mts), atenuación (perdida de señal

producto de la frecuencia y largo del cable), NEXT (grado de acoplamiento de señales

no deseadas desde un par adyacente).

Conexión Inalámbrica: Sistema de comunicación de datos sin cables. Trabaja en base a

radiofrecuencias, lo cual implica que en un mismo lugar y al mismo tiempo puede habervarias portadoras de radio funcionando a distinta frecuencia sin interferirse entre ellas.

Por ejemplo, una Wireless Lan (WLAN) funcionando a una frecuencia X, y un sistema

de teléfonos inalámbricos funcionando a una frecuencia Y.

Los estándares 802.11 b/g de conexiones inalámbricas trabajan en la banda de frecuencia

2.4 – 2.5 Ghz, en donde hay definidos 11 canales (13 en Europa) que pueden ser

utilizados. Sin embargo, estos canales no son completamente independientes, ya que

canales contiguos se superponen. Así, en la práctica, solamente podemos ocupar 3

canales: 1, 6, 11 (1, 5, 9, 13 para Europa)

Figura 4: Banda 2.4 – 2.5 Ghz y canales asociados / Fuente: www.google.cl

IEEE 802.3: Estándar que define los patrones de la Ethernet, tanto a nivel físico como a

nivel de enlace de datos (subcapa MAC). Establece los cableados permitidos y las

características que deben cumplir.

En la capa de enlace de datos trabaja en base a CSMA/CD persistente-1 para mejorar el

rendimiento de la red y así evitar el mayor número de colisiones, lo que implica

retransmitir la información colisionada, con las respectivas consecuencias de

rendimiento de la red.

Este estándar establece el formato de los marcos ( frames) en Ethernet, indicando el

contenido de información presente en cada sector del marco, como también el largo de

ellos:



11

Figura 5: Frames Ethernet / Fuente: asignatura redes de computadores

IEEE 802.11: al igual que su par en Ethernet, este estándar define los patrones de la

WLAN en los dos primeros niveles del modelo OSI, es decir, capa física y enlace de

datos (sólo subcapa MAC).Entre estos patrones encontramos las bandas de frecuencias utilizadas por la WLAN,

canales, velocidades de transmisión máxima, SSID, tipo de cifrado de datos, entre otros.

Dentro de este estándar encontramos sub-estándares asociados a las diferentes versiones

de WLAN existentes. Hoy en día encontramos 3 principalmente: 802.11b, 802.11g y

802.11n

Tabla 1: Comparación de estándares WLAN más usados

802.11 Velocidad máxima

(Mbps)

Frecuencia

(Ghz)

Canales disponibles

(América)

b 11 2.4 11

g 54 2.4 11

n 6002.4

5

11

8

IP (Internet Protocol): protocolo de internet no orientado a la conexión que permite el

envío de paquetes o datagramas desde un emisor a un receptor, tanto en una red local

como a través de redes.



12

IP provee un servicio de envío de paquetes no fiable conocido como de mejor esfuerzo

(best effort ), es decir, hará el mejor esfuerzo por entregar los paquetes pero no garantiza

la entrega de los mismos, que los datos lleguen correctamente (sin daños) ni que lleguen

en un orden determinado. Estos “problemas” son manejados por las capas superiores,

por ejemplo, en la capa de transporte, TCP se encarga de los problemas de fiabilidad de

los paquetes.

También provee direccionamiento de los paquetes a través de un número IP.

Los paquetes que son transmitidos de un equipo a otro poseen un tamaño máximo

previamente negociado llamado MTU ( Maximum Transfer Unit ). Si un paquete supera

este tamaño, será divido en las unidades que sea necesario para ser enviado aldestinatario y ensamblados nuevamente cuando sea necesario.

Dependiendo de la versión IP utilizada, el datagrama poseerá un encabezado que lo

identificará. Así por ejemplo, para nuestro caso, el encabezado de un datagrama con

IPv4 sería de la siguiente forma:

Figura 6: Cabecera IPv4 / Fuente: asignatura redes de computadores

TCP (Transmission Control Protocol): el protocolo de control de transmisión permite

garantizar que los paquetes serán entregados al destinatario sin errores y en el mismo

orden en que fueron transmitidos o enviados.

Este protocolo posee un mecanismo que le permite distinguir distintas aplicaciones

dentro de una misma máquina a través del uso de puertos o sockets.

A diferencia del protocolo IP, TCP es un protocolo orientado a la conexión (es necesario

sincronización previa de los equipos antes de transmitir), lo que le permite ofrecer una

entrega confiable de los datos a través de herramientas de control de flujo y congestión.



13

Los paquetes enviados también deben poseer una cabecera del tipo TCP para identificar

que dicho paquete está utilizando este protocolo de transporte (la otra posibilidad es el

protocolo UDP)

Figura 7: Cabecera TCP / Fuente: asignatura de redes de computadores

UDP: protocolo de la capa de transporte del modelo OSI que se basa en la transmisión

de datagramas. A diferencia de TCP, este protocolo no está orientado a la conexión, es

decir, la transmisión de datos se realiza sin establecer una conexión previa, ya que el

encabezado del datagrama cuenta con la información suficiente para llegar a destino

(pero no se me garantiza que eso suceda). No provee control de flujo ni asegura que el

paquete llegue a destino incorrupto.

Figura 8: Cabecera UDP / Fuente: asignatura de redes de computadores

HTTP: el protocolo de transferencia de hipertexto permite la transferencia de archivos

entre un navegador (cliente) y un servidor web. De forma simple, el navegador realiza

una solicitud http. El servidor al cual se le realiza la solicitud la procesa y responde a

ella (respuesta http)



14

Por defecto ocupa el puerto 80. Trabaja con protocolo TCP/IP

Ejemplo:

1. Desde nuestro navegador escribimos www.jmc.usm.cl/index.html 2. El navegador solicita al servidor DNS la IP de www.jmc.usm.cl

3. El DNS devuelve la IP 200.1.25.3

4. El navegador se conecta a 200.1.25.3 en el puerto 80 y envía un “GET

/index.html”

5. El servidor web le envía el archivo index.html y todas las imágenes que esta

página contuviera

6.

El navegador despliega el texto, las imágenes y todo lo recibido desde el servidorweb

7. Se cierra la conexión (TCP)

SSH: está asociado tanto al protocolo como al programa que lo usa, y permite acceder

de manera segura a estaciones remotas a través de una red.

Por defecto, ocupa el puerto 22 y trabaja con protocolo TCP/IP

FTP: es un protocolo para la transferencia de archivos entre sistemas conectados a

través de una red TCP basados en la arquitectura cliente-servidor. Esto permite que un

cliente se conecte a un equipo servidor para enviarle archivos o descargar archivos de él,

independientemente del sistema operativo con el cual trabajen ambos equipos.

Por defecto, ocupa los puertos 20 (datos) y 21 (control). Trabaja con protocolo TCP/IP

DHCP: es un protocolo de red que permite a los clientes de una red IP obtener sus

parámetros de configuración de manera automática. Para ello, hay un equipo servidor

que posee una lista de direcciones IP y las va asignando dinámicamente en la medida

que le son requeridas por diferentes equipos clientes, guardando esta información en otro

archivo, de manera de tener siempre claridad las que direcciones IP están ya asignadas, a

quién se le asigno y el tiempo por el cual se le asignó.

La asignación de direcciones IP puede ser manual (se asigna una IP a un equipo

determinado), dinámica (se le asigna una IP a un equipo por un tiempo limitado) o

automática (se le asigna una IP a un equipo hasta que éste la libere)

Por defecto, ocupa los puertos 67 (servidor) y 68 (cliente) y trabaja con los protocolos

UDP e IP

http://www.jmc.usm.cl/index.html



http://www.jmc.usm.cl/







15

DNS: protocolo utilizado para la resolución de nombres de dominio. Los servidores

DNS son los encargados de traducir los “nombres reales” a su correspondiente IP y

viceversa. Dichos servidores responden a consultas de DNS realizadas por los clientes.

Por ejemplo, cuando escribimos una URL en nuestro navegador es necesario traducir elnombre en su correspondiente ip para que nuestro equipo pueda comunicarse con dicho

servidor web.

Por defecto, ocupa el puerto 53. Trabaja con protocolos TCP/UDP e IP

En el siguiente ejemplo se explica lo anterior:

1. El equipo cliente consulta al servidor DNS local por la ip asociada a la url

cicada.cs.princeton.edu

2. El servidor local desconoce la ip asociada y le pregunta otro servidor DNS de

mayor jerarquía (Root Name Server)

3. El Root Name Server le dice que el servidor DNS de princeton.edu tiene ip

128.196.128.233

4. El servidor DNS local le consulta por el nombre cicada.cs.princeton.edu

5. El servidor de princeton responde que el servidor DNS de cs.princeton.edu tiene

ip 192.12.69.5

6. El servidor DNS local le consulta por el nombre cicada.cs.princeton.edu

7. El DNS asociado a cs.princeton.edu responde que la ip es 192.12.69.60

8. El servidor DNS local le entrega la información al equipo cliente

Figura 9: Ejemplo de DNS / Fuente: asignatura de redes de computadores



16

NAT: permite intercambiar paquetes entre redes que se asignan direcciones IP

incompatibles.

El caso más común del uso de NAT ocurre cuando tenemos equipos pertenecientes a una

red local y necesitamos que ellos puedan acceder a internet. Como bien sabemos, ladirección privada no nos permite acceder a internet, sino que esto lo podemos hacer a

través de una IP pública. Para ello necesitamos traducir las direcciones privadas en una

(o varias) IP pública.

La siguiente figura muestra un ejemplo de NAT: Tenemos dos clientes con IP privada

(192.168.0.2 y 192.168.0.3) conectados a un Router que tiene NAT habilitado. Es decir,

cuando uno de estos clientes envía paquetes fuera de la red local, al llegar al Router la IPde origen (192.168.0.x) es traducida por una IP pública del tipo 206.245.160.x

Figura 10: Red con NAT / Fuente: www.google.cl

1.4. Servicios

Para satisfacer los requerimientos anteriormente mencionados fue necesario configurar y

habilitar cuatro servicios en el equipo servidor:

Networking: servicio que por defecto viene activado y que permite configurar el

hardware de red presente en el equipo, el servidor en nuestro caso. Si el equipo accede a

internet vía DHCP, como suele ocurrir con nuestro ISP (VTR, Claro, Telmex…), la

configuración es automática. Pero, como en nuestro caso, las IP del servidor, tanto para

eth0 como eth1, son estáticas, es necesario configurar manualmente los parámetros de

red.



17

Archivos que fueron configurados:

/etc/network/interfaces

/etc/resolv.conf 3

Dhcp3-server: la configuración y habilitación del servicio de DHCP permitirá al

servidor asignar dinámicamente direcciones IP a los equipos clientes que se conecten a

la LAN a través de él. Junto con entregarle una dirección IP, el servidor entregará a cada

equipo otros parámetros de red necesarios para una correcta configuración (dns, máscara

de red, puerta de enlace)


/etc/dhcp3/dhcpd.conf

Importante mencionar que en la ruta /var/lib/dhcp3/ se encuentra el archivo

dhcpd.leases, el cual contiene información sobre las direcciones IP que el servidor ha

concedido.

Parte de esta información es la que se muestra en el siguiente ejemplo:

lease 192.168.1.5{ // Indica la IP que ha sido asignada

starts 1 2011/05/23 10:18:29; // Fecha y hora del inicio de asignación

ends 1 2011/05/24 10:28:29; // Fecha y hora del término de asignación

hardware ethernet 00:90:96:25:f1:54; // MAC asociada a la IP asignada

}

Bind: este servicio permite al servidor actuar como servidor DNS, DNS Caché para

nuestro caso. El servicio funciona a través del demonio named.

La primera vez que se consulta por una dirección no hay mayor cambio en los tiempos

de respuesta, pues el servidor DNS Caché no posee en su base de datos la información

que se le solicita y por tanto tiene que reenviar la consulta a los servidores DNS

externos. Sin embargo, la segunda vez (y las siguientes también) que se realice esta

misma consulta el servidor DNS Caché será el que responda a la consulta, reduciendoconsiderablemente los tiempos de respuesta.

Por ejemplo, cuando por consola consultamos por primera vez por la dirección

www.google.com, el sistema nos arrojó un tiempo de respuesta (Query Time) de 76

3Normalmente en este archivo se colocan los servidores DNS de nuestro ISP o de nuestra organización.

Sin embargo, debido que el equipo servidor de DHCP actuará también como servidor DNS, dicho archivo

hará referencia al localhost o dirección de loopback, y las referencias a los servidores DNS estarán

incorporadas en la configuración del servidor DNS (archivo named.conf.options)



18

mseg. Sin embargo, al realizarse nuevamente la consulta el tiempo de respuesta fue de 2

mseg., ya que esta última vez fue el DNS Caché quien respondió a nuestra consulta.


/etc/bind/named.conf.options

/etc/resolv.conf

Iptables: este servicio actúa como cortafuegos en el equipo servidor y puede tener

distintos niveles de control: de la red local hacia internet, de internet hacia la red local,

dentro de la red local, permisos específicos para un equipo, etc.Los distintos filtros con los que cuenta el servicio de cortafuegos implementado en esta

red serán manejados a través de diferentes scripts.

Tabla 2: Scripts para iptables y sus acciones

Nombre del script Acciones asociadas

iptables_allow.sh Habilita a los usuarios de la red local a acceder a los protocolos

de ftp, ssh, http y https.

iptables_deny.sh Prohibe a los usuarios de la red local a acceder a los protocolos

de ftp, ssh, http y https.

iptables_ftp.sh Habilita a los usuarios de la red local a acceder sólo al protocolo

ftp.

iptables_ssh.sh Habilita a los usuarios de la red local a acceder sólo al protocolo

ssh.

iptables_http.sh Habilita a los usuarios de la red local a acceder sólo al protocolo

http y https.

iptables_ftp-ssh.sh Habilita a los usuarios de la red local a acceder a los protocolos

de ftp y ssh, negándoles el acceso a los protocolos de http y

https.

iptables_http-ftp.sh Habilita a los usuarios de la red local a acceder a los protocolos

de http, https y ftp, negándoles el acceso al protocolo ssh.iptables_http-ssh.sh Habilita a los usuarios de la red local a acceder a los protocolos

de http, https y ssh, negándoles el acceso al protocolo ftp.

Es importante destacar que cada script, además de la habilitación/denegación a los

protocolos descritos, habilita el enmascaramiento y forwarding necesarios para acceder a

internet desde la red local.



19

2. Scripts y archivos de configuración utlizados

2.1. Archivos de configuración

resolv.conf

# Insert nameservers here

nameserver 127.0.0.1 // LOCALHOST

dhcpd.conf

# CONFIGURACION DE LA RED LOCAL

subnet 192.168.1.0 netmask 255.255.255.0{

# PUERTA DE ENLACE

option routers 192.168.1.1;

# DIRECCION DE BROADCAST

option broadcast-address 192.168.1.11;

# IP DEL DNS

option domain-name-servers 192.168.1.1;

# RANGO DE IP DISPONIBLES PARA ASIGNAR

range 192.168.1.3 192.168.1.10;

# TIEMPO DE ASIGNACION POR DEFECTO [SEG]

default-lease-time 43200;

# TIEMPO DE ASIGNACION MAXIMO [SEG]

max-lease-time 86400;

}



20

interfaces

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface

# automatically added when upgrading

auto lo

iface lo inet loopback

# CONFIGURACION DE LA TARJETA DE RED ETH0 (INTERNET)

allow-hotplug eth0

# IP ESTATICA PARA ETH0

iface eth0 inet static

# IP ASIGNADA

address 10.3.12.162

# PUERTA DE ENLACE

gateway 10.3.12.1


broadcast 10.3.12.255

# MASCARA DE LA RED

netmask 255.255.255.0

pre-up ifconfig eth0 up

# CONFIGURACION DE LA TARJETA DE RED ETH1 (RED LOCAL)

allow-hotplug eth1

# IP ESTATICA PARA ETH1

iface eth1 inet static

# IP ASIGNADA

address 192.168.1.1

# PUERTA DE ENLACE

gateway 10.3.12.162


broadcast 192.168.1.11

# MASCARA DE LA RED

netmask 255.255.255.0

pre-up ifconfig eth1 up



21

named.conf.optiones

options {

directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want

// to talk to, you might need to uncomment the query-source

// directive below. Previous versions of BIND always asked

// questions using port 53, but BIND 8.1 and later use an unprivileged

// port by default.

// query-source address * port 53;

// If your ISP provided one or more IP addresses for stable

// nameservers, you probably want to use them as forwarders.

// Uncomment the following block, and insert the addresses replacing

// the all-0's placeholder.

# SERVIDORES DNS [NO LOCAL]

forwarders {

200.1.21.80;

200.1.21.150;

};

auth-nxdomain no; # conform to RFC1035

listen-on-v6 { any; };};



22

2.2. Scripts

iptables_allow.sh

#!/bin/sh

# IPTABLES HABILITA PROTOCOLOS DE HTTP, FTP, SSH A LA RED LOCAL

echo "Aplicando reglas..."

## FLUSH de reglas

iptables -F

iptables -X

iptables -Ziptables -t nat -F

## Políticas por defecto

iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT

iptables -P FORWARD ACCEPT

iptables -t nat -P PREROUTING ACCEPT

iptables -t nat -P POSTROUTING ACCEPT

## Inicio del filtraje

## eth0 para salida a internet y eth1 para la red local

# Se habilita el localhost

/sbin/iptables -A INPUT -i lo -j ACCEPT

# Acceso al firewall desde la red localiptables -A INPUT -s 192.168.1.0/24 -i eth1 -j ACCEPT

# Habilitación de protocolo Http para la red local

iptables -A FORWARD -s 192.168.1.0/24 -i eth1 -p tcp --dport 80 -j ACCEPT

# Habilitación de protocolo ftp para la red local



# Habilitación de protocolo ssh para la red local

iptables -A FORWARD -s 192.168.1.0/24 -i eh1 -p tcp --dport 22 -j ACCEPT

# Enmascaramiento de red y forwarding para la salida a internet de la red local

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

# Mensaje final

echo "PROTOCOLOS HTTP, SSH Y FTP HABILITADOS"

# Fin del script



23

iptables_deny.sh

#!/bin/sh

# IPTABLES DENIEGA PROTOCOLOS DE HTTP, FTP, SSH A LA RED LOCALecho "Aplicando reglas..."

## FLUSH de reglas

iptables -F

iptables -X

iptables -Z

iptables -t nat -F









# Se habilita localhost

iptables -A INPUT -i lo -j ACCEPT

# Acceso al firewall desde la red local

iptables -A INPUT -s 192.168.1.0/24 -i eth1 -j ACCEPT

# Denegación de protocolo Http para la red local

iptables -A FORWARD -s 192.168.1.0/24 -i eth1 -p tcp --dport 80 -j DROP

# Denegación de protocolo ftp para la red local



# Denegación de protocolo ssh para la red local

iptables -A FORWARD -s 192.168.1.0/24 -i eh1 -p tcp --dport 22 -j DROP




# Mensaje final

echo "PROTOCOLOS HTTP, SSH y FTP DENEGADOS"

# Fin del script



24

iptables_ftp.sh

#! /bin/sh

# IPTABLES HABILITA SOLO FTPecho "Aplicando reglas: Habilitando FTP..."

## FLUSH de reglas

iptables -F

iptables -X

iptables -Z

iptables -t nat -F













# Denegación de servicio Http para la red local


# Habilitación de servicio ftp para la red local



# Denegación de servicio ssh para la red local





# Mensaje final

echo -n "Servicio FTP habilitado"

# Fin del script



25

iptables_ftp-ssh.sh

#!/bin/sh

# IPTABLES HABILITA FTP Y SSHecho "Aplicando reglas..."

## FLUSH de reglas

iptables -F

iptables -X

iptables -Z

iptables -t nat -F













# Denegación de protocolo Http para la red local










# Mensaje final

echo "PROTOCOLOS FTP, SSH HABILITADOS"

# Fin del script



26

iptables_http.sh

#!/bin/sh

# IPTABLES HABILITA SOLO HTTPecho "Aplicando reglas: Habilitando protocolo HTTP..."

## FLUSH de reglas

iptables -F

iptables -X

iptables -Z

iptables -t nat -F























# Mensaje final

echo "PROTOCOLO HTTP HABILITADO"

# Fin del script



27

iptables_http-ftp.sh

#!/bin/sh

# IPTABLES HABILITA HTTP Y FTPecho "Aplicando reglas..."

## FLUSH de reglas

iptables -F

iptables -X

iptables -Z

iptables -t nat -F













# Habilitación de protocolo http para la red local










# Mensaje final

echo "PROTOCOLOS HTTP Y FTP HABILITADOS"

# Fin del script



28

iptables_http-ssh.sh

#!/bin/sh

# IPTABLES HABILITA HTTP Y SSHecho "Aplicando reglas..."

## FLUSH de reglas

iptables -F

iptables -X

iptables -Z

iptables -t nat -F























# Mensaje final

echo "PROTOCOLOS HTTP Y SSH HABILITADOS"

# Fin del script



29

iptables_ssh.sh

#!/bin/sh

# IPTABLES HABILITA SOLO SSHecho "Aplicando reglas: Habilitando SSH..."

## FLUSH de reglas

iptables -F

iptables -X

iptables -Z

iptables -t nat -F













# Denegación de protocolo http para la red local










# Mensaje final

echo "PROTOCOLO SSH HABILITADO"

# Fin del script



30

inicio.sh

#!/bin/sh

# SCRIPT PARA COPIAR LOS ARCHIVOS DE CONFIGURACION AL EQUIPO

SERVIDOR Y SUBIR SERVICIOS

# COPIA LOS ARCHIVOS DE CONFIGURACION A SUS RESPECTIVAS RUTAS

cp dhcpd.conf /etc/dhcp3/

cp interfaces /etc/network/

cp resolv.conf /etc/ cp named.conf.options /etc/bind/

# INICIO DE LOS SERVICIOS

# REINICIO DEL SERVICIO DE RED

/etc/init.d/networking restart

ifup eth0

ifup eth1

# INICIO DEL SERVICIO DE DHCP

/etc/init.d/dhcp3-server start

# INICIO DEL SERVICIO DE DNS

/etc/init.d/bind9 start

# HABILITACION DE FORWARDING





31

3. Principales comandos, aplicaciones o programas utilizados

3.1. Comandos

iptables – F

iptables – X

iptables – Z

iptables −t nat – F

Estos cuatro comandos realizan acciones de flush o de vaciado a las tablas y contadores

que utiliza iptables. La primera elimina las cadenas existentes de la tabla por defecto( filter table); la segunda regla elimina todas las cadenas definidas por el usuario; la

tercera, vuelve a cero el byte y contadores de paquetes, y la última regla, elimina las

cadenas de la tabla nat.

iptables −A FORWARD −s 192.168.1.0/24 −i eth1 −p tcp −−dport 80 −j ACCEPT

Comando para iptables que permite agregar una regla a la tabla de filtraje ( filter table)

en la cual se permite a los equipos de la red local (192.168.1.0/24) acceder al protocolo

http, cuyo puerto por defecto es el 80.

Sintaxis similar se utiliza para habilitar el acceso a los protocolos ftp y ssh.

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j MASQUERADE

Comando para iptables que agrega una regla a la tabla nat (nat table) y permite realizar

enmascaramiento a los paquetes de los equipos de la red local, de manera que dichos

equipos puedan acceder a internet y comunicarse con equipos que están fuera de la red

local (por ejemplo, para acceder a un sitio web, a un servidor ftp, etc.)


Habilita el forwarding en el equipo servidor, de manera que los paquetes puedan pasar

de una tarjeta de red a otra, de eth1 a eth0 o viceversa, según sea el caso.

/etc/init.d/ nombre_servicio acción

Comando utilizado para realizar una acción (start, restart, stop, status) sobre un servicio

determinado identificado por nombre_servicio. En nuestro caso fueron los servicios de

dhcp, dns, red y firewall, a través de sus respectivos identificadores: dhcp3-server,

named, networking, iptables.



32

nano nombre_archivo

Comando que abre el archivo llamado nombre_archivo con el editor de texto nano para

su visualización y eventual modificación../ nombre_script.sh

El programa bash ejecuta las instrucciones contenidas dentro del script nombre_script.sh

Importante: el script debe encontrarse en el directorio en el que nos encontramos al

momento de ejecutar este comando.

Por ejemplo: si nos encontramos en /home/knoppix/ y escribimos ./prueba.sh , el script

prueba.sh debe encontrarse en /home/knoppix/

mount /dev/sdb1 /mnt/sdb1

El comando mount permite montar dispositivos y particiones para que puedan ser usadas

por el sistema operativo. En nuestro caso montamos el pendrive, identificado por Linux

Knoppix como sdb1, en la ruta /mnt/sdb1

Una vez montado el pendrive se procede a ejecutar el script inicio.sh el cual copia los

archivos de configuración necesarios a sus rutas respectivas. Luego inicializa los

servicios de red, dhcp y dns, dejando configurada la red y 100% operativa, de manera

que puedan empezar a conectarse los equipos inalámbricos a la red local.

Este script, como también los que se ocuparán para iptables, se encuentran en la

siguiente ruta: /mnt/sdb1/scripts/

3.2. Programas o aplicaciones

Nano: editor de texto para sistemas UNIX. El manejo de nano es a través del teclado,

más específicamente, a través del uso de la tecla control (CTRL). Por ejemplo, al

presionar control+O se guarda el archivo abierto y con control+X se sale del editor.



33

Figura 11: archivo dhcpd.conf por defecto, visto con editor nano / Fuente: elaboración propia

Bash: programa cuya función es interpretar órdenes y ejecutarlas. Su nombre es un

acrónimo de Bourne- Again Shell.

En general los scripts (conjunto de órdenes) pueden ser ejecutadas por bash sin realizar

modificaciones, salvo excepciones.

En nuestro caso, a través de bash se ejecutarán el script de inicio y los scripts de control

de iptables. Para ello, la primera línea de los scripts tendrá la siguiente forma:#!/bin/bash ó #!/bin/sh

La extensión de los archivos de scripts será .sh y tendrán activado el bit de ejecución.

Se ejecutan mediante el comando: ./nombre_script.sh

Bind: servidor de DNS desarrollado por la Internet Systems Consortium. Actualmente se

utiliza Bind9, versión escrita desde cero debido a algunos problemas que presentaba sus

antecesores y para poder incorporar DNS Security Extensions (DNSSEC).

Bind9 funciona a través del demonio named .

Entre sus opciones está la posibilidad de configurar un servidor DNS Caché, de manera

de optimizar los tiempos de respuesta a consultas DNS por parte de los equipos de la red

local.



34

Figura 12: Tiempo de consulta utilizando DNS Caché / Fuente: www.google.com

Dhcp3-server: servidor DHCP desarrollado por la Internet Systems Consortium, el cual

permite al equipo que actúa como servidor de este servicio gestionar la entrega de

direcciones IP y parámetros de red a los equipos de la red local que se conectan a través

suyo.

Si bien, la versión de Linux Knoppix utilizada en el equipo servidor ocupa la versión 3.x

de dhcp-server, en la actualidad está disponible la versión 4.x.

Linux Knoppix: Para el equipo servidor se utilizó el Live CD de Linux Knoppix en su

versión 5.1.1 (del 4 de enero del 2007). Knoppix es una distribución de Linux basada en

Debian, cuya interfaz gráfica por defecto es KDE. Sin embargo, para la administración

del servidor se utilizó siempre el modo consola.



35

Bibliografía

MARABOLI ROSSELOT, Marcelo. Redes de Computadores [Diapositivas], Viña del

Mar, Chile. Material parte de la asignatura de Redes de Computadores dictada en la

UTFSM, Sede Viña del Mar, el 2º Semestre del 2010.

Yañez, Ricardo. MAN-ES, Guía de instalación Debian GNU/Linux [en línea].

Consultado el 02 de mayo de 2011.

Disponible en <http://man-es.debianchile.org/bind.html>

ALTADILL IZURRA, Pello Xabier. Manual práctico de iptables [en línea].

Consultado el 06 de abril de 2011

Disponible en <http://www.pello.info/filez/firewall/iptables.html>

http://man-es.debianchile.org/bind.html

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

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

http://man-es.debianchile.org/bind.html

Documents

Trabajo Final Redes de Computadores