Seguridad en Sistemas de Información





CINVESTAV-IPN, México D.F.
Departamento de Ingeniería Eléctrica
Sección de Computación

Asesor:
Dr. Luis Gerardo de la Fraga

Alumnos:
Samuel Garrido Daniel, Mario Irán F. Parra Hernández, Dennis Bazan Sandoval

México D.F. 12/Julio/2004

Resumen

El presente trabajo explica como establecer conexiones seguras
a través de la tecnología conocida como VPN (Virtual Private
Net) en una red. Se creo un esquema en el cuál dos redes
militarizadas se encuentran conectadas mediante un Gateway el
cuál por medio de su tercera interfase de red se conecta a
Internet. Se explican las configuraciones necesarias para crear la
red en la cual se monto dicho trabajo, también se explica la
configuración el software necesario y su configuración.






 

Contenido

1. Introducción

2. Conceptos Básicos.

3. Configuración de la Red y el Gateway.

4. Instalación y Configuración del Software.

5. Configuración Firewall.

6. Configuración del Servidor SSH.

7. Creando túneles tunneling utilizando SSH.




1. Introducción

Este trabajo es el proyecto final de la materia: Seguridad en Sistemas de Información. El
cual consistió en realizar pruebas y poner en práctica lo aprendido en la parte del curso
referente a seguridad en redes. Utilizando GNU/Linux se explica como establecer
conexiones seguras a través de la tecnología conocida como VPN (Virtual Private Net)
utilizando SSH en una red, a la cuál se le brinda seguridad a través del la implementación
de un firewall haciendo uso de la principal herramienta en Linux para este objetivo, es
decir Iptables. Se creo un esquema en el cuál dos redes militarizadas se encuentran
conectadas mediante un Gateway el cuál por medio de su tercer interfase de red se
conecta a Internet. Se explican las configuraciones necesarias para crear la red en la cual
se monto, configurar el software necesario y establecer las políticas de seguridad dentro
del esquema.

El escenario de la red que se instalo y configuro para realizar túneles a través de SSH se
muestra en la siguiente figura:

figura 1

Figura 1. Esquema de red para el ejemplo de la creación de túneles vpn utilizando SSH


En el centro de la figura se puede ver el gateway el cual es una computadora con Linux
RedHat 9, en la que se encuentra un firewall implementado usando el iptables, las
políticas de filtrado definen la seguridad y la forma en el que se distribuye el acceso a
internet entre las dos redes militarizadas que une el gateway.


El gateway tiene instaladas tres tarjetas de red ethernet a 10/100 Mbits, estas se
encuentran en el sistema como eth0, eth1 y eth2.

La interfase de red eth0 contiene la dirección ip 10.10.10.1 y es la puerta de enlace para
la red militarizada en donde se encuentra una red de usuarios normales, esta red en
nuestro ejemplo esta formada por tres usuarios con las direcciones 10.10.10.3, 10.10.10.4
y 10.10.10.5.

También en la figura 1 se muestra una línea de color rojo con la etiqueta túnel ssh, lo que
quiere decir es que solo el usuario de la computadora 10.10.10.3 tendrá la posibilidad de
crear conexiones seguras a través de túneles ssh al servidor que se encuentra en la otra
red militarizada que se que en la figura la podemos ubicar del lado derecho.

La interfase de red eth1 tiene la dirección ip 10.2.1.1 y es la puerta de enlace para la otra
red militarizada, en esta red únicamente se tiene una computadora que tiene instalado un
servidor SSH, el cual permitirá realizar túneles VPN al usuario de la computadora
10.10.10.3 que se encuentra ubicado del otro lado del gateway. Además este servidor
SSH tendrá los servicios de Web y Web seguro.

Por último la interfase de red eth2 tiene una dirección asignada mediante DHCP la cual le
da conexión a Internet. Gracias a esta conexión podrá ser posible proveer de Internet a las
dos redes militarizadas, que como ya se menciono se encuentran conectadas al gateway
con los dispositivos eth0 y eth1 respectivamente.

Es importante mencionar, que en este último punto fue necesario crear políticas en
Iptables, de modo que se asegurara que el tráfico entrante a eth2 desde el exterior solo
fuese tráfico válido es decir que alguna computadora dentro de las redes militarizadas
hubiese requerido.


2. Conceptos básicos.

Antes de iniciar con los pasos para la instalación de la red, del software y configuraciones
necesarias, se ofrecen algunos conceptos preeliminares para un mejor entendimiento de
todos lo necesario para implementar una VPN interna.

2.1 Gateway (Puerta de enlace).

Un gateway o puerta de enlace es normalmente un equipo informático configurado para
dotar a las máquinas de una red local (LAN) conectadas a él de un acceso hacia una red
exterior, generalmente realizando para ello operaciones de traducción de direcciones IP
(NAT: Network Address Translation). Esta capacidad de traducción de direcciones
permite aplicar una técnica llamada IP Masquerading, usada muy a menudo para dar
acceso a Internet a los equipos de una LAN compartiendo una única conexión a Internet,
y por tanto, una única dirección IP externa.

2.2 Firewall (Cortafuegos).

Los cortafuegos son sistemas de seguridad para evitar incendios que consisten en
establecer una barrera física, no inflamable, separando la zona que queremos proteger de
la zona de donde puede venir el fuego. En informática, un cortafuego es cualquier sistema
utilizado para separar una máquina o una subred del resto de la red para protegerla de
intrusiones externas que puedan suponer una amenaza a la seguridad. La zona protegida
se llama "perímetro de seguridad" y la protección se realiza separándola de una zona
externa, no protegida, llamada zona de riesgo.

Evidentemente la forma de aislamiento más efectiva para cualquier política de seguridad
consiste en el aislamiento físico, es decir, no tener conectada la máquina o la subred a
otros equipos o a Internet. Pero de lo que se trata es, precisamente, de proteger datos
archivados que tienen que estar disponibles para ser transportados.

Se llama host bastión (también se denominan gates) al sistema que actúa como
intermediario. Es el punto de contacto de los usuarios de la red interna de una
organización con otro tipo de redes. El host bastión filtra tráfico de entrada y salida, y
también esconde la configuración de la red hacia fuera. Esta máquina debe estar
especialmente asegurada, pero en principio es vulnerable a ataques por estar abierta a
Internet.

Se llama filtrado de paquetes la acción de denegar o permitir el flujo de información entre
la red interna, protegida con a través del cortafuegos, y el resto de Internet. Este filtrado
se hace de acuerdo a unas normas predefinidas. El filtrado también se conoce como
screening, y a los dispositivos que lo implementan se les denomina chokes; el choke
puede ser la máquina bastión o un elemento diferente.

En casi todos los cortafuegos existen al menos un choke y una máquina bastión, aunque
también puede ser considerado cortafuegos a un simple router que filtre paquetes.


2.3 Secure Shell (SSH)

Secure Shell (ssh) es un programa para conectarse a otros equipos a través de una red,
para ejecutar comandos en una máquina remota y para mover archivos de una máquina a
otra. Proporciona una exhaustiva autenticación y comunicaciones seguras en redes no
seguras.

Ssh provee fuerte autenticación y comunicación segura sobre un canal inseguro y nace
como un reemplazo a los comandos telnet, ftp, rlogin, rsh, y rcp, los cuales proporcionan
gran flexibilidad en la administración de una red, pero sin embargo, presenta grandes
riesgos en la seguridad de un sistema. Adicionalmente, ssh provee seguridad para
conexiones de servicios X Windows y envío seguro de conexiones arbitrarias TCP.

Secure Shell admite varios algoritmos de cifrado entre los cuales se incluyen:
· Blowfish
· 3DES
· IDEA
· RSA
La ventaja más significativa de ssh es que no modifica mucho las rutinas. En todos los
aspectos, iniciar una sesión de ssh es tan sencillo como iniciar una sesión de telnet. Tanto
el intercambio de llaves, la autenticación, así como el posterior cifrado de sesiones son
transparentes para los usuarios.

2.4 Introducción a las VPN
Una red privada virtual (Virtual Private Network) es una red privada que se extiende,
mediante un proceso de encapsulación, y en su caso, de encriptación, de los paquetes de
datos a distintos puntos remotos mediante el uso de infraestructuras públicas de
transporte. Los paquetes de datos de la red privada viajan por medio de un "túnel"
definido en la red pública [4].

Para la creación de una VPN existen las siguientes opciones:
a)Soluciones de hardware
b)Soluciones basadas en firewall
c)Aplicaciones VPN por software.

El protocolo estándar de hecho es el IPSEC, pero también tenemos PPTP, L2TP,
SSL/TLS, SSH, etc. Cada uno con sus ventajas y desventajas en cuanto a seguridad,
facilidad, mantenimiento y tipos de clientes soportados.

En este trabajo nos centraremos únicamente a una de las opciones que existen para
realizar la implementación por software, específicamente con SSH. Otras opciones de
software que se tienen son el IPSEC que es quizás una de las más utilizadas actualmente,
también tenemos PPTP, L2TP, SSL/TLS.

En cuanto a las aplicaciones VPN por software son las más configurables y son ideales
cuando surgen problemas de interoperatividad. En cuanto a software de código abierto
(Open Source) se tienen OpenSSH, OpenVPN y FreeS/Wan, es precisamente el primero
el que se utilizo en este trabajo.

Una VPN debe cumplir con las siguientes características: Autenticación, Integridad y
Confidencialidad.

Autenticación hará posible saber quien se encuentra al otro lado de la conexión y que
nivel de acceso debe tener, o en su defecto que no le sea permitido ningún acceso
La integridad asegurara que los datos enviados no han sido alterados.
En cuanto a la confidencialidad, se puede decir, que debido a que los datos viajan a través
de Internet el cual es un canal totalmente público, estos son susceptibles de ser
interceptados, es a través del cifrado, con lo que se asegura que aunque los datos sean
interceptados estos no podrán ser interpretados por nadie más que no sea el receptor o el
emisor.

En cuanto a los escenarios en los que se implementará y será usada una VPN podemos
citar los siguientes tres:
VPN de acceso remoto
Este es quizás el modelo más usado actualmente y consiste en usuarios o proveedores que
se conectan con la empresa desde sitios remotos como puede ser desde su hogar, o desde
cualquier lugar en donde tengan una conexión a Internet ya que este es el vínculo de
acceso. Una vez autenticados tienen un nivel de acceso muy similar al que tienen en la
red local de la empresa.

VPN sitio-a-sitio
Este esquema se utiliza para conectar oficinas remotas con la sede central de
organización. El equipo central vpn, que posee un vinculo a Internet permanente, acepta
las conexiones vía Internet provenientes de los sitios y establece el "túnel" vpn.

VPN Interna
Finalmente este esquema que presentamos es el menos difundido pero uno de los más
poderosos para utilizar dentro de la empresa. Es una variante del tipo "acceso remoto"
pero, en vez de utilizar Internet como medio de conexión, emplea la misma red Lan (Red
de área local) de la empresa. Sirve para aislar zonas y servicios de la red Lan interna.

Es precisamente este último esquema el que se reporta en el presente trabajo, realizando
una implementación de una VPN interna.


2.5 Introducción Tunneling

Internet se construyó desde un principio como un medio inseguro. Muchos de los
protocolos utilizados hoy en día para transferir datos de una máquina a otra a través de la
red carecen de algún tipo de encriptación o medio de seguridad que evite que nuestras
comunicaciones puedan ser interceptadas y espiadas. HTTP, FTP, POP3 y otros muchos
protocolos ampliamente usados, utilizan comunicaciones que viajan en claro a través de
la red. Esto supone un grave problema, en todas aquellas situaciones en las que queremos
transferir entre máquinas información sensible, como pueda ser una cuenta de usuario
(nombre de usuario y contraseña), y no tengamos un control absoluto sobre la red, a fin
de evitar que alguien pueda interceptar nuestra comunicación por medio de la técnica del
hombre en el medio (man in the middle), como es el caso de la Red de redes.

2.5.1 ¿Qué es el tunneling?

El problema de los protocolos que envían sus datos en claro, es decir, sin cifrarlos, es que
cualquier persona que tenga acceso físico a la red en la que se sitúan nuestras máquinas
puede ver dichos datos. Es tan simple como utilizar un sniffer, que básicamente, es una
herramienta que pone nuestra tarjeta de red en modo promiscuo (modo en el que las
tarjetas de red operan aceptando todos los paquetes que circulan por la red a la que se
conectan, sean o no para esa tarjeta). De este modo, alguien que conecte su máquina a
una red y arranque un sniffer recibirá y podrá analizar por tanto todos los paquetes que
circulen por dicha red. Si alguno de esos paquetes pertenece a un protocolo que envía sus
comunicaciones en claro, y contiene información sensible, dicha información se verá
comprometida. Si por contra, ciframos nuestras comunicaciones con un sistema que
permita entenderse sólo a las dos máquinas que queremos sean partícipes de la
comunicación, cualquiera que intercepte desde una tercera máquina nuestros paquetes, no
podrá hacer nada con ellos, al no poder desciframos los datos.


Una forma de evitar el problema, sin dejar por ello de utilizar todos aquellos protocolos
que carezcan de medios de encriptación, es usar una útil técnica llamada tunneling.
Básicamente, esta técnica consiste en abrir conexiones entre dos máquinas por medio de
un protocolo seguro, como puede ser SSH (Secure SHell), a través de las cuales
realizaremos las transferencias inseguras, que pasarán de este modo a ser seguras. De esta
analogía viene el nombre de la técnica, siendo la conexión segura (en este caso de ssh) el
túnel por el cual enviamos nuestros datos para que nadie más aparte de los interlocutores
que se sitúan a cada extremo del túnel, pueda ver dichos datos. Ni que decir tiene, que
este tipo de técnica requiere de forma imprescindible que tengamos una cuenta de acceso
seguro en la máquina con la que nos queremos comunicar.


3. Configuración de la Red y el Gateway.

En el gateway es donde ubicaremos el script en el que se especificaran las políticas de
seguridad implementadas en el firewall, antes de iniciar a explicar las políticas,
describiremos brevemente la configuración de las interfaces de red y la manera en que
activaremos la opción de forward que será necesaria para repartir el Internet entre las dos
redes militarizadas.

De las direcciones ip no válidas para diseñar redes privadas o cualquier intranet se tienen
10.*.*.*, 172.16.*.* a 172.31.*.* y 192.168.*.*.[1] En este ejemplo se utilizaran del
rango 10.*.*.*.

En el gateway se tienen tres dispositivos de red, como se vio en la sección anterior.

La primera tarjeta se configura en el archivo:

/etc/sysconfig/network-scripts/ifcfg-eth0

Y su contenido será el siguiente:

DEVICE=eth0

BOOTPROTO=static
BROADCAST=10.10.10.255
IPADDR=10.10.10.1
NETMASK=255.255.255.0
NETWORK=10.10.10.0
ONBOOT=yes

La configuración para el dispositivo eth1 que es la segunda tarjeta en el gateway estará en
el archivo:

/etc/sysconfig/network-scripts/ifcfg-eth1


Siendo el siguiente su contenido:

DEVICE=eth1
BOOTPROTO=static
BROADCAST=10.2.1.255
IPADDR=10.2.1.1
NETMASK=255.255.255.0
NETWORK=10.2.1.0
ONBOOT=yes


Y para la tercera tarjeta de red el archivo de configuración se encontrara en el archivo:

/etc/sysconfig/network-scripts/ifcfg-eth2

Con las siguientes líneas de contenido:

DEVICE=eth2
ONBOOT=yes
BOOTPROTO=dhcp

El IP forwarding se habilitara editando el archivo:

/etc/sysctl.conf

Este archivo debe quedar como se muestra a continuación:

net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.ip_always.defrag=1

Para que los cambios sean aplicados reiniciaremos el demonio network con el comando:
/etc/rc.d/init.d/network restart

En este punto ya se tiene configurado el firewall.

El script que especifica las políticas de iptables es mostrado en la sección número cinco.





4. Instalación y configuración del software

El software necesario para realizar este trabajo esta incluido en la distribución Red Hat 9,
es decir Iptables y SSH.

4.1. Iptables

Iptables es la principal herramienta de cortafuegos para Linux, en las series del núcleo
2.4, es iptables, la cual reemplaza a ipchains de las series 2.2 e ipfwadm de las series 2.0.

Con los últimos núcleos 2.4.x, Iptables y gran parte de su funcionalidad ya se encuentra
disponible, sin embargo a continuación se explica como asegurarse de que se encuentre
instalado y que hacer en el caso contrario.

Primeramente tenemos que asegurarnos de tener instalado el Iptables, lo podemos hacer
de las dos formas que a continuación se presentan:

rpm -q iptables

Si la respuesta es algo como iptables-1.xxx, eso nos indicara que se si encuentra instalado
el Iptables. Cuando no se tiene instalado rpm contestara con el siguiente mensaje:
package iptables is not installed.

La otra manera es simplemente teclear el comando iptables sin ningún parámetro:

iptables

Si la salida es la siguiente, quiere decir que si se tiene instalado el Iptables.

Iptables vxxxa: no command specified
Try 'iptables -h' or 'iptables --help' for more information

De no estar instalado tendremos que instalar el iptables, para realizar esto en la siguiente
dirección podemos descargar la última versión:

http://www.netfilter.org/downloads.html.

Una vez que descargamos el archivo el cual tendrá un nombre como iptables-1.*.*.tar.bz2

Desde una consola de Linux, accedemos al directorio en el cual descargamos el paquete.
Descomprimimos el archivo de modo que quede ubicado en el directorio /usr/src con el
siguiente comando:

tar -xvjf ./iptables-1.*.*.tar.bz2 -C /usr/src

Ahora nos cambiamos al directorio creado el cuál será con mucha seguridad algo como
iptables-1.*.*, utilizamos el siguiente comando:

cd /usr/src/iptables-1.*.*

Proseguimos de la manera normal, primero con make:

make

Y finalmente con make install:

make install

Para asegurarnos ya ha sido instalado el Iptables podemos utilizar alguna de las dos
formas citadas arriba.

4.2 OpenSSH

Por otro lado SSH se encuentra en la misma distribución linux RedHat 9.0 gracias a
OpenSSH, la versión es la 2, pero también soporta la versión 1. La página oficial es
OpenSSH es:

www.openssh.org

De igual forma que con iptables primero nos aseguraremos de que se encuentre instalado
el OpenSSH y si esto no fuese así se explicaran los pasos de instalación.

Para probar si ssh se encuentra instalado podemos proceder de igual forma que con
iptables, consultando a rpm, mediante el siguiente comando

rpm ­q openssh

Si la respuesta es openssh.xx.xx, donde las x indican la versión del paquete nos asegura
que se tiene instalado en caso contrario rpm enviara el mensaje package openssh is not
installed.

Otra forma es levantar el demonio sshd esto se hace con los comandos siguientes:

cd /etc/rc.d/init.d
./sshd restart

Simplemente si el archivo sshd no existe, quiere decir que no se tiene instalado el
openssh, de otra manera el demonio será levantado.

Para el caso en el que no se tiene instalado OpenSSH, procederemos a descargarlo de su
sitio oficial.

Una vez que descargamos el paquete realizamos los siguientes pasos:

tar xvfz openssh-x.x.xpx.tar.gz
cd openssh-x.x.xpx

Una vez que estamos dentro de la carpeta tecleamos el comando configure

./configure

./configure realizará la verificación de que disponemos de un entorno válido para la
compilación de OpenSSH y nos informará si falta alguna dependencia o biblioteca de
soporte.

Si el proceso finaliza sin ningún error, podemos empezar la compilación del programa:

$ make

Finalizada la compilación sin errores disponemos de una copia personalizada de
OpenSSH lista para su instalación, realizando los siguientes pasos:

make install

Finalizando el make install, tendremos nuestro servidor SSH funcionando, para probarlo
nos aseguraremos que el demonio sshd se encuentre levantado, para asegurarnos
procedemos como se describió anteriormente y lo paramos y lo levantamos en un solo
paso:

cd /etc/rc.d/init.d
./sshd restart

Ahora podemos probar haciendo un telnet al puerto 22, que es el puerto por defecto para
el servicio SSH.

telnet localhost 22

Si obtenemos el siguiente resultado, nos indicara que el SSH ha sido instalado
correctamente.

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_x.x.xpx



5. Configuración del Firewall.

El script que se creo para ejecutar las políticas de iptables se muestra a continuación de
manera completa, posteriormente es explicado a detalle:

#!/bin/sh
# Se limpian las reglas
iptables -F
iptables -X
iptables -Z
iptables -t nat -F

# Se establecen las reglas por defecto
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

#Se establece lo que de entrada puede ser aceptado
iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -i eth2 -s 10.2.1.0/24 -j ACCEPT
iptables -A INPUT -i eth2 -s 10.10.10.0/24 -j ACCEPT

iptables -A INPUT -s 10.2.1.0/24 -i eth1 -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -i eth0 -j ACCEPT

#se establece que se dejara salir
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -o eth2 -d 10.2.1.0/24 -j ACCEPT
iptables -A OUTPUT -o eth2 -d 10.10.10.0/24 -j ACCEPT

iptables -A OUTPUT -s 10.2.1.0/24 -o eth1 -j ACCEPT
iptables -A OUTPUT -s 10.10.10.0/24 -o eth0 -j ACCEPT


iptables -A FORWARD -m state --state NEW,ESTABLISHED -i eth1 -o eth2 -j
ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -i eth2 -s !
10.2.1.0/24 -j ACCEPT

iptables -A FORWARD -m state --state NEW,ESTABLISHED -i eth0 -o eth2 -j
ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -i eth2 -s !
10.10.10.0/24 -j ACCEPT
#A través del enmascaramiento todo lo que salga de las redes militarizadas
#a internet, saldra enmascarado con la direccion ip de la interface eth2

iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

iptables -A FORWARD -i eth2 -m state --state NEW,INVALID -j REJECT

#Se le permite al usuario de la computadora 10.10.10.3 acceder a ssh,
#con lo que podrá realizar tunneling. Solo ese usuario!
iptables -A FORWARD -s 10.2.1.3 -d 10.10.10.3 -p tcp --sport 22 -j ACCEPT
iptables -A FORWARD -s 10.10.10.3 -d 10.2.1.3 -p tcp --dport 22 -j ACCEPT

iptables -A FORWARD -s 10.2.1.3 -d 10.10.10.3 -p tcp --sport 80 -j ACCEPT
iptables -A FORWARD -s 10.10.10.3 -d 10.2.1.3 -p tcp --dport 80 -j ACCEPT

iptables -A FORWARD -s 10.2.1.3 -d 10.10.10.3 -p tcp --sport 443 -j ACCEPT
iptables -A FORWARD -s 10.10.10.3 -d 10.2.1.3 -p tcp --dport 443 -j ACCEPT



Para implementar un firewall hay dos maneras [2]:

Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall se
acepta y solo se denegará lo que se diga explícitamente.
Política por defecto DENEGAR: todo esta denegado, y solo se permitirá pasar por el
firewall lo que se diga explícitamente.

El script que se implemento para nuestro firewall, esta hecho siguiendo el inciso b),
estableciendo las tres políticas INPUT, OUTPUT y FORWARD en DROP, que significa
denegar.

Para los paquetes que van para la computadora en donde se encuentra el firewall, se
aplican las reglas INPUT y OUTPUT, y para filtrar paquetes que van a otras redes o
maquinas se aplican simplemente reglas del tipo FORWARD. Otra regla que utilizamos
para nuestro firewall es una del tipo NAT, la cual se usa para realizar redirecciones de
puertos o cambios de ip de origen y de destino [2].

A continuación se explican las líneas que componen el script del firewall:

Para empezar se borran las políticas que pudiesen existir actualmente utilizando:

iptables -F
iptables -X
iptables -Z
iptables -t nat ­F



Se establecen las políticas por defecto, que como comentamos anteriormente se realizara
denegando todo, para después hacer explicito lo que permitiremos pasar a través del
firewall. Esto se realiza poniendo las tres políticas en DROP.

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP



Las políticas de entrada son las siguientes y se explican a continuación:

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -i eth2 -s 10.2.1.0/24 -j ACCEPT
iptables -A INPUT -i eth2 -s 10.10.10.0/24 -j ACCEPT

iptables -A INPUT -s 10.2.1.0/24 -i eth1 -j ACCEPT
iptables -A INPUT -s 10.10.10.0/24 -i eth0 -j ACCEPT



Primero se permite todo lo que venga hacia la dirección de loopbak, es decir la dirección
local de la computadora, la siguiente línea hablita todo el tráfico de entrada hacia el
dispositivo eth2 que venga únicamente desde cualquiera de las dos redes militarizadas,
que es el que tendrá el acceso a Internet.

Y por ultimo se permite acceso a todos los posibles usuarios de las redes militarizadas a
sus interfaces de red que corresponden a su dispositivo de puerta de enlace. Es decir la
red 10.2.1.0/24 su puerta de enlace esta en eth1 y de la red 10.10.10.0/24 su puerta de
enlace es la dirección en el dispositivo eth0.



Lo que se dejará salir a través del firewall es lo siguiente:

iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -o eth2 -d 10.2.1.0/24 -j ACCEPT
iptables -A OUTPUT -o eth2 -d 10.10.10.0/24 -j ACCEPT

iptables -A OUTPUT -s 10.2.1.0/24 -o eth1 -j ACCEPT
iptables -A OUTPUT -s 10.10.10.0/24 -o eth0 -j ACCEPT

Con lo anterior permitimos todos los paquetes internos de nuestras dos redes
militarizadas salir a Internet por medio de eth2.

Y se establece que es aceptado el tráfico de salida que se genere entre los usuarios de una
red militarizada y su dispositivo de puerta de enlace, esto se hace para las dos redes
militarizadas.




Ahora se permite que desde los dos dispositivos del gateway que conectan
respectivamente a cada una de las redes militarizadas puedan salir a través de eth2
cuando son conexiones nuevas o ya previamente establecidas.

iptables -A FORWARD -m state --state NEW,ESTABLISHED -i eth1 -o eth2 -j
ACCEPT
iptables -A FORWARD -m state --state NEW,ESTABLISHED -i eth0 -o eth2 -j
ACCEPT

Permitimos que los paquetes asociados con esas conexiones establecidas puedan entran
de regreso.

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -i eth2 -s !
10.2.1.0/24 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -i eth2 -s !
10.10.10.0/24 -j ACCEPT



Aqui se permite el enmascaramiento.

iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE



Para permitirle a un usuario en especial, que en este caso es el de la computadora
10.10.10.3 el acceso al servidor SSH se realiza con las siguientes reglas:

iptables -A FORWARD -s 10.2.1.3 -d 10.10.10.3 -p tcp --sport 22 -j ACCEPT
iptables -A FORWARD -s 10.10.10.3 -d 10.2.1.3 -p tcp --dport 22 -j ACCEPT

En la primera línea se permite que todo lo que vaya del servidor a la computadora del
cliente a través del puerto 22 sea aceptado. Y en la segunda esto es aplicado a la inversa.

Por ultimo se hace lo mismo para los puertos 80 y 443 que corresponden a los servicios
de http y httpd.

6. Configuración el servidor SSH

El servidor SSH estará listo para utilizarse ya que en la mayoría de las distribuciones de
Linux viene instalado. Básicamente lo que se configurara es el acceso para autentificarse
mediante llave pública rsa del usuario, lo que evitara que se tenga que introducir la
contraseña cada vez que se haga un acceso ssh.

Una vez instalado el paquete es necesario comprobar que en /etc/ssh/sshd_config del
servidor están las siguientes líneas:

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

En el lado del cliente, es decir en la computadora 10.10.10.3 se debe generar una llave,
que debe ser de tipo rsa. Se hará uso de la herramienta ssh-keygen.

Con el siguiente comando generamos el par de llaves del usuario en la computadora
cliente:


ssh-keygen -t rsa

El programa pedirá que se introduzca el lugar en el que se almacenarán las claves (la
pública y la privada), que por defecto se ubicarán en \$HOME/.ssh/id_rsa. En el
momento en que el programa pida la introducción de la frase de paso, esta se dejará vacía
tecleamos enter, y se confía la identidad a los archivos que se acaban de crear.

Una vez acabado este paso, se debe enviar la clave pública al servidor SSH, o de manera
más segura la podemos transportar utilizando algún dispositivo de almacenamiento, la
llave pública sera $HOME/.ssh/id_rsa.pub.

Desde este momento, se podrá autentificar desde la computadora cliente simplemente
con:

ssh 10.2.1.3

Llegados a este punto ya es posible crear túneles vpn al servidor 10.2.1.3 en la red
militarizada, recordando que únicamente se podrán realizar desde la computadora
10.10.10.3. En la siguiente sección se muestran algunos ejemplos y su explicación.


7. Creando tunneling utilizando SSH.

Teniendo el Gateway levantado y configurado con las políticas de seguridad, dentro de
estas reglas se tiene permitido que una maquina de la red de usuarios tenga acceso a
realizar túneles seguros al servidor de SSH.

Existen varias formas de realizar túneles seguros, y depende del sistema operativo ( por
ejemplo Windows , Linux, etc ) que se utilice, para cada unos de ellos existen paquetes
amigables para realizar el tunel, por mencionar un ejemplo en los sistemas operativos
Windows se puede utilizar el paquete SSH Secure File Transfer Client o SSH Secure
Shell Client.

En este trabajo, se utilizo el sistema operativo Linux por el lado del cliente utilizando el
comando SSH para realizar el túnel seguro. Antes de mostrar los comando utilizados para
realizar el túnel seguro con el servidor SSH , se ilustra la sintaxis del comando SSH.

Sintaxis:

ssh [-a] [-c idea|blowfish|des|3des|arcfour|none] [-e esc] [-i identity_file] [-l login_name]
[-n] [-k] [-V] [-o] [-p port] [-q] [-P] [-t] [-v] [-x] [-X] [-C] [-g] [-L port:host:hostport] [-R
port:host:hostport] hostname [command]




A continuación se describen brevemente las principales opciones del comando ssh.


-a
Deshabilita el agente de autenticación
-c
idea|des|3des|.. Selecciona el algoritmo de cifrado utilizado para cifrar la sesión.
.
Habilita el carácter de escape para una determinada sesión
-e
(default:~).
-i identity-file Selecciona el archivo donde leerán la llave de autenticación. Por
default
utiliza .ssh/identity dentro del home del usuario.
Especifica la cuenta remota por medio de la cual se desea tener
-l login-name acceso.
-p port
Puerto remoto de conexión.
Causa que todas las advertencias y mensajes de diagnostico sean
-q
suprimidos, solo los mensajes de errores fatales son desplegados.
Causa que ssh despliegue mensajes de depuración acerca del
-v
proceso de
conexión.
-x
Deshabilita el reenvió (forwarding) de X11.
-C
Compresión de todos los datos transmitidos durante la conexión



Ejemplos:

# ssh -l micuenta maquina.remota

En este ejemplo utilizamos la opción -l para proporcionar el login con el que tendremos
acceso a la máquina remota. En este caso la cuenta es micuenta y la máquina es
maquina.remota.


# ssh [email protected]

También podemos hacer uso del formato descrito arriba para entrar a una cuenta dentro
de una máquina remota.



# ssh maquina.remota

En caso de poseer el mismo nombre de cuenta en ambas máquinas (local y remota) es
posible tener acceso a la máquina remota proporcionando solamente el nombre de la
máquina.

En la sección numero seis de este trabajo se explico la manera de autentificar los accesos
ssh mediante llaves rsa. Con lo que se evita tener que teclear el password cada vez que
uno se conecte al servidor ssh.

Ejemplos de tunneling implementados como pruebas en el presente trabajo.

Para realizar el túnel en nuestro trabajo, se utilizo el comando ssh desde la plataforma
Linux, la instrucción utilizada fue la siguiente:

ssh -L 9000:10.2.1.3:80 [email protected]

ssh -L PuertoEnganche:DirecciónMaquinaServidoraSSH:PuertoDestinoAConectar
Usurario@DireccionMaquinaServidoraSSH

PuertoEnganche: se especifica el el puerto donde que enganchara a nuestra maquina
cliente.

DirecciónMaquinaServidoraSSH : Dirección IP del Servidor SSH en el cual nos
conectaremos.

PuertoDestinoAConectar: Numero de Puerto que Deseamos conectarnos remotamente.

Usuario: Cuenta de Usuario por la cual nos conectaremos.

Una Vez realizado el túnel nosotros nos podemos conectar al puerto destino a través del
puerto local de enganche que asignamos en el comando y esto lo podemos realizar a
través de un navegador Web. Para Nuestro trabajo Utilizamos el Mozilla de Linux y solo
bastó con poner la dirección:


http://localhost:9000

Con esto nos enganchamos al puerto remoto que solicitamos la conexión segura.




Bibliografía

[1] L. de la Fraga. "Como levantar un gateway con Linux RedHat". Cinvestav-IPN

[2] P. Altadill. "IPTABLES Manual práctico". UPV-EHU. 2003. www.pello.info

[3] L. de la Fraga. "Redes seguras usando el sistema GNU/Linux". Cinvestav-IPN

[4] D. Ferrer. "VPN: una introducción a las Redes Privadas Virtuales".
http://www.kriptopolis.com/more.php?id=P178_0_1_0

[4] www.iptables.org

[5] www.openssh.org